DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

Started by feedrail, June 12, 2017, 07:05:50 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


Unfortunately your beliefs have no backup in any measurable data. We are not even close to any raw capabilities on Digic6+ models, do not expect anything in literally years from now unless a miracle happens.
Too many Canon cameras.
If you have a dead R, RP, 250D mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.


What is the status of 6D2? I have a background in embedded development and would like to help. I am mostly interested in having a clean HDMI on my 6d2. Thanks.
Asking to not duplicate work.


Using MMU patches, I hooked mpu_send() and mpu_recv().  This allowed me to obtain a nice clean log of early MPU messages from 200D.  The same technique will be easy to adapt to all other D7, D8, DX cams.

This should greatly help in improving emulation.  So far I've only logged the very early messages, but in theory this can also log MPU traffic while the camera is exercised, to see how different camera functions work.  Note that the messages as seen by these functions are missing a container layer, so e.g. these two lines (one from my code, one from Qemu logging) are the equivalent message:

mpu_send: 06 01 27 00 64 00
[MPU] Received: 08 06 01 24 00 01 00 00  (PROP_CARD2_STATUS - spell #7)

Adding this extra layer for Qemu use looks easy.

The build is from this commit: https://github.com/reticulatedpines/magiclantern_simplified/commit/4d037140ad1c3ea72c16d508de65ddcc13f98a8d

Log (after slight manual cleanup, UART log lines get interlaced sometimes): https://pastebin.com/VmRdvQ9E


Dual ISO now works on 200D.  So that's nice.  Process is similar to other cams, but the data format for ADTG / CMOS registers appears different, here are some examples:

0b400000 // ISO 100
0b444440 // 1600
0b440400 // Dual ISO, 100/1600
0b455550 // 3200
0b466660 // 6400
0b466660 // 12800, so presumably this is boosted further elsewhere and is non-native ISO

I'm currently assuming this means the data is now 16 bit, and b4 is the register index.  The lower and upper 4 bits are used by some commands.



Some more understanding of the task scheduler.  I'm now confident that on 200d, e021cc4c is irq_handler(), it runs whenever an irq is triggered, due to VBAR setup in early code, see the table of handlers at e021cb60, associated with VBAR setup at e0040002:


See ARM manual, B4.1.156 for that mcr usage.  Also see FUN_e01caa88(&LAB_e021cb60,"Exception vector") for finding VBAR address.

As part of irq_handler(), we have:

  if (bVar5) {
    DAT_0000100c = DAT_0000100c + -1;
    return *puVar6;

This means that in most cases, handling an IRQ triggers assessing whether the task should change.  Which means the irq_handler is in essence the scheduler.  I assume there's a timer that triggers a periodic irq so it can't stall if the rest of the system is idle


Still following this. Every year I hope that it will be here by Christmas but greatness takes time I guess.


Hi All, sorry if I ask, I used the Magic Lantern in my old 1100D, fantastic ovbiusly, but I see nobody do anything for the 6D2, anybody ha doing something?


Walter Schulz

Nobody working on it.
Last talk with dev-to-be on Discord was November, 2021.


Walter Schulz

Quote from: Atarugolan on January 07, 2023, 07:19:52 PM
Any chance to ask developer to do something? :D

Sure. Please repeat:

"Are we there yet, developers?"


I'm the most active (only?) dev for Digic 7 cams, and I don't have a 6D2.  I did a blind port, but don't have a way to test it.  It has no features.

There won't be any progress on 6D2 until we get a dev that wants to work on it, or I get a 6D2 and a lot more spare time.

Bruno Italiano

Don't worry and You don't have to get in any stress. I love my 5d3 the most anyway.


As seen elsewhere, I now have good control over Wifi on 200D.  The code should be easily portable to other Digic 7 (and very likely 8, X): https://www.magiclantern.fm/forum/index.php?topic=26850.msg242999#msg242999

Further to that, I've confirmed that the 200D forces the Wifi into a low-power mode.  But this can be overriden using an MMU patch.  Also confirmed, 200D supports 802.11n, 2.4GHz only.  No sign of 802.11ac but n is okay!

Combining both of those, I have boosted bandwidth to about 3.8MB/s.  That's around 3s to upload a full res JPG - pretty useful!  It's very range dependent to the AP so I suspect the cam has a crappy antenna / transmit power.  I'm in a pretty noisy wifi environment so higher may be achievable.

e071f174 on 200D 1.0.1 is something like get_wifi_power_settings(int *chip_index, int *is_low_power).  This always sets chip_index to 1 and is_low_power to 1.  Setting is_low_power to 0 gives MOAR POWER, and presumably less battery life.  I would expect this tweak to make all Canon wifi functions faster, not just ML stuff.


Too many Canon cameras.
If you have a dead R, RP, 250D mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.


As noted here, I have some useful edmac / raw progress on 200D: https://www.magiclantern.fm/forum/index.php?topic=13746.msg245918#msg245918

I've now got mlv_lite meeting all deps for 200D (this doesn't mean much, just that all required symbols are exported - some of these I am faking for now).  Trying to run it causes problems, multiple in fact.  I've fixed some serious bugs in the module, and surrounding code (that in theory affect all cams, but may not be possible to hit in practice).  We have very bad discipline around checking for null pointers before use, which on D7 and up causes an exception, whereas D456 you can get away with it.  Canon code has also been changed due to this, they have added many more checks :D  One of the problems is the FIO_* functions often take char *filename, and Canon code checks this now, and asserts.  ML can sometimes pass in null pointers.

One oddity is worth noting.  Some MMIO addresses have changed from Digic 5, we've known this for a while.  For D5 0xc0f06014 is FPS_REGISTER_B (which is hard-coded into the source, a painful decision that I must fix).  On 7D2, this has moved to 0xd0006014.  But on 200D, while the *value* 0xd0006014 is used, it's not used as an address.  Instead, there's an array of (addr, val) pairs, 0xd0006014 is one of the addresses, and the code has some utility functions to search the array, and either update the val from a global (obtained via a function I am calling get_fps_register_b_val()), or return the val.  See e.g. e032b54a().

It's quite weird.  I suppose it might be a more space efficient way to do shamem_read(), if the region was sparsely populated?  This complicates things in at least two ways: there's no fixed offset for FPS_REGISTER_B, I may have to refactor all accesses into a function call.  Second, on 200D we can't assume 0xd00X_YYYY constants are MMIO access, which may break many assumptions in ML code.


This is related to engio_write()!  I didn't recognise the code because we've never found that function for digic 7.  I might be misinterpreting whether it's writing into the array, or writing through pointers stored in the array - the (addr, val) pairs are very similar to engio_write() buffers used on 5D3 (and I assume, other cams).  I need to look at this in more depth.

_engio_write() itself is probably at e050d6dc.