Author Topic: How to run Magic Lantern into QEMU?!... (Read 318003 times)

reddeercity · « **Reply #375 on:** August 07, 2018, 08:54:30 AM »

Quote from: a1ex on August 07, 2018, 08:34:54 AM

May I ask for a similar log while reviewing an image, with the io_trace_full branch? That should cover JPEG decoding and might be easier to understand.

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.

Sure , I'll do that right always .

reddeercity · « **Reply #376 on:** August 07, 2018, 09:38:59 AM »

Ok here it is , I take a Cr2 then reviewed it outside of Liveview dm-0001_io-trace-full_reveiwing_cr2_outside_liveview.log
Found this , not too sure if this is what your are talking about

Code: [Select]

14.986.246  ImgPlayDrv:ffa3bf78:1a:02: DEC Jpeg Format:1 W:5616 H:3744
14.986.261  ImgPlayDrv:ffa3be08:1a:02: DEC CalculateRabbitParameter 895
14.986.276  ImgPlayDrv:ffa3bf04:1a:02: DEC CalculateRabbitParameter
14.986.295  ImgPlayDrv:ffa3bf2c:1a:02: DEC XA:160 XB:16 XN:35 YA:8 YB:8 YN:467
..................................
14.986.340  ImgPlayDrv:ffa3ba30:1a:02: DEC SetResampleParametersForJuno 991
14.986.353  ImgPlayDrv:ffa3ba60:1a:02: DEC XXA:8 XXB:3 YXA:8 YXB:3
............................................
14.986.571  ImgPlayDrv:ffa3bbc8:1a:02: DEC LES_H  XA:60 XB:6 XN:35 YA:8 YB:8 YN:467
14.986.595  ImgPlayDrv:ffa3bbf0:1a:02: DEC PFIL1  XA:60 XB:6 XN:35 YA:8 YB:8 YN:467
14.986.616  ImgPlayDrv:ffa3bc18:1a:02: DEC LES_V  XA:60 XB:6 XN:35 YA:3 YB:3 YN:467
14.986.637  ImgPlayDrv:ffa3bc40:1a:02: DEC P_RES  XA:60 XB:6 XN:35 YA:3 YB:3 YN:467
..............................................
14.986.722  ImgPlayDrv:ffa3c03c:00:00: *** ConnectWriteEDmac(0x3, 0x3)
.............................
14.986.834  ImgPlayDrv:ffa3c150:1a:02: DEC ResumeDecodeJpeg 436
14.986.858  ImgPlayDrv:ffa3c194:00:00: *** StartEDmac(0x3, 0x0)
14.986.903  ImgPlayDrv:ffa3c194:00:00:     addr d00000, ptr d00000, size (please load edmac.mo)

I also by mistake I reviewed a H264 .Mov in io-trace-full and logged , lot of resizing jpeg stuff , not sure if it will be of any help.
dm-0000_io-trace-full_reviewing_mov_h264.log

reddeercity · « **Reply #377 on:** August 08, 2018, 07:11:33 AM »

Quote from: a1ex on August 07, 2018, 08:34:54 AM

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.

That's great ! I'm going to try to see what happen on cam.
Having problems compiling lossless silent.c , what branch should I be using ? "compressed_raw" , "crop_rec_4k" or ? I was using dfort's "crop_rec_4k_Digic4" but now that's giving me errors .
Was working a few mouths ago , I just clone it , so its fresh . I'll try tomorrow again.

@dfort , can you compile your "crop_rec_4k_Digic4" ?
these are changes I made to my lossless.c

Code: [Select]

      else if (is_camera("7D", "*") || is_camera("5D2", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10002 | edmac_channel_to_index(edmac_read_chan),
            0x30000,    /* read  connection  0x0 */
            0x20005,    /* write connection  0x5 */
            0x20003,    /* write connection  0x3 */
            0x50003,
            0x5000d,
            0x5000f,
            0x5001a,
            0x80000,
            0x90000,
            0xa0000,
            0x160000,
            0x130003,
            0x130004,
            0x130005,
        };
 /*       
 1)    10002 (read channel 0xa)
 2)    10003 (read channel 0xb)
 3)        3 (write channel 0x3)
 4)        4 (write channel 0x4)
 5)    30000 (read connection 0x0)
 6)    30021 (read connection 0x21)
 7)    20005 (write connection 0x5)
 8)    20003 (write connection 0x3)
 9)    50003 (?)
10)    5000d (?)
11)    5000f (?)
12)    5001a (?)
13)    80000 (?)
14)    d0000 (?)
15)    a0000 (?)
16)    90000 (?)
17)    e0000 (?)
18)   200000 (?)
*/

Do I really need the piece of code that's between the 2 asterisk ?
" /*
1) 10002 (read channel 0xa)
etc. ... "

dfort · « **Reply #378 on:** August 08, 2018, 07:40:31 AM »

Quote from: reddeercity on August 08, 2018, 07:11:33 AM

@dfort , can you compile your "crop_rec_4k_Digic4" ?

Only for the 7D and was trying just the silent module to see if I could get lossless compression working. Hit a wall a while back and put it aside.

Quote from: reddeercity on August 08, 2018, 07:11:33 AM

Do I really need the piece of code that's between the 2 asterisk ?
" /*
1) 10002 (read channel 0xa)
etc. ... "

No, that's copied from my log file and commented out. I was using it as reference.

reddeercity · « **Reply #379 on:** August 09, 2018, 07:42:16 AM »

Ok , fixed my compiling problem had to commented out in
lv-img-engio.c

Code: [Select]

//total_movie_gain *= _raw_lv_get_iso_post_gain();//now i can add my code mod's to lossless.c

cedricb · « **Reply #380 on:** September 13, 2018, 06:11:01 PM »

Hi,

How do you run the EOS M6 into qemu ? There is already a structure for the M5 therefore I've tried the CHDK dump from https://drive.google.com/open?id=0B08pqRtyrObjWVdWVGVwakVmcjQ#list but there is only a PRIMARY.bin file; how do split it to have the expected ROM0.bin and ROM1.bin ?

Before going any further, can I use qemu to use the default Canon's basic scripting, instead of constantly moving the SD card in/out of the camera/laptop ? I'm not going to emulate ML or CHDK.

So far I've installed qemu from the ML qemu branch (followed the README from the contrib folder) which is version 2.5.0. Is this version not too old? ...there is a qemu-2.9.0 branch but it's not maintained since April last year.

Cheers,

a1ex · « **Reply #381 on:** September 13, 2018, 06:42:27 PM »

I didn't look into M6 yet, as PowerShots are not exactly my primary focus. I won't be able to look into it during the next few days, so please find the general notes for emulating a new camera model.

PRIMARY.BIN is one of the two ROMs; you will need to know its start address and specify it in model_list.c (or, if that address already matches some existing model, maybe M5, start from there).

The 2.9.0 branch had some issues that were not obvious how to fix, 2.5.0 just worked, so I went forward with that. I know it's behind, but...

Just FYI, srsa_4c was able to run the A2300 GUI in QEMU, based on some draft A2200 patches from me.

cedricb · « **Reply #382 on:** September 13, 2018, 10:23:37 PM »

@alex: Thanks for the quick reply. I’ll have a go and let you know if I struggle

dfort · « **Reply #383 on:** September 19, 2018, 05:32:48 PM »

Came up with a recurring problem -- how to get into the ML menus in QEMU. Depending on the camera there is a different keystroke combination. Right now I'm looking at the EOSM, the Canon menus come up fine and I can get into LiveView but for the life of me I can't find my notes on how to get into the ML menu.

May I suggest adding a section in the documentation on how to get into the ML menus:

https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst#rst-header-navigating-menus

Another suggestion for the forum moderators -- how about making "How to run Magic Lantern into QEMU?!..." a sticky topic?

a1ex · « **Reply #384 on:** September 19, 2018, 06:23:54 PM »

It's always the same key as with regular ML. For example, on 1100D, user has to press the Av button, which is shared with Delete. In photo mode, this button behaves like the regular Av button on other models (same button code coming from the MPU). So, in the emulator, you press the Av key, i.e. A.

On EOS M, that's a long press of the Delete button (i.e. down arrow), but as the LiveView emulation is not perfect, you'll need to press L a few times to work around some GUI mode switching issue. After a bit of trial and error, the menu should appear. Just tried: M M L Down(long) showed up the long-press indicator, then ML menu showed up. It also seems to work with the Delete key, as ML interprets that button code as well in a generic way (for all models), but I'm pretty sure the hardware doesn't send that button code in LiveView, so it's not very accurate.

EOS M also opens ML menu with a double tap on the screen or something like that. I've got draft patches for touchscreen emulation, just need to clean them up and commit.

dfort · « **Reply #385 on:** September 20, 2018, 03:29:21 AM »

Thanks -- M M L Down(long) worked here though I didn't see the long-press indicator. The camera boots into LiveView and only requires Down(long) so maybe those extra steps required in QEMU could be added to the documentation and/or the model specific F1 help menu?

BTW--On the EOSM and other cameras (i.e. 100D) the SET and Q button are combined but in QEMU they behave differently.

EOSM F1 menu

Code: [Select]

[MPU] Available keys:
- Arrow keys   : Navigation 
- [ and ]      : Main dial (top scrollwheel) 
- SPACE        : SET 
- DELETE       : guess (press only)
- M            : MENU (press only)
- P            : PLAY (press only)
- I            : INFO/DISP (press only)
- Q            : guess 
- L            : LiveView (press only)
- Shift        : Half-shutter 
- 0/9          : Mode dial (press only)
- V            : Movie mode (press only)
- B            : Open battery door 
- C            : Open card door 
- F10          : Power down switch 
- F1           : show this help

Maybe add that the down key is also the Trash button?

a1ex · « **Reply #386 on:** September 20, 2018, 07:26:18 AM »

Quote from: dfort on September 20, 2018, 03:29:21 AM

Maybe add that the down key is also the Trash button?

The MPU code only knows it's sending the Down key; it doesn't care how the main firmware interprets it later.

In PLAY mode or Canon menu, the MPU might send the Delete code (not 100% sure; you may check that with a MPU log - look for "06 05 06"). Other than deleting images, is the Delete button used anywhere else in Canon menu, where I could test it?

Same for the SET/Q button (which is handled identically in 100D, EOSM and EOSM2): in some GUI modes it behaves like SET, in others it behaves like Q. QEMU doesn't know that - for now, you need to press the appropriate button, i.e. to know what button code the MPU is going to send. The MPU code is not that smart, it just does a simple mapping between PC keyboard codes and MPU button codes.

This reminds me I also need to add a definition for the Delete button for 1100D & co (which is shared with Av). In photo mode, that button behaves like Av. In Canon menu, e.g. in the Format dialog, that button apparently behaves like Delete (don't see how otherwise you could toggle the low level format option).

a1ex · « **Reply #387 on:** December 31, 2018, 01:30:53 AM »

Cleaned up and committed a bunch of minor changes I had locally. Most important:
- CPU info registers are now matching the logs from real hardware fairly well (not perfect; you are welcome to double-check)
- all GDB helpers are documented (they appear in GDB's help)
- fixed a couple of button codes and cleaned them up a bit

Still waiting for info on how the Delete button behaves in Canon menu on EOS M/M2 (previous post). Capturing a MPU log with the linked build should be enough, as long as you press the Delete key somewhere in Canon menu and somewhere outside it. No need to compile or do complicated black magic; anyone can do it.

dfort · « **Reply #388 on:** January 06, 2019, 06:29:23 AM »

Quote from: a1ex on December 31, 2018, 01:30:53 AM

Still waiting for info on how the Delete button behaves in Canon menu on EOS M/M2 (previous post).

Here's a log for the EOSM. The EOSM2 will require some more work. Looks like the builds you posted have some changes that were not committed.

https://www.dropbox.com/sh/fcgwoz3t9rmhx3h/AACPzAhF3Vt_7TNsiuIOXjn2a?dl=0

Held down the Trash (a.k.a. down key) in LiveView, which brings up the ML menu then did the same with the Canon menu.

I'm once again having problems getting the EOSM/EOSM2 running in the latest QEMU. Went over previous discussions and I believe I'm doing it right. Other cameras I tried (700D/1300D) seem to run fine.

On the Mac this will crash QEMU:

Code: [Select]

./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
Same with "boot=1"

a1ex · « **Reply #389 on:** January 06, 2019, 01:47:18 PM »

Something went wrong after 2.267353 seconds; memory corruption? Reproducible?

Can you try with build #21 as well? That's a little less verbose, so it would allow for longer experiment times, but it will only log the MPU messages and nothing else.

Reproduced the crash on the Mac VM. Workaround: comment out the call to find_rom_string in debug-logging.gdb, until I'll figure it out. For some reason, I'm unable to run QEMU under Valgrind on the Mac VM (possibly this bug); if you are able to do so, I'd like to see a log. From skimming that bug report, running QEMU under Valgrind might be possible on Mac OS older than Sierra (my Mac VM is High Sierra). Edit: after building valgrind from source and applying these patches, it still doesn't work.

Compiling QEMU with -fsanitize=address helps and points to a stack buffer overflow error during GDB communication. Fixed by this commit.

BTW, for regular use (i.e. if you don't need to log all of that stuff from debugmsg.gdb), it's best to use patches.gdb, as it's much faster.

dfort · « **Reply #390 on:** January 06, 2019, 08:31:19 PM »

Quote from: a1ex on January 06, 2019, 01:47:18 PM

Something went wrong after 2.267353 seconds; memory corruption? Reproducible?

Really? I didn't notice anything unusual with the camera but yeah--there is a problem. Tried starting in different modes and the only clean log is when starting in playback mode and leaving it in playback mode until it finishes logging.

Ran the test with Build #21 and this one had a clean finish. Saved log in the same Dropbox folder. If that works for you I'll try to do the same with the EOSM2.

Quote from: a1ex on January 06, 2019, 01:47:18 PM

Workaround: comment out the call to find_rom_string in debug-logging.gdb, until I'll figure it out.

Thanks, back up and running with the EOSM/EOSM2.

a1ex · « **Reply #391 on:** January 06, 2019, 08:54:30 PM »

Quote from: dfort on January 06, 2019, 08:31:19 PM

Ran the test with Build #21 and this one had a clean finish. Saved log in the same Dropbox folder. If that works for you I'll try to do the same with the EOSM2.

This works, with only one exception - I'm unable to identify the Delete press while in Canon menu:

Code: [Select]

 0.725.114  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 11 01 00)                               ; GMT_GUICMD_LOCK_ON
 0.725.332  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 12 00 00)                               ; GMT_GUICMD_CLOSE_SLOT_COVER
 0.730.254     PropMgr:0000393c:00:00: *** mpu_send(06 05 04 00 00 00)                               ; NotifyGUIEvent
 5.439.711  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
 6.001.290     PropMgr:0000393c:00:00: *** mpu_send(06 05 04 00 06 00)                               ; NotifyGUIEvent
 6.035.215  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 04 00 06 01)                               ; NotifyGUIEvent
 6.046.854  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1c 00 00)                               ; Unknown GUI event
 6.988.237  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN
 7.760.202  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 00 01 00)                               ; BGMT_MENU
 8.580.178  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 00 01 00)                               ; BGMT_MENU
 9.175.421  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 04 00 00 01)                               ; NotifyGUIEvent
 9.666.056  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 00 01 00)                               ; BGMT_MENU
 9.669.594     PropMgr:0000393c:00:00: *** mpu_send(06 05 04 00 01 00)                               ; NotifyGUIEvent
 9.679.593  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 04 00 01 01)                               ; NotifyGUIEvent
 9.681.301  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1c 00 00)                               ; Unknown GUI event
11.986.296  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
15.268.982  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN

Maybe the code I'm looking for only shows up when you actually try to delete some picture? Can you try to log that action as well?

That unknown GUI event has the same code as "Unpress AV" on other models. Likely some internal event used during GUI mode switching.

Quote from: dfort on January 06, 2019, 08:31:19 PM

Tried starting in different modes and the only clean log is when starting in playback mode and leaving it in playback mode until it finishes logging.

Well, that's an issue I'd like to narrow down, then.

Quote from: dfort on January 06, 2019, 08:31:19 PM

Thanks, back up and running with the EOSM/EOSM2.

It should now work on Mac without any workarounds.

Been running various tests with sanitizers; they found quite a few bugs I had no idea they were present (which were not caught by valgrind in my previous tests). Huge progress, if you ask me (or, rather, it looks like I've been living under a rock)

dfort · « **Reply #392 on:** January 07, 2019, 02:23:57 AM »

Quote from: a1ex on January 06, 2019, 08:54:30 PM

Maybe the code I'm looking for only shows up when you actually try to delete some picture? Can you try to log that action as well?

Start in play mode, delete picture -- log saved in same Dropbox folder.

Quote from: a1ex on January 06, 2019, 08:54:30 PM

Huge progress, if you ask me (or, rather, it looks like I've been living under a rock)

LOL -- I thought we made some great progress on the EOSM2 but now can't get it working in QEMU though the original EOSM works fine now.

[EDIT] Found the problem.

Compiling like this:

Code: [Select]

make -C ../magic-lantern EOSM2_install_qemu
This works:

Code: [Select]

./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb
./run_canon_fw.sh EOSM2,firmware="boot=1" -d debugmsg -s -S & arm-none-eabi-gdb -x EOSM2/debugmsg.gdb

This works only on the qemu default minimal autoexec.bin

Code: [Select]

./run_canon_fw.sh EOSM2,firmware="boot=1" -d debugmsg
This doesn't work:

Code: [Select]

./run_canon_fw.sh EOSM2,firmware="boot=0" -d debugmsg
This doesn't work at all:

Code: [Select]

./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x EOSM2/patches.gdb -ex quit
./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & arm-none-eabi-gdb -x EOSM2/patches.gdb -ex quit

I should qualify that. By "work" I mean able to bring up the GUI. The EOSM2 starts up on a grey screen, pressing the "M" key brings up the Canon menu. Pressing the "M" key again gets out of the Canon menu and from there the down arrow key should bring up the ML menu but I can't seem to get it on the M2. It is finicky but possible on the M. Note that I had more luck with "fn delete" on the Mac keyboard.

a1ex · « **Reply #393 on:** January 07, 2019, 09:10:48 AM »

Quote from: dfort on January 07, 2019, 02:23:57 AM

Start in play mode, delete picture -- log saved in same Dropbox folder.

Code: [Select]

 0.722.727  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 11 01 00)                               ; GMT_GUICMD_LOCK_ON
 0.722.942  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 12 00 00)                               ; GMT_GUICMD_CLOSE_SLOT_COVER
 0.727.044     PropMgr:0000393c:00:00: *** mpu_send(06 05 04 00 01 00)                               ; NotifyGUIEvent
 0.757.264  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 04 00 01 01)                               ; NotifyGUIEvent
 0.759.025  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1c 00 00)                               ; Unknown GUI event
 3.278.136  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
 3.834.397  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN
 4.590.576  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1a 01 00)                               ; BGMT_PRESS_RIGHT
 4.732.795  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1a 00 00)                               ; BGMT_UNPRESS_RIGHT
 7.762.292  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 0c 01 00)                               ; BGMT_PRESS_SET
 7.974.462  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 0c 00 00)                               ; BGMT_UNPRESS_SET
 8.441.945  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
11.193.172  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN

Maybe the main firmware really re-interprets the Down key in PLAY mode (i.e. it performs the Delete action instead). Any luck with the verbose logger on the same action?

Quote from: dfort on January 07, 2019, 02:23:57 AM

This doesn't work at all:
Code: [Select]
./run_canon_fw.sh EOSM2,firmware="boot=0" -s -S & arm-none-eabi-gdb -x EOSM2/patches.gdb -ex quit ./run_canon_fw.sh EOSM2,firmware="boot=1" -s -S & arm-none-eabi-gdb -x EOSM2/patches.gdb -ex quit
I should qualify that. By "work" I mean able to bring up the GUI. The EOSM2 starts up on a grey screen, pressing the "M" key brings up the Canon menu. Pressing the "M" key again gets out of the Canon menu and from there the down arrow key should bring up the ML menu but I can't seem to get it on the M2. It is finicky but possible on the M. Note that I had more luck with "fn delete" on the Mac keyboard.

Reproduced the issue on EOS M2... after swapping SFDATA.BIN with an older one from 100D.

The good one (likely from you) starts with 55 03 00 80 in a hex editor (0x80000355 is the model ID for EOS M2) and has MD5 f8c4d7fa1d7ceb4cade8b98b3573c375 (likely not essential, but could be useful to narrow down). It also works with -icount 5 (which is deterministic, i.e. it will get exactly the same execution trace on all systems, as long as you use the same ROMs).

Otherwise, both commands are working fine in QEMU (including on the Mac VM). If ML menu doesn't show up, press L a few times (as LiveView emulation is not the best). Before pressing L, Canon overlays are gray, but afterwards they should turn black and that's when ML menu works.

I wonder if emulating "just" the video timer interrupts could be enough for fixing this quirk.

dfort · « **Reply #394 on:** January 07, 2019, 11:35:46 PM »

Quote from: a1ex on January 07, 2019, 09:10:48 AM

Any luck with the verbose logger on the same action?

Nope -- log keeps borking at the same place.

Quote from: a1ex on January 07, 2019, 09:10:48 AM

Reproduced the issue on EOS M2... after swapping SFDATA.BIN with an older one from 100D.

The good one (likely from you) starts with 55 03 00 80 in a hex editor (0x80000355 is the model ID for EOS M2) and has MD5 f8c4d7fa1d7ceb4cade8b98b3573c375

Strange. Found that good SFDATA.BIN and tried it with the dumps I sent you, in fact tried it with all the dumps I have and can't get out of the grey screen. The default qemu autoexec.bin works fine with any combination.

Quote from: a1ex on January 07, 2019, 09:10:48 AM

I wonder if emulating "just" the video timer interrupts could be enough for fixing this quirk.

Know what to do with that information I do not.

Back to mpu logging--

For the EOSM2 I created a patch with the changes made on the "Project startup-log-mpu" EOSM by copying the information from the autoexec.bin file. That's a great feature by the way. The EOSM2 created a full log without borking. Same action as before--down key (trash) on LiveView (brings up ML menu) then down key in Canon menu.

https://www.dropbox.com/sh/dgyn5xzfgfn9xsx/AAAIZ9ButGKdWhoWYbdbmc1Ra?dl=0

Ant123 · « **Reply #395 on:** January 19, 2019, 10:12:45 PM »

Quote from: Ant123 on December 20, 2017, 03:52:38 PM

I think it's possible to emulate simple drawing of text strings in case main CPU will send certain messages to MZRM core...
But on EOS M3 the camera controller still does not allow to start it normally and goes to shutdown.

Got Canon menu navigation working on M3:

Code: [Select]

CtrlSrv -> SflwWrpDrawStringWithinRect [0000,0222]: No Image. 
CtrlSrv -> SflwWrpDrawStringWithinRect [-6962,0434]: Memory card locked 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: SETUP4 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Certification Logo Display 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: Copyright Info 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0271]: Clear all camera settings 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Wi-Fi Settings 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: PLAY1 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Transition Effect 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0115]: Fade 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Index Effect 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0167]: On 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: Scroll Display 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0219]: On 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0271]: Auto Rotate 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0271]: On 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0323]: Resume 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0323]: Last seen 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: PLAY2 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Magnify (approx.) 
CtrlSrv -> SflwWrpDrawStringWithinRect [0410,0167]: 2x 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Playback information display 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: SETUP1 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: Format 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0271]: Video system 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0271]: PAL 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0323]: Electronic Level 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Create Folder 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0115]: Monthly 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: File Numbering 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0167]: Continuous 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: SETUP2 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Power Saving 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0271]: Time Zone 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0323]: Date/Time 
CtrlSrv -> SflwWrpDrawStringWithinRect [0410,0323]: '19.01.13 20:00 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: LCD Brightness 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Eco Mode 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0115]: Off 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0375]: Language 
CtrlSrv -> SflwWrpDrawStringWithinRect [0410,0375]: English 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: SETUP3 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Hints & Tips 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0167]: Off 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Beep 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0115]: On 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: Touch Operation 
CtrlSrv -> SflwWrpDrawStringWithinRect [0412,0219]: Standard 
CtrlSrv -> SflwWrpDrawStringWithinRect [0544,0060]: SETUP4 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0167]: Certification Logo Display 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0219]: Copyright Info 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0271]: Clear all camera settings 
CtrlSrv -> SflwWrpDrawStringWithinRect [0036,0115]: Wi-Fi Settings 
CtrlSrv -> SflwWrpDrawStringWithinRect [0000,0222]: No Image.

Any idea how to render these strings on QEMU VGA screen?

a1ex · « **Reply #396 on:** January 20, 2019, 11:23:53 AM »

Awesome, looking forward to trying this one!

Some time ago I've extracted the VGA font routines (fixed-width, fixed-size) from QEMU console code. It won't look pretty, but at least you'll see something.

Code: [Select]

/* basic char display */
/* adapted from console.c */

#define FONT_HEIGHT 16
#define FONT_WIDTH 8

#include "ui/vgafont.h"

#define QEMU_RGB(r, g, b)                                               \
    { .red = r << 8, .green = g << 8, .blue = b << 8, .alpha = 0xffff }

static void putcharxy(DisplaySurface *surface, int x, int y, int ch)
{
    static pixman_image_t *glyphs[256];
    pixman_color_t fgcol = QEMU_RGB(0xaa, 0xaa, 0xaa);
    pixman_color_t bgcol = QEMU_RGB(0x00, 0x00, 0x00);

    if (!glyphs[ch]) {
        glyphs[ch] = qemu_pixman_glyph_from_vgafont(FONT_HEIGHT, vgafont16, ch);
    }
    qemu_pixman_glyph_render(glyphs[ch], surface->image,
                             &fgcol, &bgcol, x, y, FONT_WIDTH, FONT_HEIGHT);
}

static void putsxy(DisplaySurface *surface, int x, int y, const char * str)
{
    for (const char * c = str; *c; c++)
    {
        putcharxy(surface, x, y, *c);
        x++;
    }
}

static void printfxy(DisplaySurface *surface, int x, int y, const char * fmt, ...)
{
    char buf[256];
    va_list ap;
    va_start( ap, fmt );
    vsnprintf( buf, sizeof(buf)-1, fmt, ap );
    va_end( ap );
    putsxy(surface, x, y, buf);
}

These routines are meant to be used in the display callback procedure, somewhere before dpy_gfx_update. In any case, it's not in sync with the program execution. If you receive these strings from MMIO hooks, or from breakpoints into certain drawing functions, you will need to store them somewhere in a data structure, until the next display event comes up.

Otherwise, the display surface can be used directly, see e.g. our LED drawing code:

Code: [Select]

    uint32_t * dest = surface_data(surface);

but, of course, you will need some library to draw the fonts (some suggestions, or maybe even CHDK/ML RBF engine).

Ant123 · « **Reply #397 on:** January 20, 2019, 02:17:13 PM »

Quote from: a1ex on January 20, 2019, 11:23:53 AM

If you receive these strings from MMIO hooks, or from breakpoints into certain drawing functions, you will need to store them somewhere in a data structure, until the next display event comes up.

I recieve these strings from eos_handle_digic6: mzrm_send function writes 1 into register 0xD20F0840 to inform Zico core about new message.

I was trying this code, but it doesn't work:

Code: [Select]

			
DisplaySurface *surface = qemu_console_surface(s->disp.con);			
printfxy(surface, (pos_x >> 16), (pos_y >> 16), "%s", MZRM_str);

Do I need to update the display somehow?

Even calling printfxy from eos_update_display doesn't work.

Ant123 · « **Reply #398 on:** January 28, 2019, 06:39:38 PM »

Some progress with Zico core emulation:

But direct font taken from ML doesn't look beautiful...
But I found these fonts in M3 rom:

Code: [Select]

0xfd8a9640, 0x00021704
0xfd8eb030, 0x00024060
0xfd90f090, 0x00012e60
0xfd921ef0, 0x00056d70
0xfd978c60, 0x0009fe10
0xfda18a70, 0x0001f18c
0xfda37bfc, 0x00024cf4
0xfda5c8f0, 0x0000b9a0
0xfda682a0, 0x00000cc4
0xfda68f64, 0x00000f40
0xfda6aa8c, 0x00000cb8
0xfda6b744, 0x00000854
0xfda6bf98, 0x00000b88
0xfda6dc10, 0x00000cb0
0xfda6e8c0, 0x00000ad4
0xfda6f394, 0x0000113c

16 of them can be opened with FontForge

Also there need to decode images from ROM used to draw icons and some texts in Viewfinder mode.
These are vector graphic objects. They can be found by signature "99 99 0C 00" in DSLR's ROMs too. The next 32bit word is a size of drawing object.
Probably there need to use OpenVG to render it.

Ant123 · « **Reply #399 on:** February 05, 2019, 04:09:16 PM »

Quote from: Ant123 on January 28, 2019, 06:39:38 PM

But direct font taken from ML doesn't look beautiful...

RBF font looks better:

News:

Author Topic: How to run Magic Lantern into QEMU?!... (Read 318003 times)

dfort

dfort

dfort

dfort

dfort

dfort

dfort