Canon 7D Mark II

[heder]

The Master ICU processor has a "DSEngio" engio write (0x00013ea0) function which is used to activate LiveView (0x00017c24), including FPS registers, it's set all the standard FPS registers - but a the new address range 0xD00060{08,10,0c,14}.  This is quite usefull. Inside this engio write function there is a DryOsDebugMessage for each write, I can hijack this DryOsDebugMessage and investigate everything that the master writes. This write is not backup'ed in the shamem_read (shamem seems to only be controlled by the Master Omar processor).

I have created a BL_INST_T2 which performs the same actions as BL_INST but in thumb2 mode, that can be used to hijack instruction BL instructions in thumb2 mode - but ofc only in RAM, also it can only jump +/-22 bits, but this ain't a problem on the 7D2 ML starts around 0x1CC440 which is less than 22 bits from 0x0.

[heder]

I have RAW video up and running. I'm going to Egypt next month Giza, Luxor and the valley on the kings and the Nile, was there 24 years ago, going back so I'm really excited. But going there without ML RAW video is bad karma, so I had to investigate every possible way of getting the camera to do as I wish.

• Tryed ordinary DMA failed, failed it's too slow in LV mode
• Tryed Omar EDMAC functions .. failed, they're not compatible
• Tryed Recreating all edmac functions .. failed
• Tryed direct buffering (edmac not needed) using 14 bits .. success using a very old mlv_lite module

Im was recording the entire RAW buffer including black border, 1984x1068x14bits,  around 85 MiB/s for 24 fps. I will try to record a large file using a fast CF card ( DMA-6)  in the following days to see if I get frame drops. The following video was recording using 25 fps, and recoded to H.264

[names_are_hard]

Nice work!  I'm still struggling with edmac on 200D.

Show me your code or I will send assassins to Egypt

[heder]

The code is pure spaghetti carbonára  . I was hacking for a whole month, nothing worked until I used direct buffering, turned out it worked. But the direct buffering only works on the full stream, i.e. full image, but for a beginning it's quite useful. I have not pushed the code into git I will check-in the mlv_lite in tomorrow. The magic is done in mlv_lite process_frame(), only changed a few lines of code.

[names_are_hard]

Yup, understood.  I have 7D2 so anything I can verify will help me a lot, there's sure to be things I can steal for other cams.

Code can be crap quality for now and made nice before merging to dev branch.

[Walter Schulz]

7D2 is using 3x3 binning as 5D3. So moiré/aliasing should not be a big concern using full sensor.

But why UDMA-6 CF? Cam supports UDMA-7.

[heder]

7D2 is using 3x3 binning as 5D3. So moiré/aliasing should not be a big concern using full sensor.

But why UDMA-6 CF? Cam supports UDMA-7.

I did not see any moiré/aliasing so far, I'll have to do some more testing today.

Yes the camera support UDMA-7, but I never got to the point of buying a UDMA-7 card, as my old camera (40D) is PIO mode only. But I will need to upgrade soon. Btw. in Zoom (x5,x10) mode the format goes to 3616 x 1348, not bad for a beginning, yet that requires around 195 MiB/s at 24 fps, which can only be achieved if we can use both cards slots at the same time.

[iaburn]

Congrats heder, it sounds like a big step forward!!! 

[Danne]

I have RAW video up and running. I'm going to Egypt next month Giza, Luxor and the valley on the kings and the Nile, was there 24 years ago, going back so I'm really excited. But going there without ML RAW video is bad karma, so I had to investigate every possible way of getting the camera to do as I wish.

• Tryed ordinary DMA failed, failed it's too slow in LV mode
• Tryed Omar EDMAC functions .. failed, they're not compatible
• Tryed Recreating all edmac functions .. failed
• Tryed direct buffering (edmac not needed) using 14 bits .. success using a very old mlv_lite module

Im was recording the entire RAW buffer including black border, 1984x1068x14bits,  around 85 MiB/s for 24 fps. I will try to record a large file using a fast CF card ( DMA-6)  in the following days to see if I get frame drops. The following video was recording using 25 fps, and recoded to H.264

Wow. Great stuff.
There´s an 7D mark II for sale in Sweden for 4000:-. Maybe I should buy it.

[names_are_hard]

You may want to hold off a little.  We're making fast progress behind the scenes.  Heder knows how Edmac is supposed to work on the old cams, and I've done a lot of work finding Edmac code in new cams, as well as in general making the new cams run ML.  So we're giving each other the missing pieces.

I don't know what this "direct buffering" is that Heder mentions, but I'm hoping when I see the code it will be easy to port to other cams.  I can already get HD 422 YUV from 200D, and I have Edmac APIs 95% working there, too.    Digic 7 cams will in general be easier to hack around on, due to MMU.

On the other hand, 7D2 is a nice cam, why not buy it anyway?

[iaburn]

I wonder what could a 5Ds do with magic lantern 
Same dual Digic 6 as the 7D Mark II, but lots of pixels, so in theory high processing capacity and memory... very curious 

[Walter Schulz]

Don't expect too much. Most likely this cam is hampered by rolling shutter galore.
Haven't tested it yet, though.

[Danne]

Rolling shutter galore 😂.

I'll keep messing with eos m for a while. Nice progress though. First cam with full HD 60fps.

[Walter Schulz]

5DS can't do this ootb.

Don't get me wrong: 5DS (plus/minus R) is a fascinating cam but I'm afraid it will disappoint for raw recording. 7D2 and rest of D6 bunch may see some boost, though. Esp. 7D2 because of 3x3 binning.

[heder]

...
I don't know what this "direct buffering" is that Heder mentions, but I'm hoping when I see the code it will be easy to port to other cams.
...

Buffering in mlv_lite, click to expand images

• A: Sensor
• B: Canon Liveview RAW image buffers
• C: ML (mlv_lite,mlv_rec) double RAW buffers
• D: ML image (save) buffers
• E: CF/SD card slot

When we enable RAW, call("lv_save_raw), canon firmware will create a "RAW" EDMAC transfer from sensor (A) to its own buffers (B). The size of the RAW images is set by canon. (I know on some builds you can mess with the sizes, but this is NOT portable and re-useable on all platforms)



When we start mlv_lite or mlv_rec recording ML re-routes the "RAW" EDMAC destination from canon buffers (A) to our own ML buffers (C). Both Canon and ML buffers are equal size. Then ML will create an additional EDMAC transfer, that performs a sub-image copy to the user format (i.e. user requested width and height). the final image ends in the save buffer (D) before being written to CF/SD card (E).

Doing it in this way will make the code portable and re-useable between builds and cameras, that is pretty important. We cant have too many #ifdef if the code, itwill kill the project. Also keep in mind that on many camera it's not the internal hardware , sensors, memory that is a problem, it's the maximum save bandwidth on the CF/SD cards, thus using a smaller format (if possible) less bit (is possible), overclocking CF/SD card (if possible) if what you want to achieve your goals.



Direct Buffering.

The last option is direct buffering, which is more simple but also less good in terms of options. Here we re-route the "RAW" EDMAC image directly into the save buffers and save them to CF/SD cards. This can also be done in a portable and re-useable way. BUT we can't control the width and height in a proper portable and re-useable way. We're kinda locked to the width and height that canon chooses.

Pros

• Easy to implement
• Works without finding the EDMAC stubs, good for an early build

Cons

• No width and height control
• You need a fast CF/SD card for shooting continuously

Should this approch go into the code ? .. I have no idea.  We will need to get the EDMAC stubs/code running correctly, it's mandatory for a proper build, but until we get there, direct buffering is a cheap way of getting RAW video out of the camera. If saving on both CF+SD is possible in parallel, when even the 3616 x 1348 x 14 bits in zoom mode is possible, but the file sizes will suck.

[heder]

The experimental 7D2 "hacky" repo with RAW video.

the code was been stored as a single zip file, rather than a git repo and temporary on google drive. Its was messy repo. I have used some time to make it less messy.  Take what you need and put it into the repo, don't wait for me to submit it, that will take forever for me, as my time is limited. I will try .. to explain that I have done. 

https://drive.google.com/file/d/1GeoqHV1r1D4EOAy702CAhAMYYsnOHZHD/view?usp=drive_link

* addlog

In the code you'll see addlog() .. it's must my own version of a similar DryOsDebugMessage, just regards those.

* vsync hack
vsync_func (state-objects.cpp) is called once per frame in LiveViev. This execute all modules frame syncronization (CBR_VSYNC). The vsync_func is normally called from the LiveHandlerapp handler, but on the 7D2 the stubs has not been found. This one is necessary for all modules that requires a frame syncronization, like mlv_rec and mlv_lite. They way I solved this was by hijacking function located in RAM. I used "olddumpfall","dumpfall" to dump the DryOsDebugMessages to card and analyzed them. Found some functions what there called on a regular basis, one seemed to interrupt functions. To make this work I implemented a thumb-2 BL_INST_T2 which could be used to hijack a BL instruction in thumb-2 mode in RAM and make the code jump somewhere else. It makes the same result as BL_INST but in thumb-2 mode. The max jump is (24 bits?) and the instruction size is 4(!) bytes, really messy instruction and hard to implement). The BL_INST_T2 code is worth getting into the new branch.  I then used the BL_INST_T2 to hijack a DryOsDebugMessage and instead called vsync_func() for frame synchronization

1. BL_INST_T2 hijacks a instruction (run_test_2,debug.c) which will call private vsync function in function-override.c
2. private vsync function in is used to compute frametime and then it calls the vsync_function in state_objects.c
3. vsync_function in state_objects.c execute module CBR_VSYNC.
4. fps-engio.c is alo hacked and uses the frametime from function-override.c to return correct value via fps_get_current_x1000()

* raw video (raw.c)
I had to do some hacks in raw.c (CONFIG_7D2) to get everything to work. The raw width and height is decoded from the RAW EDMAC by looking at the EDMAC sizes register. I'm actually using shamem_read() from Omar. The Omar code on this particularly function is position independent and the shamem memory is located inside RAM so reading the EDMAC shamem values works as intended. The border values (black border around RAW image) in raw liveview is hardcoded to 0, so I can do direct buffering. Also I needed to avoid some code (there's a odd return somehwere) that crashed the camera, some additional info that raw.c api provides, but which is strictly not needed.

* mlv Lite (mlv_lite.c)
I'm using a old mlv_lite only supporting 14 bits. The new module was complex so I decided to use the old mlv_lite from the vxworks brach instead. This did not work either so I had to do some hacks were as-well. I could not get CBR_KEYPRESS / raw_rec_keypress_cbr() to start the camera, maybe because some functions returning if the camera is idle or not does not work as intended. raw_rec_keypress_cbr() was changed for the worse. I'm using a run_test_alt() in debug.c to set a flag so I can start recording (start_stop_RAW_recording) when setting this flag and performing HALFSHUTTER_PRESSED then it will start recording.

Direct buffering: Inside mlv_lite.c I force the width,height to be maximum (from value returned via the raw.c api) so I can do direct buffering. That is important because then mlv_lite will allocate buffer images which is equal size to the EDMAC canon raw video buffers. The direct buffering is done in  raw_rec_vsync_cbr()/process_frame(). raw_rec_vsync_cbr is called once per frame and changes Canon EDMAC buffer to our own temporary buffer using raw_lv_redirect_edmac(), then -(normally)  we would use EDMAC copy in process_frame() to copy the pixels from this buffer into our array of images  that will be saved. This is now changed so we skip the EDMAC copy and just change Canon EDMAC buffer into the right image in our save image buffer array. This only works when we use the entire image format. Mlv_lite also has a autocheck (all versions) that the buffer are in fact filled with the RAW image (there a signature check), this still works, so that if you get dropped frames, the recording will stop. 

* Changed some code: Somewhere in mlv_lite I also needed to skip/change? some code, AFAIR was due to skipping code in raw.c. ML video needs alot of information like black levels ect, so the MLV header regarding these additional information it not fully correct. Black level is around 2048(?).

* Somehwere along the line: I lost the ability to compile module correctly (module_string.h could not be created), so currently only mlv_lite is enabled and I have a module_string.h from a clean branch included, and when it compiles. If you make a complete clean, the module_string.h will disapeer, compilation will then fails.

And finally .. Start recording on this hacky,wacky bleeding edge build:

1 start the camera
2 enable mlv_lite module
3 reboot the camera
4.Enable RAW recoding in ML, the format is fixed and can't be changed, Enable SRM memory!.
5 Select debug menu -> vsync
6 Go in to LiveView recording mode (not LiveView photo mode)
7 Select debug menu -> start recording
8 Do half shutter press once or twice to start record

To stop recording do 7+8 again. Sometimes when pressing a button it's like ML gets the button command twice, and then it does not work, just exit video recording mode and start from 6.

-R-O-A-D---M-A-P-

I have no roadmap for the 7D2, other that at some point in time, says around April .. but not the 1st  we should make a barebone build with RAW video enabled available to everyone.

[names_are_hard]

Thanks so much for all the explanations   There are some very important points in here that I was missing knowledge of before.  Reads like you've been busy.

I agree about BL_INST_T2 being a weird encoding.  My version is in boot-d678.c, patch_thumb_branch(): https://github.com/reticulatedpines/magiclantern_simplified/blob/764c54e8d5e1c8182343c2be9452f66708c87214/src/boot-d678.c#L60
It's done as a function, so might be useful for you to adapt.  Will need the parts around the reloc buffer offset changing.

For general hook patching I use mov pc, [pc + 4] instead.  This means the encoding is fixed, which is nice.  It takes more bytes but allows jumping any distance.  You need to do fixup in the hook, but you can write it as code, not magic bytes, so it's fairly easy.
https://github.com/reticulatedpines/magiclantern_simplified/blob/764c54e8d5e1c8182343c2be9452f66708c87214/src/patch_mmu.c#L248

Example hook code:

Code Select Expand


static void __attribute__((noreturn,noinline,naked,aligned(4)))log_CRLE(void)
{
    asm(
        // push all
        "push { r0-r11, lr }\n"
    );

    // log stuff
    uint32_t pResources, resCount, lr;
    asm __volatile__ (
        "mov %0, r0\n"
        "mov %1, r1\n"
        "mov %2, lr\n" : "=&r"(pResources), "=&r"(resCount), "=&r"(lr)
    );

    // adjust stack for task_create(), which spills one arg to stack,
    // to avoid stack corruption when we return to CRLE
    asm (
        "mov r8, sp\n" // store old sp
        "sub sp, sp, #4\n" // get space for one arg
    );

    struct log_args *log_args = malloc(sizeof(struct log_args)); // freed in edmac_logger
    log_args->r0 = pResources;
    log_args->r1 = resCount;
    log_args->lr = lr;
    log_args->caller_ID = 1;
    task_create("edmac_log", 0x1c, 0x200, edmac_logger, (void *)log_args);

    // restore sp
    asm (
        "mov sp, r8\n"
    );

    asm(
        // pop all
        "pop { r0-r11, lr }\n"

        // do overwritten instructions
        "push             {r4,r5,r6,r7,r8,r9,r10,lr}\n"
        "mov              r8, r0\n"
        "ldr              r5, =0x10990\n"

        // jump back
        "ldr pc, =0xe04b3741\n" // NB set Thumb bit appropriately
    );
}


I will brave the zip file soon and try to make a sensible series of commits in a branch, so you can approve them later (and re-author them for the credit if you want).

I suspect I've already done similar with 200D, but not using mlv_lite.   Much nicer putting it there but was easier hacking it in to test.  I was missing the lv_save_raw step - I can capture full sensor, but it's YUV 422 and already resized to 1080.  Maybe we can get both cams working at the same time



I have called off the assassins, enjoy your giant triangles in peace!

[heder]

I finally got a little time to test the build with a fast CF card, turned out it was indeed a Sandisk UDMA-7 Extreme card (but limited to 120 MB/s), a little resume form the test (24 and 25 fps)

• No vsync/tearing issues, vsync hijack location is valid , this was critical
• UDMA-7 card, zoom(x1),  1984x1068x14 bits (active area 1832x1044), direct buffering,limited RAM ~ 250MB,  continuously shooting 
• UDMA-7 card, zoom(x10), 3616x1348x14 bits (active area 3472x1320), direct buffering,limited RAM ~ 250MB,  you get max 24-70 frames

[heder]

I suspect I've already done similar with 200D, but not using mlv_lite.   Much nicer putting it there but was easier hacking it in to test.  I was missing the lv_save_raw step - I can capture full sensor, but it's YUV 422 and already resized to 1080.  Maybe we can get both cams working at the same time

Direct buffering is always possible, even if it's only a temporary solution. The YUV422 (EDMAC) is always available (and it should be possible to re-size it, did that on 40D), but the save requirements is much worse than the raw format.

[names_are_hard]

Have now looked at heder's archive of code.  It's a little hard to work with since there are no commits, just changes from the base.  But most of the changes are simple I think, I just need to understand it a little better to reduce the noise, and work out a nice sequence to apply them.  There are three copies of mlv_lite module

I think I will try to get 200D working using a similar approach, and apply that to the modern mlv_lite, then port heder's.  That way I'm sure I understand what I'm doing before adapting the 7D2 code.

Heder, re "module_string.h could not be created": this normally means you are missing rst2html.  Given that you were using an old version of a module, it's possible you reverted changes I made to make everything python3 compatible.  It'll be something in this area, anyway.

[heder]

Yea, we're abit to early on. I need a little more time to make thing pretty. The quick and dirty port was only to prepare for my next travel. My next task is to complete direct buffering and push it to a repo, so it becomes usefull for all. But I need to understand all the EDMAC offsets first.

[names_are_hard]

Yup, it wasn't intended as criticism, early code is never how you want it to look.  I'm happy I can use it to check things and learn new things about mlv_lite.

With call("lv_save_raw"), how are you tracking usage of new channels?  On 200d, I don't see this call triggering any new channels to be used (I'm hooking StartEDmac() so I think I should see all new uses).  Maybe I should be looking for a change to the size of copy, on an existing in use channel?  My basic approach is log all channels that ever go active (but only log the first use), msleep(2500) while I put it in LV, and movie LV, then call("lv_save_raw").  From your description I'm expecting to see a new channel used for the first time (which should show in my logging, while previously used channels would not).  Instead, I see nothing.

[heder]

Hooking only works when the FW calls the StartEDmac function, on many occasion they don't but only EngDrvOut. If you want to see what is happening you'll need to dig deep and find the function that trigger lv_save_raw. All those function call("func") is registered somewhere and each "func" has a function attached to it.  But the easyway to find the RAW EDMAC is quite simple. Dump all EDMAC address into a file. To do this, please use shamem_read because it's stores more EDMAC values. If you don't have shamem_read when you can still read the first registers of each EDMAC using the MEM(...) macro were you can access fro 0x0 to 0xC in each EDMAC but using shamem_read you get all. The next code (see below) values is inside Liveview before doing the call("lv_save_raw"), look carefully at 0xD0004200, it's all zeros. This is before I found shamem_read, so I had to use MEM(...) and could only read from 0x0 to 0xC using the MEM(..) macro.

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


Then I found shamem_read and also turned on call("lv_save_raw"), when I dumped all EDMAC again and now look at 0xD0004200, now it non-zero and 0xD0004210 = 0x42B0D90, this is the configuration in "EDMAC internals" post that a1ex says describes as "Simplest WxH"

Code Select Expand


xb * (yb+1)        (xb repeated yb times)


0xD0004210 = 0x42B0D90 ==> (0x042B0000 | 0x00000D90)==> Simplest HxW = 1068(H) x 3472(W)   ==> 1984(W) x 1068(H) @ 14 bits.

So the RAW EDMAC transfers a bayer image of size 1984(W) x 1068(H) @ 14 bits. This is including black border, to find the borders you'll need to save the RAW image and investigate the raw bytes, or get mlv_lite or similar to save a mlv video with (borders 0,0,0,0) and check the image.

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


[names_are_hard]

Hooking only works when the FW calls the StartEDmac function, on many occasion they don't but only EngDrvOut.

Good to know it wouldn't be foolproof anyway, but there's no EngDrvOut() or shamem_read() on 200D, so I can't hook those.  They're inlined on 200D.  I've also written a monitor function that polls dma_state fields of all MMIOs, but this is unreliable; I suspect they stay with 1 bit set for too short a window for this approach to work.

But the easy way to find the RAW EDMAC is quite simple. Dump all EDMAC address into a file.

I've been doing that for weeks, it does not work.  Well, I don't dump them to file, I have uart logging so I can see them change in realtime.  But I do dump the data content of any EDMAC region that is larger than a configurable size to disk.  So far, it's never been Bayer data, only YUV (or weird junk noise, or maybe, I'm not noticing Bayer pattern data).

Then I found shamem_read and also turned on call("lv_save_raw"), when I dumped all EDMAC again and now look at 0xD0004200

I don't see any change to edmac regions when I enable lv_save_raw.

So the RAW EDMAC transfers a bayer image of size 1984(W) x 1068(H) @ 14 bits

I've never seen bayer data.  I have seen a (1984 * 2) wide region in some tests, but it contains YUV data.  I don't see any regions of a different size if I toggle lv_save_raw.

The above hopefully explain why I want to learn if there are any changes due to lv_save_raw that don't need me to find the image buffer.  Does it trigger a new channel to be used?  Or a device ID that's previously not been accessed?  Creation of a different sized region?  Etc.  Looking for the Bayer data in buffers does not seem to work on 200D.  I have a few ideas on how to possibly catch the data by changing timings on when I sample MMIO data, but low confidence.

Possibly worth noting, I'm not making any attempt to sync with vsync yet.  I was assuming this would not be a major problem, I'd see tearing in the image data, but I could fix that later.  Would you expect lv_save_raw to still give you bayer data if you weren't running at vsync?

[heder]

Dont mind vsync, it's not critical for now.

With no EngDrvOut and shamem and inlined code, this is going to be hell. So let do some sane checking..

1. Does "lv_save_raw" exist as a string in ghidra ?. It might also have changed name, like on the 7D2 I cant find any more "fdump" its now called "fdumpall" or "oldfdumpall", search for "save_raw" and investigate those places.

2. All those call("func_name") will be registered somewhere using a registerfunction call, like

Code Select Expand


registerfunction(pointer to "func_name", function pointer *_func);


The _func will be called when someone perform the call("func_name"). In 7D2 look up the address 0xfe0abde0 here you will see lots of registering

Code Select Expand


  FUN_fe100a6a(s__dumpall_fe0ac0cc + 4,0,s__dumpall_fe0ac0cc._0_4_);
  FUN_fe100a6a(s_dumpfall_fe0ac0dc,0,DAT_fe0ac0d8);
  FUN_fe100a6a(s_olddumpall_fe0ac0ec,0,DAT_fe0ac0e8);
  FUN_fe100a6a(s_olddumpfall_fe0ac0fc,0,DAT_fe0ac0f8);
  FUN_fe100a6a(s_grepall_fe0ac10c,0,DAT_fe0ac108);
  FUN_fe100a6a(s_dumpentire_fe0ac118,0,DAT_fe0ac114);
  FUN_fe100a6a(&DAT_fe0ac128,0,DAT_fe0ac124);
  FUN_fe100a6a(s_DisablePowerSave_fe0ab5cc,0,DAT_fe0ac124);
  FUN_fe100a6a(s_EnablePowerSave_fe0ab5e0,0,DAT_fe0ac12c);
  FUN_fe100a6a(s_SetTuningFlag_fe0ac154,0,DAT_fe0ac150);
...
...


FUN_fe100a6a = register call name .

There's many functions around in the code, even a call("grepall",?) function