The good old blind dumper appears to work in QEMU (should work on all D4 and D5 models with bootflag enabled, except 7D). Make sure you have a valid image on the card, then go to PLAY mode. Split the dump in two, like you did on M2.

ROM dumpers ready for 200D, 77D, 6D2 and 800D; will post the FIR versions in the DIGIC 7 thread.

These dumpers still require a very small card, but just formatting with a smaller filesystem will do the trick. The easiest way is (still) to write the QEMU SD image onto the card (howto).

The issue can be reproduced in QEMU on a large SD image (or by running from a physical card), so it's clearly not a caching issue. It can be reproduced from the FROMUTILITY menu, without loading AUTOXEC.BIN (proof of concept and details available on request). I believe are two different issues in Canon code: writing from cacheable memory (fixed on D7) and large card support (still present on D7).

The good old blind dumper appears to work in QEMU (should work on all D4 and D5 models with bootflag enabled, except 7D). Make sure you have a valid image on the card, then go to PLAY mode. Split the dump in two...

Updated with serial flash support for DIGIC 5 models (first post). Tested only in QEMU; please try and report back.

To check:- make sure the MD5 sums are correct for all files (including SFDATA.BIN if present)- make sure SFDATA.BIN looks like valid data (i.e. not full of zeros or full of FF or otherwise containing garbage - this condition is not covered by the checksums)

The reason I looked up this topic was to ask a question about the 7D. Would it be possible to dump the master? When I worked on the 2.0.6 firmware update I used the display based dumper and I'm fine with that but would like to know if it is possible and if so I need some guidance on what addresses to dump. Then to figure out how to disassemble it.

Hi.I have tried to find the issue of displaying Model Camera, Firmware version and IMG naming for models like 1300D. I extracted the following files into a directory and compiled with for offline running:

./prop_diag 1300D_ROM1.BINThe prop_diag.c file returns camera information, specifically: Camera Model, Firmware version and IMG naming. But that file can also run offline, in the sense that you give it a ROM file from which it tries to find the information above. If you run it through autoexec, then he tries to find the camera software information. If you run it offline, then he reads the given file as a parameter and tries to find that information.

To not compile portable.000 and run qemu, I chose to run it offline.Now that I can run offline, I can make changes to the software and try to see why that information is not available.

Yes, these offsets are changing at every camera startup, I think. There are a couple of property blocks with similar content, but only one of them is active (the one with the blue field 0000FFFF on most models; exception: M50, where the active block is marked with FFFFFFFF). Some of these property blocks are used by Canon for saving their settings (yes, they are reflashing the ROM at every shutdown), others appear to be fixed or possibly updated only on demand (e.g. calibration data or image capture configuration).

As I was cleaning up the M50/SX70 dumper source in order to publish it, I've noticed the same method could be used for all models, starting with the good old 5D. I ended up spending the entire weekend reworking this.

Previously, g3gg0 noticed the unreliability of Canon routines and tried to integrate a full-fledged FAT library (FullFAT), with some low-level SD driver written from scratch. For some reason, that low-level SD driver didn't work on my cameras, and since I wasn't able to understand its internals, I kept trying to debug the high-level Canon routines. Which worked, to some extent, on most of the models where they were present. On the M50/SX70, these routines were gone, so I had to find some other method.

Revisiting g3gg0's approach, I've noticed adapting it for M50, and then for all other EOS models, was just a matter of replacing his low-level routines (which are likely model-specific) with Canon's sector I/O routines (which are present in all EOS firmwares I've looked at, from DIGIC 2 to DIGIC 8 ). I did just that and tested the new dumper in QEMU:

In QEMU, I've checked all EOS models from the test suite on the 256MB image (FAT16) and on a 8GB (FAT32) image. The only issue I could find was with 500D on the large image; figure out why.

I didn't address caching issues yet (I just left them disabled), so the new dumper is not going to be very fast (at least not yet).

EXFAT is not supported.

Actually, the story begins somewhere around this, when I was trying to fix the emulation of various CPU info registers (i.e. sync the emulation with the logs posted by various users). As most of the CPU info logs were actually screenshots, I thought "OK, I'll get a plain-text log from the 5D3 real quick". I took the camera out of the bag, compiled the portable codebase, enabled the CPUINFO functionality, made some small changes to save all that info to a log file, tested it in QEMU as usual, then ran it on the camera it without thinking too much. It seemed to work, but afterwards... the card went unreadable (and the camera did not boot any more from it either). The worst part - this was the moment I realized that card contained all my holiday photos! (as they were not downloaded yet).

What happened? The QEMU image was a small 256MB one (which Canon's bootloader I/O routines have no trouble with), so my "offline" test worked fine. In the camera I had a 32GB card formatted as FAT32. Turns out, these I/O routines do not like large filesystems. At all.

After imaging the raw card contents, I ran the same code on a good filesystem, to see exactly what kind of damage it did. Nearly the entire partition table was zeroed out! Both copies of the FAT! Luckily, the data area was largely unaffected. Needless to say - I've spent the next few days grepping the filesystem and writing custom file recovery scripts, as testdisk/photorec didn't work. In the end, I was able to recover nearly everything.

Yes, all of this damage was done "just" by trying to save a small log file.

This was my motivation for getting rid of these Canon I/O routines once for all.

ROM0 MD5 not matching: expected, short answer in first post, will look up the long answer(s) later.

7D: that's actually big progress; IIRC it didn't even start. Now it was able to create a file, if I understand well.

Maybe it's some supervisor (MPU? second core?) that's turning off the camera after some inactive time. The 5D3 does that after several seconds if you run the dumper with battery door open. Guess: maybe the dumper just needs to be faster?

I've spent another couple of hours to track down caching issues. Updated autoexec.bin from previous post - is it still working? I've only tested on 5D3. Expecting it to be much faster.

Screen goes dark right away so I wasn't sure when it was finished. First time I didn't wait long enough but second time I just let it run for a couple minutes. Used a 512MB card. ROM0 md5 mismatch as expected but the dump looks good.

[EDIT] Checked 700D, EOSM and EOSM2 -- only the EOSM is showing a different md5 checksum on ROM0, the other cameras had perfect checksums.