Please find a ROM dumper for the EOS/PowerShot M50. It took an entire week of trial and error to figure it out - thanks @71m363nd3r for testing!
D_M50101.FIR (only for M50 firmware 1.0.1)
Source code:
commit 568e05a.
This is not using the portable codebase, but runs directly from the main firmware, using the regular ML boot process. For this reason, it is only compatible with M50 firmware 1.0.1. On other firmwares, it will just lock up.
There were two mysterious bugs that were preventing ML from booting on the M50 on real hardware, although it was working fine in the emulator, and its early startup code was apparently identical to 200D's:
1) The FIR is running on both CPU cores (unlike DIGIC 7, but I need to double-check). The two cores do not start at the same time; the main one (CPU0) wakes up the secondary one (CPU1) somewhere in cstart. It was
easy to fix, but figuring it out with LED blinks was very puzzling.
2) The startup code, although nearly identical to 200D's, expected one of the cache maintenance functions to preserve R3 across the call (something not compatible with the C ABI). In our relocated startup code (that makes room for loading ML), I had to use a veneer to make a long call to that function. From all of the available registers, GCC picked exactly R3 to make that long call...
... and the side effect was disabling a loop that was zeroing out some memory. The trick is that, at camera startup, the RAM is not zeroed; you still have some electrical noise or maybe even some data from previous run. In the emulator, the RAM is always zeroed at startup. The result was that my test code was booting just fine in the emulator, but was locking up on real hardware. Good luck figuring out with binary feedback from the camera (i.e. works or locks up). I've solved it comparing the execution traces between the files reported to work (i.e. jumping to unmodified Canon firmware), and the ones reported to lock up (jumping to relocated Canon firmware); if anyone is curious, . I highly doubt I could have figured it out without an emulator.
This change fixed it.
Once the two quirks were fixed, the startup code previously written for 200D worked out of the box.
When dumping the ROM, there was yet another quirk: initial attempt (calling dump_file with a ROM address) saved a file with correct size, that contained garbage. Oddly enough, it had fragments from the diagnostic log. Best guess: the DMA channel used for file I/O might be simply unable to read from the ROM. Instead, it probably ignores the higher address bits and just saves something from the RAM (matching the lower address bits). I'm not sure whether this step was working on 200D - need to double-check. Anyway, fixing this was straightforward:
copying the ROM contents to RAM before saving did the trick.
Emulation is not ready yet; still working on it. I am able to emulate the bootloader (including file I/O), but main firmware doesn't initialize the SD card, so I'm unable to test Canon Basic scripts yet.
The same dumper source code works on 200D (I've actually used it to test the M50 dumper in QEMU, as file I/O isn't fully working), and - after finding a few stubs - on all the other DIGIC 7 models. If anyone is looking for some low-hanging fruit to get started with development, the new stubs are relatively easy to find and they can be tested in QEMU. Once you do that, I'll enable the boot flag, so you'll be able to run custom code on real hardware.
Dear Santa,
please give us the time and energy to port ML on these new cameras!
