Hi,
TL;DR;
Booted AGL Jellyfish images under QEMU TCG and got at least working virtio block device and splash screen. It also manged to turn on my USB camera which implies the USB pass through was working. Once the splash screen clears and the screen re-sizes it goes blank.
Got the same results booting the images under Xen as Dom0 guest.
Plain TCG boot:
The command line is a curious mixture of MMIO and PCI virtio devices. I needed to decompress the initramfs and block images. I successfully booted with the following:
./aarch64-softmmu/qemu-system-aarch64 -cpu cortex-a57 \ -machine type=virt,virtualization=on,gic-version=3 \ -serial mon:stdio \ -netdev user,id=unet,hostfwd=tcp::2222-:22 \ -device virtio-net-device,netdev=unet,id=virt-net \ -drive id=disk0,file=$HOME/images/agl/agl-demo-platform-crosssdk-qemuarm64.ext4,if=none,format=raw \ -device virtio-blk-device,drive=disk0 \ -soundhw hda \ -device VGA,edid=on \ -device qemu-xhci -device usb-tablet -device usb-kbd \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 \ -device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon \ -m 2048 \ -kernel ~/images/agl/Image \ -append "console=ttyAMA0 root=/dev/vda" \ -initrd ~/images/agl/initramfs-netboot-image-qemuarm64.ext4 \ -display gtk,show-cursor=on
My command line complains that: qemu-system-aarch64: warning: '-soundhw hda' is deprecated, please use '-device intel-hda -device hda-duplex' instead
A couple of units fail on startup:
[FAILED] Failed to start Driver configuration for Unicens2. See 'systemctl status unicens-config.service' for details. [FAILED] Failed to start Binding for Networking. See 'systemctl status afm-service-agl-s…etwork--1.0--main.service' for details.
Adding -smp 4 makes things move a little faster. You can login on the console as root (no passwd).
Booting with Xen as a Dom0:
This uses the guest-loader device to setup the Dom0 kernel/initrd. I boosted the system memory to 4G and allocated 2G to Dom0. You can find my QEMU tree with guest-loader support at:
https://github.com/stsquad/qemu/tree/xen/guest-loader-v1
The command line is as before except more memory and a different -kernel line to load Xen:
./aarch64-softmmu/qemu-system-aarch64 -cpu cortex-a57 \ -machine type=virt,virtualization=on,gic-version=3 \ ... -m 4096 \ -kernel ~/lsrc/xen.git/xen/xen \ -append "dom0_mem=2G,max:2G loglvl=all guest_loglvl=all" \ -device guest-loader,addr=0x42000000,kernel=$HOME/images/agl/Image,bootargs="console=ttyAMA0 root=/dev/vda" \ -device guest-loader,addr=0x47000000,initrd=$HOME/images/agl/initramfs-netboot-image-qemuarm64.ext4 \ -display gtk,show-cursor=on \ -smp 4
The system boots up although I don't get any kernel messages from the console which Xen still has control over. It throws up some complains about un-handled writes:
(XEN) *************************************************** (XEN) No support for ARM_SMCCC_ARCH_WORKAROUND_1. (XEN) Please update your firmware. (XEN) *************************************************** (XEN) 3... 2... 1... (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 364kB init memory. (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER12 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER16 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER20 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER24 (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER28 (XEN) d0v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0 (XEN) d0v1: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0 (XEN) d0v2: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0 (XEN) d0v3: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0
Although I couldn't access the console I was able to ssh into the machine via my 2222 port-fwd.
Note that working VirtIO under Xen Dom0 in TCG isn't super impressive as in the emulation case the VirtIO devices behave just like real HW which Dom0 has pass-through access to.
The next step is to try this under KVM on a native aarch64 system. I'm still having issues with Xen which is being discussed in other threads.
stratos-dev@op-lists.linaro.org