Everything starts in entry.S. First use a dumper tool to extract the firmware image from a canon firmware update file (see the build_scripts/eos_tools_v11 folder in that project linked above). Use decrypt_fw and then dissect_fw to split the FIR up. See this wiki page for more details:http://magiclantern.wikia.com/wiki/Packing_FIR_Files

After you analyze the firmware dump using a program like IDA Pro (or the free ARM Console created by Alex) to see how the camera boots/works, then attempt to boot a custom FIR file running user code. Use the assemble_fw perl script in the eos_tools directory to assemble a new FIR file with your usercode (compiled autoexec.bin) instead of canon's payload. The final step is to run decrypt_fw again on this fir to sign it for the camera to accept it. (Note: this step may or may not be necessary, depends on the camera. Try both if one doesn't work). Start by just blinking an LED or something basic to know your code runs. You don't need to boot the main firmware to blink an LED.

If 40d is similar to the 5dc, then you won't be able to run any practical code from a FIR (including calling the EnableBootDisk function or booting the firmware/camera) so you will need to write some code that scans the bootloader area (0xFFFF0000-0xFFFFFFFF) for function signatures to identify the read/write bootflag functions. This will allow you to set the camera's bootflag, to boot an autoexec.bin file with a prepared card, and development takes off from there (you will be able to boot the firmware and do anything from autoexec). I created this bootdisk code from the 350d method, using the 400d bootloader to find the signatures I needed. Only modification you will need is to change are the references to these:

The 5dc took me many hours to get going, I dumped many memory addresses through LED blinks in binary, you should be prepared to do the same. Here is some code that you can use to blink out the contents of a memory address if you know the red/blue LED addresses:https://bitbucket.org/coutts/5dplus/src/a1cc964de4af/init.c

You can use this to write code to search for specific signatures of the read_bootflag and write_bootflag functions. Some signatures would be instructions like:

Quote

MOVEQ R7, #0xF8000000

which is assembled and looks like this in memory:

Quote

0x03A0733E

Use the 5dc bootloader (I can send you it) to know what signatures you're looking for (unique instructions that would only appear in the read/write bootflag functions). After you find a signature and have a match at some spot in the BL area (0xFFFF0000-0xFFFFFFFF), use this address and search in reverse (going backwards in memory to lower addresses) until you find the nearest PUSH (STMFD) instruction, this will be the address of the start of the function so that you can call it / use it.

I'll just tell you the signatures to find.First, for write_bootflag. Here is a small snippet from that function, the first 5 instructions:

If you were scanning memory, these 5 instructions would look like this(starting at 0xFFFF89F0 on the left and ending on 0xFFFF8A00 on the right):

Quote

0xE92D41F0 0xE1A05001 0xE3A04000 0xE3500000 0x13A0733E

So, look for the signature for the MOVNE R7, #0xF8000000 instruction, then once you find it, search backwards for the STMFD (push) instruction signature, and you will have located write_bootflag in the 40d bootloader. Chances are the functions will probably be identical, but take caution to verify at least 3 times that you have located the correct function and it seems the same / similar to the 5dc one (remember we are working blind here).

And in memory would look like this (same thing as before, starting at 0xFFFF8AE0 on left and ending at 0xFFFF8AF0 on the right):

Quote

0xE52DE004 0xE3500000 0x3E33A013 0x12833A02 0x13A02040

Note: there isn't a STMFD (push) instruction in read_bootflag. The 400d bootloader is like this too, so chances are the 40d is as well.

NOTE: you may need to reverse endianness of the assembled instructions above to see them in memory, but maybe not, I can't remember

So, once you have located read_bootflag() and write_bootflag(), you will be able to really start developing. This may seem confusing, and I'm sorry, but I hope you will see how valuable this information is (I had to figure it all out on my own). The 350d people dumped the bootloader using a photo diode and the LED to blink the code in binary to a computer, I couldn't figure that out so I did it this way. Let me know if you have any questions, I can probably help a lot. Do you use gmail?

I'm thinking start doing the first tests.I know it's a bit risky. Certainly, I will need your help.Firstly, I will begin by installing and configuring ubuntu to compile the project. When I can, I will test the tools specified by Coutts.

I still have nothing to work but I have spent many hours reading the forums CHDK / ML. I'm learning, have some patience with me. This still seems very complicated. Sorry if the questions are basic.

I got the firmware version 40d1.1.1. With application dissect_fw3_2, I got the unencrypted header and body. I've compiled a small application to try to find the addresses of the red and blue LED, but I've got a problem. I do not know how to encrypt the new firmware to be able to use on my machine. I read a lot about it but I could not understand the steps that have to follow.

If I can correctly encrypt my firmware I can proceed with my tests.

Since I've been searching for some string in the firmware files and I could see some interesting things. I found the string EnableBootDisk.

After seeing the flashing LEDs, I'll try to do a DUMP the firmware. When I succeed in the previous tests, I proceed to the discovery of the function EnableBootDisk addresses.

yes I am currently reading your posts in CHDK.In 2008 there were major developments, but for some unknown reason you moved away from this project. Made great advances that have helped future ports to other cameras but 40D & 450D were forgotten! Why?! ...

Their progress in the port 1000D can give a great help! I think the cameras 1000D, 450D, 40D have many similarities. This can be an advantage.