I've recently tried get my head round using qemu to boot various images for the RPi and BBB, and the wandboard/CSOS project was the next step. Of course it's not the real thing, but the emulated hardware should be sufficient to boot the CSOS image and so get an idea of how the project functions.
I did have a zImage that I got off the web that would boot the CSOS image in QEMU, but there was no audit support, no autofs4, and no cifs support. Sound and nfs were working, so this was a limited, but workable solution. When the penny dropped, I realised the CSOS boot partition contained the elements needed to boot CSOS in qemu because config-3.11.10-200.fc19.armv7hl shows a MULTIPLATFORM kernel config with vexpress included! So just extract vmlinuz, initrd, and the dtb file for 3.11.10-200.fc19.armv7hl and away you go. It wasn't quite that simple. The boot hung and after about ten minutes dropped to the dracut shell with a message about non-existent devices. I needed a crash course in dracut. A bit of googling and the failure to boot seemed to match this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=995843#c11 So I needed to re-generate the initrd, but how? Thanks to those who put CSOS together there are rescue vmlinuz initrd pairs. Was it too optimistic to think these could boot the CSOS image in rescue mode in qemu? Well it worked, and after re-generating the initrd using a simple dracut command, the full qemu emulation finally booted succcessfully. Code: -------------------- #! /bin/bash # # Boot CSOS QEMU Emulation # # normal KERNEL=vmlinuz-3.11.10-200.fc19.armv7hl INITRD=myinitramfs-3.11.10-200.fc19.armv7hl.img # rescue #KERNEL=vmlinuz-0-rescue-7238ddb8ad474ec3b174f852e5772bc4 #INITRD=initramfs-0-rescue-7238ddb8ad474ec3b174f852e5772bc4.img #KERNEL=vmlinuz-0-rescue-507a5a8563924751b52374237ae9534a #INITRD=initramfs-0-rescue-507a5a8563924751b52374237ae9534a.img DTB=vexpress-v2p-ca9.dtb qemu-system-arm -m 1024M \ -M vexpress-a9 \ -cpu cortex-a9 \ -smp 1 \ -kernel $KERNEL \ -initrd $INITRD \ -append "root=/dev/mmcblk0p3 rw console=ttyAMA0,115200n8 rootfstype=ext4 rootwait selinux=0" \ -drive if=sd,cache=writeback,file=CSOSbkup.img \ -serial stdio \ -net nic \ -net tap,ifname=tap0,script=no \ -dtb $DTB -------------------- The emulation has full network access using a bridged tun/tap on the host. I know JackofALL has written about java elsewhere, but the tomcat/java task was showing near 100% usage in htop. Things are much improved after installing the lua version. Hopefully I've updated it correctly, and currently have this in qemu: Code: -------------------- fedora@wandboard boot]$ uname -a Linux wandboard 3.11.10-200.fc19.armv7hl #1 SMP Fri Dec 6 01:59:46 UTC 2013 armv7l armv7l armv7l GNU/Linux [fedora@wandboard boot]$ rpm -qa | grep squeeze squeezelite-1.6-0.2.20140306git99df760.fc19.armv7hnl squeeze-web-gui-1-119.20140308gitc4f47d8.fc19.noarch community-squeeze-repo-1-7.noarch squeeze-player-scripts-1-6.noarch squeeze-web-gui-lua-0.1-0.28.gitb34e641.fc19.noarch squeezeslave-1.3.393-5.fc19.armv7hnl squeeze-web-gui-ROOT-1-119.20140308gitc4f47d8.fc19.noarch squeeze-web-gui-httpd-1-119.20140308gitc4f47d8.fc19.noarch [fedora@wandboard boot]$ rpm -qa | grep logi logitechmediaserver-CPAN-7.8.0-0.17.20130904git1378237026.fc19.armv7hnl logitechmediaserver-7.8.0-0.68.20140110git1388931871.fc19.noarch logitechmediaserver-vendor-7.8.0-0.6.20130303git1349179762.fc19.armv7hnl logitechmediaserver-vendor-sls-7.8.0-0.6.20130303git1349179762.fc19.armv7hnl jivelite-autologin-0.1-0.76.20140215git6238ec7.fc19.noarch -------------------- Sound is provided by AC97 in the emulation. Code: -------------------- [fedora@wandboard boot]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Interface [ARM AC'97 Interface], device 0: AACI AC'97 [aaci-pl041] Subdevices: 0/1 Subdevice #0: subdevice #0 -------------------- I used these params "80:40:16:0" with squeezelite to get glitch free audio which is routed via the host to an external DAC. Performance is slow, but acceptable. Both nfs and cifs mounts work via the lua webUI. One problem I have is that autologin does fails in qemu. I haven't a clue as to why. Code: -------------------- [fedora@wandboard ~]$ sudo systemctl status [email protected] [email protected] - Getty on tty1 Loaded: loaded (/etc/systemd/system/[email protected]; enabled) Active: failed (Result: start-limit) since Sat 2014-03-15 08:09:01 GMT; 56min ago Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Process: 1015 ExecStart=/sbin/agetty -a jivelite --noclear %I 38400 linux (code=exited, status=0/SUCCESS) Mar 15 08:09:01 wandboard systemd[1]: [email protected] holdoff time over, scheduling restart. Mar 15 08:09:01 wandboard systemd[1]: Stopping Getty on tty1... Mar 15 08:09:01 wandboard systemd[1]: Starting Getty on tty1... Mar 15 08:09:01 wandboard systemd[1]: [email protected] start request repeated too quickly, refusing to start. Mar 15 08:09:01 wandboard systemd[1]: Failed to start Getty on tty1. Mar 15 08:09:01 wandboard systemd[1]: Unit [email protected] entered failed state. -------------------- Not NB as it's better to ssh into jivelite so you get full keyboard on your host although the task consumes 56% CPU in qemu. Sorry, if this is a bit long and rambling. I shouldn't think you'd want this thread cluttered up with stuff about qemu. I wondered about putting a basic how-to on a separate forum thread so any discussion would take place there, and only there. Do you think there would be any interest? Using qemu offers a chance to get your hands dirty without a wandboard. It might widen interest in the project, provide further feedback and appreciation of the all hardwork being done on CSOS. ------------------------------------------------------------------------ Krisbee's Profile: http://forums.slimdevices.com/member.php?userid=59080 View this thread: http://forums.slimdevices.com/showthread.php?t=99395 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/unix
