On Fri, 2015-09-18 at 11:14 -0700, Peter Crosthwaite wrote: > On Fri, Sep 18, 2015 at 10:23 AM, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > On Fri, 2015-09-18 at 09:46 -0700, Peter Crosthwaite wrote: > >> >> My biggest fear is testing of the changes for the affected boards. > >> >> Peter, do you much coverage of these boards in your regressions? Do you > >> >> have automated tests in a git repo somewhere? > >> > > >> > The answers to these questions are "nowhere near enough" and > >> > "unfortunately not"... > >> > > >> > >> How hard would it be to do something Yocto powered? AFAIK Yocto only > >> supports the one ARM board (Vexpress), three (+ZynqMP, +Zynq) with the > >> Meta-Xilinx layer and there may be more with other layers (anything in > >> meta-linaro?). Can we bitbake something that builds out a large number > >> of ARM machines and tests them all on QEMU? > > > > Running our standard ARM board tests is a case of: > > > > git clone http://git.yoctoproject.org/git/poky > > cd poky > > source oe-init-build-env > > echo 'INHERIT += "testimage"' >> ./conf/local.conf > > MACHINE=qemuarm bitbake core-image-sato > > MACHINE=qemuarm bitbake core-image-sato -c testimage > > > > So qemuarm is implicitly vexpress, I guess we would want to add more, > such as qemuarm-zynq, qemuarm-zaurus, qemuarm-virt etc. Can a single > bitbake core-image-foo build out multiple MACHINEs or does it not work > like that?
You'd usually just MACHINE=X bitbake <image>; MACHINE=Y bitbake <image>. If the configuration shares a common set of compiler optimisation flags, it will reuse the image binaries. > > You could replace core-image-sato -> core-image-minimal for a smaller > > image and fewer tests or try core-image-sato-sdk or core-image-lsb-sdk > > for more. > > > > The Quick Start guide is at > > http://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html > > and has various things like precanned lists of prerequisites for the > > package manager. > > > > Not sure which other boards you could try booting but I know the Zaurus > > machines did work a long time ago as we submitted the qemu code. They > > are now in their own layer and I've not tried them in a long time. > > Do these multiple vendor layers conflict with each other and is > merging all the different ARM machines to poky mainline feasible? The layer model is intentional like a plugin architecture. OE was once a monolithic repository, it grew too large and painful to work. We therefore now have layers which have separate maintainership. The quality does vary a bit but it did with the monolithic repo too. In theory you can just plug the layers you want into the core and use them, they shouldn't conflict. > Something else that is on topic, is we should consider changing > (subject to backwards compat) the default qemuarm machine to virt, as > this machine is well maintained and intended for use as a pure virtual > machine (which is intent of Yocto qemu specific target IIUC). That would need some wider discussion with the OE community and our kernel maintainers since I know we build a specific qemuarm kernel but in principle it could be done. There are also qemux86, qemux86-64, qemuppc, qemumips, qemuarm64 and qemumips64 fwiw. I'm not sure we make the best use of qemu in these so I'd be interested in any opinions on what we're doing there... :) FWIW we did leave qemuarm as an armv5 cpu since we tend to test a lot of of armv7 on real hardware. Cheers, Richard