Messages

R4, source via reyalp at CHDK -> https://chdk.setepontos.com/index.php?topic=11316.msg142241#msg142241

Thia is really convenient and will make the port more easy, but still it's a strange beast, "dual core + single core"

Yes, it easily get confusing, with this new design. There's also a function to send message to Omar, FMID_COM_SengMsgToOmar, but I have not tried to decode that function. Use many places and afterward the code wait for TakeSemaphore.

I getting confused reading this page:
https://chdk.fandom.com/wiki/Digic_6-7_Porting

It's pretty sure it's nearly the same like the old api. RequestRPC has the same arguments. RegisterRPCHandler on 7D2 has a third argument, but it's always 0.

The two important RPC functions:
THUMB_FN(80003416, RPCRegisterHandler)   
THUMB_FN(8000351e, RequestRPC)

Current prototypes from dryos.h

Code Select Expand


uint32_t RegisterRPCHandler (uint32_t rpc_id, uint32_t (*handler) (uint8_t *, uint32_t));
uint32_t RequestRPC (uint32_t id, void* data, uint32_t length, uint32_t cb, uint32_t cb_parm);


Ghidra Examples:

Code Select Expand


RegisterRPCHandler(0x4005,DAT_fe0ba558,0); // Id, and handler function (DAT_fe0ba558 points to a function at FE0B9F7Bh)
RequestRPC(0x1024,0,0,0,0); // only Id
RequestRPC(&LAB_00002046,puVar1,4,0,0); // Id, data and size of data (puVar1 is pointer to a 32 bits variable)


Can't trust anything you read   Nothing beats testing.

Yea, testing is always required 

Bascially i'm trying to work my way out of RPC'ing too much, eventually we'll properly have to do this,  but I want to explore the options not to. Dont get me wrong, RPC'ing is the right way, but  jumping over the fence at the smallest point is'nt the worst approch either.

I did try to locate the RPC function on the Omar side but failed  , on the ICU side they're quite easy to find, the naming is the same as the old stubs.

Also I wonder (yes another test to do done) if Omar support but uncacheable bit. The Omar EngDrvOut/shamem_read and friends uses a pointer stored in RAM to read/write shadow values. I could alternate this pointer value and set the uncacheable bit, but I wonder if Omar support this. If it does, both cores would be in sync, when using these function.  I also wonder is writing to a uncache address in ICU will clear the cache version in Omar, if Omar has a cache version of the value..

soo many question, too few answers 

Accordingly to ARM TCM memories are non-cacheable non-sharable normal memory. I wonder if the 0x80000000 is real TCM memory ...

8000626a EngDrvOut
800062a4 EngDrvBits
800062ba EngDrvOuts
80006298 shamem_read
800063c2 StartEDmac
80006498 edmac_set_addr
800064c2 edmac_set_size
80006bfe ConnectWriteEDmac
80006c10 ConnectReadEDmac
80006c42 RegisterEDmacCompleteCBR

These are also present at the 0xfe6b698c region and stubs can be created and included in stubs.h the only question is ... does the EDMAC system known which core called RegisterEDmacCompleteCBR ?

[Big post]

Big post 

This is a kinda of magic. In programming there a way of saying that there's two kind of people those that understand and those does does not. 1+1=10 , but the truth is right now that when we do ping pong reverse engineering the truth is more like 1+1=3. In fact we don't need to access to omar core at all, we now have everything we need now. The omar btcm memory 0x80000000 is mapped the other core, were we're running ML. Take a deeper look and the puzzle suddenly become much more clear. The function names_are_hard in fact accessible and useable from both cores.

1. Shadow memory, aka. shamem_read.

From Wiki:
In computing, shadow memory is a technique used to track and store information on computer memory used by a program during its execution. Shadow memory consists of shadow bytes that map to individual bits or one or more bytes in main memory. These shadow bytes are typically invisible to the original program and are used to record information about the original piece of data.

This functionality was introducted in DIGIC 4 processor. I was working on the DIGIC 3 (40D) which was missing huge parts of the API that was present in the DIGIC4 camera's. Remeber that DIGIC4 camera's where the foundation of ML. shamem_read was missing on 40D so I had to understand it, and create a software abtration layer was mimicked this. The reason behind this is cost (assumption), i.e. time to design and manufactor a complex SoC system. Look at the EDMACs where the first few registers are read/writeable, yet the last EDMAC registers are not. This have never changed since D3 processor. The reason is the SoC design become more and more complex. If you design a SoC and need to make all registers (register in GPIO address space) read/writeable is will cost you a lot of additional logic and internal wires. You could make it much more simple if you only allow to write to a part design without being capable of reading, this would save you internal wires and clock logic. Yet if you still needed to read some of these registers a simple solution is present, just to copy the value you write to shadow memory, i.e. backup memory, before you actually write the value of the GPIO.

On DIGIC 4+ camera (1300D), the shadow memory shamem_read/EngDrvOut mask is 0x3FFFF, meaning there a table 65k longs of shadow GPIO values, example:

EngDrvOut(0xC0F06084,0x12345678)
Step 1.  *(shadow_mem_ptr| 0x3FFFF & 0xC0F06084) = 0x12345678
Step 2.  *0xC0F06084 = 0x12345678

The shadow memory range is different on newer than older cameras, On the 7D2 the mask is 0xD007FFFF, which equal 131k logns of shadow values. The shadow memory is inside SDRAM and accessible to us. The only draw back is that Canon ONLY calls EngDrvOut and friends when the need to store the shadow value, while other times they access the GPIO directly and thus the shadow values is not updated.

2. PIC mapped 0xdffffxxxx to omar internal cache 0x80000000
This is really a gem named_are_hard has found. The code is PIC code (position independent code) using generic arm instructions that can be used any both processor. Basically this mean that both cores can used these functions. The Omar code we need is sitting at "icu_src_02 code at 0xfe6b698c", here all the function are that we need.  shamem_read sitting at 0xfe6bc424 works flawlessly, I tested it. 

3. Write access to GPIO on both core, yahoo!.
[/b]I tried reading from the 0xD007FFFF range, but failed, that is because I did not know that the individual sub port of the SoC no longer have read access and that the shadow memory range was expanded, on the 40D alot of value where still readable, but on 7D2 they're not. Write however works from both cores!, so we can overwrite any GPIO value from any core.

Final thoughts:

4. I don't see any reason anymore to access and change the omar core, we should have everything we need.

5. A minor problem we are facing is more of an internal coding. The MEM() macro is now outdated. On the 7D2 we now need to use the shamem_read for all 0xD007FFFF read operations, which MEM() does not allow for. The MEM() macro does not specific if you going to read or write, it just cast into a *uint32_t pointer. In the 7D2 case we now need MEM(address,operation), where operation can either we read or write. If it's a write we can do it directly, but if it's a read we need to call shamem_read() and I guess this is also the same with D78X

6. Another minor problem is that some values are not stored in the shadow memory or might have change position.

Proff of concept:

I ran some tests on overwriting FPS A + FPS B register in run_test() and got the FPS down to approx 1-2 fps seconds  .

Code Select Expand


MEM(0xD0006008)= 0x7d207d2;
MEM(0xD0006014)= 1234;
MEM(0xD0006000)= 1;
   

EDMAC's taking while in LiveView (HD mode).  I got more EDMAC values now, but keep in mind the Shadow memory is only update when Canon call EngDrvOut and frields, many places the EDMAC are accessed directly and thus we don't see these value.

Code Select Expand


*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x2
0x4 = 0x20301008
0x8 = 0x1A67C000
0xC = 0x0
0x10 = 0x42B0D90
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1288800
0xC = 0x0
0x10 = 0x19705A0
0x14 = 0x0
0x18 = 0x20
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x4
0x4 = 0x20008000
0x8 = 0x1F02E000
0xC = 0x0
0x10 = 0x4370F00
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x31EB200
0xC = 0x4A
0x10 = 0x1000
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x4
0x4 = 0x0
0x8 = 0xAB32B8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004900
0x0 = 0x4
0x4 = 0x20001000
0x8 = 0x46D8E8
0xC = 0x0
0x10 = 0xDF07D0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x20001000
*************************************
Edmac = 0xD0004A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0xA5AB88
0xC = 0x0
0x10 = 0x42B0008
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x60000000
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x4
0x4 = 0x60000000
0x8 = 0x3180D00
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x16F3E800
0xC = 0x0
0x10 = 0x3FB0E30
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0xB
0x14 = 0xC0000030
0x18 = 0x1
0x1C = 0x0
0x20 = 0x0
0x24 = 0x33
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x1
0x4 = 0x60000000
0x8 = 0x32AA400
0xC = 0x12
0x10 = 0xC00
0x14 = 0x1000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A49DBC0
0xC = 0x0
0x10 = 0x160050
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x79
0x10 = 0x1EC0
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026600
0x0 = 0x2
0x4 = 0x60001008
0x8 = 0x0
0xC = 0x39
0x10 = 0x7610
0x14 = 0x8000
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x4
0x4 = 0x20000000
0x8 = 0x1A478000
0xC = 0x0
0x10 = 0x11C03B6
0x14 = 0x0
0x18 = 0x14A
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x0
0xC = 0x1FFF
0x10 = 0xFFFE
0x14 = 0xFFFE
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x4
0x4 = 0x0
0x8 = 0x1830A800
0xC = 0x0
0x10 = 0x1670500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x6
0x4 = 0x300008
0x8 = 0x1A685A00
0xC = 0x0
0x10 = 0xF01E0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x6
0x4 = 0x40300008
0x8 = 0x1A683E00
0xC = 0x0
0x10 = 0xC0200
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x6
0x4 = 0x300008
0x8 = 0xBACC80
0xC = 0x0
0x10 = 0x28
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x4
0x4 = 0x0
0x8 = 0x3397300
0xC = 0x0
0x10 = 0x3B00A0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030A00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x183166A6
0xC = 0x0
0x10 = 0x11A03B2
0x14 = 0x0
0x18 = 0x14E
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x4
0x4 = 0x0
0x8 = 0x184D2800
0xC = 0x0
0x10 = 0x1DF0500
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
0x10 = 0x0
0x14 = 0x0
0x18 = 0x0
0x1C = 0x0
0x20 = 0x0
0x24 = 0x0
0x28 = 0x0
0x2C = 0x0
0x30 = 0x0
0x34 = 0x0
0x38 = 0x0
0x3C = 0x0


GPIO taking while in LiveView (HD mode). Keep in mind the offsets are wrong 0xC0FXxxxx have changed to 0xD00XXXX. Some values seems to have change position (they're 0 ), but is you scroll down, you'll see all the LV size values are in the same positions as before, some time must be spend on finding the new positions for the missing value i.e. raw width and height for RAW video have changed position or is not recorded.

Code Select Expand


MEM(0xC0F03074) = 0x0 (Playback: horizontal banding (500D only?))
MEM(0xC0F03050) = 0x0 (Playback: vertical banding / darken?)
MEM(0xC0F08024) = 0x1000 (ISO related? (SHAD_MODE) (5D2: used for ISO 25600))
MEM(0xC0F08030) = 0x14C0 (Digital gain for ISO (SHAD_GAIN))
MEM(0xC0F08034) = 0x0 (Black level in LiveView / BW offset in photo mode (SHAD_PRESETUP))
MEM(0xC0F0819C) = 0xC38 (Saturate Offset (photo mode) (HIV_POST_SETUP))
MEM(0xC0F12054) = 0x0 (White level?)
MEM(0xC0F06000) = 0x0 (FPS register for confirming changes)
MEM(0xC0F06004) = 0x0 (FPS related, SetHeadForReadout)
MEM(0xC0F06008) = 0x0 (FPS register A)
MEM(0xC0F0600C) = 0x0 (FPS related)
MEM(0xC0F06010) = 0x0 (FPS related)
MEM(0xC0F06014) = 0x0 (FPS register B)
MEM(0xC0F06018) = 0x0 (FPS related)
MEM(0xC0F0601C) = 0x0 (FPS related)
MEM(0xC0F06020) = 0x0 (FPS related)
MEM(0xC0F06084) = 0x0 (RAW first line|column. Column is / 2. 600D: 0x0001007E.)
MEM(0xC0F06088) = 0x0 (RAW last line|column. 600D: FHD 1182|1070, 3x 1048|1102, HD 720|1070)
MEM(0xC0F06800) = 0x0 (RAW first line|column. Column is / 8 on 5D3 (parallel readout?))
MEM(0xC0F06804) = 0x0 (RAW last line|column. 5D3: f6e|2fe, first 1|18 => 5936x3950)
MEM(0xC0F07000) = 0x0 (HEAD timers (SSG counter, 0x01 to restart))
MEM(0xC0F07004) = 0x0 (HEAD timers)
MEM(0xC0F0700C) = 0x0 (HEAD timers, 0x01 to stop/standby)
MEM(0xC0F07010) = 0x0 (HEAD timers)
MEM(0xC0F07014) = 0x0 (HEAD timers)
MEM(0xC0F07018) = 0x0 (HEAD timers)
MEM(0xC0F0701C) = 0x0 (HEAD timers)
MEM(0xC0F07038) = 0x0 (HEAD timers, 0x01 <- stops processing?)
MEM(0xC0F0707C) = 0x0 (HEAD timers)
MEM(0xC0F071AC) = 0x0 (HEAD timers)
MEM(0xC0F070C8) = 0x0 (HEAD timers, State 2 Register / VCount?)
MEM(0xC0F07048) = 0x0 (HEAD1 timer (start?))
MEM(0xC0F0704C) = 0x0 (HEAD1 timer)
MEM(0xC0F07050) = 0x0 (HEAD1 timer (ticks?))
MEM(0xC0F0705C) = 0x0 (HEAD2 timer (start?))
MEM(0xC0F07060) = 0x0 (HEAD2 timer)
MEM(0xC0F07064) = 0x0 (HEAD2 timer (ticks?))
MEM(0xC0F07134) = 0x0 (HEAD3 timer (start?))
MEM(0xC0F07138) = 0x0 (HEAD3 timer)
MEM(0xC0F0713C) = 0x0 (HEAD3 timer (ticks?))
MEM(0xC0F07148) = 0x0 (HEAD4 timer (start?))
MEM(0xC0F0714C) = 0x0 (HEAD4 timer)
MEM(0xC0F07150) = 0x0 (HEAD4 timer (ticks?))
MEM(0xC0F08D1C) = 0x0 (Vignetting correction data (DIGIC V))
MEM(0xC0F08D24) = 0x0 (Vignetting correction data (DIGIC V))
MEM(0xC0F08578) = 0x0 (Vignetting correction data (DIGIC IV))
MEM(0xC0F0857C) = 0x0 (Vignetting correction data (DIGIC IV))
MEM(0xC0F140C4) = 0x0 (Display saturation)
MEM(0xC0F141B8) = 0x0 (Display brightness and contrast)
MEM(0xC0F14140) = 0x0 (Display filter (EnableFilter, DIGIC peaking))
MEM(0xC0F14164) = 0x0 (Display position (vertical shift))
MEM(0xC0F140CC) = 0x0 (Display zebras (used for fast zebras in ML))
MEM(0xC0F37AE4) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AF0) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AFC) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37B08) = 0x200 (ISO digital gain (5D3 photo mode))
MEM(0xC0F37AE0) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37AEC) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37AF8) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F37B04) = 0x73C8 (ISO black/white offset (5D3 photo mode))
MEM(0xC0F08004) = 0x0 (DARK_MODE (bitmask of bits 0x113117F))
MEM(0xC0F08008) = 0x0 (DARK_SETUP (mask 0x7FF signed) (brightns/darkens frame))
MEM(0xC0F0800C) = 0x0 (DARK_LIMIT (mask 0x3FFF) (no noticeable change))
MEM(0xC0F08010) = 0x0 (DARK_SETUP_14_12 (mask 0x07FF) (brighten, overwrites DARK_SETUP))
MEM(0xC0F08014) = 0x0 (DARK_LIMIT_14_12 (0x0000 - 0x0FFF) (no noticeable change))
MEM(0xC0F08018) = 0x0 (DARK_SAT_LIMIT (0x0000 - 0x3FFF) (no noticeable change))
MEM(0xC0F082A0) = 0x0 (DARK_KZMK_SAV_A (0/1) (causes white or black screen))
MEM(0xC0F082A4) = 0x0 (DARK_KZMK_SAV_B (0/1) (no noticeable change))
MEM(0xC0F08100) = 0x0 (CCDSEL (0-1))
MEM(0xC0F08104) = 0x0 (DS_SEL (0-1))
MEM(0xC0F08108) = 0x0 (OBWB_ISEL (0-7))
MEM(0xC0F0810C) = 0x0 (PROC24_ISEL (0-7))
MEM(0xC0F08110) = 0x0 (DPCME_ISEL (0-15))
MEM(0xC0F082D0) = 0x0 (PACK16_ISEL (0-15))
MEM(0xC0F082D4) = 0x0 (WDMAC32_ISEL (0-7))
MEM(0xC0F082D8) = 0x0 (WDMAC16_ISEL (0-1))
MEM(0xC0F082DC) = 0x0 (OBINTG_ISEL (0-15))
MEM(0xC0F082E0) = 0x0 (AFFINE_ISEL (0-15))
MEM(0xC0F08390) = 0x0 (OBWB_ISEL2 (0-1))
MEM(0xC0F08394) = 0x0 (PROC24_ISEL2 (0-1))
MEM(0xC0F08398) = 0x0 (PACK32_ISEL2 (0-3))
MEM(0xC0F0839C) = 0x0 (PACK16_ISEL2 (0-3))
MEM(0xC0F083A0) = 0x0 (TAIWAN_ISEL (0-3))
MEM(0xC0F08220) = 0x0 (ADKIZ_ENABLE?)
MEM(0xC0F08224) = 0x0 (ADKIZ_THRESHOLD)
MEM(0xC0F08238) = 0x0 (ADKIZ_INTR_CLR)
MEM(0xC0F0825C) = 0x0 (ADKIZ_THRESHOLD_14_12)
MEM(0xC0F08234) = 0x0 (ADKIZ_TOTAL_SIZE)
MEM(0xC0F0823C) = 0x0 (ADKIZ_INTR_EN)
MEM(0xC0F08060) = 0x0 (DSUNPACK_ENB?)
MEM(0xC0F08064) = 0x0 (DSUNPACK_MODE)
MEM(0xC0F08274) = 0x0 (DSUNPACK_DM_EN)
MEM(0xC0F08130) = 0x1 (DEFM_ENABLE?)
MEM(0xC0F08138) = 0x0 (DEFM_MODE)
MEM(0xC0F08140) = 0x0 (DEFM_INTR_NUM)
MEM(0xC0F0814C) = 0x5 (DEFM_GRADE)
MEM(0xC0F08150) = 0x0 (DEFM_DAT_TH)
MEM(0xC0F08154) = 0x0 (DEFM_INTR_CLR)
MEM(0xC0F08158) = 0x0 (DEFM_INTR_EN)
MEM(0xC0F0815C) = 0x0 (DEFM_14_12_SEL)
MEM(0xC0F08160) = 0x0 (DEFM_DAT_TH_14_12)
MEM(0xC0F0816C) = 0x0 (DEFM_X2MODE)
MEM(0xC0F08180) = 0x1 (HIV_ENB)
MEM(0xC0F0818C) = 0x0 (HIV_POS_V_OFST)
MEM(0xC0F08190) = 0x0 (HIV_POS_H_OFST)
MEM(0xC0F08420) = 0x4FF (HIV_BASE_OFST)
MEM(0xC0F08428) = 0x0 (HIV_GAIN_DIV)
MEM(0xC0F0842C) = 0x0 (HIV_PATH)
MEM(0xC0F08218) = 0x0 (HIV_IN_SEL)
MEM(0xC0F08214) = 0x0 (HIV_PPR_EZ)
MEM(0xC0F082C4) = 0x0 (HIV_DEFMARK_CANCEL)
MEM(0xC0F08240) = 0x0 (ADMERG_INTR_EN)
MEM(0xC0F08244) = 0x0 (ADMERG_TOTAL_SIZE)
MEM(0xC0F08250) = 0x0 (ADMERG_2_IN_SE)
MEM(0xC0F08020) = 0x0 (SHAD_ENABLE?)
MEM(0xC0F08028) = 0x0 (SHADE_PRESETUP)
MEM(0xC0F0802C) = 0x0 (SHAD_POSTSETUP)
MEM(0xC0F08038) = 0x800 (SHAD_POSTSETUP_14_12)
MEM(0xC0F08280) = 0x0 (SHAD_CBIT)
MEM(0xC0F08284) = 0x0 (SHAD_C8MODE)
MEM(0xC0F08288) = 0x0 (SHAD_C12MODE)
MEM(0xC0F08290) = 0x0 (SHAD_COF_SEL)
MEM(0xC0F0828C) = 0x0 (SHAD_RMODE)
MEM(0xC0F082A8) = 0x0 (SHAD_KZMK_SAV)
MEM(0xC0F08040) = 0x0 (TWOADD_ENABLE)
MEM(0xC0F08044) = 0x0 (TWOADD_MODE)
MEM(0xC0F08050) = 0x0 (TWOADD_SETUP_14_12)
MEM(0xC0F08054) = 0x0 (TWOADD_LIMIT_14_12)
MEM(0xC0F08048) = 0x0 (TWOADD_SETUP)
MEM(0xC0F0804C) = 0x0 (TWOADD_LIMIT)
MEM(0xC0F08058) = 0x0 (TWOADD_SAT_LIMIT)
MEM(0xC0F082AC) = 0x0 (TWOA_KZMK_SAV_A)
MEM(0xC0F082B0) = 0x0 (TWOA_KZMK_SAV_B)
MEM(0xC0F08114) = 0x0 (LV raw type (see lv_af_raw, lv_set_raw) - DIGIC IV (PACK32_ISEL))
MEM(0xC0F37014) = 0xE (LV raw type (see lv_af_raw, lv_set_raw) - DIGIC V)
MEM(0xC0F10064) = 0x42B01EF (LV resolution (RAW.height | RAW.width))
MEM(0xC0F080B0) = 0x0 (LV resolution (RAW.height | RAW.width))
MEM(0xC0F08184) = 0x0 (LV resolution (RAW.height) aka HIV_V_SIZE )
MEM(0xC0F08188) = 0x0 (LV resolution (RAW.width) aka HIV_H_SIZE )
MEM(0xC0F08194) = 0x0 (LV resolution (RAW.width))
MEM(0xC0F08198) = 0x0 (LV resolution (RAW.width))
MEM(0xC0F1D014) = 0x0 (LV resolution (raw.j.height? | raw.j.width?))
MEM(0xC0F11394) = 0x3FB0717 (LV resolution (raw.j.height | raw.j.width))
MEM(0xC0F1151C) = 0x437077F (LV resolution (raw.j.height | raw.j.width))
MEM(0xC0F1A00C) = 0x3FB0717 (LV resolution (raw.j.width | raw.j.height))
MEM(0xC0F25054) = 0x0 (LV resolution (raw.j.width))
MEM(0xC0F2500C) = 0x0 (LV resolution (raw.j.width))
MEM(0xC0F1155C) = 0x437077F (LV resolution (raw.j.height | hd.width))
MEM(0xC0F112D4) = 0x16F0280 (LV resolution (raw.j.height | ?) before upsampling?)
MEM(0xC0F11314) = 0x2D0027 (LV resolution (raw.j.height | lv.width) before upsampling?)
MEM(0xC0F08548) = 0x0 (LV resolution * downsize factor? (RAW.height * D | RAW.width * D))
MEM(0xC0F09050) = 0x340031 (Aewb metering area (y1|x1))
MEM(0xC0F09054) = 0x41401E1 (Aewb metering area (y2|x2))
MEM(0xC0F383D4) = 0x0 (Preview area (y1 | x1/4))
MEM(0xC0F383DC) = 0x41001C8 (Preview area (y2 | x2/4))
MEM(0xF000180E) = 0x0 (Blue LED)
MEM(0xF0001810) = 0x0 (LightMeasure)
MEM(0xF0001D02) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D04) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D06) = 0x0 (DFE gain (similar to ADTG 888x))
MEM(0xF0001D08) = 0x0 (DFE gain (similar to ADTG 888x))



My time for ML this year is running out, Christmas & New Year is closing in fast, but the fact that we have come so far now is cool, ML is comming to 7D2 

After a lot of reading very old forum posts, and much messing about in Ghidra, I now have some important stubs found for 7D2 1.1.2.  These are all on Omar:

8000626a EngDrvOut
800062a4 EngDrvBits
800062ba EngDrvOuts
80006298 shamem_read
800063c2 StartEDmac
80006498 edmac_set_addr
800064c2 edmac_set_size
80006bfe ConnectWriteEDmac
80006c10 ConnectReadEDmac
80006c42 RegisterEDmacCompleteCBR

Alex's notes say edmac_set_addr() and edmac_set_size() together act like SetEDmac, I haven't checked that.  If true, we can wrap these together to provide that function.

As is, we cannot call these functions from ICU.  The 0x8000_XXXX address space does not contain the same content if you read it from ICU vs Omar.

Heder - are any other stubs required to attempt reading from e.g. the sensor?  To be safe, we need to find unused channels - anything else?

This is really good news. From a minimalistic approach, the only thing we really need is access from omar so we can use: shamem_read, EngDrvOut and EngDrvIn (not used in Canon's code anymore ?, equvivalent to the MEM macro).  We could also go for a larger approach, i.e. get access to all functions or similar, but time has never cheap, and my sweet wife is actually getting slightly annoying when I spend too much time digging into assembly code @ home, so I need to use my time with caution. Accessing these 3 function are the minimum, the remaining can be supported in function-overrides.c. I tried accessing all of the old raw video registers (old 0xc0fxxxx now relocated to 0xd00xxxxx) and found I could NOT get access from ICU, that address range is only to be accessible from omar.

The first few registers from each EDMAC had readback capabilities, all cameras I believe, including the destination registers. I dumped the EDMAC channels a few days ago and there are many free once (atleast in HD video mode). The EDMAC SDRAM destination registers ends is the "0x8". I just need to do more testing HD Live Mode mode and then do a dump and see which one are free. I'm not concerned about not being able to access the EDMAC API from Omar, I can code that myself if needed.

Code Select Expand


*************************************
Edmac = 0xD0004000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405A8F40
0xC = 0x0
*************************************
Edmac = 0xD0004200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004300
0x0 = 0x1
0x4 = 0x0
0x8 = 0x126E9E0
0xC = 0x0
*************************************
Edmac = 0xD0004400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x20000000
0xC = 0x0
*************************************
Edmac = 0xD0004600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004800
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9B2D80
0xC = 0x0
*************************************
Edmac = 0xD0004900
0x0 = 0x1
0x4 = 0x0
0x8 = 0x46DB80
0xC = 0x0
*************************************
Edmac = 0xD0004A00
0x0 = 0x1
0x4 = 0x0
0x8 = 0x9584B8
0xC = 0x0
*************************************
Edmac = 0xD0004B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x16BAEF40
0xC = 0x0
*************************************
Edmac = 0xD0004E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0004F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026400
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026500
0x0 = 0x8
0x4 = 0x0
0x8 = 0x1617A000
0xC = 0x79
*************************************
Edmac = 0xD0026600
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D3EBA0
0xC = 0x14
*************************************
Edmac = 0xD0026700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1840715A
0xC = 0x0
*************************************
Edmac = 0xD0026900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15D38700
0xC = 0x1FEF
*************************************
Edmac = 0xD0026B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x15C8D200
0xC = 0x1FC2
*************************************
Edmac = 0xD0026C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0026F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030000
0x0 = 0x0
0x4 = 0x0
0x8 = 0x18543000
0xC = 0x0
*************************************
Edmac = 0xD0030100
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A683C00
0xC = 0x0
*************************************
Edmac = 0xD0030200
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1A684400
0xC = 0x0
*************************************
Edmac = 0xD0030300
0x0 = 0x0
0x4 = 0x0
0x8 = 0x40ABF4F0
0xC = 0x0
*************************************
Edmac = 0xD0030400
0x0 = 0x8
0x4 = 0x0
0x8 = 0xAA9928
0xC = 0x0
*************************************
Edmac = 0xD0030500
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030600
0x0 = 0x1
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030700
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030800
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030900
0x0 = 0x0
0x4 = 0x0
0x8 = 0x405BFF24
0xC = 0x0
************************************
Edmac = 0xD0030A00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x1835FB80
0xC = 0x0
*************************************
Edmac = 0xD0030B00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030C00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030D00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x409EA314
0xC = 0x0
*************************************
Edmac = 0xD0030E00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0
*************************************
Edmac = 0xD0030F00
0x0 = 0x0
0x4 = 0x0
0x8 = 0x0
0xC = 0x0


call("lv_save_raw",1) also works as expected  , RAW EDMAC is 0xD0004200. I dumped the raw image just to verify that it actually did work, I disregarded synchronization so I only got a part image, but it's raw bayer sensor data.  The raw width is 1984, image size is 1832 the rest 143+9 is black borders, height is still unknown. Unpacked a image quick and dirty, post processed to show the bayer pattern: (press to expand)

We can use both at the same time. I ran the test in photo mode (without other anything running) but also in LV mode - I assume Canon's EDMAC are running here. I did however not benchmark inside LV with recording on. We will hit SDRAM speed limits. On the 7D2 I ran test (photo mode) on a single DMA and got ~525 MB/s, but two parallels only got 599 MB/s, so there is a limit. While testing in LV mode the benchmark dropped around 10%.

The (old) DMA is not related to the EDMAC. This  DMA is a old school DMA engine that was been in the DIGIC chips since the dawn of times, I guess the only problem has been that we're been using it incorrectly, maybe without knowing it's true capacity. There are 4 DMA channels "DMA_BASE's" (0xC0A10000, 0xC0A20000, 0xC0A30000, 0xC0A40000). For each DMA channels the following configuration exists:  https://magiclantern.fandom.com/wiki/Register_Map#DMA

I have checked in my test code here: see the run_test's functions
https://github.com/jmheder/magiclantern_simplified/commit/0ca296a7447ac6b702441ba479ef11d89f6ad063

It's a quick bruteforce way to test the DMA - some of the tests fails (due to incorrect configuration) while others are a success.  While the testing takes place the display will show progress and memcpy transfer speeds, also a log is written  to disk. The test requires SRM memory to work.

But basically a simple version could be:

Code Select Expand


// This code snipped has not been tested .. its an example
#define DMA1_BASE 0xC0A10000
#define DMA2_BASE 0xC0A20000
#define DMA3_BASE 0xC0A30000
#define DMA4_BASE 0xC0A40000

#define DMA_ENABLE      0x0
#define DMA_UNK1        0x4
#define DMA_CONTROL     0x8
#define DMA_UNK2        0xC
#define DMA_ACK         0x10
#define DMA_CONFIG      0x14
#define DMA_SRC         0x18
#define DMA_DST         0x1C
#define DMA_SIZE        0x20

// pseudo memcpy, not tested
memcpy(uint_32t *dst, uint_32t *src, uint32_t size, uint32_t DMA_BASE)
{

  MEM(DMA_BASE+DMA_ENABLE)  = 0x1;
  MEM(DMA_BASE+DMA_UNK1)    = unk1;           //  0 or 2     
  MEM(DMA_BASE+DMA_ACK)     = 0x0;
  MEM(DMA_BASE+DMA_SRC)     = (uint32_t)pSrc;
  MEM(DMA_BASE+DMA_DST)     = (uint32_t)pDst;
  MEM(DMA_BASE+DMA_SIZE)    = size;
  MEM(DMA_BASE+DMA_CONFIG)  = config;         // 0x1 or 0x7 or 0xF

  // start DMA transfer
  MEM(DMA_BASE+DMA_CONTROL) = control;        // 0x1 or 0x30001

  // wait for complete
  while (MEM(DMA_BASE+DMA_ACK)==0)
    msleep(1);
}


There are still unknowns I have not looked at, like DMA_CONFIG defines if interrupt must be used, I don't know how to install these interrupt handler.

CONFIG_EDMAC_MEMCPY is just a EDMAC version of memcpy, properly because the dma_memcpy never was used correctly (i.e. slow dma_memcpy using wrong configuration)

Do you know of a good writeup anywhere?

Not really, I used the post "EDMAC Internals", Fandom wiki and the code.

Too bad the EDMAC api is different, the 7D2 is not like D345 cam's, nor like D78X, it's a unicorn. And while I was getting annoying of the missing EDMAC api, which is a hard requirement for RAW video. I started to look for alternatives, and ended testing the simple DMA memory tranfer which for some unknown reason completly failed, ( I guess I failed to find the dma_memcpy initialization function that initialized the DMA's). I found benchmark on the forum around 80-100 MB/s, but found none at full "EDMAC" speed. I then ended up writing a simple DMA memcpy test and testing different configuration I found in 40D and 7D2 I finally got 599 MB/S (photo mode). I tested two different copy methods single DMA and a parallel double DMA. The speed depends on the configuration values of the DMA, "0x30001" is the magic number. This one could be used as an EDMAC alternative (atleast for the time being, of course only for block copies, raw video "fixed width")

My benchmark from 7D2 (4 MB blocks), the transfer rate speeds depends on which mode your choose (photo,LV):

Single DMA = 70-80 MB/s, slow config (byte copy ?)
Double DMA = 74-84 MB/s, slow config (byte copy ?)
Single DMA = ~525 MB/s, fast config
Double DMA = 559-599 MB/s, fast config

Configuration, see https://magiclantern.fandom.com/wiki/Register_Map#DMA

Slow config:
DMA_BASE+0x04  = 0x0   
DMA_BASE+0x08  = 0x1
DMA_BASE+0x14  = 0x1 or 0x7

Fast config  (all combinations is valid):
DMA_BASE+0x04   = 0x0   
DMA_BASE+0x08  =  0X3001
DMA_BASE+0x14  =  0x1 or 0x7 or 0xf

Fast config (all combinations is valid):
DMA_BASE+0x04   = 0x2   
DMA_BASE+0x08  =  0X30001
DMA_BASE+0x14  =  0x1 or 0x7
   
I also found references to DMA_BASE+0x04 = 0x1 but I did'nt find any success with this value.   

EDMAC address on 7D2. On all other cameras the engine DMA address range was 0xC0Fxxxxx but on the 7D2 it's 0xD00xxxx

0xD0004x00 ; x = channel
0xD0026x00 ; x = channel
0xD0030x00 ; x = channel

I did not find 0xD0027x00

I will try to push the code tomorrow, next week I might need to go traveling, so I'll be busy for the whole week.

Turned out I wasn't pushing my luck with regards to SRM memory, there a limit just above 36MB, so I'll do a bruteforce run and find the correct limit. . Read the exmem.c code check what srm_malloc_crb returns ... 0x2314000 

So far I have only testet it lightly, but in all modes, with and without focus enabled, with and without flash, no crashes yet, seems to be pretty stable and solid. Only bulb mode (dial B) does not shoot if you don't enable bulb timer in ML, but I guess that is the way is should work.

I also been looking for the size of the SRM buffers (to complete the memory system), but failed to find the size, yet it seems it does not matter what size you set the SRM buffer to, the exmem system still works. Tried different sizes (32,33,34,35MB) and all times I succesfully got 5 buffers.

Another thing, less good, once I have executed "dont press me button" with any code more than 8-9 times, the executing time for the next "dont press me button" test takes longer and longer time, feels odd and incorrect. All I did in that run_test code was
foo += 0x100000.

A guess a few stubs is missing if you want to do some debugging ect.

I have the intervalometer running, but need to test is in all condition and all modes, which required me to find DISPLAY_IS_ON, so once I have tested it thoroughly I will push the code.

I have started to search for the remaining stubs, I hope that this task can be compled before newyear. The only thing I'll try to work on (beside finding stubs) is the the advanced intervalometer, because I would like to have it working before my winter/ski/christmas holiday in Sweden. 

Good job. Amazing speed.  , looks real promissing.

Working, stumbled over some strings 

ds "VRAM_InitializeVramPath LVx10"
ds "VRAM_InitializeVramPath LVAf90fps"
ds "VRAM_InitializeVramPath LVx1"
ds "VRAM_InitializeVramPath LVx1Ta10"
ds "VRAM_InitializeVramPath LVx5"
ds "VRAM_InitializeVramPath FHD30P(FLICK)"
ds "VRAM_InitializeVramPath FHD60P"
ds "VRAM_InitializeVramPath FHD30P"
ds "VRAM_InitializeVramPath DIORAMA_FHD"     
ds "VRAM_InitializeVramPath 720P60P"
ds "VRAM_InitializeVramPath VGA"
ds "VRAM_InitializeVramPath DIORAMA_VGA"

What is DIORAMA (?) also interesting with the 90 fps

You've got a large workforce, you just need to get them motivated.  Training the cats to make dinner might be the place to start.

We can update 7D2 version to 1.1.3 if you prefer, I think I picked 1.1.2 because it's the version before they implement downgrade "prevention".  Wouldn't take long to update it, it's a barebones port at present.

I can certainly help with porting work, though I don't recall if I have an easy cable connection for 7D2 uart.  Since it's my work so far, if you have any questions I feel obliged to answer them   You might want to follow the Discord link at the top of the page, it's better for quick questions than the forum (it's like IRC but easier to use).

4 tiny cats will soon have a new home (two weeks left, before we are allowed to pass them to new owners)

Discord, sure, I actually wanted to get on discord, but I ran out of time. I only have "real" time on Tuesdays and Sundays (other days .. it's at most "ghidra" reading days), I'll try to sneak in from time to time, so we can have a discussion.

I prefer to keep "1.1.2" as it. More workload is not preferred.

[Anyone]

I finally got a "little" time to get started, in between cleaning poo from 5 cats, making dinner for 2 kids (wife was working), Cleaning up after 2 kids (refusing to help), cleaning the bathroom, driving forth and back to my old mom, just to switch off her broken fire alarm,  . Anyone that wants to help out porting the 7D2 are warmly welcome, we might actually have some progress in the next month years, and helping out now is the right time.

My software was 1.1.3 and we're building for 1.1.2 so I needed a downgrade. I'm on linux, and EOS utility 3.0 does not run on linux/wine. I took 1.1.2 and put in on a 32 GB highspeed card, but the camera refused to downgrade (it actually checked the version within the FIR update file) and told me that I has the newest version!. I then renamed the file - pretending it was version 1.1.4, but the camera still refused. Then I took a old slow 8GB card and put the 1.1.2 on it, rename it to look like 1.1.4 and now it wanted to start the update procedure, but it failed right away after pressing ok (some odd message). The solution was to resort to the "dual card - switch card when pressing ok" trick. The final solution was:

My downgrade to 1.1.2 

1. Charge your battery to full capacity.
2. Get two CF card, one 8GB and one 32GB.
3. Put Canon firmware "FIR" file for 1.1.2 on both card and change the last digic "2" to "4" in both filenames.
4. Put the 8GB into the camera and initiate the upgrade procedure - but dont press "OK"
5. At the very same time you press "OK" open the card door.
6. Switch the CF cards to the 32GB and close the card door.
7. Wait a minute until the camera allows you to upgrade.
8. Verify that firmware version is 1.1.2
Btw. If your camera break, you get to keep both pieces

Upgrade to 1.1.2:
- Follow canons instructions .. - Follow canons instructions ..

ROM dumper:
- Available at the portable rom dumper page, remember to use a SD card (CF does not work)
- Worked fine, screen was red =>



Enable Bootloader flag:
Somewhere in this thread

Hey nice!  I still have mine.  Build quality is high, cam feels good to use, I really like this one.  ML wise it seems to behave better than 5D4 (but these were both fast ports by me, a day or two, not much testing).

The task creation bug that I mention is quite strange.  I wasn't able to create two tasks "at once".  If I create task A, wait for it to exit, create B, all is fine.  If I create A, create B, cam locks up.  I can't imagine they really moved to a serial model for tasks!  So I guess I either have some stub(s) wrong, or they changed the API for task creation (seems unlikely!  Later cams work as expected).

Repo should build easily on Debian (or similar) with arm-gcc tested at versions 8, 9 and 12.

As far as I recall, Alex never found a way todo cache tricks on DIGIC6 making it near impossible to make a ML port. I even found him (or a person with similar name) asking really naughty question regarding "hacks" on arm homepage, but without any luck. I also recall that ML changes some memory  to reserve stack for track creation. Without cache-patch hacks it's lucky we can even create a single task. If you can create a task, exit it, and then create another task, but not two task at once, it sounds the we're low on heap memory. If this is in fact the problem, I guess the debug-monitor/breakpoint-handler is the only way to continue.

Yes it's really a nice build, much better than I thought.

I'm currently on a Nobara distro (redhat off-brand) and I'll be spending the next week on planning how to proceed, reading up on various thread and reading the current boot code.

[501 days]

Hi all.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

501 days

Took me forever to get my HAM gear sold and getting started to look for a new camera. "M" series M50 I+II, M6 MKII,... : nice camers's but I didn't want to have a additional lens adapter, I like heavy gear, and "M" series is not future proof, "R" is coming. "R" series : really nice camera, but they're still in production, and I won't touch them. It's an ethical decision, I'm and embedded programmer. I'll go "R" in 5-7 years or so. Finally I asked by self a couple of simple questions:

Bang for the buck ?
Biggest challenge ?
I camera that can fulfill my needs for the next 5 years ?


Canon EOS 7D Mark II, with the infamious dual digit 6

Its a powerhorse that is still to be tamed, and even in 2023 it's still a powerhorse with both a CF and a SD(UHS-1) card interface. names_are_hard showed a barebone port, which is a really interesting, so I'll join the fight for the 7D2.  I promise you all nothing, except I'll work a few hours per week, I hope i'm not going to "drown", yet the 40D was a freak too.

OMG .. it's only HUUUEEEEE ! Pimped gimp image (hue-saturation +85 degrees)

Pattern is gone, but colours are screwed up, at least proof that I'm on the right track. I fighting 3 registers: 0xC0F13008, 0xC0F1300C, 0xC0F13010

I tracked down the missing hardcoded registers and they seem to be set correctly, these are JPEG engine registers for control, mode, macro block size, etc, all seem correctly set. If they're set incorrectly the JPEG engine wont work at all. Then I realized that one of the EngDrvsOuts functions was'nt being hijacked logged correctly, and the calls did not go into by log. Oddly I can't hijack this address (function entry) but when I hijacked the next address it worked. So I logged all registers again and looked - but without any new result. This EngDrvsOuts function is only used in some rare cases with the jpeg engine.

So I'm, currently back to changing registers. I have gathered various bits of information regarding these, but nothing conclusive yet. I now need to investigate each registers that is used in conjunction with YUV image transfer in blocks into the JPEG engine, this is around 20 registers around 0xc0f11??? and 0xc0f13???.