From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd48O-0006DP-2C for qemu-devel@nongnu.org; Fri, 18 Sep 2015 18:28:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zd48K-0000Xc-Rr for qemu-devel@nongnu.org; Fri, 18 Sep 2015 18:28:00 -0400 Received: from 5751f4a1.skybroadband.com ([87.81.244.161]:49379 helo=dan.rpsys.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zd48K-0000XK-H4 for qemu-devel@nongnu.org; Fri, 18 Sep 2015 18:27:56 -0400 Message-ID: <1442615253.12435.61.camel@linuxfoundation.org> From: Richard Purdie Date: Fri, 18 Sep 2015 23:27:33 +0100 In-Reply-To: References: <1442597039.12435.31.camel@linuxfoundation.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v1 0/8] QOM prop overloading + ARM MPCore CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Peter Crosthwaite , Liviu Ionescu , Pavel Fedin , QEMU Developers , Alistair Francis , Paolo Bonzini , Nathan Rossi , Andreas =?ISO-8859-1?Q?F=E4rber?= On Fri, 2015-09-18 at 11:14 -0700, Peter Crosthwaite wrote: > On Fri, Sep 18, 2015 at 10:23 AM, Richard Purdie > 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 ; MACHINE=Y bitbake . 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