Author Topic: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)  (Read 300070 times)

shankar101

  • New to the forum
  • *
  • Posts: 26
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #400 on: April 30, 2022, 09:55:17 AM »
Hi where did the development reach?? I believe 200d is going to be way better than  eos m for raw.

kitor

  • Developer
  • Senior
  • *****
  • Posts: 361
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #401 on: April 30, 2022, 10:03:19 AM »
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.

zvonkok

  • Just arrived
  • *
  • Posts: 1
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #402 on: June 17, 2022, 11:55:53 AM »
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.

names_are_hard

  • Developer
  • Hero Member
  • *****
  • Posts: 540
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #403 on: June 26, 2022, 06:18:47 AM »
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:
Code: [Select]
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

names_are_hard

  • Developer
  • Hero Member
  • *****
  • Posts: 540
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #404 on: August 15, 2022, 05:33:00 AM »
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:

Code: [Select]
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.

Danne

  • Developer
  • Hero Member
  • *****
  • Posts: 7406
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #405 on: August 15, 2022, 08:13:03 AM »
 :o
Nice work!

names_are_hard

  • Developer
  • Hero Member
  • *****
  • Posts: 540
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #406 on: November 24, 2022, 05:52:13 PM »
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:
Code: [Select]
coprocessor_moveto(0xf,0,0,&LAB_e021cb60,in_cr12,in_cr0);

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:
Code: [Select]
  if (bVar5) {
    handle_interrupt();
    DAT_0000100c = DAT_0000100c + -1;
    return *puVar6;
  }
  handle_interrupt();
  thunk_FUN_df003028();
  change_running_task_maybe(&PTR_0000101c,&PTR_00001020);

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