Canon 7D Mark II

[JagoUK]

Just found the portable binary test for rom layout checking. Posting here for completeness.

[a1ex]

Maybe also worth mentioning that g3gg0's 5DS experiments are probably valid for 7D2 as well. At least the boot trick should be similar, if not identical.

@JagoUK: does it help if you write the 256MB image to the SD card? The dumper definitely works in QEMU and was confirmed to work on most other DIGIC 6 and 7 models, with the card formatted as 256MB. That detail is important, as Canon's bootloader FIO routines don't seem to like large cards.

Code: [Select]

   7D2M: SD: ROM1.BIN: OK

If you want to use CF card for ROM dumping, just replace DRIVE_SD with DRIVE_CF on the recovery branch, then compile from platform/portable.000 with CONFIG_BOOT_DUMPER=y .

[JagoUK]

Yes I used the SD.img.xz. Still did not dump.

I don’t have a CF card reader and connecting camera only allows upload of .FIR files to CF card, won’t allow autoexec.bin

Here is what happens when you run your old fir file from CF card.

Just to clarify, i’d rather use SD card as I can read that. CF card was just testing because I found one.

[JagoUK]

Ok i've tried compiling the portable dumper and getting this error.

Code: [Select]

Using /usr/bin/arm-none-eabi-gcc (from PATH).
../../src/Makefile.src:362: target 'isspace.o' given more than once in the same rule
Makefile:21: warning: overriding recipe for target 'magiclantern'
../../src/Makefile.src:197: warning: ignoring old recipe for target 'magiclantern'
[ VERSION  ]   ../../platform/portable.000/version.bin
Not building magiclantern.bin
[ CC       ]   reboot.o
reboot.c: In function 'print_line':
reboot.c:292:20: warning: assignment to 'char *' from 'long unsigned int' makes pointer from integer without a cast [-Wint-conversion]
         log_buffer = (uintptr_t) log_buffer_alloc | caching_bit;
                    ^
/tmp/ccVvWJ7V.s: Assembler messages:
/tmp/ccVvWJ7V.s:34: Error: invalid offset, value too big (0x00000BF0)
make: *** [../../Makefile.filerules:21: reboot.o] Error 1


[a1ex]

Got a similar message with gcc-arm-none-eabi-7-2017-q4-major (different offset), but works fine with gcc-arm-none-eabi-5_4-2016q3 and gcc-arm-none-eabi-6-2017-q2-update. It seems to be from the "loaded_as_thumb" block. Fix pushed.

Here's what I did to diagnose the error:

Code: [Select]

# compile only, but don't assemble yet (to see how that temporary file looks like)
~/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc [blah blah, copied from "make V=1"] -S ../../src/reboot.c -o reboot.s

# now assemble it to see where exactly the error is
~/gcc-arm-none-eabi-7-2017-q4-major/bin/arm-none-eabi-gcc -c reboot.s
reboot.s: Assembler messages:
reboot.s:34: Error: invalid offset, value too big (0x00000664)

# reboot.s near line 34:
.code 16
loaded_as_thumb:
LDR R0, =1                 <--- this is line 34
LDR R1, _cstart_addr
BX R1
NOP
_cstart_addr:
.word cstart

With "MOV R0, #1" instead of "LDR R0, =1" -> Error: cannot honor width suffix -- `mov R0,#1'.

With "MOVS R0, #1" it worked, here's why.

[JagoUK]

Thanks.
It compiled despite errors.
Seems to be doing the same thing stuck on "Dumping ROM1..."
I'll leave it another 10 minutes.

[a1ex]

Alright, so this route is likely not an easy one. Let's try what worked on 5DS (blindly, assuming their bootloaders are similar). Apply this patch on top of the digic6-dumper branch:

Code: [Select]

diff -r b2e0efa1d090 platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -22,3 +22,2 @@
 ML_MINIMAL_OBJ  = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
 endif
diff -r b2e0efa1d090 src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -52,2 +52,10 @@
 
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+  while ( !(MEM(0xD0034020) & 0x10) );
+  MEM(0xD0034014) = value;
+}
+#endif
+
 void
@@ -96,2 +104,6 @@
 
+    #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+    set_S_TX_DATA(0x20040);
+    #endif
+
     // We enter after the signature, avoiding the
diff -r b2e0efa1d090 src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -13,4 +13,18 @@
 
+static void led_blink(int times, int delay_on, int delay_off)
+{
+    for (int i = 0; i < times; i++)
+    {
+        MEM(CARD_LED_ADDRESS) = LEDON;
+        msleep(delay_on);
+        MEM(CARD_LED_ADDRESS) = LEDOFF;
+        msleep(delay_off);
+    }
+}
+
 static void DUMP_ASM dump_task()
 {
+    /* LED blinking test */
+    led_blink(5, 500, 500);
+
 #if 0
@@ -32,6 +46,2 @@
 #endif
-
-    /* save a diagnostic log */
-    log_finish();
-    call("dumpf");
 }
@@ -41,3 +51,2 @@
 {
-    log_start();
 }

This disables the code parts for which we don't have the stubs defined yet, and enables a simple LED blinker on top of the main firmware (tested in QEMU). If that works, you'll be pretty much at the same stage as 80D after finding the missing stubs.

If that doesn't work, we'll need a good copy of the bootloader...

[JagoUK]

Cheers.
I'm getting a 404 when trying to clone the branch atm so will have to try later.

[JagoUK]

Alright, so this route is likely not an easy one. Let's try what worked on 5DS (blindly, assuming their bootloaders are similar). Apply this patch on top of the digic6-dumper branch:

Code: [Select]

diff -r b2e0efa1d090 platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -22,3 +22,2 @@
 ML_MINIMAL_OBJ  = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
 endif
diff -r b2e0efa1d090 src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -52,2 +52,10 @@
 
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+  while ( !(MEM(0xD0034020) & 0x10) );
+  MEM(0xD0034014) = value;
+}
+#endif
+
 void
@@ -96,2 +104,6 @@
 
+    #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+    set_S_TX_DATA(0x20040);
+    #endif
+
     // We enter after the signature, avoiding the
diff -r b2e0efa1d090 src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -13,4 +13,18 @@
 
+static void led_blink(int times, int delay_on, int delay_off)
+{
+    for (int i = 0; i < times; i++)
+    {
+        MEM(CARD_LED_ADDRESS) = LEDON;
+        msleep(delay_on);
+        MEM(CARD_LED_ADDRESS) = LEDOFF;
+        msleep(delay_off);
+    }
+}
+
 static void DUMP_ASM dump_task()
 {
+    /* LED blinking test */
+    led_blink(5, 500, 500);
+
 #if 0
@@ -32,6 +46,2 @@
 #endif
-
-    /* save a diagnostic log */
-    log_finish();
-    call("dumpf");
 }
@@ -41,3 +51,2 @@
 {
-    log_start();
 }

This disables the code parts for which we don't have the stubs defined yet, and enables a simple LED blinker on top of the main firmware (tested in QEMU). If that works, you'll be pretty much at the same stage as 80D after finding the missing stubs.

If that doesn't work, we'll need a good copy of the bootloader...

Hi Alex, I applied the patch and loaded the SD card, when I powered on I got 4 solid blinks.

[a1ex]

Was each blink 0.5 seconds on and 0.5 seconds off? If in doubt, change the delay to some larger values.

Were these blinks in background, while Canon's own firmware was running? Were you able to take pictures after the blinks?

If yes, try to take a picture with call("Release") at the end of dump_task. Otherwise, there's some double-checking to be done, but for that I need to know the full outcome of that patch (not just whether it blinked or not).

[JagoUK]

Was each blink 0.5 seconds on and 0.5 seconds off? If in doubt, change the delay to some larger values.

Were these blinks in background, while Canon's own firmware was running? Were you able to take pictures after the blinks?

If yes, try to take a picture with call("Release") at the end of dump_task. Otherwise, there's some double-checking to be done, but for that I need to know the full outcome of that patch (not just whether it blinked or not).

After switching on, card read then 4 blinks.

Sorry unsure what you mean by take a picture with call (“Release”) at the end of dump_task?


Ah I take it you are referring to this?

On all EOS models we have tried (including DIGIC 7), we can execute custom code. The question is - can we do anything useful with it?

On DIGIC 7, for example, we don't even know how to blink a LED (so our code does not have any visible side effects - we only know it runs because it locks up the camera).

On all DIGIC 6 models we have tried, we can display things on the screen from bootloader. Canon firmware is not running in this case, but it's useful to find out stuff about the hardware (find out what CPU it has, dump the ROM and so on).

On some DIGIC 6 models (including 80D), we can execute this code alongside Canon firmware (for example, by starting DryOS tasks). This is a huge progress (compared to bootloader stage) and you can already start tweaking various functions in Canon firmware. You cannot print things on screen yet, but you can blink the LED and save files on the SD card.

Right now, you can compile from the digic6-dumper branch and experiment. You can run these experiments either on camera, or - with some major limitations - in QEMU. I don't have any DIGIC 6 cameras (sorry, the GAS is over), so please don't wait for me - start experimenting on your own. The codebase is ready for other developers to jump in and start porting. The emulator is also in pretty good shape these days.

Tip: 5DS experiments are also available, and useful as documentation.

Whetting your appetite: put this in dump_task:

Code: [Select]

msleep(5000);
call("Release");

Don't try that with EraseSectorOfRom or other functions you don't know what they do


BTW - if anyone skilled in ARM assembly is reading - this will be very helpful for understanding how DIGIC 6 works. Code won't run out of the box, but can be debugged in QEMU first.

[JagoUK]

Well I finally finished.
I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway 

I have managed to dump the ROM1.
33,554,432 bytes
MD5 = 3179c1504591b28c1a01ec50c1927b03  ROM1.BIN.
Dumped successfully all 3 times and only took one minute too!




I think there is a bit of garbage data at the beginning and end so parameters may have to be changed.


Disp_Dump works too.

[JagoUK]

I tried to get the serial flash stubs dump but I don’t even think the code is there for it?

[a1ex]

That's rather our autodetection not recognizing the code patterns from 7D2 bootloader. Pretty sure this camera has a serial flash (otherwise there wouldn't be a SROM menu). The code is meant to be generic, for all DIGIC 6 models, but there may be some unhandled variations. It was tested on 80D, 750D (real hardware), 760D and 5D4 (QEMU), but I did not try it on 7D2 / 5DS yet.

[DENIX]

You guys can do it, despite the time I've noticed they've come a long way. Courage, you can achieve it. 

[tsengvane]

7D mk II is nice camera for 1080P 60fps
Watting magiclantern for 7D MK II

[a1ex]

I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway 

Reproduced the issue in QEMU - it crashes, hopefully because I didn't emulate the DIGIC 6 CF interface yet.

There is a string that suggests how drives are coded:
"select storage(1:SD 2:CF) :"

If you follow the code from there, SD is coded as 2 and CF is coded as 1 (they are reversed). In other words, the vanilla code (from the recovery branch) should dump to CF. Why did 0 even work?! I've noticed explicit checks whether drive_id is 2 in the bootloader...

Can you set boot_open_write to 0x102D10 and try to dump to CF (first argument 1) ?

That's pretty much a nitpick, as the dumper already worked on SD; I just wanted to understand why it locks up when using the CF card.

[Mech]

Hey guys!
We are all holding breath waiting for your success with ML for 7DMkII.

I have this camera, so if I can help somehow, please PM me.

[a1ex]

Updated ROM dumper, but got no way to test. Does it work?

Master/Slave: 7D2

And btw... did anyone try the patch from reply #406? I don't see any valid feedback for that patch, in subsequent replies. The patch no longer applies cleanly on the latest codebase, so here's an updated version:

Code: [Select]

diff -r 6bc1f65d50dc platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -21,5 +21,4 @@
 ML_SRC_PROFILE  = minimal
 ML_MINIMAL_OBJ  = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
 endif
 
diff -r 6bc1f65d50dc src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -51,4 +51,12 @@
 }
 
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+  while ( !(MEM(0xD0034020) & 0x10) );
+  MEM(0xD0034014) = value;
+}
+#endif
+
 void
 __attribute__((noreturn,noinline,naked))
@@ -95,4 +103,8 @@
     sync_caches();
 
+    #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+    set_S_TX_DATA(0x20040);
+    #endif
+
     // We enter after the signature, avoiding the
     // relocation jump that is at the head of the data
diff -r 6bc1f65d50dc src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -73,6 +73,6 @@
 
     /* save a diagnostic log */
-    log_finish();
-    call("dumpf");
+    //log_finish();
+    //call("dumpf");
 }
 
@@ -81,5 +81,5 @@
 {
 #ifdef LOG_EARLY_STARTUP
-    log_start();
+    //log_start();
 #endif
 }
@@ -89,5 +89,5 @@
 {
 #ifndef LOG_EARLY_STARTUP
-    log_start();
+    //log_start();
 #endif
 

[JagoUK]

Updated ROM dumper, but got no way to test. Does it work?

And btw... did anyone try the patch from reply #406? I don't see any valid feedback for that patch, in subsequent replies. The patch no longer applies cleanly on the latest codebase, so here's an updated version:

Code: [Select]

diff -r 6bc1f65d50dc platform/7D2.104/Makefile.platform.default
--- a/platform/7D2.104/Makefile.platform.default
+++ b/platform/7D2.104/Makefile.platform.default
@@ -21,5 +21,4 @@
 ML_SRC_PROFILE  = minimal
 ML_MINIMAL_OBJ  = minimal-d6.o
-ML_SRC_EXTRA_OBJS += log-d6.o stdio.o
 endif
 
diff -r 6bc1f65d50dc src/boot-d6.c
--- a/src/boot-d6.c
+++ b/src/boot-d6.c
@@ -51,4 +51,12 @@
 }
 
+#if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+static void set_S_TX_DATA(int value)
+{
+  while ( !(MEM(0xD0034020) & 0x10) );
+  MEM(0xD0034014) = value;
+}
+#endif
+
 void
 __attribute__((noreturn,noinline,naked))
@@ -95,4 +103,8 @@
     sync_caches();
 
+    #if defined(CONFIG_5DS) || defined(CONFIG_7D2)
+    set_S_TX_DATA(0x20040);
+    #endif
+
     // We enter after the signature, avoiding the
     // relocation jump that is at the head of the data
diff -r 6bc1f65d50dc src/minimal-d6.c
--- a/src/minimal-d6.c
+++ b/src/minimal-d6.c
@@ -73,6 +73,6 @@
 
     /* save a diagnostic log */
-    log_finish();
-    call("dumpf");
+    //log_finish();
+    //call("dumpf");
 }
 
@@ -81,5 +81,5 @@
 {
 #ifdef LOG_EARLY_STARTUP
-    log_start();
+    //log_start();
 #endif
 }
@@ -89,5 +89,5 @@
 {
 #ifndef LOG_EARLY_STARTUP
-    log_start();
+    //log_start();
 #endif
 

Spooky, just checked here after months and you just posted too!

Just to let you know I tried your new dumper and it does dump to a 2GB formatted SD card.

Unfortunately the MD5 changes each time (prob due to areas dumped)

[a1ex]

MD5 change is fine; Canon code is reflashing the main ROM at every camera shutdown. Card size is no longer an issue.

Does the patched startup code work?

[JagoUK]

I'm afraid I don't have an environment setup at the moment to compile the patched code.

When I used a larger memory card I got "Failed to mount partition, the format of the MBR was unrecognised". It was a 64GB card, I think FAT32 and not GPT.

[a1ex]

64GB card: pretty sure it wasn't FAT32.

Startup code: autoexec.bin. It requires firmware 1.0.4. I'm currently integrating the 5DS experiments into the digic6-dumper branch (i.e. for all Dual DIGIC 6 models).

Tested in QEMU. Does it work on real hardware?

[Mech]

Hey fellas,

If I can help you with anything I will be happy to do that.
I'm not a programmer, but I have 7DmkII and various flash drives CF and SD from 1Gb up to 64Gb

If it is safe for camera I might try something that you need...

[KenSoftTH]

I'm a first year computer engineering student and an owner of 7D2. I know how to code in C, and would like to help, but i'm not sure where to start. I read the guide already and have the environment setup, but when I run 7D2 firmware, I got gray screen in QEMU. Also, I can't make any sense out of the discussion including this guide https://t.co/jZqGIQXMMT . I think I need some guide to get me started.