[meta-xilinx] [PATCH V2 3/5] config: Set the Xilinx QEMU as the prefered QEMU to build

[Manjukumar Harthikote Matha]

Hi Nathan/Alistair,

On 08/11/2016 04:33 AM, Nathan Rossi wrote:
> On Tue, Aug 2, 2016 at 9:52 AM, Alistair Francis
> <alistair.francis at xilinx.com> wrote:
>> On Sun, Jul 31, 2016 at 7:49 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
>>> On Thu, Jul 28, 2016 at 7:26 AM, Alistair Francis
>>> <alistair.francis at xilinx.com> wrote:
>>>> Signed-off-by: Alistair Francis <alistair.francis at xilinx.com>
>>>> ---
>>>>  conf/machine/include/machine-xilinx-default.inc | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/conf/machine/include/machine-xilinx-default.inc b/conf/machine/include/machine-xilinx-default.inc
>>>> index 02fa077..4ea68fd 100644
>>>> --- a/conf/machine/include/machine-xilinx-default.inc
>>>> +++ b/conf/machine/include/machine-xilinx-default.inc
>>>> @@ -38,3 +38,5 @@ UBOOT_ELF_aarch64 ?= "u-boot.elf"
>>>>  # kernel modules for ZynqMP
>>>>  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS_append_zynqmp = " kernel-module-mali-modules"
>>>>
>>>> +PREFERRED_VERSION_qemu-native = "2.2.5"
>>>
>>> I am not sure if this approach will work as expected due to some other
>>> parts of Yocto depending on QEMU in different ways. For example the
>>> "qemu-usermode" distro flag and the corresponding linux-user execution
>>> of tasks might break?
>>
>> Hmmm... How else can it be done?
>
> 'Why not have both?' :)
>
> To avoid any issues with replacing qemu-native, I looked at setting it
> up as a separate recipe. "qemu-xilinx" recipe which populates the
> binaries in a sub-dir of the sysroots usr/bin.
>
> Here is a work in progress tree with the recipe:
> https://github.com/nathanrossi/meta-xilinx/tree/nrossi/qemu-xilinx
>
> Essentially the binary is located here:
> tmp-glibc/sysroots/x86_64-linux/usr/bin/qemu-xilinx/qemu-system-aarch64.
> We can work in the ability to select the qemu to use into the runqemu
> part, allowing to select depending on what you want to run on.
>
I think it should be according to PREFERRED_PROVIDER methodology and not 
build both. Currently Xilinx QEMU do support zynq, zynqmp and 
microblaze, user can change this PREFERRED_PROVIDER way to build 
upstream or Xilinx QEMU (just like kernel, u-boot etc)

We have tested on various packages including xen-image-minimal with 
Xilinx QEMU, are we missing something in testing? or you witnessing any 
breakage with Xilinx QEMU and other components?

Whats the strong reason for having both? I would prefer it that we built 
using PREFERRED_PROVIDER methodology and default to Xilinx QEMU in 
meta-xilinx.

Thanks
Manju