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.


Isaac Martínez

Hii!
I have alredy loaded 800D, 50D & 200D dumpers into Ghidra.
What I need to do now?
Best regards,
Isaac Martínez

names_are_hard

@mfurseman - 200D is fairly cheap.  I'm biased because I have one and I have a (very) partial port.  It's the port that's the furthest done so far.

@Isaac - first, read this entire thread.  There is useful information about how to work on ML ports, as well as specific information about 200D, and later on some posts from me about current problems.

Ghidra helps you understand how the ROM code works.  Qemu can run the code.  But, Qemu does not fully understand how to emulate Digic 7, it only partly understands.  So, one task you could try would be improving emulation in Qemu so that it can get further when running the 200D ROM.  50D ROM emulates very well so that might help as a comparison.

Another task would be to check and improve the found stubs for 200D.

Another would be running my 200D repo code on your cam and trying to diagnose why it crashes.  This is the highest risk task as it involves running known bad code on a real cam.  If your camera breaks, it is your fault.  All I can say is that it hasn't broken my 200D so far.

You can join the unofficial Discord to ask questions if you'd like.  Asking here is also fine.

Isaac Martínez

Ok, I don't know much about code, so I'll first help run some known bad code on my 800D and in the meantime, I'd like you to pass me some tutorials so I can help with the programming part.

Isaac Martínez

Quote from: Isaac Martínez on September 03, 2020, 02:41:34 PM
Ok, I don't know much about code, so I'll first help run some known bad code on my 800D and in the meantime, I'd like you to pass me some tutorials so I can help with the programming part.
Sorry for my english

names_are_hard

If you don't have any programming experience, the goods news is, you can learn for free.  The bad news is, it will likely take several months at least.  I hear CS50 from Harvard is a good free course that covers C.  I learnt a long time ago so I don't have any experience with modern tutorials.

Walter Schulz

Isaac, it is as names_are_hard said: It will take a long time until your efforts will result in useable code for a cam. If you are unable to put several hundred hours of work into it you won't succeed (IMO). And everyone will understand if you don't want to take that path!

Isaac Martínez

Well, I have a lot of free time and I could invest it in that



Walter Schulz

Upload dumped ROM files somewhere (hidden to public), PN link to srsa and a1ex.

names_are_hard

I think I have found something significant for DIGIC 7 (and probably 8, 10, maybe 6).  The task struct now has a field that determines which CPU the task is scheduled for.

The old struct looks like this for Digic < 7 (only the end shown):

        uint8_t         yieldRequest;   // 0x47, 1
        uint8_t             unknown_0c; // 0x48, 1
        uint8_t         sleepReason;    // 0x49, 1
        uint8_t             unknown_0d; // 0x4a, 1
        uint8_t             unknown_0e; // 0x4b, 1
        struct context *context;        // 0x4c, 4


For 200D (probably all D7), I think it looks like this:

        uint8_t         yieldRequest;   // 0x4b, 1
        uint8_t             unknown_0c; // 0x4c, 1
        uint8_t         sleepReason;    // 0x4d, 1
        uint8_t             unknown_0d; // 0x4e, 1
        uint8_t             unknown_0e; // 0x4f, 1
        uint8_t         cpu; // 0x50, 1
        uint8_t             unknown_10; // 0x51, 1
        uint8_t             unknown_11; // 0x52, 1
        uint8_t             unknown_12; // 0x53, 1
        struct context *context;        // 0x54, 4
        uint32_t            unknown_13; // 0x58, 4


Trying to update Qemu for 200D, it was failing to reach code that would initialise needed structures in memory.  A task was getting scheduled to do the init, but never running.  It was being scheduled for cpu1, which we disable in Qemu early on.

Forcing cpu = 0 for all tasks, I see the "init1" task running and the structures getting at least partially populated.  Unfortunately it triggers an exception, but before it would never run at all.  It looks to me that there are two init routines, designed to run in parallel (presumably no dependencies?).  See 0xe0040224 and 0xe0040220.  The former is "init", the latter "init1".

Beyond helping with qemu, this may allow ML to choose which cpu tasks run on - and that could mean we can run things twice as fast, if we're cpu bound.  Are we cpu bound for recording video, for example?

sm105

Very exciting! I'm no expert, but since these DIGIC 7 cameras all have UHS-I controllers (I think?), then the bottleneck will probably be write speed. However, this could be quite a valuable finding when it comes to cameras that support UHS-II.

names_are_hard

Minor update, another field probably identified, better names chosen:

        uint8_t         yieldRequest;   // 0x4b, 1
        uint8_t             unknown_0c; // 0x4c, 1
        uint8_t         sleepReason;    // 0x4d, 1
        uint8_t             unknown_0d; // 0x4e, 1
        uint8_t             unknown_0e; // 0x4f, 1
        uint8_t         cpu_requested; // 0x50, 1 : 0, 1, ff,  ff means "any cpu"
        uint8_t         cpu_assigned; // 0x51, 1 : 0, 1, ff, ff means "not yet assigned"
        uint8_t             unknown_11; // 0x52, 1
        uint8_t             unknown_12; // 0x53, 1
        struct context *context;        // 0x54, 4
        uint32_t            unknown_13; // 0x58, 4

srsa

Quote from: names_are_hard on October 13, 2020, 03:36:56 AM
Are we cpu bound for recording video?
I'm not in the position to answer that, but I can say that the ARM core of DIGIC 6 is clocked faster than previous DIGICs and the primary ARM cores of DIGIC 7 are clocked 4x the clock of DIGIC 6. In my cameras - DSLRs might differ, I don't know.
Quotethis may allow ML to choose which cpu tasks run on
FWIW, there are versions of CreateTask that allow specifying the CPU core to run on.
In the M50 firmware (I don't have a D7 DSLR dump), the init1 task is created with the low level version of that function. If you trace that back in disassembly, one of its callers is a function with SystemIF::KerTask.c asserts - that one is the "normal" CreateTask_on_core. CreateTask_on_core also has a "strict" version (recognizable by the SystemIF::KerMisc.c assert). The name "CreateTask_on_core" is not the function's real name, just something I came up with.

names_are_hard

I thought that might be the case. The "normal" CreateTask (task_create in ML land) doesn't have a CPU argument and looks to copy the CPU index from current_task, so it will always schedule on the same CPU as the running task.

Do you know if existing code ever uses 0xff for cpu_requested?  I'm wondering if/when Canon would want tasks to be scheduled opportunistically on either CPU.

srsa

Quote from: names_are_hard on October 13, 2020, 08:16:07 PM
Do you know if existing code ever uses 0xff for cpu_requested?  I'm wondering if/when Canon would want tasks to be scheduled opportunistically on either CPU.
"CreateTask_on_core" asserts if the core parameter is not 0 or 1. If what you're saying about task_create is true then I guess this DryOS configuration does not support that.
FWIW, I've encountered the following DryOS version string in a printer's firmware:
DRYOS version 2.3, release #0049+SMP
If the SMP is that SMP, that might suggest that the DryOS instances in our cameras are not configured to be symmetric, but the OS itself supports that config.
The ARM cores are set to run in SMP mode (ACTLR register SMP bit is 1).

names_are_hard

Interesting.  The task consumer function on 200D will assign tasks that have that field set to 0xff.  Either CPU will take them.  It's an explicit check "if -1, assign task to this CPU", so it must be deliberate.  I haven't logged any tasks being created that match.

Curious about SMP.  200D says 2.3, release #0059 - a later release but not listed as SMP, yet the hardware is.

T7i owner

It's so awesome to see progress on this port!
I'm a Rebel T7i owner and am willing to do testing wherever is needed.

T7i owner


names_are_hard

There's no testing required if that's what you're thinking.  Have you got any experience with C or ARM assembly?

Abdul Samad


names_are_hard


T7i owner

Quote from: names_are_hard on October 27, 2020, 01:23:19 PM
There's no testing required if that's what you're thinking.  Have you got any experience with C or ARM assembly?
Not really. But I'll be glad to help maybe even try learning.

names_are_hard

C is a fairly small language, so it doesn't take much time to learn; probably a few months.  Feel to give it a go!