Messages

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.

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 Expand


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)

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

7Dmk2 (Dual digic 6) dumped


Had to tell it to dump to CF but it actually dumped to the SD.

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.

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 Expand


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.

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 Expand


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.

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

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

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

Code Select Expand

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


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.

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

7D mk2

Well I decided to pop back and check in after I found a CF card.

I've tested the portable binary display tester (Autoexec.bin) which now works




I've tested the portable rom dumper (May 2018) which now displays info but still doesn't dump
ROMBASEADD Cycles down to 0xFE0A0000




As for the CF card (Which is the primary card in the camera)
When I run DMPD-7D2.fir from the CF as opposed to the SD card I get a graphical glitch at the top of the screen like it is reading through data (Lasts about 30 seconds and wrapped around the screen)



If I can find a CF card reader i'll test the PRD on it given that it finds the ROMBASEADDR..

Useful bit of info for anyone else testing.

With the autoexec.bin files they will freeze on a pink screen (Even without turning power on) unless you do a specific sequence to load.

Open battery compartment.
Eject battery.
Open memory card compartment.
Remove memory card.
Reinsert memory card.
Close memory card compartment.
Insert battery.
Close battery compartment.
Turn on camera.

Any other sequence including skipping ejecting SD card results in a pink screen with no text.

Tested with

Portable display
http://www.magiclantern.fm/forum/index.php?topic=14732.0

Portable rom dumper (Pink screen then goes to a black backlit screen)
http://www.magiclantern.fm/forum/index.php?topic=16534.0


EDIT:
Interestingly the CPUINFO doesn't work from here
http://a1ex.magiclantern.fm/debug/portable-cpuinfo/autoexec.bin
Just gives the first two lines of text
CHDK CPU info for 0x289 7D2
-----------------------------------------

Then nothing.

The FIR file did work ok. Not sure if 7D2 is not enabled in source though.

[This will modify your camera.]

The BOOTU7D2.FIR was a dummy version; it did not actually enable the boot flag, but only printed what it's going to do. To enable it:

BOOTF7D2.FIR

This will modify your camera.

After enabling the boot flag in the camera, you may run:

- the portable display test (copy autoexec.bin and make your card bootable)
- the portable ROM dumper (not working on 7D2, figure out why)
- anything compiled from the recovery branch (it runs from bootloader context); check Makefile.user.default for options
- the digic6-dumper branch (you will have to modify the code and experiment - it won't boot in its current state)

Have fun!

@JagoUK: I still need a copy of the 7D2 booloader (currently I have the blinked one from you, with errors); maybe you can try g3gg0's graphical dumper from the recovery branch?

Hi  Alex, yes found the F version and enabled flag 




Tested on camera and confirm dumper didn't work btw, i'll see if I can reset my environment to compile the graphical dumper.

Ready to enable the boot flag: http://www.magiclantern.fm/forum/index.php?topic=17360.msg189584#msg189584

BOOTU7D2.FIR

(still don't know how to jump to main firmware, but...)

Hi Alex

Nice to see you trying 7dmkii again.
Just to let you know I tried your bootflag enabler. It ran but didn't set bootflag 

Don't know if this helps but the new firmware is available:

https://www.usa.canon.com/internet/portal/us/home/support/details/cameras/dslr/eos-7d-mark-ii/eos-7d-mark-ii#drivers_downloads_tab

Cheers for that, thought we were going to have to wait a little while longer for it.
I would advise against upgrading as I believe recent FW has disabled the ability to downgrade FW and currently only v1.0.4 is being worked on. (1.0.5 has the ability to roll back to 1.0.4)

[Windows and Linux.]

Are you on a Mac?

I was referring to the Mic input on Laptop.
Problem is it does it in Windows and Linux.

I have managed to get a 217K dump so far

Nope just a normal PC laptop.

Not got anything else to record it onto (Phone didn't like it either)

I'm thinking the diodes are sophisticated enough to have their own gain.

Oh yes, far too early.
I sent A1ex a copy of what I could get earlier, hopefully it had something useful in it.
I will keep trying to flash the whole code out but I cannot seem to disable AGC.
The program to convert is supposed to allow you to use multiple dumps to create a complete dump but it doesn't seem to be working. (Or you have to manually dump the right parts, instructions are not clear)

Yes, while in movie mode, you can go to the audio menu and switch to Manual.

I was referring to the Mic input on Laptop.

http://superuser.com/questions/362343/how-do-i-disable-microphone-volume-auto-adjusting

Problem is it does it in Windows and Linux.

I have managed to get a 217K dump so far

Think I may have found the problem! AGC on my mic port. Now to find out if I can turn it off!

Bootloader is 640K, so I guess it should be fine. This is the dumper that worked on 80D, but there we had to dump the entire thing. On 7D2, I need the two bootloaders, but I only know how to dump one of them.

Hi Alex.

New photodiodes arrived.
Almost there, having some sync errors in the decoding, but interesting stuff coming out.

https://www.dropbox.com/s/qsopaubye3c5fd5/bootflag.png
https://www.dropbox.com/s/ky82acqbnnidkko/master-slaveRAM-ROM.png
https://www.dropbox.com/s/gworqqeu2zrbrem/SD-CF-SLAVE.png

You need a diode for the sound card method?

Yes, you capture the Blinks of the LED from the Card Port.

http://chdk.wikia.com/wiki/Obtaining_a_firmware_dump#Using_soundcard_input

I had it working with a Raspberry Pi on the GPIO port pin 18 too but this seems easier. I just cut off a 3.5mm jack off a set of old Apple headphone (4pole to match my laptop dual mic/headphone port.)

I was using an IRled that I shaved the IR coating off but it ended upbreaking after too much abuse so I just ordered a set of 20 photodiodes for £2

Ah ok, BDMP-7D2.FIR is to dump the 1st Bootloader only (should have read closer!).

Wouldn't a dump of all the whole ROM capture both bootloaders?