Canon 7D Mark II

[heder]

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.   

[names_are_hard]

Interesting and seems good progress!

I've had the dma_memcpy stub found for 200D for a long time but the copy speed isn't very high.  It would really help if you could link to the commit where you make these changes (what am I supposed to do with the DMA_BASE info?  How do I use this?).  Given the clues, maybe this is CONFIG_EDMAC_MEMCPY related?  I've avoided that code so far because it wants a lot of EDMAC stubs found.  I've never worked with D45 cams, so I don't know how EDMAC is supposed to work when doing a port.  The more you can share about *how* you're finding things, the better chances I'll have to understand how to do similar on other cams.

7D2 has some of the same strings I'm finding useful in 200D, but not all of them.  A large difference is that they are mostly in the Omar code.  Omar is another ARM core, which the ICU initialises by copying part of the ROM over.  It's Thumb capable.  I suspect ShtVfx processing is all done on Omar.  So you may need to look there for EDMAC usage.  I'm fairly sure the EDMAC hardware has the same interface as D45.  This has been discussed on Discord before, you should find recent references if you search for Omar.

E.g. see "ShtVfxMultiShotPathState" - this exists in 200D main rom, doesn't exist in 7D2 main rom, but is in Omar instead.  E.g. e008f84a() on 200D is 01af4ae8() on 7D2 Omar.  Most of the MultiShot functions seem to use EDMAC.

[heder]

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)

[names_are_hard]

Great, thanks a lot, good write up!  So this is an improvement on an old system.  Sounds useful and will be interesting to see how it interacts with EDMAC - can we use both at once, do we hit ram limits, etc?

Doesn't look like we use dma_memcpy() much, but there are a few places.  I'll see if I can improve mem benchmark module with this change, and test on a few cams.

[heder]

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%.

[names_are_hard]

I played around with this and now understand it more.  I haven't been able to do direct comparison between EDMAC on modern digic and fast dma_memcpy(), for complicated reasons.

Heder isn't using dma_memcpy() the *function*, he's using the underlying physical DMA controller in a similar manner to how the code tries to do it, but via direct access.  I suspect the reason you're doing that is because dma_memcpy() doesn't work on 7D2?  At least, that's what I find: it always fails for me, taking the "Nothing DMA ch now!" path, which I think means it fails to find a free DMA channel, possibly because they haven't been initialised.

7D2 has EDMAC, and it lives on Omar core.  https://www.magiclantern.fm/forum/index.php?topic=26249.msg245605#msg245605

If we want to use EDMAC resources that are sometimes used by *any* DryOS instance, we may have to go through Omar, or we're going to get into trouble with races / contention of physical resources.  If we can find channels / ports that are never used by DryOS then we can probably do stuff direct from ICU.  Or if there's some signalling method, RPC or interrupts etc to synchronise across cores.

D7 has a very different dma_memcpy() to older gens.  The functionality is the same, but the code is doing things in a very different way, no use of digic registers are easily found.  Might exist deeper into the code, I haven't spent a lot of time on it (EDMAC works for memory copies here).

Given that dma_memcpy() looks deliberately not working on 7D2 ICU, but does work on Digic 7, maybe this functionality is supposed to happen via Omar on D6?  It's not clear to me.

[names_are_hard]

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?

[heder]

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)

[names_are_hard]

Nice, glad it's useful to you!  I've been looking for these for ages (more the 200D ones really), and now I know how to do it, it's not even that hard to find.  But the docs for what anything means are so fragmentary

The EDMAC stuff you're talking about helps me, it's easier to understand the wiki page now: https://magiclantern.fandom.com/wiki/Register_Map#EDMAC

It would make sense to me if you could read back the edmac_info region values, I'll try that.  I want to map out usage, I assume channels get remapped when in different modes / purposes.  I'm reading up on EDMAC (again) and intend to run tests on 200D - Digic 7 doesn't have Omar, and we can patch rom via MMU, so it's easier.  The code in edmac-memcpy.c has a lot of very ugly hard-coded values, as does the module.  I will look at making these general, should help me understand how things work, and it would be good to have these working on modern cams.

Re running code on Omar, I can think of a few ways.  The cleanest would be finding an existing Canon RPC mechanism.  It feels likely this exists (probably the code near fe0a30b2 is doing RPC with Omar).  If it doesn't, or we can't find it, since Omar is running DryOS, and ICU supplies the firmware it runs, it wouldn't be that hard to create our own RPC.  Bilal pointed me at some experiments on Eeko RPC here: https://www.magiclantern.fm/forum/index.php?topic=13408.msg175842#msg175842  Might be useful?  It's not clear how it triggers code in shared mem to run, presumably via the 0xc0XX_YYYY registers, but it's not explained.

So, we have options.  Since I don't know how to use EDMAC yet perhaps it makes sense for you to get it working however you want, and I can try and make a cleaner RPC method if needed.  Presumably 5D4 is similar, would be nice to have it somewhat general.

lv_save_raw is new to me.  The function just sets a flag, and indeed forum search suggests "There's a debug flag (lv_save_raw) that enables this".  I see that CONFIG_EDMAC_RAW_SLURP is supposed to be "better" than lv_save_raw.  Trying to understand this from reading forum posts is so incredibly slow.  I'm glad you're still around to keep the old knowledge alive

Possibly related...  take a look at 7d2 master rom1, fe25570a.  This is clearly Omar init related and looks to be doing something EDMAC.

I believe 13dfe() is send_msg_to_Omar(), there's a similar ComForOmar on the other side.  No idea on the message contents (refs Postman, so probably the same system, whatever that is).

[names_are_hard]

fe0ad874 is load_Omar().  This copies (somehow, indirectly) Omar firmware from 7D2 master, and does some other region setup.

I would guess 0xdff0_0000 is mirrored to 0x8000_0000, 0xdff4_0800 to 0x8000_0800.  However, my quick tests on phys cam don't make sense.  Maybe I did something wrong, maybe my assumptions are wrong.  Either way, it seemed potentially useful enough that I wanted to share before fully understanding it.

Bear in mind, we think the Omar core is Digic 5: ARMv5t.  D6 is ARMv7-R.  I know that's not forward compatible: -R has hardware division ops.  Can't remember if it's backwards compatible.  I think so?  Running Omar code from ICU may be dumb for a bunch of other reasons too, but you know that

EDIT: mistake identified.  I'd got two comments in the wrong places in a struct.

Code Select Expand


omar_dst_01 0xdff00000        // this is mapped as Omar atcm at 0x0
icu_src_01  code at 0xfe6afd04
len_01      0x6c80
omar_dst_02 0xdff40800        // this is mapped as Omar btcm at 8000_0800
icu_src_02  code at 0xfe6b698c
len_02      0xa0f0
omar_dst_03 0x1ac0000
icu_src_03  0xfe6c0a84
len_03      0x95c8
omar_dst_04 0x1ae0000
icu_src_04  0xfe6ca054
len_04      0x1f2ea8


So, all the Omar EDMAC func code should be readable (and writable!) in the dff40800 region.  Good luck flushing Omar's icache, I guess.

[heder]

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 

[heder]

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 ?

[names_are_hard]

It may not be safe to run the Omar code from ICU.  These cores are similar but different ARM architectures.  The code may not be compatible with ICU.  I also don't know if this code is truly PIC.  Arm code tends to be mostly PIC by default, but this is no guarantee it all is.  And, calling shamem_read() from ICU may well give incorrect results - assuming it's intended to be read from Omar, the masking may be the reverse of what you expect.

Some of the EDMAC routines obtain kernel locks before proceeding.  Since the Omar core is running an entirely different instance of the OS, I wouldn't expect these to be shared locks with the ICU.  This is untested.  And, since the kernel locks probably aren't shared between different OS instances, the cam will crash if you contest for resources on different cores.

The Omar 0x8000_6XXX code is populated by a copy from fe6X_YYYY rom region.  See the struct created in fe0ad874().  After the copy, the memory is visible at 0xdfXXXXXX on 7D2, or 0x8000_XXXX on Omar - I haven't tested writing the 7D2 side so I don't know if this is a mirror (my guess) or a copy.

Triggering arbitrary code from Omar looks easy, so this may be the safer route.  That way we know code is running in the intended context.  If you can prove all the code is appropriate and safe to run from ICU context that's fine too.  Feels like more work to me.  It also seems fairly likely there is an existing RPC mechanism.

The shamem info is useful to me, thanks.  I've not worked with this before, it doesn't seem to exist on D7 and above.

[heder]

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

[names_are_hard]

Can't trust anything you read   Nothing beats testing.  I would expect 0x8XXXYYYY to be separate (different address space?) comparing Omar and ICU.  But I'm guessing 0xdfXXYYYY is mirrored, so it doesn't matter.  If Omar instead copies from that range into 0x8XXXYYYY, then it may be harder to mess with.

[heder]

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 

[names_are_hard]

I have no problem with hacks while exploring   Only if we give stuff to other people do we need to make sure it's doing things in a sensible way.

Which old RPC stubs are these?  Omar is a new core with digic 6.  Something like Eeko, but not the same.

[heder]

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)


[names_are_hard]

Ah, that RPC handler.  Isn't that the one for doing master-slave comms?  7D2 has master, slave *and* Omar.

[heder]

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

[names_are_hard]

Ah, okay, so not a confirmed Omar RPC function.  Oh well   Yes, I've seen that msg send function.  I haven't tried logging it to see what it sends, don't know if it allows RPC.

Something I hadn't noticed before from that wiki page, they claim Omar is also R4.  I thought it was a Digic 5 chip, but if it's R4 I'm wrong.  Could use cpu ID registers to check.  If it is, then we at least know the Omar firmware blob is compatible with ICU (we still don't know if it all makes sense to run from ICU context).

[kitor]

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

[heder]

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"

[names_are_hard]

Both 7D2 master and slave have their own Omar.  I've done a little investigation, I have suspicions that it might be a true dual-core part, if so, this is "dual-socket dual-core", with four R4 cores in total.  Hard to prove fully without a nice x-ray machine I suppose

[kitor]

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

Huh? D6 is one R4 core (Marius, what we call ICU) and one secondary R4 (Omar), also one secondary Xtensa (Zico, GPU accel) and two tiny cores (Arima, Shirahama; IIRC Xtensa, in single CPU models related to lens comm. They run tiny dryos variant like MPU)
7D2 has two physical D6 chips, thus twice that. So four R4 cores in total across two physical CPUs.