Hi, I was able to extract the LED addresss, I see something changing from 0x08 to 0x09 at 0xC022D1FC (green) and 0xC022D200 (AF).
Interesting, those are the 2 last entries in the GPIO table, but I don't see the corresponding indexes (0x61, 0x62) anywhere.
I put these addresses in the boot assembler (entry.s), but I still do not see a reaction.
I think my DISKBOOT.BIN is not recognized as a valid image? If I present a diskboot.bin with just 0x00 inside, The camera will hang also.
The diskboot file requires to be encoded with the appropriate "dancingbits" sequence, you used the value from stubs_entry.S (NEED_ENCODED_DISKBOOT = 12), so that's probably correct (but unverified).
Note that if you manage to start a diskboot and let the camera continue with the bootup sequence, you need to prevent starting the diskboot again, otherwise you'll stuck in a boot loop. So, to try the LEDs, you need to temporarily halt further code execution with an infinite loop.
If the encoding isn't right, the camera will try to execute "garbage" and usually hang.
Obviously I do something wrong with some very basic settings.
Up to now i just set up some stuff in my diskboot.bin and added some stubs.
How can I verify those very basic settings? Yet I do not understand several stuff like PLATFORMID. I hope I set them right, but I'm not sure.
PLATFORMID is required to produce a firmware update binary that the camera will accept. You don't need any EXMEM related definitions in makefile.inc at this point. Using stuff you find at the beginning of stubs_entry.S (below "Values for makefile.inc") should be OK (KEYSYS is d4f, but that only matters when using the firmware update boot method).
You can try poking the LED addresses from Canon Basic (I'm not sure whether it will work, it doesn't on DIGIC6) with the Poke32 command (registered by System.Create).
You can also try to make an unencoded binary and run it as a task like
this, but obviously you need to compile for armv5. The loading address is 0x60e000 on your cam (found in stubs_entry.S).
There probably is a "right way" of extracting the pure code from the resulting .elf file, I just used a hex editor to extract the right looking bytes.edit: the correct commands are:
arm-elf-gcc -Wl,-N,-Ttext,0x60e000 -nostdlib try1.s -o try1.elf
arm-elf-objcopy -O binary try1.elf try1.bin
You can then copy try1.bin to the card and use this Canon Basic script to start it:
private sub Initialize()
System.Create()
AdditionAgentRAM("A/try1.bin","something")
end subIf something isn't clear, please do ask.
