ML on EOS-M2

Started by Palpatine, September 22, 2015, 02:48:23 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Danne

Got this when taking a cr2 still image in movie mode:
ML ASSERT:
0
at ../../src/raw.c:669 (raw_lv_realloc_buffer), task shoot_task
lv:1 mode:3

shoot_task stack: 213a30 [213c08-211c08]
0x00496BA8 @ 4771f8:213ba0
0xUNKNOWN  @ 496bfc:213b88
0x00B03948 @ b05194:213b18
0x0048CFA4 @ b03998:213b08
0x0048CF64 @ 48cfa8:213af0
0x0048C598 @ 48cf7c:213ae0
0x0048A3F0 @ 48c638:213a80
0x0044C8CC @ 48a54c:213a60
0x0044C478 @ 44c928:213a30

Magic Lantern version : Nightly.2018Dec12.EOSM2103
Mercurial changeset   : 88eba9bdb6c8+ (EOSM2.103_crop_rec_4k_wip)
Built on 2018-12-12 14:55:58 UTC by [email protected].
Free Memory  : 379K + 1867K


When shooting in 14bit lossless:
ML ASSERT:
0
at mlv_lite.c:2697 (compress_task), task compress_task
lv:1 mode:3

compress_task stack: 216b88 [216c18-215c18]
0x0044C8CC @ b0a698:216bb8
0x0044C478 @ 44c928:216b88

Magic Lantern version : Nightly.2018Dec12.EOSM2103
Mercurial changeset   : 88eba9bdb6c8+ (EOSM2.103_crop_rec_4k_wip)
Built on 2018-12-12 14:55:58 UTC by [email protected].
Free Memory  : 379K + 1930K

uizin

Quote from: JohanJ on December 12, 2018, 02:21:13 PM
Right. That comment was helpful! My first thought was that you are probaly not shooting stills in RAW format. Maybe you do. But the freezing has to do with RAW parameters for certain  ML overlays!

Yes! I was shooting in jpg. Switching to RAW I experience freezing too. I confirm that in jpg LV is more stable.

dfort

What might help track down these issues is using one of the logging branches:

EOSM2.103_dm-spy-experiments 18168:e8396696980f
EOSM2.103_io_trace         18167:d5a0e069c803
EOSM2.103_io_trace_full    18166:4a41ee21b185

Danne

Yes, gotta nail down the bug. Lossless is not working at all. Do we have the correct raw buffer for lossless?

Here is mv1080p by the way, 10bit:
MLV file:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/EOSM2_mv1080p.MLV





It´s like registers are moving around and either it´s coded to freeze somewhere or the freeze occurs as a result of faulty registers? Also noted that shamem registers cannot be read in raw.c like with eosm. Or maybe something else is going on. Maybe adtg registers not applied...

Trying to see if registers are added in raw.c:
NotifyBox(5000, "shamem_read(0xC0F07150) 0x%x", shamem_read(0xC0F07150));


In crop_rec.c:
static inline uint32_t reg_override_3x3_eosm2(uint32_t reg, uint32_t old_val)
{
    switch (reg)
    {
        case 0xC0F06804: return 0x4a601d4;
case 0xC0F37014: return 0xe;
        case 0xC0F0713c: return 0x4a7;
case 0xC0F07150: return 0x475;
    }

    return 0;

}


Adding the notifybox above yields a very short flash showing 0x455(not 475 which it should) of the register and then it´s back to its origin which is 0x2d8. Set registers isn´t hooked here.

This works obviously since we are getting stretched liveview:
     case CROP_PRESET_3x3_mv1080_EOSM2:
adtg_new[0] = (struct adtg_new) {6, 0x800C, 2};
break;



On a sidenote. When adtg_gui is enabled, engio registers and show known registers the 10bit liveview will be less prone to get stuck. This gives more stable recordings. Somehow adtg_gui is having some stabilizing effect here.

dfort

Quote from: Danne on December 13, 2018, 10:11:10 AM
Do we have the correct raw buffer for lossless?

I don't know but this might be related. There are only two resources groups and I figured the M2 belongs to the first group but maybe not? Maybe it doesn't fit into either group? I'm not sure how to verify this.

modules/silent/lossless.c
    if (is_camera("700D", "*") || is_camera("650D", "*") || is_camera("EOSM", "*") || is_camera("EOSM2", "*") || is_camera("100D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10000 | edmac_channel_to_index(edmac_read_chan),
            0x20005,
            0x20016,
            0x30002,
            0x50034,
            0x5002d,
            0x50010,
            0x90001,
            0x90000,
            0xa0000,
            0x160000,
            0x260000,
            0x260001,
            0x260002,
            0x260003,
        };

        TTL_ResLock = CreateResLockEntry(resources, COUNT(resources));
    }
    else if (is_camera("5D3", "*") || is_camera("6D", "*") || is_camera("70D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10000 | edmac_channel_to_index(edmac_read_chan),
            0x30001,    /* Read connection 1 (uncompressed input) */
            0x2002d,    /* Write connection 45 (compressed output) */
          //0x20016,    /* Write connection 22 (for WR2 - not used) */
            0x50034,
            0x5002d,
            0x50010,
            0x90001,
            0x230000,
            0x160000,
            0x260000,
            0x260001,
            0x260002,
            0x260003,
        };

Danne

Kind of nailed down where to look further for the liveview freezing on the eosm2. Seems to have to do with raw_slurp:
Maybe these registers are faulty?
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)
#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
#endif


Anyway. What I did was checking different parts in raw.c and then came in here:
#ifdef CONFIG_EDMAC_RAW_SLURP

void FAST raw_lv_vsync()
{
    /* where should we save the raw data? */
    void* buf = redirected_raw_buffer ? redirected_raw_buffer : raw_get_default_lv_buffer();
   
    if (buf && lv_raw_enabled)
    {
        /* this needs to be set for every single frame */
        EngDrvOut(RAW_TYPE_REGISTER, lv_raw_type);

        if (lv_raw_gain)
        {
            /* optional - adjust digital gain */
            /* fixme: hardcoded for 5D3 */
            EngDrvOut(RAW_TYPE_REGISTER, 0x12);
            EngDrvOut(SHAD_GAIN_REGISTER, lv_raw_gain);
        }

        /* pull the raw data into "buf" */
        int width, height;
        int ok = raw_lv_get_resolution(&width, &height);
        if (ok)
        {
            int pitch = width * raw_info.bits_per_pixel / 8;
            if (raw_lv_buffer_size >= pitch * height)
            {
                edmac_raw_slurp(CACHEABLE(buf), pitch, height);
            }
        }
    }
   
    /* overriding the buffer is only valid for one frame */
    redirected_raw_buffer = 0;
}


Commenting out following leaves liveview alone and stops from freezing:

/* uncommenting keeps EOSM2 liveview from freezing */
        /* pull the raw data into "buf" */
        int width, height;
       /* int ok = raw_lv_get_resolution(&width, &height); */
       /* if (ok) */
       /* { */
           int pitch = width * raw_info.bits_per_pixel / 8;
          /*  if (raw_lv_buffer_size >= pitch * height) */
          /*  { */
                /* edmac_raw_slurp(CACHEABLE(buf), pitch, height); */
           /* } */
       /* } */
        }



New code part looks like this:
#ifdef CONFIG_EDMAC_RAW_SLURP

void FAST raw_lv_vsync()
{
    /* where should we save the raw data? */
    void* buf = redirected_raw_buffer ? redirected_raw_buffer : raw_get_default_lv_buffer();
   
    if (buf && lv_raw_enabled)
    {
        /* this needs to be set for every single frame */
        EngDrvOut(RAW_TYPE_REGISTER, lv_raw_type);

        if (lv_raw_gain)
        {
            /* optional - adjust digital gain */
            /* fixme: hardcoded for 5D3 */
            EngDrvOut(RAW_TYPE_REGISTER, 0x12);
            EngDrvOut(SHAD_GAIN_REGISTER, lv_raw_gain);
        }

/* uncommenting keeps EOSM2 liveview from freezing */
        /* pull the raw data into "buf" */
        int width, height;
       /* int ok = raw_lv_get_resolution(&width, &height); */
       /* if (ok) */
       /* { */
           int pitch = width * raw_info.bits_per_pixel / 8;
          /*  if (raw_lv_buffer_size >= pitch * height) */
          /*  { */
                /* edmac_raw_slurp(CACHEABLE(buf), pitch, height); */
           /* } */
       /* } */
    }
   
    /* overriding the buffer is only valid for one frame */
    redirected_raw_buffer = 0;
}

/* integer gain used to fix the image darkening caused by lv_raw_gain */
/* this gain must not (!) change the raw data */
int _raw_lv_get_iso_post_gain()
{
    if (lv_raw_gain)
    {
        return 4096 / lv_raw_gain;
    }

    return 1;
}
}

It sometimes has to be updated by pressing canon menu back and forth but it works recording 10bit, 12bit, 14bit files. Lossless is still an issue and so are certain registers from crop_rec which aren´t applied.
What next? A lot of time and testing. Hopefully a1ex can see something/pointing us a bit further.

critix

The values seem ok.
#ifdef CONFIG_EOSM2
#define DEFAULT_RAW_BUFFER MEM(0x91CF0 + 0x78)


About these do not know what to say :

#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)
#endif

Canon 1300D, 500D, EOS M, EOS M2

Danne

Updated my uncommenting stuff above:
https://bitbucket.org/Dannephoto/magic-lantern/commits/1d378c7735b0d0ae5fc920e122ceffcdadf8b82e

This proves liveview can run without freezes but to the cost of corrupted footage also in 10-12bit.

So the redirect buffer I assume to make everything work is going here:
edmac-memcpy.c
void edmac_raw_slurp(void* dst, int w, int h)
{
    /* see wiki, register map, EDMAC what the flags mean. they are for setting up copy block size */
#if defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM2) || defined(CONFIG_EOSM) || defined(CONFIG_100D)
    uint32_t dmaFlags = EDMAC_2_BYTES_PER_TRANSFER;
#elif defined(CONFIG_6D)
    uint32_t dmaFlags = EDMAC_4_BYTES_PER_TRANSFER;
#else
    uint32_t dmaFlags = EDMAC_8_BYTES_PER_TRANSFER;
#endif


And to:
lv_rec.c
    {
        /* copy 2 byte per transfer */
        data.dmaFlags = 0x20000000;
        /* read from YUV connection */
        data.dmaSourceConn = 0x1B;
       
        /* no special treatment, save the exact size */
        save_data.frameSize = save_data.frameSizeReal;
        save_data.bottomDrop = 0;
    }


Since we are very close, or actually working, 10bit files there is the possibility of some interference somewhere else. Right now I have no idea where to go from this...


dfort

Quote from: critix on December 14, 2018, 01:35:35 PM
About these do not know what to say :

#define DEFAULT_RAW_BUFFER_SIZE (0x48C00000 - 0x48798100)


I'd say we found these values:

Quote from: a1ex on February 01, 2018, 12:51:29 AM
EOSM2: 48798100 - 48CC40C4

More about how we found it:

https://www.magiclantern.fm/forum/index.php?topic=5601.msg197778#msg197778

[EDIT] Yeah, it is confusing because the addresses are transposed and the first value is rounded down but if you check the other cameras you'll see that this should work for the EOSM2.

dfort

I won't have the EOSM2 in my hands until January but since there are users willing to be guinea pigs I'll start posting test builds on my Bitbucket downloads page. Note that this is highly experimental--you've been warned.

Today's build was taken from Danne's latest changes as noted on Reply #332.

dfort

What Danne is finding seems to point to a problem with the YUV addresses:

platform/EOSM2.103/consts.h
// Started out by using the one found value (0x4f3d7800)for all three as a workaround
// then adding 0x410000 to determine the other two.
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_LV_BUFFER_1 0x4F3D7800
#define YUV422_LV_BUFFER_2 0x4F7E7800
#define YUV422_LV_BUFFER_3 0x4FBF7800

// http://magiclantern.wikia.com/wiki/VRAM_ADDR_from_code
// stateobj_disp[1]
#define YUV422_LV_BUFFER_DISPLAY_ADDR (*(uint32_t*)(0x90494+0x12C))

#define REG_EDMAC_WRITE_LV_ADDR 0xC0F04208 // SDRAM address of LV buffer (aka VRAM)
#define REG_EDMAC_WRITE_HD_ADDR 0xC0F04108 // SDRAM address of HD buffer (aka YUV)

#define YUV422_HD_BUFFER_DMA_ADDR (shamem_read(REG_EDMAC_WRITE_HD_ADDR)) // first line from DMA is dummy

// http://magiclantern.wikia.com/wiki/ASM_Zedbra
// skipped for now, will come up with a way to autodetect these values
// http://www.magiclantern.fm/forum/index.php?topic=15895.msg186493#msg186493
#define YUV422_HD_BUFFER_1 0x44000080
#define YUV422_HD_BUFFER_2 0x46000080


We're using some placeholder values here but maybe they have already been found and I just don't know how to use this information?

Quote from: a1ex on July 06, 2017, 05:36:55 PM
EOS M2, QEMU:
...

  1160: 48852.480 [RSC] YUV                     0x4AEEA000 0x0222C000 35831808
  1161: 48852.480 [RSC] YUV_OUT                 0x42000000 0x0222C000 35831808


dfort

@uizin @pureaxis @Skozyashiy @Jenus @JohanJ @DeafEyeJedi @chrissul13 @vagaboundedu @platerytter @dacampora @bookemdano @orielsy @glassescreditsroll @jonkjon @godashram @bender @brocolimayo @Skylin3 @yazcui @Palpatine @neoplanta @GenMeiHikaru

And all other EOS M2 users "waiting" for Magic Lantern. After a long time of hearing, "Are we there yet? Are we there yet?" test builds have been posted and the developers are asking for your input.

We know it isn't quite ready for prime time but maybe the one or two features you're craving are working? How is focus peaking looking? Able to shoot a timelapse?

This is a community project and the more users can get involved the more this port will improve.

@a1ex - Any hints where to go from here? Seems like we're getting close but your direction works much better than invoking the infinite monkey theorem.

JohanJ

Focus peaking worked just fine with the build I was checking out ;) I am travelling this weekend. Back on Tuesday. Will continue testing then for sure!

Sent from my SM-G930F using Tapatalk

60D.111 / 100D.101 / M2.103

uizin

I started testing overlay features! Dfort, thank you for your last build.

The camera has a vintage lens installed, so both aperture and focus are fully manual.
General comment: to enable overlays I need to enter and exit Canon menu after leaving ML menus.

When taking pictures in RAW, I get "RAW error, falling back to YUV overlays" message, but pictures are saved.
If I switch to JPG shooting, this message does not appear.

Many overlays work in LiveView in video mode, while in C2 mode I only see these overlays in QuickReview, even if "Global draw" in settings shows "ON, all modes".
(Zebras, spotmeter, False Colors, Histogram, Waveform).

Magic zoom
Flickers with all the settings combinations I tested. This happens both in video mode and C2 mode.

Focus Peak
Looks ok!

Cropmarks
Looks ok!

Vectorscope
Looks ok!

I also tried the Advanced Bracket and Intervalometer features, everything seems working.
I'm having strange feedbacks with Bulb Timer, I need to test more before reporting.

I think I'm not understanding how the "ExpSim" and "Expo. Override" settings work. I'll dig the forum to get a background on this ;)
As I'm new to ML (this is the only camera I can test on), I still have to understand many features, so sorry if I'm not being very useful.

I'm here to continue the tests, if you need something in particular, just ask! :)



dfort

@uizin - Excellent reporting!

Quote from: uizin on December 16, 2018, 03:15:45 PM
When taking pictures in RAW, I get "RAW error, falling back to YUV overlays" message, but pictures are saved.
If I switch to JPG shooting, this message does not appear.

That's a good hint, I have also seen that on the EOSM2 and other cameras. Turn global draw off and shoot a CR2, does that still bring up the message? Have you tried shooting silent stills? That's where it was showing up when I reported it on the 5D3.113 crop_rec_4k branch.

Quote from: uizin on December 16, 2018, 03:15:45 PM
General comment: to enable overlays I need to enter and exit Canon menu after leaving ML menus.
...
Many overlays work in LiveView in video mode, while in C2 mode I only see these overlays in QuickReview, even if "Global draw" in settings shows "ON, all modes".

I keep going back to the YUV values pointed out in Reply #335 but am at a loss how to check these values.

Quote from: uizin on December 16, 2018, 03:15:45 PM
Magic zoom
Flickers with all the settings combinations I tested. This happens both in video mode and C2 mode.

That issue has come up on other cameras too. Last time it came up on the EOSM the fix was to tweak the fps timer values. Well, at least I believe that's what finally fixed it--I may be wrong but looking at the code we're still using values copied from the EOSM as a place holder so the correct values still need to be found:

src/fps-engio.c
#elif defined(CONFIG_EOSM2) // using EOSM values for now
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 716 : MV1080CROP ? 532 : 520)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN ( \
    RECORDING_H264 ? (MV1080CROP ? 1750 : MV720 ? 990 : 1970) \
                   : (ZOOM || MV1080CROP ? 1336 : 1970))


There's also another assumption in fps-engio.c that may or may not be true:

src/fps-engio.c
    #if defined(CONFIG_EOSM) || defined(CONFIG_EOSM2)
    if (!RECORDING_H264) return 0;  /* EOS-M is stubborn, http://www.magiclantern.fm/forum/index.php?topic=5200.msg104816#msg104816 */
    #endif


Hum, that link goes to a discussion on Auto ETTR and doesn't explain why that line of code is necessary. At least I can't see the connection.

uizin

Quote from: dfort on December 16, 2018, 05:11:55 PM
That's a good hint, I have also seen that on the EOSM2 and other cameras. Turn global draw off and shoot a CR2, does that still bring up the message? Have you tried shooting silent stills? That's where it was showing up when I reported it on the 5D3.113 crop_rec_4k branch.

Yes, if I turn off global draw there is no error message on the screen.

I tried the silent stills module (both in DNG and MLV): whit half shutter is pressed, LV shows a "Preparing..." message, but stops there and no file is saved on the card.

dfort

Quote from: uizin on December 16, 2018, 08:20:49 PM
I tried the silent stills module (both in DNG and MLV): whit half shutter is pressed, LV shows a "Preparing..." message, but stops there and no file is saved on the card.

Ok, simple silent stills used to work so we'll need to dig into that.

Danne

Ok, might have found the culprit to why liveview was freezing. It seems fps related. To test it do following:
Download following build:
https://bitbucket.org/Dannephoto/magic-lantern/downloads/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2018Dec19.EOSM2103.zip

1 - Enable  mlv_lite.mo
2 - Enable RAW video(screen will freeze)
3 - Set FPS override to 24
4 - Go to advanced inside FPS override and set following:
FPS timer A 574 (FT+46)

Hit canon menu button twice. Screen should not freeze now and you will be able to even record in lossless!

EDIT: These numbers needs more experimenting. Or updated in fps-engio of course.

dfort

Nice find. I mentioned in Reply #339 that the timer values were copied from the EOSM and need to be updated. Not sure about the process but we had similar issues on the EOSM a while back.

Quote from: dpjpandone on August 12, 2015, 07:26:05 AM
Next on my list:

1. fps override - let's fix this first so nightly builds will work again. Dunno if anyone has played with overcranking on other builds, but the EOSM shoots up to 45fps 1080p (crop mode, h264, low-light method) it's pretty awesome. So let's get that back working again.

2. magic zoom is useless in crop mode, we need to slow it down to stop the flicker, - this is lower on my list of priorities since I can navigate with my external monitor attached now...

This is the pull request that fixed the timer values on the EOSM so maybe backtrack through the discussion. Note that it was also a problem on the 1100D so checking out how that was resolved might help.

Danne

Cannot see any obvious from your posts dfort. Feel free to present a few numbers or any ideas what to do in fps-engio code.
Eosm2 is a pain in the ...

dfort

Maybe the 12 to 24 fps (FPS override Problem) topic will provide the information we need?

Sorry, don't have the camera in my hands right now to run these tests.

Also:

Quote from: a1ex on February 22, 2018, 06:27:21 AM
We have 3 ways to proceed:

1) hardcode the resolutions (and get bitten by this Canon bug in other parts of the code)
2) reallocate this buffer from somewhere else (where?)
3) patch ENGIO routines to use ADD instead of ORR, to make them able to work on unaligned buffers

I'd try the last route first.

Ok, so patching worked but that means the EOSM2 depends on the patch manager to function. Wasn't option 2, reallocate this buffer, found here?

Quote from: a1ex on February 01, 2018, 12:51:29 AM
EOSM2: 48798100 - 48CC40C4

Or is this unrelated?

dfort

Posted a new test build on my Bitbucket downloads page. Same disclaimer as always, this is highly experimental. This time I started with a clean raw_video_10bit_12bit branch and added just the pieces need to get the EOSM2 working.

uizin

@dfort do you need some specific tests on this build?

dfort

Never mind -- got a report that the new build I posted only does the LED blink thing so I took it down.

JohanJ

Just trying to get an overview about the different builds published by @critix, @danne and @dfort so far. I feel a bit unsure how I should continue testing on which build. Took some RAW pictures and tested basics with all OVERLAY functions again on all three of these versions and came up with the following observation (again from a still photo point of view. Not that much MLV skills here - yet):

A build magic-lantern-crop_rec_4k_mlv_snd_isogain_1x3.2018Dec07.EOSM2103 (critix)
B build crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_2018Dec19.EOSM2103 (danne).
C build magiclantern-Nightly.2018Dec14.EOSM2103 (dfort)

A & B both show the same freezing effect in LV photo mode 2 as soon as overlays are activated based on RAW depending parameters (Histogram and/or Spotmeter - as discribed in post #321)
C does not at all freeze in LV photomode even with activated histogram in RAW RGB, LOG while shooting RAW stills!  That's good!

So from that perspective I tend to continue testing w/ build C! But there is another minor observation, it is about lens information shown in the ML Overlay bar:

A build shows correctly focal lenght 22mm, also a varying focus distance as well as the DOF range when activated for LV.
B & C builds do not! Focal lenght is 0mm and focus distance is constantly 56m, DOF range is not shown at all, even when activated for LV. Something got lost in these builds!

Last but not least all builds have in common:
- DUAL-ISO module crashes for all builds directly after re-booting (some error messages are sent to the console. Will post them later)
- Leaving ML menue always requires doubble-press Canon menu button to get into photo mode with all overlays shown (see #308 comment 5)

Based on Build A I also did a bunch of tests for all funtions in Shoot / Focus / Display menue - mostly w/ positive results (as far as I recall). But I will wait for your hint what build should be the one to continue working with before spending time with texting (unnecessarily).

60D.111 / 100D.101 / M2.103