Portable ROM dumper

Started by a1ex, January 25, 2016, 09:29:53 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

a1ex

This is a small program that saves the contents of your camera's ROM contents on the card.
It won't modify your camera - at least, not intentionally :)

This is *NO* Magic Lantern build

Latest download: autoexec.bin (2020Aug17, updated for EOS R/RP/90D/250D - only after enabling bootflag via UART)

DIGIC 4+:  1300D  2000D  4000D
DIGIC 6:  5D4  750D  760D  80D
DIGIC 7:  200D  6D2  77D  800D
DIGIC 8:  EOSR EOSRP 250D 90D M6 II G7X III M50  SX70  SX740
Master/Slave:  5DS  5DSR  7D2 7D
Oldies:  1000D  30D  400D  40D  450D  5D

- built from c019793 with CONFIG_BOOT_FULLFAT=y CONFIG_BOOT_DUMPER=y CONFIG_BOOT_SROM_DUMPER=y
- green = confirmed working (either the last version, or a slightly older one)
- blue = not tested, but likely to work (based on other similar models, or on previous tests)
- purple = not tested, there may be surprises, but fixable (based on previous tests)
- orange = not tested, but unlikely to work (based on previous failures)
- red = not working, no idea how to fix

Supported cameras:
- tested in QEMU: 5D, 5D2, 5D3, 5D4, 6D, 6D2, 7D, 7D2, 40D, 50D, 60D, 70D, 77D, 80D, 400D, 450D, 500D, 550D, 600D, 650D, 700D, 750D, 760D, 800D, 100D, 200D, 1000D, 1100D, 1200D, 1300D, EOSM, EOSM2, M50, SX70.
- other models from the same generation may work, too (see the FIR list for models not yet running ML).

Not supported:
- cameras running PowerShot firmware (including EOS M3, M5, M6, M10, M100)

Requirements:
- a memory card formatted as FAT12/16/32 (exFAT won't work)
- for autoexec.bin: boot flag enabled in the camera (e.g. ML already installed) + bootable card (EOSCard, MacBoot, make_bootable.sh, QEMU image)
- FIR versions do not require any boot flags (just place on the card and run Firmware Update)
- check MD5 checksums after dumping (important!)

Source code:
- recovery branch
- compiled from platform/portable.000 with CONFIG_BOOT_FULLFAT=y, CONFIG_BOOT_DUMPER=y and CONFIG_BOOT_SROM_DUMPER=y




Old limitations (for 2018 and earlier dumpers only):

Quote

Requirements:
- a very small SD card or filesystem (important!)
- no important files on the card (these routines are buggy and may destroy the filesystem!!!)
- boot flag enabled in the camera (e.g. ML already installed) + bootable card (EOSCard, MacBoot, make_bootable.sh, QEMU image)
- alternative: FIR version does not require any boot flags
- check MD5 checksums after dumping (important!)

Formatting a larger card at a much lower capacity (e.g. 256MB) does the trick. For example, you can write the SD image that comes with QEMU to your SD or CF card (follow this guide). This image contains the portable display test and is bootable (so, you can test it in the camera straight away).





Original post:

Lately I've got a few softbricked cameras to diagnose, and struggled a bit with the ROM dumper from bootloader: it wasn't quite reliable. A while ago, g3gg0 reimplemented it with low-level routines (which worked on his camera, but not on mine). Today I looked again at the old approach, and it looks like the file I/O routines from bootloader had to be called from RAM, not from ROM.

So, I've updated the code and need some testing. I've emulated this in QEMU, but the results may be different on real hardware.

What you have to do:

- download autoexec.bin
- place it on a card without any important data on it (it might corrupt the filesystem if anything goes wrong)
- the display looks roughly like this: http://www.magiclantern.fm/forum/index.php?topic=14732
- after it's finished, look on the card, and you will find 4 files: ROM[01].BIN and ROM[01].MD5.
- you don't have to upload them, just check the MD5 checksum:
  - Windows: you may use http://www.winmd5.com/
  - Mac, Linux: md5sum -c *.MD5
- repeat the test on the same card (let it overwrite the files), then on a card with different size (and maybe different filesystem).

Some cameras have only ROM1 connected, so dumping ROM0 will give just random noise. In this case, the ROM0 checksum may not match, but that's OK.

The ROM dumper should recognize all ML-enabled cameras, except for 5D2, 50D and 500D. These old models do not appear to have file writing routines in the bootloader (or, at least I could not find them). The QEMU simulation works even on exotic models like 1200D or EOS M2.

So, you don't have to upload any files or screenshots. Simply verify the MD5 checksums on your PC (if in doubt, paste the md5sum output).

That's it, thanks for testing.

nikfreak

Both 100D.100B and 70D.111A get stuck at "Dumping ROM0...". No LED activity neither any sign of placing / writing files to sdcard on both cams.
[size=8pt]70D.112 & 100D.101[/size]

Walter Schulz

650D
Magic Lantern Rescue
----------------------------
- Model ID: 0x301 650D
- Boot flags: FIR=0 BOOT=-1 Ram=-1 UPD=-1
- ROMBASEADDR: oxFF0C0000
- Dumping ROM0...


... and doing nothing else. No LED activity, no file.

7D: Pretty much the same. Different strings for Model ID and ROMBASEADDR of course.

mk11174

700D works and gives Files, But ROM1.MD5 checksum changes each time, ROM0.MD5 stays the same.

I used winmd5free, I ran 1 test, got the checksum from ROM0.MD5 and copy and pasted it in the Original text box, then ran test again and loaded new ROM0.MD5 and checksum was same as first.

Did same steps for ROM1.MD5, but checksum was differ.

Did I even do it correctly or were you wanting something else?
500D/T1i  550D/T2i  600D/T3i  700D/T5i

a1ex

On 700D, ROM0 does not appear to be connected, so you are interested only in ROM1.

So, in the Browse dialog, you select ROM1.BIN, and check if the number in the "Current file MD5 checksum value" box is the same as the one from ROM1.MD5. However, I already know, from the user with the bricked 700D, that it doesn't work well on this camera :(

Any 600D user can try it?

mk11174

Yeah, no same  :(

Only can try with 1 card though, don't have any extra cards at this time.  :-[
500D/T1i  550D/T2i  600D/T3i  700D/T5i

mk11174

600D

Model ID: 0x286 600D
Boot flags: FIR=0 BOOT=-1 RAM=-1 UPD=-1
ROMBASEADDR: 0XFF010000
Dumping ROM0...

nothing on card no led
500D/T1i  550D/T2i  600D/T3i  700D/T5i

a1ex

Made some updates. Can you try again on 600D, 650D and 700D?

I don't expect it to work on 7D, but who knows.

edit: it's much slower this time (5-10 minutes per file), and there's no LED activity

Walter Schulz

7d hangs after line "- Dumping ROM 0. . .".

650D does simply fly through "-Dumping ROM 0. . .". Much too fast, about 20 seconds between ROM and MD5 line.
Hangs after ROM 1 message. MD5 file seems to be corrupted. Windows wants to check the card, other files seems to be out of order, too.

Boys, take warning about card corruption seriously!

DeafEyeJedi

Quote from: Walter Schulz on March 05, 2016, 11:24:27 AM
7d hangs after line "- Dumping ROM 0. . .".

I can also confirm this as well for the 7D.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

a1ex

I managed to get correct ROM dumps on 5D3 on an 8GB card that was previously failing (filesystem corruption). It's still not perfect, the first file saved ends up corrupted, but seems to be a small step forward.

The issue: Canon's bootloader routines for file I/O copy the data to some cacheable (!) memory; when that buffer reaches 0x4000 bytes, it's written to card using DMA. However, patching Canon code to use an uncacheable memory pointer didn't help.

Before, I was disabling data and instruction caches, and I could get correct dumps on an old 256MB (yes, MB) card.

Today I've tried to disable the write buffer (SCTLR bit 3), but that didn't seem to help. What helped was disabling the cache and write buffer in the memory regions that are set up at camera startup (see http://magiclantern.wikia.com/wiki/Memory_map ):

static inline void disable_all_caches()
{
    asm(
        "mrc p15, 0, r0, c1, c0, 0\n"   /* read SCTLR */
        "bic r0, #0x4\n"                /* disable data and unified caches */
        "bic r0, #0x8\n"                /* disable write buffer */
        "bic r0, #0x1000\n"             /* disable instruction cache */
        "mcr p15, 0, r0, c1, c0, 0\n"   /* write back SCTLR */
        "mov r0, #0\n"
        "mcr p15, 0, r0, c2, c0, 0\n"   /* disable data cache on all memory regions */
        "mcr p15, 0, r0, c2, c0, 1\n"   /* disable instruction cache on all memory regions */
        "mcr p15, 0, r0, c3, c0, 0\n"   /* disable write buffer on all memory regions */
        : : : "r0"
    );
}


Still, the first file is always saved with incorrect checksum on the 8GB card. To work around this, I dump the two ROMs twice => 4 files. First has incorrect checksum, next 3 are fine, and the behavior is very consistent.

All 4 files end up correct on the 256MB card.

I've updated the autoexec.bin from the first post, and I'd like you to try it on all ML-enabled cameras, except 7D.

Walter Schulz



Used a 1 GB card formatted with cam.
EOScard with "classic" ML.
Replaced autoexec.bin.
Inserted into cam and - after a while - done.

Anything else to test on 650D? Other card sizes, file systems?

a1ex

Yes, on the card, from a Linux or Mac shell, run this command: md5sum -c *.MD5

For Windows, cygwin might have the equivalent command, otherwise you may have to use a GUI.

Walter Schulz

Or commandline (Powershell 4.0)

PS H:\> get-filehash ROM*.BIN -Algorithm MD5

Algorithm       Hash
---------       ----
MD5             D5929B7A5AD99F511FC83D7D0B48B85F
MD5             A1C1204A28D2453F11374C8690CB0C35
MD5             D5929B7A5AD99F511FC83D7D0B48B85F
MD5             A1C1204A28D2453F11374C8690CB0C35


EDIT: BTW, is it intended to use lowercase for first bin and uppercase for the rest?

rom0a.bin
ROM1A.BIN
ROM0B.BIN
ROM1B.BIN

a1ex

Looks like it finally worked, right?

The case difference is not intended. Maybe it has to do with the corruption I'm experiencing for the first file?

nikfreak

canon released a bunch of firmware updates recently. Any plans on updating the portable dumper so it works for all cameras?
[size=8pt]70D.112 & 100D.101[/size]

a1ex

Quote from: a1ex on November 01, 2016, 08:38:20 PM

[...]

Testing portable ROM dumper...
   5D: skipping
  5D2: skipping
  5D3: ROM0.BIN: OK ROM1.BIN: OK
  5D4: ROM1.BIN: OK
   6D: ROM0.BIN: OK ROM1.BIN: OK
   7D: ROMs not saved
7D2M: ROM1.BIN: OK
  40D: skipping
  50D: skipping
  60D: ROM0.BIN: OK ROM1.BIN: OK
  70D: ROM0.BIN: OK ROM1.BIN: OK
  80D: ROM1.BIN: OK
400D: skipping
450D: skipping
500D: skipping
550D: ROM0.BIN: OK ROM1.BIN: OK
600D: ROM0.BIN: OK ROM1.BIN: OK
650D: ROM0.BIN: OK ROM1.BIN: OK
700D: ROM0.BIN: OK ROM1.BIN: OK
750D: ROM1.BIN: OK
760D: ROM1.BIN: OK
100D: ROM0.BIN: OK ROM1.BIN: OK
1000D: skipping
1100D: ROM0.BIN: OK ROM1.BIN: OK
1200D: ROM0.BIN: OK ROM1.BIN: OK
EOSM: ROM0.BIN: OK ROM1.BIN: OK

[...]


nikfreak

Can you post a dumper for 7D1 please?
[size=8pt]70D.112 & 100D.101[/size]

DeafEyeJedi

Quote from: nikfreak on December 08, 2016, 12:03:05 PM
Can you post a dumper for 7D1 please?

+1 as this should open some doors for newer firmwares that were released by Canon recently.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

nikfreak

Quote from: nikfreak on December 08, 2016, 12:03:05 PM
Can you post a dumper for 7D1 please?

or maybe update the portable binary to save the 7D ROM?
[size=8pt]70D.112 & 100D.101[/size]

a1ex

I don't have one ready; the portable codebase probably requires some sort of IPC communication.

Understanding it could be useful for other things as well (QEMU, 7D2, running code on master without FIR).

On 7D, I don't even know how to blink the LED from bootloader context (source), but can be found out from the dm-spy branch (binary search to find out where the LED starts to blink with the usual register commands, to see what Canon code does).

If you have enough patience, g3gg0 committed some QR code experiments on the portable codebase. Might be useful.

dfort

Used the portable dumper to get a 700D.115 ROM1.BIN. Would this be the first step to porting a firmware update?

Notes: An exfat formatted card didn't work and neither did an old 8GB card but a fairly new 32GB SanDisk Extreme PRO worked--the second time I tried it. The first time it only saved the ROM0B.MD5 file. Interesting that the card was renamed to EOS_DEVELOP.

dfort

Got my hands on a 7D and the first thing I tried was to get a dump of the latest 2.0.6 firmware just to see if some of the stubs that I'm not finding porting 2.0.3 to the crop_rec_4k branch. Yeah, that's a long shot. Of course I hit the wall with the Portable ROM dumper. I also tried the DUMP1300.FIR and dumperM2.fir, another long shot that didn't work. Is there any way to dump the 7D ROM? There must be but maybe the original porting notes are long forgotten? I couldn't dig up anything in previous forum posts.

dfort

Just an interesting observation. On the 7D the portable ROM dumper works fine in QEMU but not on the camera!



Of course to run QEMU you need a ROM dump. That's a Catch 22.

nikfreak

check also my requests above.
You'll be amazed that adtg_gui makes problems, too.
For the moment I'd rather focus on getting dual_iso as well as lossless compression to work (instead of adding support for 2.0.6)
[size=8pt]70D.112 & 100D.101[/size]