[meta-xilinx] Xilinx QEMU in meta-xilinx

Alistair Francis alistair.francis at xilinx.com
Wed Jul 27 09:10:05 PDT 2016


On Fri, Jul 22, 2016 at 3:43 PM, Alistair Francis
<alistair.francis at xilinx.com> wrote:
> On Fri, Jul 22, 2016 at 5:45 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
>> On Wed, Jul 20, 2016 at 10:21 AM, Alistair Francis
>> <alistair.francis at xilinx.com> wrote:
>>> Hello everyone,
>>>
>>> Xilinx maintains it's own version of QEMU based on the mainline
>>> version of QEMU: https://github.com/xilinx/qemu/
>>>
>>> This tree has a lot of focus on extra support and features for the
>>> Xilinx architectures. Although we are trying to get all of these
>>> features upstream to mainline QEMU it is slow work and unfortunately
>>> not always possible.
>>>
>>> We are looking at providing support to build the Xilinx QEMU in the
>>> meta-xilinx layer. This could be disabled by default and enabled by
>>> changing the PREFERRED_VERSION_qemu variable. The advantage this would
>>> bring is much more accurate and extensive support for emulating the
>>> Xilinx platforms.
>>
>> Hi Alistair,
>>
>> This sounds like a great feature.
>>
>> Some things to consider about having two versions of QEMU. Due to how
>> qemu is built and populated into the native sysroot, only one binary
>> version can exist at a time and because switching machines does not
>> change the native sysroot this would cause a rebuild of qemu when
>> switching from a meta-xilinx machine (set to use the xilinx qemu) to
>> for example a qemu* machine in oecore.
>>
>> An alternative that may be worth looking into is to have both version
>> populated in the sysroot at the same time. This could be done a number
>> of ways, the easiest would be to install the qemu binaries into a
>> /usr/bin/qemu-xilinx/ subdir. And have a "qemu-xilinx" recipe that
>> inherits qemu.inc.
>
> So I have a working solution now, but the problem is that we need our
> own qemu.inc and qemu_xilinx.bb.
>
> At the moment I just swap the preferred provider for QEMU to use the
> Xilinx one. Do we want to do it this way, or create a new recipe that
> builds the Xilinx tree?
>
> I'll look into changing the install location so we can use both, that
> is a good idea.

After looking into this more I don't think a different directory is
the way to go.

It causes a lot of problems as other Yocto recipes expect the QEMU
binaries to be there. I have a patch series almost ready, so hopefully
I'll be able to send that out today for comments.

Thanks,

Alistair

>
>>
>> Also I think there would need to be a runqemu script or similar setup
>> in meta-xilinx to handle the Xilinx QEMU due to some of features that
>> are not available in mainline (e.g. fdt-generic, loader, etc).
>
> Yes, it does need a new runqemu/runqemu-internal script. This won't be
> automatically sourced from meta-xilinx though, so the user will need
> to edit their path to call this one first. Do you know any ways around
> that?
>
>>
>>>
>>> What is the consensus on this, do people think that including the
>>> Xilinx tree of QEMU is acceptable?
>>
>> It sounds acceptable to me.
>
> Awesome!
>
> Thanks,
>
> Alistair
>
>>
>> Regards,
>> Nathan
>>
>>>
>>> Thanks,
>>>
>>> Alistair
>> --
>> _______________________________________________
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx



More information about the meta-xilinx mailing list