3K/UHD 5D2 Raw development and Other Digic IV Cams

Started by reddeercity, April 06, 2017, 12:22:27 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

reddeercity

So would EDMAC#5 cofo4500
address:43e28a4
State : 1
Flags : 20000040
Size : B (4046 x1127
Connection : write=0x0    read=0xff

found that in "Show EDMAC" in the debug menu
Look like the right frame size if that's what the 4046x1127 is ?

Or I'm I miss understanding this .

Looking at this #crop_rec_4k-raw.c-479 , so if I replace "EDMAC+8" with "EDMAC+5 ,  will that work or I'm I off base here ?
   /* autodetect raw size from EDMAC */
    uint32_t lv_raw_height = shamem_read(RAW_LV_EDMAC+4);
    uint32_t lv_raw_size = shamem_read(RAW_LV_EDMAC+8);
    if (!lv_raw_size) return 0;

    int pitch = lv_raw_size & 0xFFFF;
    *width = pitch * 8 / 14;
   
    /* 5D2 uses lv_raw_size >> 16, 5D3 uses lv_raw_height, so this hopefully covers both cases */
    *height = MAX((lv_raw_height & 0xFFFF) + 1, ((lv_raw_size >> 16) & 0xFFFF) + 1);
    return 1;
#endif



Greg

4046/14*8 = 2312
So the size is 2312 x 1127

500D "LV_Initialize %s" :
int a1 = 0x1D78 + 0x2600;
*(a1 + 208) = 1664;
*(a1 + 210) = 660;

It looks like width and height raw, but who knows.

reddeercity

That's Greg  :)
Now the Crazy Part  :o

Some how either with dumb luck or divine intervention ::) I manage to get 3.5K in 1:1  @1.6 crop  8) 8) 8)

Check it out , thou I couldn't record any image just yet had a small error in edmac-memcpy.c line 80


5D Mark ii experimental 3.5K Raw Video
by RedDeerCityTV, on Flickr

The write requirements for that size was reported about 198MB/s @30fps 14bit :o
If and when I get if working fully then compressed raw is next.

The files I modified are raw.c , edmac-memcpy.c
in raw.c I add this

#ifdef CONFIG_5D2
#define RAW_LV_BUFFER_ALLOC_SIZE (2040*1267)
#endif


also in raw.c  changed to 0xC0F04500 from  0xC0F04508

#if defined(CONFIG_5D2) || defined(CONFIG_50D)
#define RAW_LV_EDMAC 0xC0F04500
#endif



in edmac-memcpy.c change the r/w channel to 0xff & 0x0 from read 0x19 & write 0x03
If may be a problem as I have a write issue , need to look further in to this of course.

#if defined(CONFIG_5D2) || defined(CONFIG_50D)
uint32_t edmac_read_chan = 0xff;
uint32_t edmac_write_chan = 0x0;


That's a good step in the right direction and the start many buggy problem to come
But Hey I'm so much closer now thanks to all  :D
Poor mans 1DC  :P :P :P
more to come

Edit:FYI to get this build I clone the source ,  updated with iso-research branch then modified the files 

DeafEyeJedi

Really incredible stuff and I am loving this progress so far, David!

'Poor man's 1DC' -- very well said!

Also after some thoughts in my head recently I remember helping @nikfreak out w 70D/100D merge awhile ago by doing this...

https://vimeo.com/197958207

Guess it's basically like a cheat sheet by clicking on 'don't click me' then afterwards you go into EDMAC which will show a screen full of registers addresses after while in each mode (mv1080, mv720, 5x zoom crop, etc) and it seemed to help him out.

Maybe you already are aware of this protocol but felt it was worth sharing just in case.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

nikfreak

I can recommend to undo all code snippets from above. Yor best bet is to try to get near 3k width with adtg / fps overrides
Don't change the EDMAC channels. They have proven to work for years and there's find_free_edmac_channels() if you really need to add more.
[size=8pt]70D.112 & 100D.101[/size]

ilia3101

@reddeercity Wow, difficult to believe thats happening :o :o :o I was a little pessimistic about getting rid of that pink corruption, but you got rid of it, so I guess you'll be able to fix the record error ;D I can't be much help developing this stuff, as I don't understand how the the Magic Lantern code even works and I'm not a lot of use at programming in general. I'm always ready to test tho :D :D

@nikfreak What is the level of risk in doing this kind of stuff, corrupted image or corrupted ROM?

nikfreak

Low risk of a brick if you know what you do. You got to keep all pieces if it breaks ofc.
You can get raw recording errors, corrupted frames or wrong recording sizes etc.

http://www.magiclantern.fm/forum/index.php?topic=19336.msg182847#msg182847

follow the links to Greg's PoC and a1ex's 3k implementation.(Digic5) They did it just with modifying register(s). The difference between Digic5 and Digic4 is:


  • C0F06804 (Digic5)
  • C0F06084 / C0F06088 (Digic4)
Ofc you must find apropriate value for 3k width for 5D2. Don't think that 5D3's will match 5D2.

Check this code snippet

I guess Canon did some calculation themself befor implementing zoom/crop modes for FHD H264 30FPS recording. Now you can calculate yourself how much you can extend the resolution in zoom/crop mode (x*y*fps) for recording with 24fps. Maybe 15-20% could be fine but you might have to extend the buffer, too...
[size=8pt]70D.112 & 100D.101[/size]

Greg

500D  LV zoom 5x - "StartPass_x5 CrawAddr:%lx / Kind:%d"
SetEDmac(0x10, *(0x16604 + 808), 0xFF44F0B0, 0x20000000);

ROM:FF44F0B0
ROM:FF44F0C8        DCD 0xE1C, 0      //‭3612‬
ROM:FF44F0D0        DCD 0x35D, 0, 0   //861


5D2  LV zoom 5x - "StartImagePass_x5 CrawAddr : %lx / KindOfCraw : %d"
SetEDmac(0x5, *(0x13ECC + 804), 0xFFCAA1D4, 0x20000000);

ROM:FFCAA1D4
ROM:FFCAA1EC        DCD 0xFCE, 0       //‭4046
ROM:FFCAA1F4        DCD 0x467, 0, 0  ‭  //1127‬



This code will increase EDMAC size, but the buffer will be overflowed - it's dangerous.
static void run_test()
{
    static uint32_t craw_5x_edmac_h = 0xFF44F0D0;
    patch_memory(craw_5x_edmac_h, 861, 861 + YRES_DELTA, "lv_edmac_h"); // add height
}


Now we should use our own buffer.

reddeercity

Thanks for the code but I'm not really sure how implement it  , being read the source code raw.c & edmac_mencpy.c
for clues still not sure , can you point me in the right direction please.

ItsMeLenny


Greg

I increased the height by 140px (841px to 981px). More does not work.
I do not know why, some problem with memory or edmac.

To do this you need to change (500D):
CMOS[5] //vertical offset
ADTG[2]1172 -> old_val + YRES_DELTA (nrzi)
ADTG[2]1173 -> old_val + YRES_DELTA (nrzi)
ADTG[2]1178 -> old_val + YRES_DELTA (nrzi)
ADTG[2]1179 -> old_val + YRES_DELTA (nrzi)
ADTG[2]1214 -> old_val + YRES_DELTA (nrzi)
ADTG[2]120A -> old_val + YRES_DELTA (nrzi)
C0F0713C -> 0x370 + YRES_DELTA
C0F07150 -> 0x388 + YRES_DELTA
C0F06088 //RAW last line|column
C0F06008 -> 0xaf90af9   //photo mode value
C0F0600C -> 0xaf90af9  //photo mode value
C0F06010 -> 0xaf9    //photo mode value
C0F06014 -> 0xc83   //photo mode value
patch EDMAC size
patch buffer

Greg

Buffer patched :

void* buf = malloc(2064 * 2000 / 8 * 14);
MEM(0x16604 + 808) = buf;




It still works a bit randomly, some frames have standard height...

So if someone finds a solution, it will work.
I do not plan further research.

reddeercity

@Greg Cool thanks , I'll keep going .
Just a couple of questions.
Was this test with the 3x Live view code & edmac size buffer patch   or just buffer patch ?

I still haven't tried the code you posted , need to find where I should add this code too .




Greg

It was in live view 5x zoom. Both buffer patch and edmac size.

The buffer should not be needed :

silent.c
/* Reprogram the raw EDMAC to output the data in our buffer (ptr) */
raw_lv_redirect_edmac(sp_frames[next_slot % sp_buffer_count]);
sp_num_frames++;


raw.c
/* to be called from vsync hooks */
void FAST raw_lv_redirect_edmac(void* ptr)
{
    #ifdef CONFIG_EDMAC_RAW_SLURP
    redirected_raw_buffer = (void*) CACHEABLE(ptr);
    #else
    MEM(RAW_LV_EDMAC) = (intptr_t) CACHEABLE(ptr);
    #endif
}


So ML uses its own buffer, which should have the correct size after patching EDMAC.

If you do not solve this problem, we will announce the end of digic IV support. :D

a1ex

The custom buffer is required, as ML redirects it only while recording.

In the crop_rec_4k branch I've used a SRM buffer (which can accommodate a full-res 14-bit picture). This needs to be passed to SetEDmac as the first argument (instead of Canon's default buffer).

The buffer redirection without CONFIG_EDMAC_RAW_SLURP is fragile: it relies on lucky timing. It's best refactored somehow, but cache patching is also ugly...

It's quite difficult to get these patches right, but I'm making progress on a tool that should help understanding the LiveView internals a lot better.

reddeercity

@Greg thanks for the info
Quote from: Greg on April 18, 2017, 10:59:26 PM
If you do not solve this problem, we will announce the end of digic IV support. :D
Yea  I had thoughts , but if there a will there way  :D

Quote from: a1ex on April 18, 2017, 11:55:34 PM
The custom buffer is required, as ML redirects it only while recording.
So when I use the custom RAW_LV_BUFFER_ALLOC_SIZE (2040*1267) , RAW_LV_EDMAC  0xC0F04508 & r/w channel to 0xff & 0x0 and got 3584x1068 (got all this from the "show edmac"  in the debug menu in 1:1)
(I forgot to mention in  Reply #27 where I got 3.5k , I enabled adtg_gui with digic registers and applied the 3k 5d3 preset)
So this happen by chance to have access to that lv buffer size ? Oh , I also had the Raw video frame size at the 3584 preset , thou I could not adjust the size or aspect ratio
it was lock to that size . Just trying to understand better .

Edit: A thought just came to mind , so if there was a higher preset  , lets say 4096 etc. .... instead of 3584 would it go to the highest possible size ? or is this limited to lv buffer size for that  frame size and I had frame override turned off with canon menu frame rate set to 30 ntsc

Quote from: a1ex on April 18, 2017, 11:55:34 PM
....... but I'm doing progress on a tool that should help understanding the LiveView internals a lot better.
Yes  :) That great to hear @a1ex
There's still hope for digic iv

a1ex

Just FYI, I had an attempt to find out the size of Canon's LiveView raw buffer on 5D3.

Result (not committed): it's not allocated using "traditional" malloc, but its address (and probably its size too) are hardcoded, near 0xFF16B318 (1.2.3). The size reported by the memory "allocation" routine was 0x1cae000 (30MB - enough for 10-bit full-res LiveView), but when trying to use that, I've noticed the bottom of the frame being overwritten.

So, I don't know the size of the default LV RAW buffer. On 1100D (a camera with only 128MB RAM), Canon's default buffer is overwritten (by other Canon code) even at small LiveView resolutions, so the safest way is to assume nothing about it...

Most models appears to handle x5 zoom fine though, but that's not a guarantee other tasks are not using this memory. Might even be the cause for some kind of frame corruptions...

(memory management on these cameras is quite strange, with many hardcoded areas, fragmentation, and descriptions found in strings not always matching the reality)

reddeercity

Thanks help a lot to understand , since I had a little luck with that custom lv buffer I used in post#27 I thought I would try and investigate further and see if any variable change EDMAC#5 in 1:1 & 3x crop . So I notice that in photo live view there is no secondly lv buffer for 5x zoom(3x crop) (could be that it's in 1:1 pixel mode so not needed I guess) but in movie mode there is and by switching Raw photo mode in the canon menu from raw to small raw1 & small raw2 the address changes as follows:
EDMAC Address 103e28a4  (3578x1267 1:1)(4046x1127 3xcrop) raw(5616x3744) (Movie mode)
EDMAC Address 103e28a4  (3578x1267 1:1)(4046x1127 3xcrop) small raw1(3861x2574)(Movie mode)
EDMAC Address 43e28a4   (3578x1267 1:1)(4046x1127 3xcrop) small raw2(2784x1856)(Movie mode)

EDMAC Address 103e28a4  (3578x1267 1:1)(No buffer change) (5x zoom) (3xcrop) raw (5616x3744) (Photo mode)
EDMAC Address 103e28a4  (3578x1267 1:1)(No buffer change) (5x zoom) (3xcrop) small raw1(3861x2574)(Photo mode)
EDMAC Address 43e28a4   (3578x1267 1:1)(No buffer change) (5x zoom) (3xcrop) small raw2(2784x1856)(Photo mode)


Not sure if this help , look interesting -- from this I'm concluding that 3X crop has a larger lv buffer maybe because in 1:1 pixel instead of line skipping and pixel binding
for FHD , just guess there. Next I think I'll try that large buffer and see if I can hard code the edmac address unless ML check for available addresses (no sure) , specially with the small raw2 and check the results .

a1ex

Uncompressed 14-bit data takes 14 bits regardless of what pixel binning mode is used. Should be obvious...

The addresses are allocated dynamically, so of course, changing the camera settings (or sometimes, just starting in a different mode) will give different numbers.

Photo quality shouldn't be relevant (it might change slighly the amount of available RAM, or how it's divided between SRM and shoot buffers), but you will have to use some memory allocation API to get a memory buffer.

reddeercity

Ok ,understood .
Quote from: a1ex on April 20, 2017, 09:19:00 AM
..... you will have to use some memory allocation API to get a memory buffer.
Maybe this will help ? did a search for "memory allocation API "and got this , go figure developer ARMS api , could be a wealth of information , assuming I can understand it  ::)
https://developer.arm.com/docs/0030/latest/modules/memory-allocation

Edit: something interesting to look at schematic diagrams for 5d2 I think , takes me back to my early auto mechanic days when computers started (mid '80's ) to control basic engine functions
which of course was very buggy  :P
https://photo-parts.com.ua/parts/Datasheets/KCD-A210-BACH8SchematicDiagrams_ENG.pdf

reddeercity


reddeercity

I think I found register memory map  :D
http://www.ti.com/lit/ds/symlink/tms320dm368.pdf
page 50 of 208
Table 3-1. System Module Register Memory Map

Table 3-1. System Module Register Memory Map
Hex address Register           Acronym            DESCRIPTION(1)
0x01C4 0000                    PINMUX0            Pin Mux 0 (Video In) Pin Mux Register
0x01C4 0004                    PINMUX1            Pin Mux 1 (Video Out) Pin Mux Register
0x01C4 0008                    PINMUX2            Pin Mux 2 (AEMIF) Pin Mux Register
0x01C4 000C                    PINMUX3            Pin Mux 3 (GIO/Misc) Pin Mux Register
0x01C4 0010                    PINMUX4            Pin Mux 4 (Misc) Pin Mux Register
0x01C4 0014                    BOOTCFG           Boot Configuration
0x01C4 0018                   ARM_INTMUX      Multiplexing Control for Interrupts
0x01C4 001C                  EDMA_EVTMUX     Multiplexing Control for EDMA Events
0x01C4 0020                  DDR_SLEW           DDR Slew Rate
0x01C4 0024                  UHPICTL               UHPI Control
0x01C4 0028                  DEVICE_ID           Device ID
0x01C4 002C                  VDAC_CONFIG      Video DAC Configuration
0x01C4 0030                  TIMER64_CTL       Timer64 Input Control
0x01C4 0034                  USB_PHY_CTL      USB PHY Control
0x01C4 0038                  MISC                   Miscellaneous Control
0x01C4 003C                  MSTPRI0             Master Priorities Register 0
0x01C4 0040                  MSTPRI1             Master Priorities Register 1
0x01C4 0044                  VPSS_CLK_CTL    VPSS Clock Mux Control
0x01C4 0048                 PERI_CLKCTL        Peripheral Clock Control
0x01C4 004C                 DEEPSLEEP           DEEPSLEEP Control
0x01C4 0050 -                                          Reserved
0x01C4 0054                 DEBOUNCE0         Debounce for GIO0 Input
0x01C4 0058                 DEBOUNCE1         Debounce for GIO1 Input
0x01C4 005C                 DEBOUNCE2         Debounce for GIO2 Input
0x01C4 0060                 DEBOUNCE3         Debounce for GIO3 Input
0x01C4 0064                 DEBOUNCE4         Debounce for GIO4 Input
0x01C4 0068                 DEBOUNCE5         Debounce for GIO5 Input
0x01C4 006C                DEBOUNCE6          Debounce for GIO6 Input
0x01C4 0070                DEBOUNCE7          Debounce for GIO7 Input
0x01C4 0074                VTPIOCR               VTP IO Control
0x01C4 0078                PUPDCTL0 IO         cell pullup/down on/off control #0
0x01C4 007C                PUPDCTL1 IO         cell pullup/down on/off control #1
0x01C4 0080                HDVICPBT              HDVICP Boot Register
0x01C4 0084                PLL1_CONFIG         PLL1 Configuration Register
0x01C4 0088                PLL2_CONFIG         PLL2 Configuration Register


http://www.ti.com/lit/ug/sprufg5a/sprufg5a.pdf
More Registers (4.1 Memory Map) Page 25 Table 6. Memory Map & Page 27 Table 7. ARM Configuration Bus Access to Peripherals
http://www.ti.com/lit/ds/symlink/tms320dm368.pdf
page 85 Table 6-9. PRTC Interface (PRTCIF) Registers
page 86 Table 6-10. Power Management and Real Time Clock Subsystem (PRTCSS) Registers
http://www.ti.com/lit/ds/symlink/tms320dm368.pdf
page 91 Table 6-16. EDMA Channel Synchronization Events


reddeercity

going thought the branches I came across "new-lv-buffer-detections"  :o
as this is my issue atm , so I complied it are run it enabled the mem_spy.cfg & mem_chk along with raw video
not too sure how to use it correctly . mem_spy was running in the background but I was hoping it would make a log file but did not.
I was able to run the stub test in the "burn in test" with mem_chk and it did generate a log file , not knowing how long it would run I aborted after a few minute
it below here
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x17b068
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x17b000
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x17afe0
[Pass] bar => '*****hjkl;'
       bzero32(bar + 5, 5)
[Pass] bar => '****'
       t0 = *(uint32_t*)0xC0242014 => 0xccf82
       msleep(250)
       t1 = *(uint32_t*)0xC0242014 => 0x61e8c
[FAIL] ABS(mod(t1-t0, 1048576)/1000 - 250) => 0x168
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x5
       Date/time: 2017/04/23 00:05:0ü&,¸ ]&,½ l,CK<&²Ã
–(¹`UrV‹x&'°ËX'¢½"k":‹%R­JD&ÿ½´j"'K'¿Ëu%}©<L¢ ¨'²Ã w$Hªô^ÂÓ ì',½Ìv(mÇh‡BþŒP)¸J7%E¸ u'‹ÌØ(ÇKv& ½€wbÒ ¤&ÂØÒÓ2yßBÍс3ó8       m0 = MALLOC_FREE_MEMORY => 0x203c8
[Pass] p = _malloc(50*1024) => 0x104930
[Pass] CACHEABLE(p) => 0x104930
       m1 = MALLOC_FREE_MEMORY => 0x13bd8
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x203d8
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x10
       m0 = GetFreeMemForAllocateMemory() => 0x3e55e8
[Pass] p = _AllocateMemory(256*1024) => 0x972f94
[Pass] CACHEABLE(p) => 0x972f94
       m1 = GetFreeMemForAllocateMemory() => 0x3a5574
       -_FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x3e5580
[Pass] ABS((m0-m1) - 256*1024) => 0x74
[Pass] ABS(m0-m2) => 0x68
       m01 = MALLOC_FREE_MEMORY => 0x203d8
       m02 = GetFreeMemForAllocateMemory() => 0x3e5520
[Pass] p = _alloc_dma_memory(256*1024) => 0x409d0270
[Pass] UNCACHEABLE(p) => 0x409d0270
[Pass] CACHEABLE(p) => 0x9d0270
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x409d0270
       _free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(24*1024*1024) => 0x4e5d00e8
[Pass] UNCACHEABLE(p) => 0x4e5d00e8
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x203d8
       m12 = GetFreeMemForAllocateMemory() => 0x3e6634
[Pass] ABS(m01-m11) => 0x0
[FAIL] ABS(m02-m12) => 0x1114
[FAIL] p = (void*)_shoot_malloc(24*1024*1024) => 0x0
[FAIL] UNCACHEABLE(p) => 0x40000000
[FAIL] ABS(m02-m12) => 0x101fc
4ÐD-òûÏÅ+fðع¤ŽØ*"åN¡)×,,ŽâÍ@(ÒË z'vÂ<gÎ ¼%¢·KT$4­üE"¸Jô#B§Ê;#J <1"߉˜"Rœ‰'"©—by‰ ¡oÇÂo(À¡ýF!pÀp ¿ÇpÇÁpÃÑDApÅoLÄ¡ ÇáoGÃp<ÅaGLq‡Ä pÊ ‡`ÁqGÇq¬Ë‡ QqÌp¤Ì¡ÇÀqÏq¸Ì±GŒQq‡Ì q´ÉAÇhqpÇÈq"ɱX1qGÆ qdɇ|ÁpÉpÀÈ¡G˜1p‡ÊqÈËA‡¼QqÏqρGqrÇÐ)r@Õ¡(‡xtÛ9rœÛñ[Pass] suite = shoot_malloc_suite_contig(0) => 0x86b91c
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1cf8000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x86b940
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1cf8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(64*1024*1024) => 0x9b8758
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x4000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x9b877c
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1cf8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       chunk = GetNextMemoryChunk(suite, chunk) => 0x9b87f4
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3724000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x565d00e4
[Pass] UNCACHEABLE(p) => 0x565d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x9b886c
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x525d00e4
[Pass] UNCACHEABLE(p) => 0x525d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4000000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[FAIL] suite = shoot_malloc_suite(0) => 0x0
[FAIL] suite->signature => '‡'
[FAIL] suite->num_chunks => 0xe59ff014
t*†H½.½°ü"¶ˆ+²...H­-†ŒXþÒÍH0,BˆÞ-ֈظ'– -ŽHú,ǃ¨•ÒX˜,"‰ˆÛ1÷'hüÊH˜/ãŽH +´ŒÔ$ÉÄ/‹Èâ/Ã"LgŠ"A¤Á bB#¾¼É"VL€@³¦In.ˆÔu'ÔØ#"z‡-"œx wÀ quÇöHu¼'[GœuÇúEu˜ùEpAtGúTtöQ=ÇÑsí:v¨þLÇä!u‡þ Zu<õ1IÇ8¡tÇî6sÌîaF‡Ôs‡ì4s íá2‡ ±rGè;t ðAFÇh¢t‡  UuûA[X "w$#¤}ìVú‡L'ƒH™)@‡àÌ,Hð-,‡H¡(8,X`
HÔ&²ƒÈ,­'¸
$6£Ê¬@¿µF$,,‹àE¶Ê9<Ò ¬QC}É`3"/ðŽýRáH,0C‰ /‹,,ê±HÈ-"ŠÖ.¼Œæ2͐0òŒï1è'#ÃÉ|1ˆî,•‰³k€)r,ÇW!³uDöÑF‡1sÇç@s0äAE‡$ Rv&¹...üÆB–ˆ -âˆHÑ.ÈŒðòÊÈì/cˆ
0ûŽ ÃíȨ/R‹ÈÓ.¸‹¸ãÒåˆ"0ãI$9œ«˜+ô ,,F¤»KfD³·T44{Ë@D"º pG÷ÀTsì °D3´
Þ6t˜,úBÈHˆ("GC Žuðïá6Œs‡ïRvÜâžG#R{Ç*"¯y BfÇÈÑu‡õSu
ò‡Ü#r€Hƒ.£˜có'Ê\?"ºÌ€MžÓx %YÍ|OäÎ̯DQ¶ÅCpÊ63š ,$Š ›wˆ(,†‡)ŒìÏ@I\2ƒ¡Š˜AÜ¿‡"㠐PÕÜNfY{ìˆìÕCÏÔ`¦ö4c×ûœXö8Ég¦¢i–é‡ÖF hFЋgI éb†ûfæÿyg'Ù,Ö=ñgŠg'AtV#ÐagcfþxoF+ÐqgÆqfþ$CæЈcÆõ
^0ë˜Ë5¾ÎX\ÅìNÈ\·ì€Íµ¸h\•êµZ...å(•>ÎÌWâNrVßl`µë¼UÅávUÜÌ@žlSÕÙÍ*S•Ùu...
°QµÖÍQlÕP ...;Í°NôÎLÊJËÇx'4B ,F´¾KBB±·´/K\>Ó°Ëò@E¸|ŠôÈÍa— "†‹TR1wÉný‰cÔ‰ƒä......7L >銥;¥­8ÚÓ ?"² ?9³°õC! `>±ÊÚ=ê¬4Å"»Š <3«Š¼;¯«|¶¤Êt;cªŠ¹;¬«È¸3¤Š€;"§J¶: ªô³cªÊ$;é
¨9¦ä—ãrÊÐ8"¥Êˆ8h¥Ìa
:Ó¥
¡9s¦<›ƒhJD9S¥Ê‡8W¥ "3e
9ó¥
™9l§À ³zJ:㨊¬9—¨ø£C›ŠL:3¨Š¤:†¨€ "Šü9"§Šš9h§l"CgJ 9¦
‹8h¥èŠã]
8¦
8p¥À‰cŠÌ8c¦Š'8f¦¼‰SLŠ¸7s£Š}60 ¬bcŠT5£‰N6ô£,Š³œ
´<ä²
DÕÇôŠÔûŒ°L4×ÍãN"Ù$Ýd¤ÌM"×MÝMƒ×TÙŒÍ,,M"ØMÐLØÌÓ¤˜ÍÄMtØ
ØM˜×Ñ"c¼L"ÙÍÓLy×tÏ´ƒÈLtÖMÇLƒÖlÁTnÍxKՍ¿KEÔä¯4/ͬJdԍ§J+Ïp´üŒxHÄÍ ~HàÌ}ÄÃŒ4G,,ËÌnF±Êäe"Ì(FÆLTC6ÁÐ'4ó‹°Aƒ½‹ý>ž¶¸×#@ `<3°J¤9½¨sãVŠ(6s¢IJ3ô›`£' H0•Ií.>Í"ßHˆ+R‹ª)§ˆÀ‹,l (...È{&E,üf'pGÀpÔÀ¡û† !p‡Á
o¾¡
±pGÁpì¾AG$1pÇÄpøÄ¡Ç$1qǽpÁÑG$qqÃr8Á‡8±rÃ(rdÂ'%h1sÃ/r,ÅÑ)‡PÑq‡Ã'rhÁÑ)‡8'rGÄ-r4Ʊ*‡ParÇÄ&rLÃ%‡`¡qÂq@Á‡$!r‡À#rHÂ1‡tsÅ*rDÅÁ;ÇxasGÉBsTÃ!<,,QtGÌRuÇñe‡œáuÇÌav¸È1\G|ñuÈUu È1EÇœtÅ/rhÇÑ(G°'tËVyÓa¹ÇÌá~Hå6‰¼öÁÐHÄrI X™äÒËÉ !¢œ !ᝀÌIŒ!B‰!âœ|"·‰!ÒšI m"Œ
úHL RH áp rú!'" $#½¡lEB...Š8%R®Ka& ±pb20‹Ô&² l&B³¸nâC‹'bµ u'Iµq"j 0'²¶ z'o¸|zbË"'·K~'²·Ü~ò›‹ü'2¹ (¼»ˆ¸Kh(òº‹†(Á»D...R¼‹€(R½‹Š(î¾ÀŠ'æ‹,)r¿L'(Áä–â h)RÁÌ–))ÂX"'3ŒŒ)RÄL)\Äl 'XŒä)bÅÌŸ*iÇ £', ˜*rÈŒ§*œÉD¨R£Ìh*,É̪*ÀÌ,,®bÃÌä*rÌ ³+ÛÍ ³,èL8+bÍ̵+éвRç̼+²ÎŒÂ+ÿÑ,,·R0,ÂÑͼ+3ÔôÄ\
D,BÕMÇ,\ÖtËUÍ-R×ÍË,'ØìÏR¥M(-òٍÐ-¼Ü4ÙÒ×
"-òۍÓ-àÝ"×,ëÍø-Þ
Ü-üàüáBøÍ(.'àÎç.'Ý ÌM¨+2Ð̤(¼<jRúJˆ$ò¢I* `Š,,ô±Jˆ€ñ,Èé:ŠìÿPIX!B¡J*"ž®ø7rVK0%ÒÅ       SetGUIRequestMode(0); msleep(1000);
[FAIL] CURRENT_DIALOG_MAYBE => 0x26
[FAIL] display_idle() => 0x0

There some memory address stuff but not LV , so I should re-run the stub test and see  if there any LV stuff ?
is there any info I can read on how to use the mem_spy for the raw lv buffer or is this a red herring
thanks in advance.

reddeercity

Ok run the full stubs test with "new-lv-buffer-detections" branch results below
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x177048
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x176fe0
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x176fc0
[Pass] bar => '*****hjkl;'
       bzero32(bar + 5, 5)
[Pass] bar => '****'
       t0 = *(uint32_t*)0xC0242014 => 0x63161
       msleep(250)
       t1 = *(uint32_t*)0xC0242014 => 0xa1441
[Pass] ABS(mod(t1-t0, 1048576)/1000 - 250) => 0x4
       LoadCalendarFromRTC( &now )
       s0 = now.tm_sec => 0x15
       Date/time: 2017/04/23 18:34:21
       msleep(1500)
       LoadCalendarFromRTC( &now )
       s1 = now.tm_sec => 0x17
[Pass] mod(s1-s0, 60) => 0x2
[Pass] mod(s1-s0, 60) => 0x2
       m0 = MALLOC_FREE_MEMORY => 0x203d8
[Pass] p = _malloc(50*1024) => 0x104930
[Pass] CACHEABLE(p) => 0x104930
       m1 = MALLOC_FREE_MEMORY => 0x13bd8
       _free(p)
       m2 = MALLOC_FREE_MEMORY => 0x203d8
[Pass] ABS((m0-m1) - 50*1024) => 0x0
[Pass] ABS(m0-m2) => 0x0
       m0 = GetFreeMemForAllocateMemory() => 0x3eb7fc
[Pass] p = _AllocateMemory(256*1024) => 0x9670fc
[Pass] CACHEABLE(p) => 0x9670fc
       m1 = GetFreeMemForAllocateMemory() => 0x3abaa0
       -_FreeMemory(p)
       m2 = GetFreeMemForAllocateMemory() => 0x3ebaac
[Pass] ABS((m0-m1) - 256*1024) => 0x2a4
[Pass] ABS(m0-m2) => 0x2b0
       m01 = MALLOC_FREE_MEMORY => 0x203d8
       m02 = GetFreeMemForAllocateMemory() => 0x3eba4c
[Pass] p = _alloc_dma_memory(256*1024) => 0x4096713c
[Pass] UNCACHEABLE(p) => 0x4096713c
[Pass] CACHEABLE(p) => 0x96713c
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x4096713c
       _free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(24*1024*1024) => 0x42004074
[Pass] UNCACHEABLE(p) => 0x42004074
       _shoot_free(p)
       m11 = MALLOC_FREE_MEMORY => 0x203d8
       m12 = GetFreeMemForAllocateMemory() => 0x3ebaac
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x60
[Pass] suite = shoot_malloc_suite_contig(24*1024*1024) => 0xa6e5e4
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1800000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0xa6e608
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1800000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0xa7a038
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1cf8000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0xa7a05c
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1cf8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(64*1024*1024) => 0xa7a69c
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x4000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0xa7a6c0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1cf8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa7a738
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3724000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x5a5d00e4
[Pass] UNCACHEABLE(p) => 0x5a5d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa7a7b0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x565d00e4
[Pass] UNCACHEABLE(p) => 0x565d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4000000
       shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0xa89580
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x7
[Pass] suite->size => 0xb700000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0xa895a4
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1cf8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42004070
[Pass] UNCACHEABLE(p) => 0x42004070
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa8961c
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3724000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x5a5d00e4
[Pass] UNCACHEABLE(p) => 0x5a5d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa89694
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x5150000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x565d00e4
[Pass] UNCACHEABLE(p) => 0x565d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa8970c
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x6b7c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x525d00e4
[Pass] UNCACHEABLE(p) => 0x525d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa89784
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x85a8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4e5d00e4
[Pass] UNCACHEABLE(p) => 0x4e5d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa897fc
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x9fd4000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a5d00e4
[Pass] UNCACHEABLE(p) => 0x4a5d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0xa89874
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0xb700000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x465d00e4
[Pass] UNCACHEABLE(p) => 0x465d00e4
       chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0xb700000
       shoot_free_suite(suite); suite = 0; chunk = 0;
       EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
       call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
       SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_DIALOG_MAYBE => 0x1
       SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_DIALOG_MAYBE => 0x2
       SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_DIALOG_MAYBE => 0x0
[Pass] display_idle() => 0x1
       GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(500);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x1
[Pass] PLAY_MODE => 0x0
[Pass] MEM(dialog->type) => 0x414944
       GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
       task_create("test", 0x1c, 0x1000, test_task, 0) => 0x818400b4
[Pass] test_task_created => 0x1
[Pass] get_task_name_from_id(get_current_task()) => 'run_test'
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0x81940086
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0x81e6015a
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0x82360098
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
[Pass] f = FIO_CreateFileEx("test.dat") => 0x4
[Pass] FIO_WriteFile(f, (void*)ROMBASEADDR, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)ROMBASEADDR, 0x10000) => 0x10000
       FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = alloc_dma_memory(0x20000) => 0x409648dc
[Pass] f = FIO_Open("test.dat", O_RDONLY | O_SYNC) => 0x4
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
       FIO_CloseFile(f)
       free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] FIO_RemoveFile("test.dat") => 0x0
       SW1(1,100)
[Pass] HALFSHUTTER_PRESSED => 0x1
       SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0


lots of address but doesn't look like any LV buffer address etc. .... unless someone smarter can help .


Screenshot EDMAC
by RedDeerCityTV, on Flickr
Screenshot of the edmac  and I notice that edmac#5 is now active (green) (3570x1267) that the buffer size I used with very limited success to get 3584x1068 in post #27
When I did update to this branch I notice it was on the older ml core even thou I cloned a fresh copy of the source.
on the newer ml source code that channel is not active (yellow) so I have to wonder why ? could this be a issue , have to investigate further
# Magic Lantern v2.3.NEXT.2017Apr23.5D2212 (09dcd0475cb3+ (new-lv-buffer-detection))
# Built on 2017-04-23 05:47:00 UTC by ml@ml-pc
# Configuration saved on 2017/04/23 18:44:11
beta.warn = 23


So I'm not sure it these stubs are still useful .

Next I complied the "allocate-raw-lv-buffer" and that one seem to use the newer ml core source .
# Magic Lantern Nightly.2017Apr24.5D2212 (5d168ad4e8c9+ (allocate-raw-lv-buffer))
# Built on 2017-04-24 01:16:11 UTC by ml@ml-pc
# Configuration saved on 2017/04/23 19:47:45
beta.warn = 23



Screenshot of Lv with MPU_Dump running
by RedDeerCityTV, on Flickr

So I found this very interesting as I pushed the 5x Zoom button I notice that the Live view resolution is not what I thought  & have read to be  ???
In 1:1 a surprising 2040x1268  and in 3x crop (5x Zoom) 2312x1128 , Really !
I was under the impression that full Liveview was only 1880x1250  and 3x crop was 2152x1078.
Wondering out loud , could be a result of the edmac channel #5 being active (maybe  larger buffer size)
More mysteries to solve  :D
I have a MPU-EEP , Ram & Rom dumps not sure how to use them yet , there may be nothing useful either .

On a lighter note I never notice the False Color Overlays , there where on by default in the  "Magic Lantern v2.3.NEXT" version
If it wasn't for that i would have never notice them  8)


False Color Overlays
by RedDeerCityTV, on Flickr