On Tue, Mar 12, 2019 at 10:36 AM Markus Armbruster <arm...@redhat.com> wrote: > > Dear board code maintainers, > > This is a (rather late) follow-up to the last QEMU summit. Minutes[*]: > > * Deprecating unmaintained features (devices, targets, backends) in QEMU > > QEMU has a mechanism to deprecate features but there remains a lot of > old unmaintained code. Refactoring is hindered by untested legacy > code, so there is a desire to deprecate unmaintained features more > often. > > [...] > > We should require at least a minimal test for each board; if nobody > cares enough to come up with one, that board should be deprecated. > > [...] > > Also see the qemu-devel discussion about deprecating code: > https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html. > > That's a link to "Minutes of KVM Forum BoF on deprecating stuff". > Quote: > > * One obvious class of candidates for removal is machines we don't know > how to boot, or can't boot, say because we lack required firmware > and/or OS. > > Of course, "can boot" should be an automated test. As a first step > towards that, we should at least document how to boot each machine. > We're going to ask machine maintainers to do that. > > Let's get going on this. > > I gathered the machine types, mapped them to source files, which I fed > to get_maintainer.pl. Results are appended. If you're cc'ed, > MAINTAINERS fingers you for at least one machine type's source file. > Please tell us for all of them how to to a "meaningful" boot test. > > For now, what's "meaningful" is entirely up to you. Booting Linux > certainly is. > > Make sure to include a complete QEMU command line. If your QEMU command > line requires resources beyond the QEMU source tree and what we build > from it, please detail them, and provide download URLs as far as > possible. > > Goals for this exercise: > > * Gather information we need to cover more machines in our automated > testing. > > Related work: > [PATCH v4 00/19] Acceptance Tests: target architecture support > Message-Id: <20190312121150.8638-1-cr...@redhat.com> > https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html > > * Maybe identify a few machines we don't know how to boot anymore. > > Thanks in advance for your help! > > > > Machines with at least one maintainer: > > > = hw/arm/mcimx7d-sabre.c = > Peter Maydell <peter.mayd...@linaro.org> (odd fixer:MCIMX7D SABRE / i...) > Andrey Smirnov <andrew.smir...@gmail.com> (reviewer:MCIMX7D SABRE / i...) > qemu-...@nongnu.org (open list:MCIMX7D SABRE / i...) >
Sorry I am late to this party. I haven't used i.MX7 emulation in a while and things didn't go smoothly out of the box, so I had to create a number of fixes (submitted to the ML). I use Linux kernel built using Buildroot for validation. Buildroot should have a default i.MX7 Sabred SD configuration and that should probably work. I usually change mine slightly to use compiled-in rootfs to simplify storage setup. In case this is helpful here's a number of commands I use to start my test cases: * PCIe (e1000 ethernet attached), USB (usb stick attached), SD: arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre -nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to DTB> -device e1000e,bus="dw-pcie",netdev=lan0 -netdev tap,id=lan0,ifname=tap0,script=no,downscript=no -append "console=ttymxc0,115200 noinitrd" -usb -drive if=none,id=stick,file=<patch to USB stick image>,format=raw -device usb-storage,bus=usb-bus.0,drive=stick -drive id=sd1,if=sd,format=file,file=<path to SD1> -drive id=sd2,if=sd,format=file,file=<path to SD2> -driv eid=sd3,if=sd,format=file,file=<path to SD3> * EHCI USB attached via PCIe with legacy interrupts, Ethernet connected to built-in controller: arm-softmmu/qemu-system-arm -smp 2 -m 1024 -machine mcimx7d-sabre -nographic -serial mon:stdio -kernel <path to zImage> -dtb <path to DTB> -device usb-ehci,id=ehci,bus="dw-pcie" -net nic,model=imx.fec,netdev=lan0 -netdev tap,id=lan0,ifname=tap0,script=no,downscript=no -append "console=ttymxc0,115200 noinitrd pci=nomsi" -usb -drive if=none,id=stick,file=<path to USB stick image>,format=raw Also, I don't think anyone would try to do this, but just as a warning, building QEMU with --enable-tcg-interpreter doesn't really work that well (/init gets SIGKILLed every time), so I'd recommend avoiding using that option. Hopefully this is enough info, but if not, feel free to ask me more questions. Thanks, Andrey Smirnov