Re: [Qemu-devel] [RFC PATCH v1 0/8] QOM prop overloading + ARM MPCore CPUs

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2015-09-18 at 11:14 -0700, Peter Crosthwaite wrote:
> On Fri, Sep 18, 2015 at 10:23 AM, Richard Purdie
> <richard.purdie@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