Author Topic: Canon 7D Mark II  (Read 262423 times)

JagoUK

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #400 on: August 27, 2018, 03:01:07 AM »
Just found the portable binary test for rom layout checking. Posting here for completeness.




a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #401 on: August 27, 2018, 07:40:37 AM »
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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #402 on: August 27, 2018, 01:06:24 PM »
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.

https://youtu.be/PkcrWRHLGbA

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

JagoUK

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #403 on: August 27, 2018, 04:33:15 PM »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #404 on: August 27, 2018, 06:52:46 PM »
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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #405 on: August 27, 2018, 07:13:51 PM »
Thanks.
It compiled despite errors.
Seems to be doing the same thing stuck on "Dumping ROM1..."
I'll leave it another 10 minutes.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #406 on: August 27, 2018, 08:13:57 PM »
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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #407 on: August 27, 2018, 08:43:07 PM »
Cheers.
I'm getting a 404 when trying to clone the branch atm so will have to try later.

JagoUK

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #408 on: August 28, 2018, 09:32:46 PM »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #409 on: August 28, 2018, 09:44:10 PM »
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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #410 on: August 28, 2018, 09:54:01 PM »
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.
https://youtu.be/PkcrWRHLGbA

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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #411 on: August 29, 2018, 03:39:08 AM »
Well I finally finished.
I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway  :D

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

  • New to the forum
  • *
  • Posts: 33
Re: Canon 7D Mark II
« Reply #412 on: September 01, 2018, 06:56:44 PM »
I tried to get the serial flash stubs dump but I don’t even think the code is there for it?



a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #413 on: September 01, 2018, 07:12:52 PM »
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

  • New to the forum
  • *
  • Posts: 1
Re: Canon 7D Mark II
« Reply #414 on: October 03, 2018, 11:05:56 PM »
You guys can do it, despite the time I've noticed they've come a long way. Courage, you can achieve it.  :) :D

tsengvane

  • New to the forum
  • *
  • Posts: 2
Re: Canon 7D Mark II
« Reply #415 on: October 05, 2018, 12:22:12 AM »
7D mk II is nice camera for 1080P 60fps
Watting magiclantern for 7D MK II

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 11792
  • 5D Mark Free
Re: Canon 7D Mark II
« Reply #416 on: October 06, 2018, 10:18:16 PM »
I modified the portable display dumper to dump to CF card and it wrote to the SD card anyway  :D

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.