A590IS porting...

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.

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.

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

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.

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

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 

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
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..

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.

Udumper (with newdryos) works fine.

i have no clues....

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.

  thanks whoever

edit: probably we should "reverse-code" his decode algorithm... i will give a try.