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

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #100 on: July 21, 2016, 01:33:09 PM »
Testing code without cam:
- Cam will not brick
- You have not to wear out gear (card, slot, cardreader, etc.) each time you have to replace binaries.

- debugging your code like a PC program, by running it step by step (not just with printf's)
- you can debug Canon code as well, in order to understand what it does
- possible to implement automated tests for the nightly builds (see also http://direct.magiclantern.fm/forum/index.php?topic=12396.0 )
- test Lua scripts in the emulator
- lower the entry barrier for new developers
- assist me in unbricking cameras (the main driving force behind this, sadly)

Greg

  • Hero Member
  • *****
  • Posts: 550
Re: How to run Magic Lantern into QEMU?!...
« Reply #101 on: July 21, 2016, 03:22:31 PM »
500D, LV
Code: [Select]
mpu_send(06 04 09 00 00)
mpu_recv(3c 3a 09 00 3c 3c e0 00 3f 80 00 00 38 12 c0 00 b9 cb c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 11 10 50 49 02 59 88 88 00 32 00 00 00 00 00 01 00 00 00)
PROP_LV_LENS


0x32 - focal length
0x10 - aperture

Now we can read lens_info in Photo mode.
Just call mpu_send(06 04 09 00 00). CPU receives data and automatically overwrite property lens_info.


a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #102 on: July 22, 2016, 11:27:57 AM »
Nice trick.

Let's continue the discussion regarding MPU communication here: http://www.magiclantern.fm/forum/index.php?topic=17596

nkls

  • New to the forum
  • *
  • Posts: 23
Re: How to run Magic Lantern into QEMU?!...
« Reply #103 on: July 29, 2016, 10:33:43 AM »
I've managed to get the dm-spy-extra branch to run for 100D (fw 100A) with full logging, sources are at:
https://bitbucket.org/niklastisk/magic-lantern/branch/100D-mpu-spy

Still no success at emulating the 100D though, just including the correct mpu messages did not work out.


On a side note, me and a1ex discovered some interesting things about the memory management of the 100D's 256M RAM when using the CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP configuration:
Code: [Select]
      p1=&memtest; p3=UNCACHEABLE(p1);
      init:00b1c75c:00:00: POINTER   p1         p2         p3
      init:00b1c77c:00:00: ADDRESS   0x00B7F204 0x10B7F204 0x40B7F204
      init:00b1c7a8:00:00: (init)    0x00000123 0x00000123 0x00000123
      init:00b1c7e0:00:00: memtest++ 0x00000124 0x00000123 0x00000123
      init:00b1c818:00:00: (*p1)++   0x00000125 0x00000123 0x00000123
      init:00b1c850:00:00: (*p2)++   0x00000125 0x00000123 0x00000123
      init:00b1c888:00:00: (*p3)++   0x00000125 0x00000124 0x00000124
(source code: http://pastebin.com/vHWcH9ij)

My interpretation is that (0x10000000 | ptr) creates a pointer that wraps around the 256M ram, but bypasses the cache and is read-only such that write attempts fail silently. This obviously won't work for 512M cameras. :)
100D.100A

nkls

  • New to the forum
  • *
  • Posts: 23
Re: How to run Magic Lantern into QEMU?!...
« Reply #104 on: August 01, 2016, 11:04:47 AM »
I've fixed the serial flash reads, turns out the QUAD mode discards the last 16 bytes in each 0x800-byte block. Now the property tables are read correctly.

https://bitbucket.org/niklastisk/qemu/branch/eos-develop-new

The spell sets for 100D are included as well, and I even got the GUI showing (once)! There still seems to be problems with the touch panel, but I don't know if they are critical or not.
100D.100A

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #105 on: September 10, 2016, 11:54:09 PM »
Just committed some updates, mostly written while I had limited network connectivity (which is why they weren't uploaded earlier):

- directory layout changed, you need to move the ROM files (see install script)
- 5D3 boots the GUI on 1.1.3 :)
- cache hack emulation (very incomplete, only tested on 60D dm-spy, which runs successfully and saves its log on the SD card image)
- SD emulation fix (card info is now read correctly and gets mounted on digic 5 models)
- experimental EDMAC emulation (didn't really play with it, but can be used to research the picture taking process, bit depth reduction tricks, eeko and lots of other low level stuff)
- initial support for 750D and 760D (nothing interesting, they crash in the same way as 80D)
- integrated nkls' changes about 100D, but not yet tested (they will certainly be helpful for 70D and most other recent cameras)

I'm also starting to get confident about emulating the TX19A in QEMU, thanks to leegong's findings, but I have nothing interesting to show yet.


a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #106 on: September 26, 2016, 01:07:16 AM »
Small updates:

- card LED emulation
- better SD emulation on DIGIC 6 (tested on EOS M3 - it loads DISKBOOT.BIN from the SD card image)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #107 on: September 26, 2016, 11:52:52 PM »
We now have a test suite for QEMU :)

Code: [Select]
./run_tests.sh
Compiling...

Testing bootloaders...
  5D2: K218 READY
  5D3: K285 READY
   6D: K302 READY
   7D: FAILED!
 7D2M: K289M READY
 7D2S: K289S READY
  50D: FAILED!
  60D: K287 READY
  70D: K325 READY
  80D: K350 READY
 500D: K252 READY
 550D: K270 READY
 600D: K286 READY
 650D: K301 READY
 700D: K326 READY
 750D: K393 READY
 760D: K347 READY
 100D: K346 READY
1100D: K288 READY
1200D: K327 READY
 EOSM: K331 READY

Testing display from bootloader...
Setting up a temporary SD card image...
‘../magic-lantern/contrib/qemu/sd.img.xz’ -> ‘./sd.img.xz’
  5D2: OK
  5D3: OK
   6D: OK
   7D: please check
 7D2M: OK
 7D2S: OK
  50D: please check
  60D: OK
  70D: OK
  80D: OK
 500D: OK
 550D: OK
 600D: OK
 650D: OK
 700D: OK
 750D: OK
 760D: OK
 100D: OK
1100D: OK
1200D: OK
 EOSM: OK
Restoring your SD card image...

Testing Canon GUI...
  60D: OK
  5D3: OK
 600D: OK
1200D: OK
1100D: OK

Can you recommend some testing framework that could work in this case? I feel like I'm reinventing the wheel with all those scripts, but at least it works. For now.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #108 on: September 30, 2016, 12:03:45 AM »
Added support for a few more cameras (they all load autexec and run the display test):
- 5D, 40D, 400D, 450D, 1000D (oldies)
- 50D (minor fix)
- 5D4

This one just boots DryOS and starts a few tasks:
- A1100 (PowerShot)

Current test results:
Code: [Select]
Testing bootloaders...
   5D: ROM READY
  5D2: K218 READY
  5D3: K285 READY
  5D4: K349 READY
   6D: K302 READY
   7D: FAILED!
 7D2M: K289M READY
 7D2S: K289S READY
  40D: K190 READY : Ver 4.0.1
  50D: K261 READY
  60D: K287 READY
  70D: K325 READY
  80D: K350 READY
 400D: InitializeIntercom
 450D: K176 READY : Ver 4.0.3
 500D: K252 READY
 550D: K270 READY
 600D: K286 READY
 650D: K301 READY
 700D: K326 READY
 750D: K393 READY
 760D: K347 READY
 100D: K346 READY
1000D: K254 READY : Ver 3.7.5
1100D: K288 READY
1200D: K327 READY
 EOSM: K331 READY

Setting up temporary SD/CF card images...
‘../magic-lantern/contrib/qemu/sd.img.xz’ -> ‘./sd.img.xz’

Testing display from bootloader...
   5D: OK
  5D2: OK
  5D3: OK
  5D4: OK
   6D: OK
   7D: please check
 7D2M: OK
 7D2S: OK
  40D: OK
  50D: OK
  60D: OK
  70D: OK
  80D: OK
 400D: OK
 450D: OK
 500D: OK
 550D: OK
 600D: OK
 650D: OK
 700D: OK
 750D: OK
 760D: OK
 100D: OK
1000D: OK
1100D: OK
1200D: OK
 EOSM: OK

Testing EOS M3...
SD boot: StartDiskboot
Display: TurnOnDisplay

Restoring your SD/CF card images...

Testing Canon GUI...
  60D: OK
  5D3: OK
 600D: OK
1200D: OK
1100D: OK

Hope all of this will be useful to other developers  8)

wildstray

  • New to the forum
  • *
  • Posts: 9
Re: How to run Magic Lantern into QEMU?!...
« Reply #109 on: October 21, 2016, 09:24:29 PM »
Hello, I'm new to ML, I'm trying it on an EOSM. I wish to develop a module, but it would be really difficult using the "physical" camera. So I'm trying to setup an emulation environment... unluckily I miss something... I'm stuck on qemu... I need some help.

Code: [Select]
/opt/qemu/bin/qemu-system-arm -machine EOSM
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 3FFFFFFF: eos.ram
40001000 - 7FFFFFFF: eos.ram_uncached
F0000000 - F0FFFFFF: eos.rom0
F1000000 - F1FFFFFF: eos.rom0_mirror_F1
F2000000 - F2FFFFFF: eos.rom0_mirror_F2
F3000000 - F3FFFFFF: eos.rom0_mirror_F3
F4000000 - F4FFFFFF: eos.rom0_mirror_F4
F5000000 - F5FFFFFF: eos.rom0_mirror_F5
F6000000 - F6FFFFFF: eos.rom0_mirror_F6
F7000000 - F7FFFFFF: eos.rom0_mirror_F7
F8000000 - F8FFFFFF: eos.rom1
F9000000 - F9FFFFFF: eos.rom1_mirror_F9
FA000000 - FAFFFFFF: eos.rom1_mirror_FA
FB000000 - FBFFFFFF: eos.rom1_mirror_FB
FC000000 - FCFFFFFF: eos.rom1_mirror_FC
FD000000 - FDFFFFFF: eos.rom1_mirror_FD
FE000000 - FEFFFFFF: eos.rom1_mirror_FE
FF000000 - FFFFFFFF: eos.rom1_mirror_FF
C0000000 - CFFFFFFF: eos.iomem
[EOS] loading 'ROM-EOSM.BIN' to 0xF0000000-0xF0FFFFFF
[EOS] loading 'ROM-EOSM.BIN' to 0xF8000000-0xF8FFFFFF (offset 0x1000000)
FIXME: no MPU spells for EOSM.

Available keys:
- Arrow keys   : Navigation
- [ and ]      : Main dial (top scrollwheel)
- SPACE        : SET
- M            : MENU
- P            : PLAY
- I            : INFO/DISP
- L            : LiveView
- F1           : show this help

VNC server running on '127.0.0.1;5900'

I know that without MPU spells I cannot display Canon menu. But the only think I can display in VNC is the garbled screen. How to load ML?
I compiled EOSM platform with CONFIG_QEMU=y and I made qemu-helper.bin.



This is my directory setup (all uppercase as required?):

Code: [Select]
├── ROM-EOSM.BIN
└── sdcard
     ├── AUTOEXEC.BIN
     ├── ML
     │   ├── CROPMKS
     │   │   ├── CINESCO2.BMP
     │   │   ├── CRSSMTR2.BMP
     │   │   ├── PASSPORT.BMP
     │   │   ├── PHIPHOTO.BMP
     │   │   └── PHIVIDEO.BMP
     │   ├── DATA
     │   │   ├── APSC8P.LUT
     │   │   ├── APSC8R.LUT
     │   │   ├── FF8P.LUT
     │   │   └── FF8R.LUT
     │   ├── DOC
     │   ├── DOCS
     │   ├── FONTS
     │   │   ├── ARGHLF22.RBF
     │   │   ├── ARGNOR23.RBF
     │   │   ├── ARGNOR28.RBF
     │   │   ├── ARGNOR32.RBF
     │   │   ├── TERM12.RBF
     │   │   └── TERM20.RBF
     │   ├── MODULES
     │   │   ├── ADV_INT.MO
     │   │   ├── ARKANOID.MO
     │   │   ├── AUTOEXPO.MO
     │   │   ├── BENCH.MO
     │   │   ├── DEFLICK.MO
     │   │   ├── DUAL_ISO.MO
     │   │   ├── EOSM_202.SYM
     │   │   ├── ETTR.MO
     │   │   ├── FILE_MAN.MO
     │   │   ├── LUA.MO
     │   │   ├── MLV_PLAY.MO
     │   │   ├── MLV_REC.MO
     │   │   ├── MLV_SND.MO
     │   │   ├── PANO.MO
     │   │   ├── PIC_VIEW.MO
     │   │   ├── RAW_REC.MO
     │   │   ├── SELFTEST.MO
     │   │   └── SILENT.MO
     │   ├── README
     │   └── SCRIPTS
     ├── MAGICLANTERN
     ├── ML-SETUP.FIR
     └── QEMU-HELPER.BIN

Qemu 2.5.50 from niklastisk repo, branch eos-develop-new (./configure --disable-docs --target-list=arm-softmmu).

...anyway, I'm asking myself: is there a way to display ML menu at startup in the emulator? Otherwise it would be a bit difficult to recall it on EOSM... on the real camera I use double touch on the screen...

wildstray

  • New to the forum
  • *
  • Posts: 9
Re: How to run Magic Lantern into QEMU?!...
« Reply #110 on: October 21, 2016, 09:51:07 PM »
PS: I had to comment out a code fragment from eos_init_common(). Otherwise, after loading ROM-EOSM.BIN, qemu exits with a "CF init failed".

Code: [Select]
    /* init CF card */
    DriveInfo *dj;
    dj = drive_get_next(IF_IDE);
    if (!dj) {
        printf("CF init failed\n");
        exit(1);
    }

    ide_bus_new(&s->cf.bus, sizeof(s->cf.bus), NULL, 0, 2);
    ide_init2(&s->cf.bus, s->interrupt);
    ide_create_drive(&s->cf.bus, 0, dj);

EOSM doesn't have CF. It fails also if I create a cfcard directory. And now I have the dubt that sdcard and cfcard directory are totally ignored...

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #111 on: October 22, 2016, 01:37:07 PM »
For now, I recommend working on a model that can display Canon menu (at the time of writing, 60D, 5D3, 1100D or 1200D).

There are two qemu branches, with different design goals:

- the one in unified, which only attempts to run some ML code:
   - it displays the ML menu for most models
   - requires several changes to ML code (lots of hacks - grep for CONFIG_QEMU)
   - runs only a tiny part of Canon code (some startup code, task scheduler and... that's pretty much it)
   - there is a filesystem emulation, but it's extremely hackish: ML file I/O calls are replaced with wrapped calls to the host system (in the sdcard/cfcard directories)
   - it also runs some LiveView and HDMI tests (also very hackish)
   - back then, emulating Canon GUI was a pipe dream
   - I don't remember touching it in the last 1-2 years, so it should probably go away.

- the one in the qemu branch, which attempts to run the complete Canon firmware and unmodified autoexec.bin:
   - ML menu only works on those models that can boot Canon GUI
   - to navigate it easily, define GUIMODE_ML_MENU as 0 in consts.h (that's because GUI mode switching doesn't work yet)
   - patching ML code is optional (it can load unmodified autoexec.bin files, but patching can still be useful)
   - storage emulation uses a SD or CF card image (a single big file)
   - SD/CF emulation works by emulating the low-level calls (Identify Drive, read/write sector, stuff like that)
   - bootloader emulation works on nearly all models (from DIGIC 2 to DIGIC 6), including loading autoexec.bin from the card image
   - file I/O calls from both Canon and ML code are expected to work well on SD (e.g. loading ML modules, saving settings, creating the DCIM and MISC directories from Canon code)
   - CF emulation is not very solid (there are nondeterministic errors)
   - changing most Canon settings (properties) doesn't work (it requires talking to MPU)
   - LiveView and HDMI tests are very hard to run (it requires hacking some very hackish code)
   - you can debug it and trace various calls in Canon firmware using gdb (very useful for reverse engineering)

Basically, that's the current state of the emulation. Not exactly straightforward for new developers, but slowly getting there.

It also serves as "executable documentation" for a very large part of our knowledge about Canon code.

wildstray

  • New to the forum
  • *
  • Posts: 9
Re: How to run Magic Lantern into QEMU?!...
« Reply #112 on: October 22, 2016, 02:17:48 PM »
Thank for the clarifications, A1ex!

Ok, I could works indifferently on an emulated 60D, 5D3 or so. But the only ROM I have is the one dumped from my camera, so firstly I need to obtain another ROM (how?).

About ML branches, you recommend to use qemu branch for new developers? If it would be more reliable I'll use it. Actually, I wanted to use unified because of SD emulation wrapping on host fs... it would be simpler and more agile to work in ML directory without mounting and unmounting an image file.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #113 on: October 22, 2016, 03:28:18 PM »
I think the newer branch is a lot more robust and the emulation is much closer to the real thing.

For mounting/unmounting, it should be similar to a real SD card: once you have set up your SD card image with kpartx (see mount.sh), you click on EOS_DIGITAL in your file browser, then you run "make install" from your camera or module directory, then you start QEMU. You can automate this as well, if you like.

FYI, the install script sets up an initial SD card image, cloned from a 256MB card, which is already bootable and contains the portable display test autoexec.bin (handy to test your initial installation).

wildstray

  • New to the forum
  • *
  • Posts: 9
Re: How to run Magic Lantern into QEMU?!...
« Reply #114 on: October 22, 2016, 10:07:04 PM »
Yeah! :D After several peregrinations between repositories and patches, and thanks to install.sh and run_canon_fw.sh scripts and the suggestions of a1ex, now I have a semi-working qemu environment. After seconds, I got the Canon menu...



But this is the maximum I can do. When I press a key, I can see only these warnings in qemu console...

Code: [Select]
Warning: no scancode found for keysym 112
Warning: no scancode found for keysym 112
Warning: no scancode found for keysym 112
Warning: no scancode found for keysym 112

Did I miss something about keycodes?

PS: I tried to run 60D and EOS ROMs... I seen the Magic Lantern Rescue screen for both. But the sd card image I prepared with ML installation is 60D.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #115 on: October 22, 2016, 10:19:37 PM »
Looks fine (I get the same screen here).

The scancode error is internal to qemu; maybe it doesn't like some keyboard layouts?

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #116 on: October 23, 2016, 12:47:28 AM »
BTW, some small updates:

- initial support for 5D4 AECU aka K349AE (a secondary core, also ARM with DryOS)
- a test for GDB scripts (in the test suite)
- interactive UART support (you can navigate those bootloader menus)



Here's an easy coding task for you: some models don't have a debugmsg.gdb script. Creating one requires just finding some stubs. Right now, those models are: 5D2, 6D, 7D, 50D, 500D, 650D, 100D, 1100D and EOS M.

Ant123

  • Freshman
  • **
  • Posts: 65
Re: How to run Magic Lantern into QEMU?!...
« Reply #117 on: October 25, 2016, 10:26:31 PM »
I don't see menu on Lubuntu 16.04:

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #118 on: November 01, 2016, 08:38:20 PM »
Some more updates:

- emulate the picture taking process (60D and 1200D):
   - can "capture" a full-res silent picture; that includes:
     - EDMAC transfers and interrupts
     - image processing modules (dummy emulation of ADKIZ and HIV for now)
     - HEAD timers (dummy emulation for now)
   - you will need a reference image at qemu/<camera>/VRAM/PH-QR/RAW-000.DNG (a full-res silent picture)
   - it cannot emulate the unmodified silent.mo because of some GUI calls
   - you can either patch silent.c & raw.c, or use a minimal implementation
- 550D shows the date/time screen (but refuses to show the main screen)
- heartbeat timer now works on VxWorks models (can switch tasks)
- 450D emulates file I/O from main firmware
- a few more self-tests:
   - portable ROM dumper test (SD I/O from bootloader; no CF yet)
   - file I/O test from main firmware (check whether the DCIM directory is created at startup; SD models only)
   - test for picture taking emulation (test code under minimal/qemu-frsp)



The first feature also reveals the register configurations required for taking a picture by directly driving the sensor with our own code :)

Full-res photo capture log: qemu-60D-FA_CaptureTestImage.log

Current self-test log:
Code: [Select]
Testing bootloaders...
   5D: ROM READY
  5D2: K218 READY
  5D3: K285 READY
  5D4: K349 READY
   6D: K302 READY
   7D: FAILED!
 7D2M: K289M READY
  40D: K190 READY : Ver 4.0.1
  50D: K261 READY
  60D: K287 READY
  70D: K325 READY
  80D: K350 READY
 400D: InitializeIntercom
 450D: K176 READY : Ver 4.0.3
 500D: K252 READY
 550D: K270 READY
 600D: K286 READY
 650D: K301 READY
 700D: K326 READY
 750D: K393 READY
 760D: K347 READY
 100D: K346 READY
1000D: K254 READY : Ver 3.7.5
1100D: K288 READY
1200D: K327 READY
 EOSM: K331 READY
5D4AE: K349AE AECU Firm Ver. 5.8.1(5.8.1)
 7D2S: K289S READY

Testing Canon GUI...
  60D: OK
  5D3: OK
 550D: OK
 600D: OK
1200D: OK
1100D: OK

Testing GDB scripts...
   5D: [  tExcTask:ffb223cc ] task_create(CmdShell, prio=a, stack=0, entry=ffb22420, arg=0)
  5D2: 5D2/debugmsg.gdb not present
  5D3: [      init:ff0c32d4 ] task_create(Startup, prio=11, stack=400, entry=ff0c2928, arg=0)
  5D4: [      init:fe0e14c9 ] task_create(SFRead, prio=11, stack=400, entry=fe0e0ef7, arg=620008)
   6D: 6D/debugmsg.gdb not present
   7D: 7D/debugmsg.gdb not present
 7D2M: [      init:00002207 ] task_create(OmarInit, prio=f, stack=400, entry=2183, arg=4ae1ec)
  40D: [ tTaskMain:ff812a60 ] task_create(HotPlug, prio=1e, stack=0, entry=ff812cb8, arg=0)
  50D: 50D/debugmsg.gdb not present
  60D: [   Startup:ff1dcc18 ] task_create(PropMgr, prio=14, stack=0, entry=ff1dcb24, arg=807b1c)
  70D: [      init:ff0c3360 ] task_create(TaskMain, prio=1d, stack=0, entry=ff0c28ac, arg=0)
  80D: [      init:fe0d449f ] task_create(TaskMain, prio=1d, stack=0, entry=fe0d3619, arg=0)
 400D: [  tStartup:ffb1d1bc ] task_create(ImagePlayDriverTask, prio=19, stack=0, entry=ffa0ccd0, arg=0)
 450D: [ tTaskMain:ffd0a664 ] task_create(PropMgr, prio=15, stack=0, entry=ffd0a9e4, arg=384e5c)
 500D: 500D/debugmsg.gdb not present
 550D: [   Startup:ff1d8b30 ] task_create(PropMgr, prio=14, stack=0, entry=ff1d8a3c, arg=726d20)
 600D: [   Startup:ff1fbba8 ] task_create(PropMgr, prio=14, stack=0, entry=ff1fbab4, arg=757140)
 650D: 650D/debugmsg.gdb not present
 700D: [   Startup:ff0c38fc ] task_create(Startup2, prio=11, stack=400, entry=ff0c35b0, arg=0)
 750D: [      init:fe0ce241 ] task_create(TaskMain, prio=1d, stack=0, entry=fe0cd4a9, arg=0)
 760D: [      init:fe0ce445 ] task_create(TaskMain, prio=1d, stack=0, entry=fe0cd6ad, arg=0)
 100D: FAILED!
1000D: [          :ff812eec ] task_create(HotPlug, prio=1e, stack=0, entry=ff813050, arg=0)
1100D: 1100D/debugmsg.gdb not present
1200D: [      K327:ff2b9bd8 ] task_create(PropMgr, prio=14, stack=0, entry=ff2b9ae4, arg=71a11c)
 EOSM: EOSM/debugmsg.gdb not present
5D4AE: [      init:fe0a2aa1 ] task_create(TaskMain, prio=1d, stack=0, entry=fe0a2159, arg=0)
 7D2S: 7D2S/debugmsg.gdb not present
EOSM3: [   Startup:010e17a9 ] task_create(SD1stInit, prio=18, stack=0, entry=10e1739, arg=0)
A1100: [   Startup:ffc3f6b0 ] task_create(SD1stInit, prio=18, stack=0, entry=ffc3f604, arg=0)

Setting up temporary SD/CF card images...
‘../magic-lantern/contrib/qemu/sd.img.xz’ -> ‘./sd.img.xz’

Testing FA_CaptureTestImage...
  60D: OK
1200D: OK

Testing file I/O (DCIM directory)...
  60D: OK
  5D3: OK
 550D: OK
 600D: OK
1200D: OK
1100D: OK
 100D: OK
 450D: OK

Testing display from bootloader...
   5D: OK
  5D2: OK
  5D3: OK
  5D4: OK
   6D: OK
   7D: please check
 7D2M: OK
  40D: OK
  50D: OK
  60D: OK
  70D: OK
  80D: OK
 400D: OK
 450D: OK
 500D: OK
 550D: OK
 600D: OK
 650D: OK
 700D: OK
 750D: OK
 760D: OK
 100D: OK
1000D: OK
1100D: OK
1200D: OK
 EOSM: OK

Testing EOS M3...
SD boot: StartDiskboot
Display: TurnOnDisplay

Preparing portable ROM dumper...
Testing portable ROM dumper...
   5D: skipping
  5D2: skipping
  5D3: ROM0.BIN: OK ROM1.BIN: OK
  5D4: ROM1.BIN: OK
   6D: ROM0.BIN: OK ROM1.BIN: OK
   7D: ROMs not saved
 7D2M: ROM1.BIN: OK
  40D: skipping
  50D: skipping
  60D: ROM0.BIN: OK ROM1.BIN: OK
  70D: ROM0.BIN: OK ROM1.BIN: OK
  80D: ROM1.BIN: OK
 400D: skipping
 450D: skipping
 500D: skipping
 550D: ROM0.BIN: OK ROM1.BIN: OK
 600D: ROM0.BIN: OK ROM1.BIN: OK
 650D: ROM0.BIN: OK ROM1.BIN: OK
 700D: ROM0.BIN: OK ROM1.BIN: OK
 750D: ROM1.BIN: OK
 760D: ROM1.BIN: OK
 100D: ROM0.BIN: OK ROM1.BIN: OK
1000D: skipping
1100D: ROM0.BIN: OK ROM1.BIN: OK
1200D: ROM0.BIN: OK ROM1.BIN: OK
 EOSM: ROM0.BIN: OK ROM1.BIN: OK

Restoring your SD/CF card images...

It's getting close to being usable for testing the nightly builds :)



You may wonder why I'm looking at those old VxWorks models - they do a lot of things in a slightly different way, yet still compatible with the new models. This gives extra information for understanding hardware internals (e.g. different debug strings, or just exercising different code paths in QEMU).

For example, the photo taking code on 60D uses an old-style interface for the interrupt controller, but most other code uses the new one. There is a single interrupt controller, with two interfaces (see eos_handle_intengine and eos_handle_intengine_vx in eos.c). The VxWorks models use both interfaces (very old models probably use only the old interface).

Before looking at VxWorks models, I had no idea what the old-style registers might even be doing.

Will this extra knowledge translate into new features or new models ported? I hope so, but - as usual - can't promise anything. Feel free to jump in and get your hands dirty with the code.


Ant123

  • Freshman
  • **
  • Posts: 65
Re: How to run Magic Lantern into QEMU?!...
« Reply #120 on: November 09, 2016, 07:13:35 PM »
i still want 1k FPS :)
it's better to want a replacement for cache hacks on Digic 6  :)


Ant123

  • Freshman
  • **
  • Posts: 65
Re: How to run Magic Lantern into QEMU?!...
« Reply #122 on: November 10, 2016, 11:56:13 AM »
I mean that cache debug operations are not found in Cortex-R4 Technical Reference Manual


a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 9827
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #124 on: January 18, 2017, 01:18:50 AM »
More updates:

- 100D boots Canon GUI
- 70D shows date/time screen (but refuses to boot Canon GUI if date/time is patched)
- EOSM and 450D run most of the initialization and pass the DCIM dir test
- very basic (incomplete) support for Eeko and JPCORE
- photo capture emulation works on 5D3 as well (test doesn't fully pass yet though)
- memory protection registers are printed at startup
- full list here.



The test suite now runs on ML build server as well, here.