Canon 5D Mark IV

[thekreative]

a1ex thanks for all your work and have a happy New Year...... Time to get testing.

[Danne]

Very nice indeed!

[zerocool22]

Thanks guys! Happy NY!!!

[banertop]

good work guys! Again!

[ThingsChange]

Joined the forum just to thank a1ex and the other testers/coders for their great work.  Thanks everyone and happy new year!

[The_Aussie_Photoguy]

Just joined the forum officially after many years of use.

I was hoping the 5d Mkiv kit would be out, I already miss ML on it after my upgrade.

The features you guys are developing will really make this camera an absolute beast. I am looking forward to seeing it upon completion.
Unfortunately I don't have the paycheck to offer my Mkiv up. But once there is a semi stable build happy to provide as much feedback as possible.

Keep up the solid work team!

[djfr971]

Hello guys! Happy New year! Thanks for this wonderful news. I've already installed it on my 60D with the classic method but I would like to know if someone has successfully installed it on the 5D mack4. If someone did and it's working properly. Sorry for those stupides questions!
Thank you .

[Seanc]

I've already installed it on my 60D with the classic method but I would like to know if someone has successfully installed it on the 5D mack4.

Not even close. This is only the first step on the path to being able to begin work, though a very important one.

Thanks A1ex!

[a1ex]

The latest 80D experiment can be also ran on 5D4 1.0.4, without any changes.

That was just FYI, as I don't have high hopes anyone is going to run the test on this camera. The previous tests were a lot easier to run, but nobody tried them yet, to my knowledge.

Edit: the experiment was successful on 80D.

[robotron]

Hi there,

this is my first post here, but I've been following both the 80D and the 5D IV threads for a little while now, since I just upgraded from an 80D to a 5D IV.
I'm a computer science student and am willing to spend some time on this, and think I could help a little bit. My 5D IV runs v1.1.2, so I'll start by updating the codebase to the new version.
However, I've got finals coming up in a few weeks and won't be able to work on this until late February.

Hope I'll be able to help!

[zerocool22]

Hi there,

this is my first post here, but I've been following both the 80D and the 5D IV threads for a little while now, since I just upgraded from an 80D to a 5D IV.
I'm a computer science student and am willing to spend some time on this, and think I could help a little bit. My 5D IV runs v1.1.2, so I'll start by updating the codebase to the new version.
However, I've got finals coming up in a few weeks and won't be able to work on this until late February.

Hope I'll be able to help!

Awesome news! Having big hopes on you robotron!

[KelvinK]

Hi there,

this is my first post here, but I've been following both the 80D and the 5D IV threads for a little while now, since I just upgraded from an 80D to a 5D IV.
I'm a computer science student and am willing to spend some time on this, and think I could help a little bit. My 5D IV runs v1.1.2, so I'll start by updating the codebase to the new version.
However, I've got finals coming up in a few weeks and won't be able to work on this until late February.

Hope I'll be able to help!

Just do not fade out as previous ppl! Also take a look in 80D thread, there's an actual progress.

[legreve]

How big of a chance is there to brick the camera if experimenting with the firmware and code?

[a1ex]

It very much depends on what you are trying to do.

The code sequences suggested in reply #397 should be quite safe. Logging code was already tested on 5D4 (an earlier version, not the latest codebase), so it should be OK, too. Other code sequences (e.g. found in 80D thread) should be OK as long as they don't use hardcoded pointers. If in doubt, ask.

In particular, stay away from EraseSectorOfRom and similar (I'm pretty sure you will), don't attempt to change properties yet (the proof of concept code doesn't include any backend for that) and try not to overwrite Canon's data structures (double-check any pointers you use for writing). Canon firmware saves some of their settings at shutdown by reflashing the main ROM, so you'll want to be extra careful not to overwrite their data structures.

If something goes really wrong, you have the boot flag enabled, so you will still be able to run diagnostic code on the camera (unless you somehow manage to erase the bootloader... extremely unlikely). From there, I can inspect the (non-booting) ROM, debug it in QEMU, reflash it with a good copy and so on. I did that on some other models (recently on 5D3 and 70D), but... let's hope we'll never get there. Worst case: JTAG and UART (I've never tried these on physical hardware).

A while ago I wrote a short guide on safety, that I should update.

On 80D, I have used some hardcoded pointers (such as 0x30000000, 0x28000000 and so on). Do not use them; they are not valid on any other camera. Rather, follow the source code comments and run the test code to find out what memory areas appear to be free on your camera, and use those instead. In any case, these pointers are well above DryOS and general-purpose memory buffers; these are managed by RscMgr and used for things like image capture, processing, LiveView and others. I highly doubt writing into these by mistake could result in permanent camera damage, but I still prefer to triple-check before using them.

Writing into the display buffer is safe (and hopefully that's all you need for a Hello World), but first you need to know its address. It's not going to be the same as on 80D (or other models). This can be found either from a RAM dump (there are tutorials around the 'net), or from diagnostic logs. The MMIO registers are also different, so what worked on 80D is going to require some (hopefully minor) changes.

To summarize, the next steps are:
- try the code sequences from reply #397 [easy]
- get a RAM dump and identify the image buffers [easy]
- you can attempt to print things on the screen at this stage, but I prefer to know what I'm doing, so...
- run this experiment to find possibly unused memory areas (this was linked in reply #408)
- update log-d6.c and io_trace.c with the hardcoded memory buffers found at previous step
- enable LOG_EARLY_STARTUP in log-d6.h
- also enable io_trace (see 80D Makefile)
- this will give you a fairly complete startup log (debug messages + interrupts + MPU messages + MMIO activity)
- from this log, we will be able to see how the display buffer is configured (for Hello World) and many other details that will be useful later.
- Hello World!
- afterwards, getting an initial ML port (with basic functionality) should be relatively straightforward.

[Ford1080]

I used ML on 7D, now have 5Div.  I would love to help but I have no idea what I'm doing with any of the coding stuff - and have no time right now.

I'll be watching this thread tho and I if find the time to figure out various tasks, I'll do whatever.

Thank you guys!!!!!   Especially A1ex and g3ggo.  Thanks for your work on 7D!!

[chris_overseas]

I finally found some time to update the rest of the stubs for 1.1.2. I've hit a problem getting further though.

Please find the FIR to enable the boot flag on the 5D Mark IV:

BOOTF5D4.FIR (works on any^*) firmware version; source code).

The above doesn't work on 1.1.2. When I try to run it I get "Firmware older than Ver 1.1.2 is on memory card. Delete old file and update using a later verison". a1ex, could you please create a BOOTF5D4.FIR with a higher version number for me to try?

[a1ex]

Done. I don't get this error in QEMU, so it's very easy to overlook it. Also updated the portable ROM dumper.

Size of autoexec.bin is OK; it won't load any modules. Just copy it on the card; it doesn't require any data files either.

My advice is to copy it on the virtual card first, in QEMU, as that will give you a way to debug it. To cross-check, if you compile the current code from digic6-dumper (on 1.0.4) and run it in QEMU, it will save a log on the virtual card.

[chris_overseas]

Thanks a1ex, the updated BOOTF5D4.FIR and ROM dumper are both now working fine on 1.1.2. I'm happy to report that the bootflag being enabled on the 5D4 doesn't seem to introduce nearly as much lag as it does on the 5D3.

Logging on the physical camera with 1.1.2 works using the code from my 5d4-112 branch, as does the intervalometer. I'll generate more/better logs and chip away at the various other outstanding tasks (as per replies #397, #417, 80D thread #468) when I can, but my spare time is sadly very limited so anyone else willing to join in is most welcome to do so.

[KelvinK]

@chris_overseas what's going to be next?

[chris_overseas]

I scanned for free memory regions (as per the 80D). The log file fills up extremely quickly on the 5D4 even with filtering, so I hacked the logging code a bit so the memory results overwrite the start of the log file instead of disappear off the end. Across 4 attempts I found these common unused areas:

Code Select Expand


42600000-42FFFFFF = 10MB
4B100000-4BCFFFFF = 12MB
5D100000-5D6FFFFF = 6MB
60B00000-614FFFFF = 10MB
7C500000-7D0FFFFF = 12MB


The areas aren't as big as the 80D unfortunately, nevertheless I managed to capture a few 12MB logs here using 0x7C500000: http://www.redyeti.net/test/5d4-112-logs-4.7z

I tried to get an MMIO log but my first/only attempt came up empty, will hopefully have time to try that again in a couple of days.

[a1ex]

Stubs verified (actually I've programmed a robot to do that) and included in the main repository. Nice job!

Expecting MMIO log to work as well (tested in QEMU)... as long as one doesn't use the camera in burst mode. These hardcoded buffers are not guaranteed to be always available, but I believe the risk is low - these are used for image data, so if there's any collision, either the images or the logs will be affected.

[chris_overseas]

I managed to get continuous logging working using a smaller buffer on the 5D4 (https://bitbucket.org/chris_miller/ml-fork/commits/branch/5d4-112). This gave me a 30MB log file recorded over 50 seconds worth of camera workout. The log is available here: http://www.redyeti.net/test/DEBUGMSG-5D4-big.7z

I've also made a few attempts to get MMIO logs but without success so far. I can generate MMIO logs in QEMU but I've had no luck with the real camera even after trying a few different memory areas for the MMIO log buffers - the camera always just hangs, reboots, or gives an Err 80 after a few seconds. I've still got other ideas to investigate/test to try and get this working, but any tips appreciated.

[chris_overseas]

Some good progress today:

[Walter Schulz]

Nice day it is. First Digic 7, now Digic 6+. Not bad, not bad at all!

[Danne]

Great!