ProcessTwoInTwoOutLosslessPath

[koljanych]

io-trace-full_magiclantern-Nightly.2018Aug11.550D109.zip

https://yadi.sk/d/NlOlpbms3aMHrB - capture
https://yadi.sk/d/H7dkA4SA3aMHrC - view

[reddeercity]

Thanks for the 550D LOG's 
they look very close to my 5d2 LOG's if not the same .
Looks like we my have a winner here for Lossless !

Code: [Select]

11.533.527  FrontShtDe:ff08a33c:96:05: sdfExecuteMem1ToRawPath(49091)��(SemOK)
11.533.551  FrontShtDe:ff08a374:96:05: ProcessTwoInTwoOutJpegPath(R) Start(49091)
11.533.592  FrontShtDe:ff06a018:00:00: *** LockEngineResources(8b0a14) x17:
11.533.620  FrontShtDe:00cb97fc:00:00:      1)    10002 (read channel 0xa)
11.533.636  FrontShtDe:00cb97fc:00:00:      2)        3 (write channel 0x3)
11.533.650  FrontShtDe:00cb97fc:00:00:      3)        4 (write channel 0x4)
11.533.670  FrontShtDe:00cb97fc:00:00:      4)    30000 (read connection 0x0)
11.533.689  FrontShtDe:00cb97fc:00:00:      5)    20005 (write connection 0x5)
11.533.709  FrontShtDe:00cb97fc:00:00:      6)    20016 (write connection 0x16)
11.533.721  FrontShtDe:00cb97fc:00:00:      7)    50003 (?)
11.533.734  FrontShtDe:00cb97fc:00:00:      8)    5000d (?)
11.533.748  FrontShtDe:00cb97fc:00:00:      9)    5000f (?)
11.533.760  FrontShtDe:00cb97fc:00:00:     10)    5001a (?)
11.533.772  FrontShtDe:00cb97fc:00:00:     11)    80000 (?)
11.533.784  FrontShtDe:00cb97fc:00:00:     12)    90000 (?)
11.533.797  FrontShtDe:00cb97fc:00:00:     13)    a0000 (?)
11.533.812  FrontShtDe:00cb97fc:00:00:     14)   160000 (?)
11.533.826  FrontShtDe:00cb97fc:00:00:     15)   130003 (?)
11.533.841  FrontShtDe:00cb97fc:00:00:     16)   130004 (?)
11.533.855  FrontShtDe:00cb97fc:00:00:     17)   130005 (?)

So any one with a 550D can jump in and start to dev. lossless , just look back a few page's for code on digic 4
here the code I'm working from --crop_rec_4k_Digic4_Lossless.c and this post here is where I start Lossless for 5d2 but it should apply to 550D .

Edit: a1ex , the 50D logs don't have the same level of Resources details as 5d2 , 550d is that the way it is on 50D or did I miss something when I compiled "io_trace_full" for 50D ?

[scotophorus]

Debug io-trace messages from the 7D 2.0.3, i loaded edmac.mo from nightly build and followed your instructions, i hope they are valid:

https://drive.google.com/open?id=1ZrSDF9c8gENH78rvIudZ6fjElD3nBuid

[reddeercity]

Thanks , looks good 

[a1ex]

Edit: a1ex , the 50D logs don't have the same level of Resources details as 5d2 , 550d is that the way it is on 50D or did I miss something when I compiled "io_trace_full" for 50D ?

Something like this should work for all cameras (in dm-spy-extra.c):

Code: [Select]

    STUB_ENTRY(CreateResLockEntry, 2 | RET, CreateResLockEntry_log),
    STUB_ENTRY(LockEngineResources, 1, LockEngineResources_log),
    STUB_ENTRY(UnLockEngineResources, 1, UnLockEngineResources_log),

Will test some more and enable it by default.

[aprofiti]

Edit: a1ex , the 50D logs don't have the same level of Resources details as 5d2 , 550d is that the way it is on 50D or did I miss something when I compiled "io_trace_full" for 50D ?

Something like this should work for all cameras (in dm-spy-extra.c):

Code: [Select]

    STUB_ENTRY(CreateResLockEntry, 2 | RET, CreateResLockEntry_log),
    STUB_ENTRY(LockEngineResources, 1, LockEngineResources_log),
    STUB_ENTRY(UnLockEngineResources, 1, UnLockEngineResources_log),

Will test some more and enable it by default.

Code: [Select]

9.633.183  FrontShtDe:ff882068:96:05: ->sdsPostJob InsertStageJob(32186)
 9.633.233  FrontShtDe:ff8a2830:00:03: [JOB] PostNextStage (ID = 32186, Class = 150, Pos = 4)
 9.633.324  FrontShtDe:ff8820dc:96:05: sdsPostJob Start(32186)
 9.633.360  FrontShtDe:ff882108:96:05: sdfGetDevelopDevType(32186)(0x7000)
 9.633.406  FrontShtDe:ff88217c:96:05: ENABLE(Poster:0)(Ohyear:0)
 9.633.452  FrontShtDe:ff88148c:96:05: sdfAllocateMemoryDevelopSuite(32186)
 9.636.780  FrontShtDe:ff882c90:96:05: sdsMem1ToRawCompression
 9.638.127  FrontShtDe:ff880e4c:96:05: sdfExecuteMem1ToRawPath(32186)
 9.638.227  FrontShtDe:ff881060:96:05: sdfExecuteMem1ToRawPath(32186)Å©(SemOK)
 9.638.261  FrontShtDe:ff881098:96:05: ProcessTwoInTwoOutJpegPath(32186)
 9.638.326  FrontShtDe:ffa3620c:00:00: *** LockEngineResources(72089c) x31:
 9.638.371  FrontShtDe:00090c34:00:00:      1)    10002 (read channel 0xa)
 9.638.399  FrontShtDe:00090c34:00:00:      2)        3 (write channel 0x3)
 9.638.422  FrontShtDe:00090c34:00:00:      3)        4 (write channel 0x4)
 9.638.454  FrontShtDe:00090c34:00:00:      4)    30000 (read connection 0x0)
 9.638.488  FrontShtDe:00090c34:00:00:      5)    20005 (write connection 0x5)
 9.638.519  FrontShtDe:00090c34:00:00:      6)    20016 (write connection 0x16)
 9.638.543  FrontShtDe:00090c34:00:00:      7)    50003 (?)
 9.638.566  FrontShtDe:00090c34:00:00:      8)    5000d (?)
 9.638.588  FrontShtDe:00090c34:00:00:      9)    5000f (?)
 9.638.612  FrontShtDe:00090c34:00:00:     10)    5001a (?)
 9.638.639  FrontShtDe:00090c34:00:00:     11)    80000 (?)
 9.638.663  FrontShtDe:00090c34:00:00:     12)    90000 (?)
 9.638.685  FrontShtDe:00090c34:00:00:     13)    a0000 (?)
 9.638.710  FrontShtDe:00090c34:00:00:     14)   160000 (?)
 9.638.736  FrontShtDe:00090c34:00:00:     15)   130003 (?)
 9.638.760  FrontShtDe:00090c34:00:00:     16)   130004 (?)
 9.638.785  FrontShtDe:00090c34:00:00:     17)   130005 (?)
 9.638.810  FrontShtDe:00090c34:00:00:     18)   130006 (?)
 9.638.836  FrontShtDe:00090c34:00:00:     19)   130007 (?)
 9.638.861  FrontShtDe:00090c34:00:00:     20)   130008 (?)
 9.638.888  FrontShtDe:00090c34:00:00:     21)   13000c (?)
 9.638.912  FrontShtDe:00090c34:00:00:     22)   130010 (?)
 9.638.937  FrontShtDe:00090c34:00:00:     23)   130011 (?)
 9.638.962  FrontShtDe:00090c34:00:00:     24)   130012 (?)
 9.638.987  FrontShtDe:00090c34:00:00:     25)   130013 (?)
 9.639.011  FrontShtDe:00090c34:00:00:     26)   130014 (?)
 9.639.035  FrontShtDe:00090c34:00:00:     27)   130015 (?)
 9.639.058  FrontShtDe:00090c34:00:00:     28)   130018 (?)
 9.639.085  FrontShtDe:00090c34:00:00:     29)   13001a (?)
 9.639.109  FrontShtDe:00090c34:00:00:     30)   13001b (?)
 9.639.137  FrontShtDe:00090c34:00:00:     31)   13001c (?)

This looks much better for our needs

[reddeercity]

Great ! can you post the full Logs some where ?

[aprofiti]

Great ! can you post the full Logs some where ?

Cr2TakeDetailed Cr2ReviewDetailed

Is this code working for 5d2/7d? I got this when I tried to compile dfort's branch for 50D:

Code: [Select]

lv-img-engio.o: In function `digic_iso_step':
/Users/alex/Desktop/pullML/dfort/platform/50D.109/../../src/lv-img-engio.c:847: undefined reference to `_raw_lv_get_iso_post_gain'
make: *** [magiclantern] Error 1

Can I have rom dumps of both camera? I would like to patter match stubs for 50D

[dfort]

Is this code working for 5d2/7d?

This was from a series of failed experiments where I was trying to get lossless compression working with the silent module on the 7D. Didn't get very far with it though it does compile on the 7D. If you try merging the latest crop_rec_4k into that branch you'll notice a suggestion to add FRAME_SHUTTER_BLANKING_READ. It is defined on the 50D but not the other Digic 4 cameras. Maybe this is the key to fixing the "earthquake video" sync issues on the 10bit/12bit Digic 4 experiments? I don't know, it has been a while since playing around with this.

[aprofiti]

Used 7D as a reference for pattern matching and come to this:

Code: [Select]

    if (is_camera("50D", "*"))
    {
        TTL_SetArgs     = (void *) 0xFF195924;      /* fills TTJ_Args struct; PictureSize(Mem1ToRaw) */
        TTL_Prepare     = (void *) 0xFF236248;      /* called right after ProcessTwoInTwoOutJpegPath */
                                                    /* calls [TTJ] GetPathResources and sets up the encoder for RAW/SRAW/MRAW */
        TTL_RegisterCBR = (void *) 0xFFA3555C;      /* RegisterTwoInTwoOutJpegPathCompleteCBR */
        TTL_SetFlags    = (void *) 0xFF0A2534;      /* called next, with PictureType as arguments */
        TTL_Start       = (void *) 0xFFA3652C;      /* called next; starts the EDmac transfers */
        TTL_Stop        = (void *) 0xFFA36564;      /* called right after sssStopMem1ToRawPath */
        TTL_Finish      = (void *) 0xFFA3659C;      /* called next; calls UnlockEngineResources and returns output size from JpCoreCompleteCBR */
    }
@dfort can you double check please? Mostly used strings to find adjacent code and then checked argument number/function code.
First one is a bit different as argument numbers passed to function, but look like it is the right one.

Code related to resources:

Code: [Select]

    else if (is_camera("50D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10002 | edmac_channel_to_index(edmac_read_chan),
            0x30000,    /* read  connection  0 */
            0x20005,    /* write connection  5 */
            0x20016,    /* write connection 16 */
            0x50003,
            0x5000d,
            0x5000f,
            0x5001a,
            0x80000,
            0x90000,
            0xa0000,
            0x160000,
            0x130003,
            0x130004,
            0x130005,
            0x130006,
            0x130007,
            0x130008,
            0x13000c,
            0x130010,
            0x130011,
            0x130012,
            0x130013,
            0x130014,
            0x130015,
            0x130018,
            0x13001a,
            0x13001b,
            0x13001c,
        };
Is the write_channel set to 0 good instead 0x10003/0x10004 from logs?

Can't find stubs for decompress_init using 7D... Im'a bit stuck... Also what are all the "EngDrvOut(...)" stuff?

@reddeercity Can you update you repository please? It should be very useful to understand what to change from the dfort's repo (won't compile also for 5d2)

[aprofiti]

Commented "total_movie_gain *= _raw_lv_get_iso_post_gain();" in a similar way of an old reddeercity's post.

It show option for lossless compressed DNG, but camera freezes right after taking a lossless picture (full-res or simple).
It print overexposed areas but does't print info about compression (max_compressed_size infobox)




Maybe is because it miss EngDrvOut() code for 50D? or it is not necessary?

[dfort]

@dfort can you double check please?

Looks good to me. Then again I don't have lossless compression working on the 7D yet so it might be that my addresses might be off.

Then there's this:

modules/silent/lossless.c

Code: [Select]

    if (is_camera("7D", "2.0.3"))
    {
        Setup_DecodeLosslessRawPath = (void *) 0xFF2E8EAC;
        Start_DecodeLosslessPath    = (void *) 0xFF2E8F5C;
        Cleanup_DecodeLosslessPath  = (void *) 0xFF2E906C;
    }

I tried finding it in the 50D using pattern matching but couldn't do it. It might be buried somewhere in the log files when shooting CR2 files.

[reddeercity]

Good to see some actions , my plan worked 
@aprofiti I see you figured it out , yea that looks right freeze after a lossless , a1ex tried in qemu  I think or he still has a 5d2 and he says after the taking photo it needs to go somewhere
to be save , but it not there , maybe a wrong channel ? not sure .

Also getting closer to emulating a CR2 image capture. Emulation reaches sdfExecuteMem1ToRawPath (FrontShtDevelop),
attempts to configure JPCORE and gets stuck requesting image data from EDMAC channel #3, connection 5.
I believe that's where the firmware expects LJ92 data from the lossless encoder.

One thing is for sure it does capture the lossless , just need to understand why it not saving  , the jpeg raw compression slices could be wrong etc. ....
I think I did some mods there I'll look at my source . Look here I play around with slices and I got the compressed sized as seen in that photo but did not save ,
so yea I think "EngDrvOut" is needed with out I get no compressed size on screen just lockup/freezes after pressing the shutter for photo .

Code: [Select]

if (is_camera("5D2", "*"))
    {
        EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2    - 1)); 
        EngDrvOut(0xC0F12020, PACK32(width    - 1,  height/10 - 1));  /* 0x18A0127 */
    }



[reddeercity]

Here my sources code for Lossless on digic 4/5d2 I'm working from eXperimental4kLossless_magic-lantern.zip
also here is the build for Lossless on 5d2 , doesn't work but if someone what to try and see what happen ......
magiclantern-eXperimental4kLossless.2018Aug20.5D2212.zip

[aprofiti]

Here my sources code for Lossless on digic 4/5d2 I'm working from eXperimental4kLossless_magic-lantern.zip
also here is the build for Lossless on 5d2 , doesn't work but if someone what to try and see what happen ......
magiclantern-eXperimental4kLossless.2018Aug20.5D2212.zip

Thank you reddeercity, this is what i noticed:

Code: [Select]

    if (is_camera("5D2", "2.1.2"))
    {
        /* ProcessTwoInTwoOutJpegPath, 5D2 2.1.2 */
        TTL_SetArgs     = (void *) 0xFF1BEB18;      /* fills TTJ_Args struct; PictureSize(Mem1ToRaw) */
        TTL_Prepare     = (void *) 0xFF259B58;      /* called right after ProcessTwoInTwoOutJpegPath */
                                                    /* calls [TTJ] GetPathResources and sets up the encoder for RAW/SRAW/MRAW */
        TTL_RegisterCBR = (void *) 0xFF258E70;      /* RegisterTwoInTwoOutJpegPathCompleteCBR */
        TTL_SetFlags    = (void *) 0xFF0AA9D4;      /* called next, with PictureType as arguments */
        TTL_Start       = (void *) 0xFF259E3C;      /* called next; starts the EDmac transfers */
        TTL_Stop        = (void *) 0xFF259E74;      /* called right after sssStopMem1ToRawPath */
        TTL_Finish      = (void *) 0xFF259EAC;      /* called next; calls UnlockEngineResources and returns output size from JpCoreCompleteCBR */
    }
Cross-checked with 50D and 7D from me and dfort and they appears to be good, they appears point out at the same functions.
This mean that is less likely to be bad but can't be sure because we don't have lossless working on these camera...

I tried finding it in the 50D using pattern matching but couldn't do it. It might be buried somewhere in the log files when shooting CR2 files.

Same here, as it's a "ProcessTwoInTwoOutJpegPath" camera instead of "ProcessTwoInTwoOutLosslessPath", it I tried looking for string regarding Jpeg printed by "ImgPlayDrv" from logs:

Code: [Select]

    if (is_camera("50D", "*"))
    {
        Setup_DecodeLosslessRawPath = (void *) 0xff962c60; //<<<<<< ImagePlayDriverTask ProcessID = 6 - not sure if need to start from here or if the bottom one are better, but this is in the same address range like the one from D5 cameras
    //    Setup_DecodeLosslessRawPath = (void *) 0xffa17290; //DEC RequestDecodeJpeg(mode:1) 193
    //    Setup_DecodeLosslessRawPath = (void *) 0xffa16e68; //DEC SetParameterDecodeJpeg 148
        Start_DecodeLosslessPath    = (void *) 0xFF960AE8; //StartJpegDecoding 614
        Cleanup_DecodeLosslessPath  = (void *) 0xff963e2c; //ClearDecodeJpegPath 414
    }
Maybe a better idea is to sneak peek address from a working d5 camera using ProcessTwoInTwoOutJpegPath (700D, 650D, M, 100D).
What do you think about @dfort?

Tried this with 50D with no results, but I wasn't expecting to works:

Code: [Select]

    if (is_camera("5D2", "*"))
    {
        EngDrvOut(0xC0F12010,        width    - 1                 );  /* 0xB8F     */
        EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2    - 1));/* 0xF6D0B8F */
        EngDrvOut(0xC0F1201C,        width/10 - 1                 );  /* 0x127     */
        EngDrvOut(0xC0F12020, PACK32(width/10 - 1,  height/20 - 1));  /* 0x18A0127 */
    }
@reddeercity can you explain how you got these address and values? Is due to this procedure?

[ArcziPL]

Yes. Or logs done by running io-trace-full build on a real camera.

[reddeercity]

Yes. Or logs done by running io-trace-full build on a real camera.

Yes , real hardware/Camera

[reddeercity]

Thank you reddeercity, ..........
Tried this with 50D with no results, but I wasn't expecting to works:

Code: [Select]

    if (is_camera("5D2", "*"))
    {
        EngDrvOut(0xC0F12010,        width    - 1                 );  /* 0xB8F     */
        EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2    - 1));/* 0xF6D0B8F */
        EngDrvOut(0xC0F1201C,        width/10 - 1                 );  /* 0x127     */
        EngDrvOut(0xC0F12020, PACK32(width/10 - 1,  height/20 - 1));  /* 0x18A0127 */
    }
@reddeercity can you explain how you got these address and values? Is due to this procedure?

Mainly a guess , but being the 5d2 & the 5D3 are very similar , (e.g. c0f06084 D4 , c0f06804 D5 they do the same thing on both camera) it's usually 1 or 2 reg numbers different .
Case in point -- all my 4k/UHD dev. is base of the first 3k 5d3 preset and work backwards from there to where I nearly have it working (Oh so close now  , it shouldn't be too long from now )

But those  "EngDrvOut" address are in my decompiled 5d2 rom and also in my dm-0001_io-trace-full_reveiwing_cr2_outside_liveview Log so I figured it couldn't hurt .

Code: [Select]

**dm-0001_io-trace-full_reveiwing_cr2_outside_liveview**
 4.098.439  FrontShtDe:ff9a5630:MMIO : [0xC0F12010] <- 0x0E9F078F
 4.098.441  FrontShtDe:ff9a5630:MMIO : [0xC0F12014] <- 0x0E9F077F
 4.098.445  FrontShtDe:ff9a5630:MMIO : [0xC0F1201C] <- 0x00E90078
 4.098.446  FrontShtDe:ff9a5630:MMIO : [0xC0F12020] <- 0x00E90077

and from 5d2.212.dis -- there 3 address for c0f12010

Code: [Select]

ff4dfd6c: c0f12010 rscsgt r2, r1, r0, lsl r0
ff4e0298: c0f12010 rscsgt r2, r1, r0, lsl r0
ff4e0838: c0f12010 rscsgt r2, r1, r0, lsl r0

 from 5d2.212.dis -- there 3 address for c0f12014

Code: [Select]

ff4dfd74: c0f12014 rscsgt r2, r1, r4, lsl r0
ff4e02a0: c0f12014 rscsgt r2, r1, r4, lsl r0
ff4e0840: c0f12014 rscsgt r2, r1, r4, lsl r0

from 5d2.212.dis -- there 3 address for c0f1201C

Code: [Select]

ff4dfd84: c0f1201c rscsgt r2, r1, r12, lsl r0
ff4e02b0: c0f1201c rscsgt r2, r1, r12, lsl r0
ff4e0850: c0f1201c rscsgt r2, r1, r12, lsl r0

from 5d2.212.dis -- there 3 address for c0f12020

Code: [Select]

ff4dfd8c: c0f12020 rscsgt r2, r1, r0, lsr #32
ff4e02b8: c0f12020 rscsgt r2, r1, r0, lsr #32
ff4e0858: c0f12020 rscsgt r2, r1, r0, lsr #32

Not sure what the strings are doing , I still have a very had time understand strings fully .
After the "Pack32" stuff I have no idea if that code is right for d4 cam's ,
I think it has to do with the slices (d4/5d2 are 1936 & 1920) Understanding What is stored in a Canon RAW .CR2 file

Found d4/5d2 old compressed raw test from back in march of this year
had the "EngDrvOut" stuff , I did something else too to the code can't remember right now , I'll have to look in one of my old compressed raw source code experiments .



@a1ex , I notice something in the cr2 compressed between the 5d2 & the 5d3 in Understanding What is stored in a Canon RAW .CR2 file the 5D3 uses  "jpeg comp" "2" where the 5d2 uses "4

the Full Raw Jpeg is encoded with 14 bits, in 2 colors (prior to the 50D and the Digic IV), then using 4 colors with the 50D up to 1100D. Since 1D X and up to 6D, Canon is back to 2 components

Could this be a problem ? or does this even apply ? mind you I don't total understand this .
Does this have something to do with slices ? 

Code: [Select]

width/10 - 1,  height/20 - 1etc. ....

[reddeercity]

Quick check of the dm-50D-cr2Take.Log for "C0f12010 , C0f12014 , C0f1201C & C0f12020"
there are present

Code: [Select]

3.418.899  FrontShtDe:ff97d91c:MMIO : [0xC0F12010] <- 0x0C5F064F
3.418.900  FrontShtDe:ff97d91c:MMIO : [0xC0F12014] <- 0x0C5F063F
3.418.904  FrontShtDe:ff97d91c:MMIO : [0xC0F1201C] <- 0x018B00C9
3.418.906  FrontShtDe:ff97d91c:MMIO : [0xC0F12020] <- 0x018B00C7
if they do anything is another matter

[aprofiti]

To my understanding, to make lossless works we need to "tell" to camera via registry values what is the size of the image to process and others possible values to fix image;
Also image is processed into two "slices" from LossLess routine. Are they calculated from sensor size, image size or jpeg size?

Using dfort's spreadsheet as a reference for sensor size, some possible values found in logs and used to make it works could be:

Code: [Select]

Camera 50D:
Sensor Width:  4832  -> 0x12E0
Sensor Height: 3228  -> 0xC9C
Image Width:   4752  -> 0x1290
Image Height:  3168  -> 0xC60

PACK32(Sensor Width - 1, Sensor Height -1)      -> 0000 1100 1001 1011 (0xC9B) 0001 0010 1101 1111 (0x12DF)   -> 0xC9B12DF
PACK32(Sensor Width - 1, Sensor Height/2 -1)    -> 0000 0110 0100 1101 (0x64D) 0001 0010 1101 1111 (0x12DF)   -> 0x64D12DF


Yes. Or logs done by running io-trace-full build on a real camera.

Unfortunately looking into logs for RABBIT's address range 0xc0f1*, I can find only those lines:

Code: [Select]

15.702.354     CtrlSrv:ff85de78:82:01: ImgDDev Reg c0f140e0 01b00000
15.702.389     CtrlSrv:ff85de78:82:01: ImgDDev Reg c0f140e4 01b005a0

@a1ex Is again logging 50D a bit different from others camera and need to be taken care of it? (500D logs appears to have it)
How does full-io-trace's logs looks like from D5 ProcessTwoInTwoOutJpegPath cameras (ex. 700D)?

Edit:
Found pack32 sensor size at a different address than expected:

Code: [Select]

2.505.534  ShootCaptu:ff97d91c:MMIO : [0xC0F080B0] <- 0x0C9B12DF
 2.743.185  FrontShtDe:ff97d91c:MMIO : [0xC0F13068] <- 0x0C9B12DF


[reddeercity]

Slices are as far as I know are a set size in the encoder for each camera .
Looking in to those reg's again

Code: [Select]

  [0xC0F12010] <- 0x0E9F078F
  [0xC0F12014] <- 0x0E9F077F
  [0xC0F1201C] <- 0x00E90078
  [0xC0F12020] <- 0x00E90077

If you do the math on the last reg's  0x00E90078 = 15270008 , 0x00E90077 = 15270007 
then add the Decimal number together you get 30540015 very close to the (see post #417) compressed size for 5d2 5632x3752 = 30842880
if I did my math right . Maybe I'll try "c0f1201c & c0f12020 and see if it works .

[aprofiti]

I was using wrong log to look for 0xC0F13*** and found the correct one, here are MMIO traces regarding RABBIT:

Code: [Select]

2.743.052  FrontShtDe:ff97d91c:MMIO : [0xC0F13060] <- 0x80000000
 2.743.183  FrontShtDe:ff97d91c:MMIO : [0xC0F13064] <- 0x00000E08
 2.743.185  FrontShtDe:ff97d91c:MMIO : [0xC0F13068] <- 0x0C9B12DF
 2.743.187  FrontShtDe:ff97d91c:MMIO : [0xC0F13050] <- 0x00000014
 2.743.189  FrontShtDe:ff97d91c:MMIO : [0xC0F13054] <- 0x00000000
 2.743.190  FrontShtDe:ff97d91c:MMIO : [0xC0F13058] <- 0x00000000
 2.743.922  FrontShtDe:ff97d91c:MMIO : [0xC0F13048] <- 0x00000003
 2.743.924  FrontShtDe:ff97d91c:MMIO : [0xC0F13060] <- 0x00000000
 2.743.929  FrontShtDe:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 2.743.931  FrontShtDe:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000003
 2.743.934  FrontShtDe:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 2.743.936  FrontShtDe:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 2.866.854  FrontShtDe:ff97d91c:MMIO : [0xC0F13060] <- 0x80000000
 2.872.860  FrontShtDe:ff97d91c:MMIO : [0xC0F13000] <- 0x80000000
 2.873.155  FrontShtDe:ff97d91c:MMIO : [0xC0F13008] <- 0x00000101
 2.873.156  FrontShtDe:ff97d91c:MMIO : [0xC0F1300C] <- 0x00000880
 2.873.158  FrontShtDe:ff97d91c:MMIO : [0xC0F13010] <- 0x00000CC0
 2.873.160  FrontShtDe:ff97d91c:MMIO : [0xC0F13014] <- 0x00000008
 2.873.162  FrontShtDe:ff97d91c:MMIO : [0xC0F13018] <- 0x0C5F020F
 2.873.163  FrontShtDe:ff97d91c:MMIO : [0xC0F1301C] <- 0x0000020F
 2.873.165  FrontShtDe:ff97d91c:MMIO : [0xC0F13020] <- 0x00000001
 2.873.167  FrontShtDe:ff97d91c:MMIO : [0xC0F13050] <- 0x00000000
 2.873.169  FrontShtDe:ff97d91c:MMIO : [0xC0F13054] <- 0x00000000
 2.873.170  FrontShtDe:ff97d91c:MMIO : [0xC0F13058] <- 0x00000000
 2.876.725  FrontShtDe:ff97d91c:MMIO : [0xC0F13000] <- 0x00000000
 2.876.729  FrontShtDe:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 2.876.732  FrontShtDe:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000003
 2.876.735  FrontShtDe:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 2.876.737  FrontShtDe:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 2.991.160  FrontShtDe:ff97d91c:MMIO : [0xC0F13000] <- 0x80000000
 2.995.403  RearShtDev:ff97d91c:MMIO : [0xC0F13000] <- 0x80000000
 2.995.483  RearShtDev:ff97d91c:MMIO : [0xC0F13008] <- 0x00000101
 2.995.484  RearShtDev:ff97d91c:MMIO : [0xC0F1300C] <- 0x00000280
 2.995.486  RearShtDev:ff97d91c:MMIO : [0xC0F13010] <- 0x000003C0
 2.995.488  RearShtDev:ff97d91c:MMIO : [0xC0F13014] <- 0x00000000
 2.995.490  RearShtDev:ff97d91c:MMIO : [0xC0F13018] <- 0x0077009F
 2.995.491  RearShtDev:ff97d91c:MMIO : [0xC0F1301C] <- 0x00000000
 2.995.493  RearShtDev:ff97d91c:MMIO : [0xC0F13020] <- 0x00000001
 2.995.495  RearShtDev:ff97d91c:MMIO : [0xC0F13050] <- 0x00000000
 2.995.497  RearShtDev:ff97d91c:MMIO : [0xC0F13054] <- 0x00000000
 2.995.499  RearShtDev:ff97d91c:MMIO : [0xC0F13058] <- 0x00000000
 2.995.547  RearShtDev:ff97d91c:MMIO : [0xC0F13000] <- 0x00000000
 2.995.551  RearShtDev:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 2.995.554  RearShtDev:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000003
 2.995.556  RearShtDev:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 2.995.559  RearShtDev:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 2.997.414  RearShtDev:ff97d91c:MMIO : [0xC0F13000] <- 0x80000000
 3.261.519  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 3.261.522  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000030
 3.261.524  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000001
 3.261.527  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 3.262.055  **INT-64h*:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000000
 3.262.057  **INT-64h*:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 3.262.060  **INT-64h*:ff97d7d0:MMIO : [0xC0F13000] <- 0x80000000
 3.265.204  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000000
 3.265.205  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 3.265.209  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x80000000
 3.268.690  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 3.268.693  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000030
 3.268.694  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000001
 3.268.698  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 3.269.408  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x80000000
 3.269.411  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13008] <- 0x00000111
 3.269.415  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1300C] <- 0x00000E00
 3.269.417  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13010] <- 0x00001500
 3.269.420  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13014] <- 0x0000001D
 3.269.422  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13018] <- 0x0C5F009F
 3.269.424  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1301C] <- 0x0000006F
 3.269.426  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13050] <- 0x00000000
 3.269.861  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x00000000
 3.269.863  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000030
 3.269.865  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000001
 3.269.868  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13004] <- 0x00000001
 3.373.401  **INT-5Bh*:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000000
 3.373.403  **INT-5Bh*:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 3.373.406  **INT-5Bh*:ff97d7d0:MMIO : [0xC0F13000] <- 0x80000000
 3.373.616  **INT-6Eh*:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 3.373.864  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13048] <- 0x00000000
 3.373.866  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F1304C] <- 0x00000000
 3.373.869  ImgPlayDrv:ff97d7d0:MMIO : [0xC0F13000] <- 0x80000000
Something to notice about apart the PACK32(Sensor Width - 1, Sensor Height -1)?

I tried EngDrvOut with these values:

Code: [Select]

      EngDrvOut(0xC0F2E02C, 0x064D0C9B); // here is PACK32(Sensor Width - 1, Sensor Height/2 -1) in canon configuration. Replaced with ML configuration for "slices"
      EngDrvOut(0xC0F13068, 0x0C9B12DF); // FrontShutter PACK32(Sensor Width - 1, Sensor Height -1)
      EngDrvOut(0xC0F13064, 0x00000E08);
      EngDrvOut(0xC0F13050, 0x00000014);
      EngDrvOut(0xC0F13054, 0x00000000);
      EngDrvOut(0xC0F13058, 0x00000000);
      EngDrvOut(0xC0F13060, 0x80000000);
      EngDrvOut(0xC0F13000, 0x80000000);

Unfortunately camera still freezes after taking a silent picture and I'm still trying to figure out what informations to extract from MMIO traces

Slices are as far as I know are a set size in the encoder for each camera .
Looking in to those reg's again

Code: [Select]

  [0xC0F12010] <- 0x0E9F078F
  [0xC0F12014] <- 0x0E9F077F
  [0xC0F1201C] <- 0x00E90078
  [0xC0F12020] <- 0x00E90077

If you do the math on the last reg's  0x00E90078 = 15270008 , 0x00E90077 = 15270007 
then add the Decimal number together you get 30540015 very close to the (see post #417) compressed size for 5d2 5632x3752 = 30842880
if I did my math right . Maybe I'll try "c0f1201c & c0f12020 and see if it works .

Code: [Select]

2.743.197  FrontShtDe:ff97d91c:MMIO : [0xC0F12010] <- 0x0C5F064F  // PACK32(? , Image Height - 1)
 2.743.199  FrontShtDe:ff97d91c:MMIO : [0xC0F12014] <- 0x0C5F063F  // PACK32(? , Image Height - 1)
 2.743.203  FrontShtDe:ff97d91c:MMIO : [0xC0F1201C] <- 0x018B00C9 // PACK32(close to image width * 12 , ?)
 2.743.204  FrontShtDe:ff97d91c:MMIO : [0xC0F12020] <- 0x018B00C7 // PACK32(close to image width * 12 , ?)
They appears to be used also on 50D. Their values are close to sensor/image size

[reddeercity]

Playing around with different " EngDrvOut" code .
Tried

Code: [Select]

if (is_camera("5D2", "*"))
    {
        EngDrvOut(0xC0F13068, PACK32(width    - 1,  height    - 1));  /* 0x0EDB169F on 5D2 */ 
        //EngDrvOut(0xC0F12010,        width    - 1                 );   /* 0x0E9F078F *//
        //EngDrvOut(0xC0F12014, PACK32(width    - 1,  height/2    - 1)); /* 0x0E9F077F *//
        //EngDrvOut(0xC0F1201C,        width - 1                 );  /* 0x00E90078 *//
        //EngDrvOut(0xC0F12020, PACK32(width - 1,  height - 1));  /* 0x00E90077 *//
    }Those values came from my cr2 review log outside liveview io-trace-full build , didn't work but something interesting
happen when I tried burst mode in lossless , started to save frames around 5-7 then said out of memory this printed out a error on screen
and made a "assert log"

Code: [Select]

ML ASSERT:
tmp_suite
at silent.c:1042 (silent_pic_take_lv), task shoot_task
lv:1 mode:3

shoot_task stack: 18ffa8 [190168-18e168]
0xUNKNOWN  @ ff8773e0:190160
0x0009D668 @ 7c7b4:190100
0xUNKNOWN  @ 9d6bc:1900e8
0x009A5444 @ 9a655c:1900d0
0x0004EADC @ 9a5cd4:18ffd8
0x0004E378 @ 4eb38:18ffa8

Magic Lantern version : eXperimental4kLossless.2018Aug26.5D2212
Mercurial changeset   : 4286b6c7b755+ (crop_rec_4k_Digic4)
Built on 2018-08-26 22:28:53 UTC by david@reddeercity.
Free Memory  : 166K + 3698K
not sure if it helpful , there is some "unknow" there should there be a variable there ?
on to the next change and see would happen.
 

[reddeercity]

have another go at lossless on 5D2/D4
Did a dm-spy log in sRaw2 (small raw2 - 2800x1872)
Hoping to find something how is encodes for full frame 5768 to 2808

Code: [Select]

[TTJ][150,5768,0] SRAW(2808,1872,0,15)
      ..........
DA738> FrontShtDe:ffa59888:16:03: [TTJ] START WR1:0x31d00b8 WR2:0x2e040c4
DA76C> FrontShtDe:ffa598b4:16:03: [TTJ] START RD1:0x100882fa RD2:0x124d1864I'm see some different address in the recourse's then full frame , going thought the log now .
Also did a dm-spy with sRaw (3820x2560) I think , haven't looked at yet .
I'll update if I find anything useful .
   

[reddeercity]

I think we may have a encoder size/resolution  miss match on the 5d2/d4 ,
The size we capture is 5632x3752 see image in post

Looking at 5d2 cr2 with exiftool

Code: [Select]

ensor Width                    : 5792
Sensor Height                   : 3804
Sensor Left Border              : 168
Sensor Top Border               : 56
Sensor Right Border             : 5783
Sensor Bottom Border            : 3799So the Canon active area is

Code: [Select]

5624x3748and magic lantern active area is

Code: [Select]

5632x3752I would think the encoder has stick rules for input & export and by changing input size It could cause a locking up in the encoder .
I wonder if we change the active area to what canon is for the encoder .

From what I tell all problem start with the encoder on export , that when it lockup the cam & need a battery pull
I need to look at the silent picture module code and see if I can change the capture area to the same as Canon
and see if there still a issue.