This experiment made possible a much nicer error handling when ML is loaded on a different camera or firmware version. Rather than freezing and attempting to blink a LED, we can now turn on the display from bootloader and print a nice error message, explaining the user what's going on and what to do.
The easiest way to test this is if you have two cameras. Compile ML for camera A, put the card inside, and it should work just fine. Put the same card in camera B, and it should print a nice error message.
If you only have one camera, you can upgrade or downgrade your Canon firmware to a different version (links), and ML should display the error page. Upgrade your Canon firmware back to your original version, and ML should be up and running again.
@ reviewers: can you suggest some better messages for the error page?
Here's a binary that just displays the error page and nothing else: autoexec.bin
edit: 7D works as well, thanks g3gg0!
600D v1.0.2: works :)
Model detection error.
Your camera doesnt look like a 60D v1.1.1.
this branch won't compile, did you forget to add a file?:
make -C /Users/david/Code/magic-lantern/platform/60D.111
../../src/Makefile.src:335: ../../build_tools/Makefile: No such file or directory
make: *** No rule to make target `../../build_tools/Makefile'. Stop.
make: *** [60D] Error 2
ok it works now, thanks
question: some cameras have smaller MemSiz limits than others, so what happens if I take the 60D autoexec.bin which is 0x873d4 and try to load it on 1100D, which has issues with anything bigger than 0x8000? Does it not matter since we never leave the bootloader context? Is there any danger?
Correct, it doesn't matter. The bootloader code is discarded anyway once magiclantern.bin is copied at RESTARTART and the code jumps to it.
I've loaded several MB of bloat besides magiclantern.bin (much more than maximum autoexec.bin size) a while ago, to check other issues (like removing the card while autoexec.bin is still loading from the card).
Hm, I thought it was because of YUV layer, but it seems to be something else.
Can you send me a copy of the 1100D bootloader? (from FFFF0000 to FFFFFFFF).
Tested EOS-M version on 500D and the other way around. Both work as expected.
BUT running the EOS-M version in the 500D caused some kind of (temporary) screen burn in. After putting back in a 500D version I could still see (barely) the error text underneath magic lantern/canon gui. After about one to two minutes it seems to be gone completely. Maybe figuring out how to set the screen brightness would be good - or just using grey instead of pure white.
Could we make a list of camera signatures and use them to say something like 'this seems to be a EOS 3D with 4.5.6 firmware'?
Those screen burns appear every time you take the battery out without turning off the display properly. To get this effect from main firmware, you need to clear the interrupts (cli) while the display is on, so it no longer detects when you open the battery door, then remove the battery.
The display init routine is the one used by Canon to print "firmware update not found" and related messages. I think the screen burns appear from that message as well (will double-check).
We can identify the camera and firmware version, but I don't think it's worth the effort. This is just a nicer error handling routine, to avoid panicking the user (e.g. when he updates Canon firmware and then camera freezes, or when he attempts to install on a wrong firmware version). For diagnostics, we can use the "recovery" branch.
Ok. Let's not introduce more complexity then necessary.
In regards to the screen burn in - if canon displays their error this way its good to me.
Works on 70D.
First compiled for 70D and it booted fine. Afterwards compiled for 5D3.113. Immediately after inserting sdcard I got the "Model detection error. Your camera doesn't look like a 5D3 1.1.3...."
Not able to compile for 650D. Error message works on 650D. But text section "What you can do:" has a font size not that well suited to my eyes.