A590IS porting...

  • 948 Replies
  • 167940 Views
*

Offline ma_jk

  • **
  • 60
  • Publish
    A590IS porting...
    « on: 25 / September / 2008, 19:01:39 »
    Advertisements
    Hi.
    Im working on the a590 ver.100e, with much of the a720 as a basis. I managed to compile, correctly created a bootable SD via Cardtrcks, locked, but... the camera just ignores it! doesnt even seem to look at the card (2gb and 32 mb, same result).
    whats going wrong?

    another question: how do i figure out the various MEMISOSTART,MEMISOSIZE, etc?
    thanks in advance.
    « Last Edit: 18 / October / 2008, 09:55:13 by ma_jk »

    *

    Offline reyalp

    • ******
    • 9951
  • Publish
    Re: First boot: a failure!
    « Reply #1 on: 25 / September / 2008, 19:33:34 »
    If you are working off the latest trunk, MEMISOSIZE is automatic. In earlier versions, the actual size is reported at the end of the build, and you need to set MEMISOSIZE to be >= to that.

    MEMISOSTART needs to be after the end what the canon firmware loads starting 0x1900 and later. You find this by examining the disassembly.  This normally includes some data copied from ROM, followed by a large chunk of memory initialized to zero (i.e. initialized data and BSS for the firmware).

    For dryos, the number you are looking for should be in the first function at the start of ROM, after the "gaonisoy" string and the stuff that fiddles with CP15

    RESTARTSTART needs to be after where your CHDK is initially loaded ( i.e. >= 0x1900+ your memisosize.)

    Assuming the LED addresses have been found for the 590, you can light up an led early in the bootprocess to make sure your code is getting loaded at all.

    edit:
    Looks to me like copied ROM data ends at 0xDC48 and zeroed data ends at 0xA5304

    Note that the a720 sub/*/boot.c uses the equivalent of these values (canon_data_len, canon_bss_len), and has a whole bunch of addresses and ASM which you can't just copy.
    « Last Edit: 28 / September / 2008, 16:40:18 by reyalp »
    Don't forget what the H stands for.

    *

    Offline ma_jk

    • **
    • 60
  • Publish
    Re: First boot: a failure!
    « Reply #2 on: 28 / September / 2008, 14:49:05 »
    Looks to me like copied ROM data ends at 0xDC48 and zeroed data ends at 0xA5304

    Not that the a720 sub/*/boot.c uses the equivalent of these values (canon_data_len, canon_bss_len), and has a whole bunch of addresses and ASM which you can't just copy.

    Thanks reyalp. I did get those value from the disassembly after a lot of tampering. Should that be put in the wiki?

    Not that the a720 sub/*/boot.c uses the equivalent of these values (canon_data_len, canon_bss_len), and has a whole bunch of addresses and ASM which you can't just copy.
    Did that too, I just skipped (removing the call and not converting subroutines) the SDHC boot for the moment, since im using a 2GB card.

    Now compiling gcc quits saying
    \Temp/ccsHbaaa.s:337: Error: internal_relocation (type: OFFSET_IMM) not fixed up

    Probably a syntax error that i cant nail down :(

    *

    Offline reyalp

    • ******
    • 9951
  • Publish
    Re: First boot: a failure!
    « Reply #3 on: 28 / September / 2008, 16:10:02 »
    if you get GCC to save the .s, that may shed some light on the problem.

    There are a lot of google results for this message, but there appear to be multiple possible causes.
    Don't forget what the H stands for.


    *

    Offline ma_jk

    • **
    • 60
  • Publish
    Re: First boot: a failure!
    « Reply #4 on: 28 / September / 2008, 16:38:53 »

    it WAS a syntax problem [#C instead of #0xC  :-X ]

    everything seems to be in place, but once download in the card, the camera seems not to even look for it!
    reyalp, any advice? Ill probably go for the debug led  :(

    *

    Offline ma_jk

    • **
    • 60
  • Publish
    Re: First boot: a failure!
    « Reply #5 on: 29 / September / 2008, 18:45:34 »

    Im stuck. Compiling gives no error, but camera doesnt seem to like to boot from SD.
    The bootdisk.bin its rather big around 270kb.
    I cant even brick it, by putting
    Code: [Select]
    void boot() { //#fs
        long *canon_data_src = (void*)0xFFED0D74;
        long *canon_data_dst = (void*)0x1900;
        long canon_data_len = 0xDC48 - 0x1900; // data_end - data_start
        long *canon_bss_start = (void*)0xDC48; // just after data
        long canon_bss_len = 0xA5304 - 0xDC48;

        long i;


        asm volatile (
    > "loop:\n"
    > "b loop\n"
    "MRC     p15, 0, R0,c1,c0\n"
    "ORR     R0, R0, #0x1000\n"
    "ORR     R0, R0, #4\n"
    "ORR     R0, R0, #1\n"
    "MCR     p15, 0, R0,c1,c0\n"
        :::"r0");

    i need suggestions..

    *

    Offline reyalp

    • ******
    • 9951
  • Publish
    Re: First boot: a failure!
    « Reply #6 on: 29 / September / 2008, 19:42:34 »
    It sounds like your diskboot.bin isn't being loaded at all. This suggests a problem making a bootable card, rather than a problem with your build.

    Not sure what to suggest for that, except double checking that you've followed the correct steps for a dryos cam on the wiki.

    Have you successfully run udumper on your cam ? It also uses diskboot.bin, so if you got that to work, you know a diskboot.bin is getting loaded.

    270k is a reasonable size btw.
    Don't forget what the H stands for.

    *

    Offline ma_jk

    • **
    • 60
  • Publish
    Re: First boot: a failure!
    « Reply #7 on: 30 / September / 2008, 10:16:36 »
    Udumper (with newdryos) works fine.

    i have no clues....


    *

    Offline whoever

    • ****
    • 280
    • IXUS950
  • Publish
    Re: First boot: a failure!
    « Reply #8 on: 30 / September / 2008, 13:52:28 »
    Udumper (with newdryos) works fine.

    i have no clues....

    That's the clue. New DryOS "f/w upgrade" has to be encoded, even bootdisk.bin. The user by nick chr, and maybe he alone, knows how to encode.

    *

    Offline ma_jk

    • **
    • 60
  • Publish
    Re: First boot: a failure!
    « Reply #9 on: 30 / September / 2008, 14:49:09 »
     :o thanks whoever

    edit: probably we should "reverse-code" his decode algorithm... i will give a try.
    « Last Edit: 30 / September / 2008, 14:55:39 by ma_jk »

     

    Related Topics