Hi Nathan/Alistair,
On 08/11/2016 04:33 AM, Nathan Rossi wrote:
On Tue, Aug 2, 2016 at 9:52 AM, Alistair Francis
<[email protected]> wrote:
On Sun, Jul 31, 2016 at 7:49 AM, Nathan Rossi <[email protected]> wrote:
On Thu, Jul 28, 2016 at 7:26 AM, Alistair Francis
<[email protected]> wrote:
Signed-off-by: Alistair Francis <[email protected]>
---
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
--
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx
