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

[Peter Crosthwaite]

On Fri, Sep 18, 2015 at 10:23 AM, Richard Purdie
<address@hidden> 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 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?

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).

Regards,
Peter

> The above will build its own qemu-native as there are some patches we
> rely on (like the network fixes). You can point the qemu recipe at
> different source easily enough.
>
> Cheers,
>
> Richard
>