-----------------------------
Documentation
-----------------------------
Before we can port magic lantern to this camera, we have to understand what magic lantern is doing in the first place.
I will try to explain what my understanding of how magic lantern works so far is.
If some information are wrong or missing, please let me know.
A. Boot-up process
---------------------
Cases:
1. Turn camera on (normal):
The camera will boot up the firmware, normal camera operation.
2. Update the camera (normal):
With the original canon.fir on the SD card.
In the camera menu -> firmware update execution.
The new firmware will written into the internal flash.
This is the typical process for any firmware updates, not only on cameras.
After the firmware update finished, the camera reboots and the camera operates as usual.
3. Update with custom generated .fir file
With the custom .fir and AUTOEXEC.BIN on the SD card.
In the camera menu -> firmware update execution.
The custom firmware .fir on the SD card sets a boot-flag, which allows us to load the AUTOEXEC.BIN from the SD card.
The camera restart, now the camera is in normal operation + custom magic lantern code running in parallel.
Since the boot-flag is set, the camera will load the AUTOEXEC.BIN automatically each time the camera is started,
when turn on and off with camera switchI guess.
Comments on case 3:This seems the normal operating process of magic lantern on most of the implementation so far.
Coutts explained here a little bit deeper:
https://www.magiclantern.fm/forum/index.php?topic=1452.0And here in the wiki:
http://magiclantern.wikia.com/wiki/Packing_FIR_FilesB. Current development
---------------------------
Now that is interesting, because in my example "led_blinking.zip" I don't remember setting any bootflags.
So why does it work anyway?
The code for the modification of the boot process is usually defined in:
entry.S
Well looking into the entry.S shows:
.text
.org 0
.globl _start, start
start:
_start:
sysInit:
B main
.align 2
fin:
And the there is no entry_subs.S file so far in "led_blinking.zip" release.
So the question would be, does it also work without the AUTOEXEC.BIN on the SD card?
After a quick test with only the 1000d.fir on the SD card.
The answer is, yes it does. But why?
Well, thinking about it, what is the 1000d.fir?
It is base on the AUTOEXEC.BIN, which is again base on our code in the main.c.
Compilation order: brain -> main.c -> AUTOEXEC.BIN -> 1000d.fir
Simple speaking, the 1000d.fir is like an .exe in windows with our code.
Each time we execute the 1000d.fir through the firmware update menu, our code will be executed.
That means:
1. The .fir file and AUTOEXEC.BIN, both can have the same code.
2. The .fir file can be executed standalone without the AUTOEXEC.BIN.
3. Each time we turn the camera off and on, we have to start the firmware update process again to load our code.
4. The AUTOEXEC.BIN can only be executed if the bootflag is set.
And setting the bootflag can be done with the .fir file, since we know how to sign it and the camera can read and executed it.
Now, I just need some confirmation to back up my theory.
After thinking a while, I remember somebody gave a talk about magic lantern.
A quick google search and here we go:
Presentation:
https://events.ccc.de/congress/2013/Fahrplan/system/attachments/2246/original/Magic_Lantern_30C3.pdfVideo:
https://media.ccc.de/v/30C3_-_5554_-_en_-_saal_6_-_201312281400_-_magic_lantern_-_michael_zollerFrom slide 23 of the presentation:
8.2 How is ML being executed?
Method 1: Firmware update - We forge a firmware update file (.fir) with Magic Lantern as payload
- Contains no flash data
- Flash loaders in .fir are replaced with our code
- Checksums and hashes need recalculation
- User runs firmware update from original firmware menu
- Firmware restarts into boot loader
- Bootloader loads .fir into RAM and executes it
- Magic Lantern takes over control of the system and boots original firmware
Method 2: Autoboot - Using .fir we set a flag in flash called "BOOTDISK"
- Bootloader checks for "AUTOEXEC.BIN" on CF/SD
- If found, it gets loaded and executed without checks
- Magic Lantern takes over control of the system and boots original firmware
----------------------------
Now, looking at Coutts latest release, we do have functions to set and de-assert the bootflag.
The functions to enable and disable of the boot-flag is defined in:
entry_subs.S
NSTUB(EnableBootDisk, 0xFFD21248)
NSTUB(DisableBootDisk, 0xFFD21260)
C. Development outlook
----------------------------
Highest priority:
- Currently the screen is black during the code execution (led_blinking.zip).
- We have to find out, how to load the original firmware to get into the normal operation mode where we can see the camera menu.
- After that we can try to get the magic lantern menu showing up on the screen and porting all functions to get magic lantern works correctly.
Low priority: Highest priority:
Figured out how to set the bootflag correctly to auto load the AUTOEXEC.BIN.
If it was that simple, why Coutts comment the code section out with the functions call in his latest release?
Translating his comments of the latest release, he had troubles to get it working correctly.