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


  • Hero Member
  • *****
  • Posts: 1647
Re: How to run Magic Lantern into QEMU?!...
« Reply #175 on: June 08, 2017, 01:07:38 AM »
I see, so we should check if /Volumes/EOS_DIGITAL* exists on OS X.
EOSM.202 EOSM.203 EOSM2.103 700D.115 5D3.*


  • Administrator
  • Hero Member
  • *****
  • Posts: 9933
  • 5D Mark Free
Re: How to run Magic Lantern into QEMU?!...
« Reply #176 on: June 11, 2017, 12:34:21 AM »
More updates:

* Monitor console available by default as a UNIX socket; that means, during emulation you can interact with it with netcat (for quick commands or from a script), or with socat (for interactive console):
Code: [Select]
echo "log io" | nc -U qemu.monitor
socat - UNIX-CONNECT:qemu.monitor

* Log DebugMsg calls without GDB (very fast; credits go to @nkls - I've used a modified version of his initial DebugMsg hook). To use it on plain Canon firmware (any shell):
Code: [Select]
env QEMU_EOS_DEBUGMSG=0x5b90 ./ 5D3,firmware="boot=0" -d debugmsg
or, with ML loaded (requires bash):
Code: [Select]
. ./ 5D3.113
./ 5D3,firmware="boot=1" -d debugmsg

* Verbose stack trace (to see where each message is coming from), for both -d debugmsg and GDB scripts (DIGIC 4-6). Example for the former:
Code: [Select]
env QEMU_EOS_DEBUGMSG=0x5b90 ./ 5D3,firmware="boot=0" -d debugmsg,callstack,v

Current stack: [14ff80-14ef80] sp=14fed8                                         at [FileMgr:5b90:ff0f9684]
0x17B60(51ec48 &"TaskClass", 17b60, 19980218, 19980218)                          at [FileMgr:de48:14ff78] (pc:sp)
 0xFF11B818(51ea28 &"FileMgr", 6, 0, 2)                                          at [FileMgr:17bbc:14ff50] (pc:sp)
  0x178B4(51ec1c &"StateObject", 51ea28 &"FileMgr", 6, 0)                        at [FileMgr:ff11b844:14ff38] (pc:sp)
   0x178EC(51ec1c &"StateObject", 51ea28 &"FileMgr", 6, 0)                       at [FileMgr:178e4:14ff28] (pc:sp)
    0xFF2C8F5C(51ea28 &"FileMgr", 0, 2, ff2c8f5c)                                at [FileMgr:1796c:14ff08] (pc:sp)
     0xFF0C5194(10, 0, 24, ff0c5194)                                             at [FileMgr:ff2c9050:14fef0] (pc:sp)
      0x5B90(0, 3, ff0f9784 "[SEQ] NotifyComplete (Cur = %d, %#x, Flag = %#x)", 4)
                                                                                 at [FileMgr:ff0f9680:14fed8] (pc:sp)
[     FileMgr:ff0f9680 ] (00:03) [SEQ] NotifyComplete (Cur = 4, 0x10, Flag = 0x10)

This tool is very powerful - rather than hunting for several minutes/hours to see where some error message might be coming from, you now get the answer in seconds. TODO: example on finding and fixing some error.

* Thorough consistency check to make sure the stack trace gives the same information as if you would follow the call/return trace manually.

More to come (regarding 1300D, digic 6, memory checking, automatic testing of ML builds). Most of these were written some time ago, but it takes a while to integrate everything and make sure they pass the test suite. Though slow, this approach does catch a lot of bugs very early, and I hope to have soon the tools to use a similar development approach for the main ML codebase.