Portable ROM dumper

[a1ex]

I tried DUMP_40D.FIR with 4 different CF cards, also old ones with 256 MB capacity, but it does not seem to work: the MD5 for ROM1.BIN is different each time (even if the check with PC always succeeds).
ROM0.MD5 is always the same though...

Already answered this one in the 40D thread (noticed this message afterwards).

That's probably alright - Canon firmware reflashes the ROM at every shutdown, to save their settings. If you compare the two ROMs, you will see differences only in the settings area (not in the executable code).

To get the same MD5 every time, you need to avoid starting the main Canon firmware between the two attempts (i.e. just run the dumper twice, possibly on different cards, without booting the camera normally in-between).

[chapan]

I tried running DMP2000D.FIR on my Canon EOS Rebel T7 and RESCUE.LOG shows this:

  Magic Lantern Rescue
 ----------------------------
 - Model ID: 0x432 2000D
 - Camera model: Canon EOS Rebel T7 / K432
 - Firmware version: 1.0.0 / 2.3.2 13(03)
 - IMG naming: 100CANON/IMG_0786.JPG
 - Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xFE0C0000
 - card_bootflags 1069ec
 - boot_read/write_sector 1071e0 1072d8
 - 101F70 Card init => 2
 - Dumping ROM0... 100%
 - MD5: 66354cabd287d45faae4c6158ba09606
 - Dumping ROM1... 100%
 - MD5: 65a90329df0b77b083a27a1f5583810f
 - No serial flash.
 - Saving RESCUE.LOG ...

But when I try to check the MD5 I get this:

root@craig-ubuntu:~# md5sum -c ROM0.BIN
md5sum: ROM0.BIN: no properly formatted MD5 checksum lines found
root@craig-ubuntu:~# md5sum -c ROM1.BIN
md5sum: ROM1.BIN: no properly formatted MD5 checksum lines found


I tried recreating the ROM files several times but the results are always the same.

[Walter Schulz]

Code: [Select]

md5sum ROM?.BIN -c ROM?.MD5

[chapan]

This is what I see for Canon EOS Rebel T7.

Magic Lantern Rescue
 ----------------------------
 - Model ID: 0x432 2000D
 - Camera model: Canon EOS Rebel T7 / K432
 - Firmware version: 1.0.0 / 2.3.2 13(03)
 - IMG naming: 100CANON/IMG_0786.JPG
 - Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xFE0C0000
 - card_bootflags 1069ec
 - boot_read/write_sector 1071e0 1072d8
 - 101F70 Card init => 2
 - Dumping ROM0... 100%
 - MD5: 66354cabd287d45faae4c6158ba09606
 - Dumping ROM1... 100%
 - MD5: 65a90329df0b77b083a27a1f5583810f
 - No serial flash.
 - Saving RESCUE.LOG ...


root@craig-ubuntu:~# ls -l ROM*
-rw-r--r-- 1 root root 33554432 Dec 31  1979 ROM0.BIN
-rw-r--r-- 1 root root       43 Dec 31  1979 ROM0.MD5
-rw-r--r-- 1 root root 33554432 Dec 31  1979 ROM1.BIN
-rw-r--r-- 1 root root       43 Dec 31  1979 ROM1.MD5

root@craig-ubuntu:~# md5sum -c ROM0.MD5
ROM0.BIN: FAILED
md5sum: WARNING: 1 computed checksum did NOT match
root@craig-ubuntu:~# md5sum -c ROM1.MD5
ROM1.BIN: OK

md5sum: ROM1.BIN: no properly formatted MD5 checksum lines found
ROM1.BIN: OK

Does that mean ROM1.BIN is the good firmware?




r

[chapan]

Dumping EOS Rebel T7 gives this:

- Model ID: 0x432 2000D
 - Camera model: Canon EOS Rebel T7 / K432
 - Firmware version: 1.0.0 / 2.3.2 13(03)
 - IMG naming: 100CANON/IMG_0786.JPG
 - Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xFE0C0000
 - card_bootflags 1069ec
 - boot_read/write_sector 1071e0 1072d8
 - 101F70 Card init => 2
 - Dumping ROM0... 100%
 - MD5: 66354cabd287d45faae4c6158ba09606
 - Dumping ROM1... 100%
 - MD5: 65a90329df0b77b083a27a1f5583810f
 - No serial flash.

-rw-r--r-- 1 root root 33554432 Aug 15 15:05 ROM0.BIN
-rw-r--r-- 1 root root 33554432 Aug 15 15:05 ROM1.BIN

The MD5 checksum for ROM1.BIN is good. If I run disassemble.pl I get this:

root@craig-ubuntu:/usr/local/qemu-eos/1500D# perl disassemble.pl 0xFE0C0000 ROM1.BIN
offset + filesize - 1 > 0xffffffff. We can't wrap around!

game over at disassemble.pl line 50.


Does that mean the ROM1.BIN file is too big? Is the ROMBASEADDR of 0xFE0C0000 from the RESCUE.LOG the correct address to use?

[names_are_hard]

Try this:
perl disassemble.pl 0xFE000000 ROM1.BIN

Magiclantern is a bit inconsistent about what "base address" means.  In some places it uses it to mean "entry point address", which is confusing.  0xFE000000 is the base address, ie, the address at which the first byte in the ROM is loaded into memory.  0xFE0C0000 is the entry point address, the address at which execution of the code starts.

[chapan]

That solved the disassemble problem for 1500D. 

Given what you said in your post, would these be correct parameters to use in hw/eos/model_list.c?

           .firmware_start         = 0xFE0C0000,
           .rom1_addr              = 0xFE000000,

And how would I know what to use for ram_size?

[names_are_hard]

I'd expect that to be right for firmware_start and rom1_addr.  I don't know the ram size for 1500D.  model_list.c has 256MB for 1300D, so I'd guess 1500D is either the same, or maybe 512MB since it's a later camera.

If you want, try:
.ram_size               = 0x10000000

and see if it makes your camera explode.  That's 256MB.  Try 0x20000000 for 512MB.  I don't know what the risk is if you get the ram size wrong.  Maybe the correct size is listed in some other thread.

[a1ex]

If you declare - in QEMU - a RAM size smaller than physical size, emulation will not run. The firmware will attempt to address memory outside the declared size (unmapped). In particular, the RscMgr task is going to initialize its data structures, covering pretty much the entire RAM.

If you declare a RAM size larger than physical size, nothing obvious will happen. There will be some memory that's never going to be addressed. The emulation will run just as well as if you would declare the correct size.

RAM size is not currently used in ML.

[Walter Schulz]

Got a new cam: 250D/Rebel SL3/Kiss X10/200D Mark II (seriously, Canon?) with firmware version 1.0.1.
Is there a ROM dumper for this DIGIC 8 cam?

[a1ex]

This model, alongside G7X III and 90D (maybe also M6 II), uses the same encryption as EOS R/RP, so the "state-of-art" way to dump the firmware is via UART (for now).

We actually made some progress figuring it out (thanks Indy), and it's likely that solving one of these will work for all others.

[DeafEyeJedi]

...(seriously, Canon?)...

Seriously that's just flabergasting to hear... Does it feel more like 200D Mark II than 250D?

[tanvir5971]

After formated the 64gb sdxc card as FAT32, i put the "DUMP800D.FIR" in the card. As per instructions i try to dum the ROM but error occured. i dont know how to insert picture here so link of the Screenshot is given below.

https://photos.app.goo.gl/NMa5juPu3ufbEWVQ7

[Walter Schulz]

Try using a smaller card or repartition to a much, much smaller size. Do not expect to make ExFAT work.

[Pangu]

I'd expect that to be right for firmware_start and rom1_addr.  I don't know the ram size for 1500D.  model_list.c has 256MB for 1300D, so I'd guess 1500D is either the same, or maybe 512MB since it's a later camera.

If you want, try:
.ram_size               = 0x10000000

and see if it makes your camera explode.  That's 256MB.  Try 0x20000000 for 512MB.  I don't know what the risk is if you get the ram size wrong.  Maybe the correct size is listed in some other thread.

Did this actually worked? I am looking forward for a fix. My dump gives exact same results. Thank you.

[ilia3101]

Code: [Select]

  Magic Lantern Rescue
 ----------------------------
 - Model ID: 0x382 5DS
 - Camera model: Canon EOS K331
 - Firmware version: 1.1.1 / 8.1.2 94(37)
 - IMG naming: 100?????/5DS_7425.JPG
 - User PS: ??? ??? ???
 - Boot flags: FIR=0 BOOT=-1 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xFE0A0000
 - card_bootflags 10c074
 - boot_read/write_sector 10c698 10c784
 - 102A08 Card init => 1
 - Dumping ROM1... 100%
 - MD5: 1c4033b9cf1a088f29280ba4284216a6
 - No serial flash.
 - Saving RESCUE.LOG ...

Code: [Select]

1c4033b9cf1a088f29280ba4284216a6  ROM1.BIN
Confirmed MD5:

Code: [Select]

MD5 (/Volumes/EOS_DIGITAL/ROM1.BIN) = 1c4033b9cf1a088f29280ba4284216a6

[monmond]

Hi, I'm newb here.
btw, I have 6D2 and this is the text on dumper screen

  Magic Lantern Rescue
 ----------------------------
 - Model ID: 0x406 6D2
 - Camera model: Canon EOS K406 / 6D Mark II
 - Firmware version: 1.0.4 / 6.4.5 71(3e)
 - IMG naming: 100CANON/IMG_6018.JPG
 - User PS: EOSHD C-LOG EOSHD VIVID SKINTONE EOSHD MONOCHROME
 - Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
 - ROMBASEADDR: 0xE0040000
 - boot_read/write_sector 106f59 107055
 - 1018F7 Card init => 2
 - Dumping ROM0... 100%
 - MD5: 36bfe44f2a0a9c028a4d1ce5e3f5ae16
 - Dumping ROM1... 100%
 - MD5: ef9966e6391c45cd235841132bd75480
 - No serial flash.
 - Saving RESCUE.LOG ...

via 4gb sd card.

[Walter Schulz]

250D not working yet.
Enabled bootflag via srsa's script and used latest autoexec.bin on a 128 GB ExFAT and 8 GByte FAT32 (Eye-Fi) card. Same result.

[yourboylloyd]

Can also confirm that it doesn't work on EOS R6.

Camera COMPLETELY locks up. No lights, no button presses change, nothing. Camera is completely unusable. Resets on battery pull. So Bootflag confirmed at least

[kitor]

Something tells me that display access may be completely different.

@a1ex, can you prepare one that logs only to file? Similar to what we initially attempted on R.

Camera COMPLETELY locks up. No lights, no button presses change, nothing. Camera is completely unusable. Resets on battery pull. So Bootflag confirmed at least

No reaction on buttons, etc is normal. Question is if you wait a few minutes in this state, is card access led activating / any new files made on SD card?
I doubt, if memory locations for display buffers are different, but there's a chance it's doing things silently

@Walter - this screenshot looks like it's there, same location but display buffers works differently (?) Or at least display resolution is detected wrong, as every next line seems to start at wrong position.

[a1ex]

The display issue is just a matter of fixing the resolution (in particular, the horizontal one). It's not auto-detected, but hardcoded, based on model ID.

The red thing is an error message - probably the dumper couldn't find suitable stubs for writing to card.

However, Canon Basic dumper appears to provide a complete ROM dump for now, so the portable ROM dumper is no longer essential. Just nice to have, as a proof of concept (portable code running on all cameras). I should be able to troubleshoot it in QEMU using the Canon Basic dumps - these include the bootloader, from what I've seen.

[Ant123]

I should be able to troubleshoot it in QEMU

Please don't forget to commit the QEMU branch to the repository.
The "Source code" link from the main page at this moment leads to the removed repisitory on bitbucket.org

[kitor]

However, Canon Basic dumper appears to provide a complete ROM dump for now, so the portable ROM dumper is no longer essential. Just nice to have, as a proof of concept (portable code running on all cameras).

Let me disagree with that, it's still a nice tool for broken camera diagnosis (as long as bootflag is enabled, but now it seems that we have a way to enable it on all current models)

Not to mention all the coverage that will hit the news if you'll post photo of R5 running ML Rescue

[coon]

250D not working yet.
Enabled bootflag via srsa's script and used latest autoexec.bin on a 128 GB ExFAT and 8 GByte FAT32 (Eye-Fi) card. Same result.

I had the same issue with the RP. See R / RP thread: https://www.magiclantern.fm/forum/index.php?topic=22770.msg230480#msg230480

Changing the resolution values for disp_xres and disp_yres in src/disp_direct.c to the proper value for the RP did fix the issue. However, I cannot find the difinitions for the 250D there!?

[Walter Schulz]

Let me disagree with that, it's still a nice tool for broken camera diagnosis

And I predict we will see that more often in the future. At the moment all those not-so-versed-in-coding-people get stuck when they try to make ML code run on unsupported firmware or trying to install ML on unsupported cams. We had a lot of "discussions" how to make it run anyway by gifted fellows (renaming the file for example ... hey, it will work: Checksum is identical! Hooray!).
Canon Basic Script however is plain text and word will get around. All safeguards implemented (if any) checking for proper firmware or camera type can be disabled with just a few characters (' -> You are a comment now). And here we go poking the hell out of a 1D X Mark III by using a script for M6 II!

I suggest a1ex to switch to billing per starting hour for those <censored> if there cams have to be reanimated.

It will happen. It will happen soon. It will happen quite often.