On 3 October 2015 at 22:31, Peter Crosthwaite <crosthwaitepe...@gmail.com> wrote: > Hi, > > I have done an audit of the ARMv7 boards to see what can boot a > vanilla linux kernel. The basic approach is to build ARM > multi_v7_defconfig kernel and boot QEMU using the DTBs built out by > the kernel. The intersection of what mainline Linux has a DTB for and > what QEMU models is tested.
Thanks for doing this; this is an interesting survey of what we implement. > The boards that do/should work include: > > vexpress-a9 > vexpress-a15 > smdkc210 (exynos) > xilinx-zynq-a9 > cubieboard (allwinner) > highbank > midway > virt FWIW I have test images for vexpress-a9, vexpress-a15, cubieboard and virt, though of course these are often older kernels and probably tweaked configs. > virt: > > Virt largely works, but there are no immediately obvious > storage/network options that are supported by the kernel. So I have to > make some exceptions to the kernel config rule, that is, I add: > > CONFIG_VIRTIO_PCI=y" > CONFIG_VIRTIO_BLK=y" > CONFIG_VIRTIO_NET=y" > > To get disks and network for the virt board. > > Could we add these configs to mainline Linux's defconfig? Note, we > don't need to add a DTS for this board, as QEMU's bootloader will > generate and provide it for us. > > There is the known highmem PCI issue that is currently under discussion: > > https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg06529.html > > So aside from the missing VIRTIO kernel configs and highmem bug, virt > is in good shape. Did you build your kernel with LPAE or not? I think an LPAE config ought to avoid the PCI highmem bug (and it's definitely what you want for anything that's Cortex-A15 based). > vexpress: > > vexpress boots up to rootfs probing, however the only storage media > that seems to be supported is flash, which doesn't have the needed > kernel configs to boot from (not 100% sure on that but I gave up > quickly). What are people who use this board in real hardware doing? > It may just work best with initrd style boots. For real hardware I expect people will be using USB disks. We don't currently model the USB controller in QEMU, though. My test images use emulated SD card storage (ie -drive if=sd,file=...). (Emulated SD card will have lousy performance.) > realview: > > Realview is not tested, but I discuss it here as it is a bit of a red > herring. The kernel has dtb support for the realview-1176 board, Actually, "realview-pb1176". The "PB" part is important! > however this is not modelled by QEMU. I creating a Realview variant > with 1176 in QEMU, however the memory maps of all the peripherals were > mismatched. > > Turns, out, QEMU is is modelling the realview FPGA emulation platform > which has a different peripheral map to the 1176 realview board > proper. So QEMU doesn't support the realview boards, just the FPGA > emulation platform, for which I can't find a kernel dtb. Should we > upstream one with some dtsi's for the CPU variation supported in QEMU? "realview" is not really a very helpful term to use here, because it's a generic label applied to a whole slew of ARM devboards. What QEMU models is: "realview-eb" -- the RealView Emulation Baseboard with an ARM926 "realview-eb-mpcore" -- the RealView Emulation Baseboard with an 11MPCore "realview-pb-a8" -- the RealView Platform Baseboard for Cortex A8 "realview-pbx-a9" -- the RealView Platform Baseboard Explore for Cortex A9 The DT in the kernel tree is for the Realview Platform Baseboard for 1176, ie PB1176. That's a different board from EB1176, as you've found. This is why "realview" on its own (or with a CPU name) is not sufficient to identify a board and why we have those -eb- and -pb(x)- infixes in our board names :-) > So Realview does not work within my testing parameters with no > immediate prospects. The kernel does support EB, PBA8 and PBX; presumably they haven't been converted to use DT (yet?). > how I am testing: > > So this is all powered by the Yocto project (Poky). I got some good > help from Nathan Rossi. I have a poky fork which changes the qemuarm > target to build my mainline (4.2.1) kernel (multi_v7_defconfig + > VIRTIO), all the DTBs and a usable rootfs. You can then specify the > type of machine (from the list above) to yocto's runqemu command. The > command sets up boot media and network automatically. > > To use it: > > git clone https://github.com/pcrost/poky.git > cd poky > source ./oe-init-build-env > MACHINE=qemuarm bitbake core-image-minimal #this takes a while > QEMUBIN=/path/to/qemu-arm MACHINE_SUBTYPE=virt runqemu qemuarm slirp > > The QEMUBIN is optional as Yocto does build QEMU for you, but this > lets you BYO QEMU if you are doing qemu development outside of the > Yocto flow. Change MACHINE_SUBTYPE to one of the supported boards to > see results. I suggest starting with virt. Skip cubieboard, that > assumes my SATA patches. Everything else you will see varying degrees > of success. Pass qemuparams="-m 256" to runqemu for the smdkc200 > (Exynos) board. Highbank and Midway will blank screen as the > outstanding issues happen pre-UART. A meaningful logbuf can be pulled > from RAM over the monitor. Useful instructions here: > > http://www.wiki.xilinx.com/QEMU-Linux+Kernel+logbuf+Extraction > > Some QEMU patches to follow to fix a few of the things mentioned. > > We should get this into regression testing. Yocto has some automated > testing features in it's own right that we should be able to leverage. > Yet to investigate (Richard pasted some stuff on an earlier thread). Nice work. thanks -- PMM
