Magic Lantern: The 5D Mark Free Firmware FAQ

What is it?
Magic Lantern is an enhancement atop of Canon's firmware that makes your 5D Mark II into the 5D Mark Free. It adds new features like onscreen audio meters and zebra stripes, as well as disables the audio AGC. It is an open (GPL) framework for developing extensions to the official software, tailored for film making needs.

Where do I get it?
http://magiclantern.wikia.com/

What can I do to help?
If you're a programmer skilled in ARM assembly, embedded systems, GUI programming and don't mind risking your expensive camera, send me a PM. If you're a hosting provider, we'll need a site to host the software, a mailing list or three for announcements, users and developers. If your skills are more suited to web site development, we'll need that, too. I'd like to setup a Mediawiki site for documentation

Can I donate / pay for it?
You can donate via PayPal, but it is not required. I'm also looking for used film making equipment (steadicams, booms, jibs, rails, matte boxes, filters and lenses), so if you have any older ones that are no longer being used please let me know. Or you can make a donation to the EFF for me.

How is it installed?

As shown in the video, a file named '5d2.fir' is copied to the CF card and "Update firmware" is selected from the menu. The running firmware shuts down, loads the file into RAM and starts it running. Rather than reflashing the ROMs, this new program:
* copies itself above the DryOS BSS
* copies part of the DryOS ROM image into the BSS
* modifies it to reserve the new regions
* adjusts the code flow to return to itself
* creates its own task (that doesn't do anything yet)
* installs a hook so that task scheduling will call its own routine to override Canon functions
* hooks the sound_dev_task() so that my version is used instead (which just turns off AGC)
* calls dumpf() to write out the console log to a file for analysis
* create a task to draw audio levels on screen

Does it modify the camera?
Nothing is written into the ROMs. When the camera reboots, the RAM image is flushed and the bootloader FROMUTIL at 0xFFFF0000 starts the pristine copy in ROM at 0xff810000. After any reboot (or even powersave), you must select the "Update firmware" menu item. Eventually we want to be able to boot directly from the AUTOBOOT.BIN file on the CF card.

Is it dangerous?
I haven't bricked my camera yet, but that is no guarantee. It doesn't write to the ROMs at all, so it should be fairly safe, but anytime software is interacting with hardware there is possibility of significant damage. The FROMUTILITY appears to have a way to reflash even a bricked camera, but I don't know how to access the console.

How will it interact with a possible upgrade from Canon?
The current code is very tightly integrated with the 1.0.7 firmware image; it modifies specific instructions at hard-coded addresses and uses function addresses that will change in a new firmware. Once the new Canon firmware is widely available, Magic Lantern will be updated to support it as well as the 1.0.7 firmware.

Despite this tight integration, the 5D Mark Free software does not contain any Canon code.

When will {manual control,24p,etc} be available?
Canon has announced their own firmware upgrade available 2 June that will include manual exposure control. We'll have to see what other features they fix in this upgrade.

It is hard to predict how much effort will be required to implement new features. Disabling existing features is fairly easy, which is why AGC support was the first target. Disabling auto-exposure should be easy as well, but an accurate estimate is difficult to give since I'm only working on this in my spare time.

For these reasons it is hard to say if all of the terms of http://canonhack.com/ will be met. Perhaps, although changing the frame rate to 24p and PAL are the one that has the most unknowns.

Does it work with chdk?
I've used some of the CHDK tools to learn about Canon firmware files, but this is all new code. They have done an amazing job of supporting hundreds of different camera models across multiple architectures and operating systems. At some point in the future chdk might be ported to the 5D Mark 2, but this project is much more focused on just the 5D Mark II and the needs of film makers.

Why the name change?
Originally the project was called just "5D Mark Free", but out of an abundance of caution it seemed best to avoid Canon's trademarks.

What is it written in? Can I get the source?
The firmware hack is in C, with some inline assembly for boot strapping. The firmware build tools are in Perl and use Makefiles for dependency tracking. You need an arm-linux-elf build of gcc and binutils. Most of the code analysis has been done with objdump, strings and the IDA demo. A hg tree can be made available if you know what these terms mean and aren't scared of them. No tech support will be provided. If it breaks you get to keep both pieces.

How do I get a ROM0.bin firmware image?
I've written a modified version of the 1.0.7 firmware image that uses the embedded DryOS to dump out the firmware. Since it is a derived work of Canon's firmware, I am not comfortable distributing it. There is no reason that this could not be added to the new 5d2-hud.fir file once we have custom menus, which should avoid any IP issues.

What are all of the 0xff81beef things and funny names like EP_SetManualMovieMode()?
These are the addresses in the official ROM firmware for different functions and names that we have given to functions. If you load the ROM0.bin image into IDA or use objdump you can trace through the instructions to determine how the software works. If you are just using the camera, they don't need to mean anything to you, but they give other developers a place to look in the firmware image.

The function names are unlikely to be the same as the ones in Canon's source code, which we have never seen. We name functions based on what they seem to do, or debugging / diagnostic strings embedded in the function. It isn't perfect, but it is sufficient to locate the important things for task creation, file I/O and GUI operation.

What are the next steps?
* Onscreen level meters are working!
* Zebra stripes are working!
* Debug manager is working!
* Figuring out how to create additional menus
* Understanding localization and string pointers into ROM1.bin
* Adding custom functions for enabling/disabling new features
* Overriding lvae_*
* AUTOBOOT.BIN to automatically start the new firmware from the CF card
* Adjusting frame rate of video (24p and PAL)
* 4 GB file limit
* Scripting language (or full CHDK port)
* HDR / Timelapse / etc

Is it legal?
This is a "clean room" / "black box" reverse engineering effort and as such should be ok. Frequently asked questions about reverse engineering addresses the legality question; producing an interoperable product is one of the explicit allowances enshrined in law.

Will it work on a 50D, GH1, etc?
It is likely that the 50D is close enough to the 5D Mark 2 that the same techniques can be applied to building similar firmware. The CHDK project succcessfully supports many different cameras running different operating systems, but finding the necessary kernel entry points is a very time consuming process. Once the 5D Mark Free software is publicly available, some one with the inclination to port it to the 50D can do so. The 40D is similar in hardware, but runs vxWorks and would be lots of effort to support The GH1 is a completely different bit of hardware and would require an entire from-scratch reverse engineering effort. Until Panasonic releases a firmware update it is unlikely that any such efforts can be begun.

What about feature X?
Some features that have been requested, with commentary if I've thought about it. These are all very speculative and a long way down the road from where we are today.
* Preserving * locked exposure values between takes: surprisingly difficult due to the code organization. Full manual control looks easier.
* 24 FPS or > 30 FPS: Unknown at this time. 24 may be doable, greater than 30 might tax the already swamped CPU doing h.264 encoding
* Cropped mode: Might be possible, but will require significant code modifications. This is one that I would find very useful.
* Live full-res HDMI output: Unlikely -- the LV VRAM is only 960x540, so it is decimated from the already downscaled 1080p video frame.
* Peaking, false-color and edge detection on LCD: Very likely.
* Digital zoom for focusing while recording: I hope this is possible!
* 720p mode
* Overcranking: unlikely, based on the sampling rate of the sensor. Perhaps combined with crop mode it might work (cf. the Sony EXilim)
* Better sampling algorithm: unlikely, but highly desirable
* Auto-splitting at 4 GB file size: it is likely that there would be a few frames lost
* Temperature monitoring of CMOS sensor: it appears to do this; we just need to display it
* Swapping buttons: very difficult due to the hard-coded design of Canon's GUI. Rather than build a data-structure that reflects the state of the GUI and all of its callbacks, the button mapping is defined in a giant switch statement that is burned into ROM.
* Headphone output on the A/V jack: this might work if the AK4646 is wired up correctly. The lv_task() would need to be wrapped to prevent any property messages regarding video mode switching from reaching it so that it doesn't go into NTSC mode when the headphones are plugged in.

"HUDSON HACK" FTW!!!!!

Come on! you have it! great work!

Unbelieveably amazing programming and technical communication skills, Hudson...... go, go, go!

Best vibrations for you, man!

Hacked cameras... This is the future!

great news....now pardon my ignorance but lets say that you release the firmware and we all install it and it works like a champ....now Canon a week later releases a firmware that ONLY addresses 24p and nothing else. If we all run and install Canon's firmware, would it disable your firmware?

I think it's safe to assume that if Canon can add 24p by a firmware update, Hudson certainly will.

The encouraging bit is that it does look like there are functions that may take a frame rate as a parameter. For example, LV_FPS is something we explored a while back. But I'm not the expert, this may be nothing since we ran into a bit of a dead end with it.

I think it's safe to assume that if Canon can add 24p by a firmware update, Hudson certainly will.

The encouraging bit is that it does look like there are functions that may take a frame rate as a parameter. For example, LV_FPS is something we explored a while back. But I'm not the expert, this may be nothing since we ran into a bit of a dead end with it.

I suspect any framerate capability currently on the camera is for compatibility with output devices only.

great news....now pardon my ignorance but lets say that you release the firmware and we all install it and it works like a champ....now Canon a week later releases a firmware that ONLY addresses 24p and nothing else. If we all run and install Canon's firmware, would it disable your firmware?

If a firmware hack is successfully achieved and If Canon release a new Firmware (like it is supposed and we still hope) you will probably need to choose between one of them, but maybe not permanently, according to the explanation (in the 1st post of this thread):

" Does it modify the camera?
Nothing is written into the ROMs. When the camera reboots, the RAM image is flushed and the bootloader FROMUTIL at 0xFFFF0000 starts the pristine copy in ROM at 0xff810000. After any reboot (or even powersave), you must select the "Update firmware" menu item. Eventually we want to be able to boot directly from the AUTOBOOT.BIN file on the CF card."

So, if the firmware hack gets deeper with more functionality and menus, you would probably be able to load it everytime you turn on the camera, from your Compact Flash memory card (where you already had to save the hacked firmware file)

But please people, keep in mind this is just the beginning.
There is still a LOT work to do. This is not easy at all.
Hudson is investigating and discovering by himself the ways and possibilities, there is no manual nor guide here.
So support him, encourage him, but don't expect fast solutions. This will take lot of time and work to him.

Indeed, one of the most interesting things still to be seen is how much the Canon Firmware Update can give to customers, and how much Hudson's one can.

I strongly believe (hope I'm wrong...) that Canon will not deliver all the features they could, but just the most essentials and most requested (hopefully FULL manual control for video).

Hudson instead has a longer list of goals, and INDEED is "listening to customers" and his own needs. So, he has no need to lock any function nor anything that could be improved.

Best luck and support to Hudson for so much dedication in this very hard task.

I strongly believe (hope I'm wrong...) that Canon will not deliver all the features they could, but just the most essentials and most requested (hopefully FULL manual control for video).

Hudson instead has a longer list of goals, and INDEED is "listening to customers" and his own needs. So, he has no need to lock any function nor anything that could be improved.

Best luck and support to Hudson for so much dedication in this very hard task.

Thanks for the explaining. Now my question is this...My only experience with Canon was when I used to own a XL1...and I remember we all loved the camera but always wanted improvements in some of the internal camera features. We had hoped there would be some sort of firmware but at the end a whole new XL2 came out...new hardware and yes some of the improvements maybe needed new hardware.

Now, I do not know if Canon video and Canon photo are two different identities...but is there good reason to believe that the 5d MarkII would be improved via only firmaware without having to go into a 5d MarkIII?