[UNBRICKED / HARDWARE] 70D Bricked "update file cannot be found"

[KimWexler]

Hello friends!

Originally had Magic Lantern Nightly.2016Apr23.70D111A installed. Never bothered upgrading because it worked fine and did everything I needed. Brother thought he would do me a favour and and install the 1.1.2 firmware or something (he's not clear on what he did).

Now, when I try to power on the camera with a non-ML card, freshly formatted card, or no card, it gives me this:

Firmware update program
Update file
cannot be found.
Please check the memory
card and reload
the battery and try again

When I use my original ML card, I get:

Model detection error.
Your camera doesn't look like a 70D 1.1.1

What you can do:
- Make sure you've got the right ML zip for your camera model.

- If in doubt, upgrade (or downgrade) your Canon firmware to 1.1.1 (again).

- To use your camera without Magic Lantern, format this card from your computer.

You may now remove your battery.

Both of these appear when I insert the battery. I tried reinstalling ML, but end up with the same issue. No access to menus, as far as I can tell. If I had the 1.1.1 firmware file, maybe that would work, but since that's the one that came installed on the 70D, there doesn't seem to be a .FIR file for it.

Any further suggestions?

[a1ex]

1) Use the portable ROM dumper to get a copy of your current firmware (just in case). You don't need to send it to me; just keep it safe. Please post just the log file saved by the dumper (RESCUE.LOG).

2) Place Canon's 1.1.2 firmware on a formatted card and record a video of the camera screen.

On previous models, updating Canon firmware was enough to clear this error, but I'm not 100% sure it's the same issue (I thought it was solved many years ago). That's why I'm asking you to run the ROM dumper first.

[KimWexler]

Thanks for the reply. Was away from the PC for a couple of days. Will need to cast about for a small enough SD card. Will reply when I've found one and done the ROM dumper thing.

[a1ex]

FYI, you can use large cards with some trickery:

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).

[KimWexler]

Okay, sorted out the card (re-formatted a larger one to a smaller size, as suggested). However, after following the instructions (copying the autoexec.bin over), and popping the battery in I still get the same "update file cannot be found" error, and no dumped ROM files. So possibly a different bricking than you were expecting?

[a1ex]

Card must be bootable (EOSCard, MacBoot, QEMU image, make_bootable.sh etc.)

[KimWexler]

Sure, but didn't my writing of the QEMU image as referenced at https://www.magiclantern.fm/forum/index.php?topic=16534.0  take care of that? Sorry if I've missed a step here...

EDIT: added missing link

[a1ex]

The QEMU image contains, out of the box, a small autoexec.bin. Does that work?

After writing the image to the card, you should be able to see that small autoexec in the file browser. Inserting the card in any ML-enabled camera should print some diagnostic info (without any special setup, as long as the boot flag was enabled in the camera, i.e. ML installed previously). That binary is compatible with all models from DIGIC 2 to 7.

When I use my original ML card, I get:
Model detection error.
Your camera doesn't look like a 70D 1.1.1
...

That means you have the boot flag enabled in the camera, but that card contains a ML version for the older firmware. In this case, if the ROM dumper did not work, that means the card was not prepared properly.

[nikfreak]

Use EOSCARD to make your card bootable. Afterwards extract this zip onto your card:
https://builds.magiclantern.fm/70D-112.html

Be happy with ML on 70D with firmware V1.1.2

[a1ex]

@nikfreak: the following *is* an issue and I'm trying to solve it:

Now, when I try to power on the camera with a non-ML card, freshly formatted card, or no card, it gives me this:

Firmware update program
Update file
cannot be found.
Please check the memory
card and reload
the battery and try again

Of course, the camera can be used with ML and firmware 1.1.2, but currently it doesn't boot with plain Canon firmware when used with a formatted card.

[KimWexler]

The QEMU image contains, out of the box, a small autoexec.bin. Does that work?

No, it doesn't.

BUT, tried the same process with a different card and dumped the ROM! Yay! Have preserved those files in a safe place. But no RESCUE.LOG file to be seen.

Formatting a card (and making it bootable using EOScard) and putting the firmware update on results in a quick message saying that firmware update is loading, and then nothing. See video: https://mega.nz/#!N0AmiSBI!9QOCh2MvJwwTSvclB58wFG1WcVBBOsudxuAdt-ug9PE

Doing the same with current ML firmware, as suggested by @nikfreak, results in a similar error, but in this case, the LED stays lit until the battery is removed: https://mega.nz/#!8gwnkYoa!oYXPUDWNwluCkN7X7H2B2ItKXaQxvR5T9fSD9oU8cYs

Suggestions as to what I'm messing up, or any next steps?

Thanks for your time on this. I'm in the Japan Standard timezone, by the way, which is one of the reasons it takes me so long to reply, so I appreciate your patience. (Both a1ex and nikfreak)

[a1ex]

This is very unusual.

"no RESCUE.LOG" -> if the MD5 files on the card are OK, please PM me the ROM files; otherwise we'll need to retry the ROM dumper. Bootloader file I/O routines are known to be buggy with large filesystems; maybe it's that.

"No, it doesn't." -> likely some issue when writing the card image. Mind showing a video of this process?

So far, the ROM dumper worked every single time from that SD image, but failed often with plain formatted cards.

"putting the firmware update on results in a quick message saying that firmware update is loading, and then nothing." -> guess: some unexpected ROM contents or MPU settings?! I should be able to reproduce it in QEMU.

"Doing the same with current ML firmware, as suggested by @nikfreak, results in a similar error, but in this case, the LED stays lit until the battery is removed:" -> guess: ROM checksum performed by ML at startup succeeds, then it attempts to boot main firmware to run the installer, but for some reason, it fails to boot. I should be able to find out why in QEMU.

Firmware update message visible -> Canon's bootloader color palette is alright.

[KimWexler]

PM sent.

[a1ex]

Reproduced the issue in QEMU; looking into it.

Minor issue: main firmware flag is disabled.

Major issue: after enabling it, the ROM starts to boot, but prints a lot of gibberish to the console.

Best guess (unconfirmed): battery removed during the firmware update?!

[KimWexler]

Reproduced the issue in QEMU; looking into it.

Minor issue: main firmware flag is disabled.

Major issue: after enabling it, the ROM starts to boot, but prints a lot of gibberish to the console.

Best guess (unconfirmed): battery removed during the firmware update?!

Hm. My brother said it had hung for 5+ minutes when was doing whatever he was doing (installing 1.1.2 firmware?). I imagine he probably pulled the battery at that point.

So, is there a next step, or am I borked?

[a1ex]

There is a fix, but it requires a manual reflash of a large part of the ROM. I'm pretty sure it was an incomplete update, and here's why.

vbindiff 70D/112/ROM1.BIN 70D/1120/ROM1.BIN # "1120" is your ROM (named that way to load it easily in QEMU)

Jump to 0xC0000 (absolute address 0xFF0C0000, i.e. where main firmware starts) and search for the next difference (ENTER). The first difference starts at offset 0042 0000: in your ROM, 0xFF all the way to 0044 0000 (not including that address). From that point, there are scattered small differences between the two ROMs, but these differences disappear when comparing with one of the two 1.1.1 ROMs. Last difference at 00DF 7DA0.

In other words:
0xFF000000 - 0xFF000003: main firmware flag disabled, easy to revert
0xFF000004 - 0xFF07FFFF: boot flags and other stuff; minor differences, looks OK to me
0xFF080000 - 0xFF0BFFFF: properties, minor differences, looks OK to me
0xFF0C0000 - 0xFF41FFFF: main firmware code, identical to firmware 1.1.2
0xFF420000 - 0xFF43FFFF: empty, 0xFF repeated (ROM was erased, but not programmed; firmware update was interrupted here)
0xFF440000 - 0xFFDFFFFF: main firmware code and other stuff; identical to firmware 1.1.1 from 2013 .09.25 13:56:21 (there are two 1.1.1 ROMs)
0xFFE00000 - 0xFFFFFFFF: bootloader and other stuff; same with both firmwares (no need to touch this range)

IIRC, the firmware update normally takes a couple of minutes to complete; progress bar stalling for 1-2 minutes is not unusual.

I wouldn't exclude a defective ROM chip, or a non-deterministic bug in the ROM reflashing routine or even on the hardware side (i.e. one of these things that happen once every 100000 test runs). I wouldn't exclude an accidental battery pull either (it happens pretty often here if I don't close the battery door well). One thing is clear: the firmware update was interrupted somehow in the middle of reflashing the main firmware.

After "reflashing" your ROM with this:

Code: [Select]

cp 70D/1120/*.BIN 70D/1121/
dd if=70D/112/ROM1.BIN of=70D/1121/ROM1.BIN bs=64K conv=notrunc skip=$((0x42)) seek=$((0x42)) count=$((0xE0 - 0x42))

it boots just fine in QEMU and shows the menus.

[KimWexler]

Thanks for taking that in-depth look. Yeah, battery pull sounds about right.

So, what is my course of action? Is a manual reflash something that can be done on the actual camera, rather than just in the emulator? If so, is it something I can manage myself? (Had a look through the forums for this answer; couldn't find anything. Probably don't know what search terms to use.)

[a1ex]

Yes, I'm going to implement the reflashing routine in the recovery tool, to run it on the camera; just need to take some precautions to avoid (God forbid!) erasing the bootloader by mistake. With such a function present in the binary, even a transfer error (such as incomplete autoexec, or the "right" bit flipped by a bad cell in the SD card) will have a small possibility to make things worse.

I've never reflashed a 70D, so I'm not aware of the quirks in Canon's flashing routine on this model. On the models I've tried (550D and 60D - just tests on my own cameras to make sure I'll be able to handle an emergency like this), their flashing routine from bootloader had an interesting bug: it did not write the last 4 bytes from the last block (but erased them); to work around it, I had to end the flashing procedure with something that ended in FF FF FF FF (that's what this flash will have after erasing it).

If anyone has a 70D that powers on, but it's otherwise unusable and it's not going to be repaired, I'd like to try the reflashing routine on that camera first.


Meanwhile, I've prepared another non-destructive test: updated the portable ROM dumper to also save the serial flash, to make sure its contents are alright before the "surgery".

[KimWexler]

Thanks again. (Public holiday yesterday in Japan, which is why my extremely slow reply) I'll try that test tomorrow when I'm home at my machine again.

[a1ex]

Serial flash looks OK, no need to change anything there.

I've managed to emulate the ROM reflashing process in QEMU, prepared the fix, added a couple of checksums and tested it a couple of times. Maybe it's best to have the code reviewed by another pair of eyes first, and we also need to sync on IRC or whatever for some real-time chat. Mornings are usually OK for me, e.g. tomorrow from 8 to 10 AM (same timezone as the server here, i.e. 04:39 PM at the time of posting).

[a1ex]

Some progress:

- reflashed the affected ROM area and double-checked that code sections (from FF0C0000 until the end of the ROM) are alright
- camera is alive, can navigate Canon menu etc
- can take pictures and use LiveView, but image is garbled (?!)
- could save diagnostic logs; no obvious errors
- re-running Canon's firmware update apparently completes, but jumps from ~45% to 99% very quickly (and doesn't solve the image garbling issues)

Hypothesis: the firmware update might notice the code area is already up to date (1.1.2) and skip some important steps.

Code: [Select]

      + tag  + foffset  +   size   + moffset
 ---------------------------------------------
 0x01: 0x0200 0x000000e0 0x000008b7 0x00000000
 0x02: 0x0200 0x00000998 0x00152dcf 0x00000000
 0x03: 0x0100 0x00153768 0x000d5784 0xf00c0000
 0x04: 0x0100 0x00228ef0 0x00071544 0xf8f40000
 0x05: 0x0100 0x0029a438 0x004741a4 0xf0240000
 0x06: 0x0100 0x0070e5e0 0x00000014 0x00000000
 0x07: 0x0100 0x0070e5f8 0x00d3a3dc 0xf80c0000
 0x08: 0x0105 0x014489d8 0x0000986e 0x00000000

Tag 0x100 is for main CPU (all of these blobs were applied correctly), tag 0x200 is for the MPU (not checked, but it appears to operate normally), tag 0x105 is unknown (possibly some FPGA). Best guess: the last item might require updating and Canon's firmware update might skip it.

Possible paths from here:
- investigate what exactly the firmware update does (whether it flashes the last blob, and what's up with it)
- force downgrading to 1.1.1, hoping Canon's firmware update can fix it from there

edit: downgraded to 1.1.1 by reflashing the code area only, then re-ran Canon's 1.1.2 update; photos still bad.