Canon 7D Mark II

Started by Pelican, November 02, 2014, 09:55:18 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I also would like to know what is the difficulty/problems that prevent ML from porting into 7D2, and maybe I could help with that.


QEMU won't run the 7D2 GUI yet - it might do so in a few years. Yes, it's that difficult because of the Dual DIGIC architecture, and for this reason, not a priority for me. The good news - porting the basic ML features may not require support for both CPU cores - see e.g. the Hello World PoC for 5DS/R, also Dual DIGIC models.

In your case, it's a lot easier to debug on real hardware, i.e. adapting code already debugged on other D6 (single-DIGIC) models. I've already debugged the startup process in QEMU - this code is already used on other DIGIC 6 models, and - guess what - it was written for 7D2 first (but nobody confirmed it on this camera yet).

Start by compiling the digic6-dumper branch and report back. I expect Hello World to be working already - it compiles, but nobody tested it (see e.g. reply #422 - still waiting for a confirmation). You may follow other DIGIC 6/7/8 threads for hints.


Hi a1ex,

I have some experience in Android programming before, so I'd guess it's similar because this is also ARM, right? but in android, we have a tool where we can plug our phone in and debug the log. Is there similar tool available for my camera? Also, I read "how to develop magic lantern," but it doesn't seems to talk about "how to port into a new camera." I read the example of porting into EOS M2, but I got confused. In C, C++, when you comply, you end up with executable .exe right? What would be the complied file that i need to put on the camera and run it? Also, which piece of code that I need to tweak? Can you guide me roughly? I tried to search the forum already, but ended up inconclusive.



Yes, the PoC code in the digic6-dumper branch (i.e. what you get by compiling from platform/7D2.104) does just that - logging. Hello World is in minimal/hello-world - same source code covering all DIGIC 4..8 models (for now).

This sticky topic should be a good starting point.

edit: you also have an Edit button, FYI ;)


I just realized that the branches is "a version" of the magic lantern. I thought i need to download the branches and put inside the main magic lantern clone, then compile.


So, I got autoexec.bin and ML folder, how do I execute that?


First you enable the boot flag in the camera (reply #390), then you make the card bootable (EOSCard/MacBoot/

Then copy autoexec.bin to the card.

This flowchart should help.

Quote from: a1ex on March 12, 2019, 10:59:48 AM


Thanks, I will give it a shot and report back


i got some error during build, that's fine right?


No, you shouldn't get errors (some warnings are normal).

The issue is with some builds that there are no modules, then the build fails.

For the 77D I solve that by building one random module for another camera model (e. g. arkanoid for 5D3.113). After this I can do the 77D builds with "ML_MODULES=" without errors.

See for examples.



Even if you copy a sample module from other camera... it will be replaced when running "make zip".

If you want to use this method, look at console output to know what is getting compiled and after your see your selected module get compiled for 2nd time, then quickly copy and paste "" in modules/yourmodule path.

Otherwise you can simply use "make" and get only autoexec.bin compiled and then copy it into card.

At the moment ut is the only ML file needed in order to run Hello World and early d678 experiments


My camera lockup and it doesn't boot at all. autoexec.bin seems to be too small (12kb), for 5d3, it's 66kb in size


hg up digic6-dumper -C
cd minimal/hello-world
make MODEL=7D2 clean
make MODEL=7D2
make MODEL=7D2 install # works fine here, it doesn't ask for any modules

My autoexec is about 9.5K.

If it doesn't boot, the first step is to go into reboot.c and enable the "jump to main firmware" section.

If jumping to main firmware works, the next step is in boot-d6.c, copy_and_restart. Try the same trick (i.e. jump to ROMBASEADDR at the end). If that works, try starting the relocated code without overriding init_task (comment out the line using my_init_task).


make MODEL=7D2 clean
make MODEL=7D2 install_qemu CONFIG_QEMU=y

./ 7D2,firmware=boot=1 -d debugmsg
./ 7D2,firmware=boot=1 -d debugmsg -s -S & arm-none-eabi-gdb -x 7D2/debugmsg.gdb

You will see ML code running alongside Canon firmware, starting tasks and so on, but... that's pretty much how far the emulation goes on this camera.

Running "make clean" is important, btw; the code compiled with CONFIG_QEMU=y will not work on real hardware.


I just noticed that my camera running firmware 1.1.0, but the code is for 1.0.4. Do I need to change anything?


Quote from: a1ex on February 12, 2019, 10:53:14 PM
Startup code: autoexec.bin. It requires firmware 1.0.4.

Quote from:
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.


So, my camera is useless for now?


Looks like there is a newer 1.1.2 firmware for 7d2

KenSoftTh you can try to downgrade from 1.1.0 to 1.0.4 if your camera allow this or try to update stubs.S to the newer firmware.

In the second case just update your camera and the start by dumping the firmware with Portable rom dumper and then follow two tutorials for finding stubs


I'll definitely take Assembly course next year in college....

Walter Schulz


Is it possible to flash the older version over the new one?

Walter Schulz

Extra points for finding out ...
Spoiler: It would be the first cam unable to be downgraded.


Success! Hello World from Bangkok, Thailand. Now, what's next...?


A little bit of Tweaking...


Next step would be capturing some detailed logs of whatever the firmware does. I've covered these steps in detail in other threads; other contributors will be able to guide you through this process. The logs will only cover the activity on one of the cores; these will reveal many useful hints, button codes and so on.

I might be able to capture a log from the second core, but it's not exactly a trivial task and - I hope - not required for porting the basic ML functionality.

Meanwhile, I'm cleaning up the M50 changes to make them compatible with hopefully all earlier models; stay tuned.