Testers wanted: Qemu 4.2.1

[names_are_hard]

Hello!  I have tidied up my work (with some help from a1ex on the multicore stuff ) porting Qemu from 2.5.0 (current ML uses this) to Qemu 4.2.1.  It works at least okay, can get to GUI in some cams known to be supported well in Qemu.  It emulates Digic 7 cams better than before.

I would like some testers who can compare results between 2.5.0 and 4.2.1 with different roms.  Note that I'm expecting 4.2.1 to generally be worse at this time.  I want to know how so I can improve it.  Modern Qemu is much easier to build on modern systems and emulates Arm better.  With your help, we can make it work as well as 2.5.0.

To do this testing you will need to be happy getting Qemu 2.5.0 from ML "qemu" branch working, as well as get my port working:
https://github.com/reticulatedpines/magiclantern_simplified/commit/5c05e1e073842b50c4bb0d6d666c3766bb74db24

Then, please try and find differences in behaviour between the two versions.  One significant difference is that 4.2.1 will crash if the cam tries to access unmapped memory - this seems common on the roms I've tested.  I've fixed this for I think 200D, 50D and 80D.  If it's not yet fixed, in my port, this should assert with the address that caused problems and is an easy fix.  This is a good crash - emulation will be better in 4.2.1 once we find these crashing regions and I update the memory maps.

Different -d flags to Qemu will exercise different code and can cause different behaviours.  Try these if you have the time.  Use a bad -d option, e.g. "-d broken", and Qemu will give you a list.  Lines with EOS are worth testing (you will need to run Qemu in different ways to get these to work; see previous posts about ML Qemu).  I am most interested in cases where there are repeatable differences in behaviour between 2.5 and 4.2 - I would like logs from both runs so I can find and fix the problems.

One last thing...  good luck getting both built on the same system.  Qemu 2.5.0 is hard to build on modern systems.  Qemu 4.2.1 is hard to build on old systems.  This is a large part of the reason I want to do the upgrade!

[lorenzo353]

Hi,

I'm trying to summarize here available info splitted in different forum posts, legacy and new HG repositories.

Sorry, I'm a total noob about qemu building and emulating. I'm just a user: I would like to debug from IDA pro with QEmu.
Just to be sure, I'm doing everything OK, here are the steps I'm following.

* for qemu 2.5.0

old and new links after hg migration:
https://www.magiclantern.fm/forum/index.php?topic=24420.msg230228#msg230228

doc on heptapod.net:
https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/qemu/contrib/qemu/README.rst
https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/qemu/contrib/qemu/HACKING.rst

m50 patch (digic8):
https://www.magiclantern.fm/forum/index.php?topic=23296.msg210088#msg210088

question: what is the good ubuntu version to ease qemu 2.5.0 building ?

- to install:

hg clone https://foss.heptapod.net/magic-lantern/magic-lantern
cd magic-lantern/
hg update qemu -C
cd contrib/qemu/
./install.sh

I had a crash last week, I'll publish later traces.

I have built successfully https://github.com/reticulatedpines/magiclantern_simplified/commit/5c05e1e073842b50c4bb0d6d666c3766bb74db24
with my config (same system as with 2.5.0):

   Static hostname: ubuntu
         Icon name: computer-vm
    Virtualization: vmware
  Operating System: Ubuntu 18.04.1 LTS
            Kernel: Linux 4.15.0-122-generic
      Architecture: x86-64

*** Using GCC: /usr/bin/arm-none-eabi-gcc
gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1)

*** Using GDB: /usr/bin/gdb-multiarch
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

I have created directory EOSR and put ROM0.bin and ROM1.bin here. But debugmsg.gdb is required, right ?
even with the simple
/path/to/qemu-eos$  ./run_canon_fw.sh EOSR,firmware="boot=1"

Lorenzo

[names_are_hard]

Thanks for trying   It is not trivial getting two different Qemu versions working on the same system.  It might be easier using two different VMs, but I have both working on one OS so it is possible.  I'm using Debian Testing.  I have arm-none-eabi-gcc version 8.3.1, and gdb-multiarch version 9.2-1.

If you do "boot=1", Qemu will mark the virtual disk as bootable and try to run autoexec.bin.  That is the harder case.  If you do boot=0 it will try to boot stock Canon firmware.

You don't require debugmsg.gdb.  It depends what -d options you use (-d debugmsg requires it, maybe others).

[ChristianEOS]

So I didn't really understand...

Basically testers wouldn't work for the Canon EOS 5D Mark III ?

[names_are_hard]

This is a request for people to test Qemu against roms.  It doesn't require a physical cam.  It does require you to know how to build and run Qemu.  Tests against 5d3 roms would be appreciated.

[lorenzo353]

Hi,

using qemu 4.2.1:

./run_canon_fw.sh EOSR

cat: EOSR/debugmsg.gdb: No such file or directory
DebugMsg= (from GDB script)
qemu-system-arm: -M EOSR: unsupported machine type
Use -machine help to list supported machines

in run_canon_fw.sh, line 130:
CAM=${1//,*/}
if [ "$CAM" ] && [ ! "$QEMU_EOS_DEBUGMSG" ]; then
    QEMU_EOS_DEBUGMSG=`cat $CAM/debugmsg.gdb | $GREP DebugMsg_log -B 1 | $GREP -Pom1 "(?<=b \*)0x.*"`
    echo "DebugMsg=$QEMU_EOS_DEBUGMSG (from GDB script)"
else
    echo "DebugMsg=$QEMU_EOS_DEBUGMSG (overriden)"
fi

[names_are_hard]

How does that compare with 2.5.0?

[lorenzo353]

Hi,

I'm pretty sure, it is the same with 2.5.0. and last time I tested it, it certainly crashed because of wrong DebugMsb value in DebugMsg.gdb

Alex wrote a bash script to generate DebugMsg.gdb for each new updates : https://www.magiclantern.fm/forum/index.php?topic=2864.msg200846;topicseen#msg200846
but I wonder if this file is mandatory, and which function are needed.

What is the mininal DebugMsg, like a minimal stub.s ?

is it used by EOS patches for QEMU?

Lorenzo

[names_are_hard]

Ah, you're using run_canon_fw.sh, I didn't notice that last time.  I don't use that, I run Qemu directly, so I don't understand run_canon_fw.sh in detail.  I looks like it has a specific check for the existence of debugmsg.gdb, whether or not it's required for the Qemu task you're testing.

The supported cameras already have debugmsg.gdb files.  This thread is for comparing 2.5.0 against 4.2.1.  The thread isn't about getting Qemu working with a new camera.