On Fri, Jul 22, 2016 at 3:43 PM, Alistair Francis <[email protected]> wrote: > On Fri, Jul 22, 2016 at 5:45 AM, Nathan Rossi <[email protected]> wrote: >> On Wed, Jul 20, 2016 at 10:21 AM, Alistair Francis >> <[email protected]> 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 >> [email protected] >> https://lists.yoctoproject.org/listinfo/meta-xilinx -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
