Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components
Hi Jean-Francois, Appreciate your input, however, since we don't use meta-xilinx-tools, the workaround of a dual dependency (from both image- and u-boot) towards PMUFW appears more feasible for us. Thanks, Martin From: Jean-Francois Dagenais Sent: Thursday, December 13, 2018 2:31:30 PM To: Martin Siegumfeldt Cc: Alejandro Enedino Hernandez Samaniego; meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components On Dec 12, 2018, at 3:21 AM, Martin Siegumfeldt mailto:m...@gomspace.com>> wrote: It looks to me as Manju's proposal of adding it as an image dependency may work when building the image, but appears to be subject to a race condition between pmu-firmware and virtual/bootloader. I instigated the idea to transform the fsbl build from a class to a proper recipe and tying it the the wic stage using. I then had to resolve this same race and if I remember correctly, the fix looked like this: https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg02458.html Not sure if it applies to your specific situation here. I have not invested much time in the multi-config stuff. I resorted to meta-xilinx-tools a while back, managed to "make it work" in our CI docker environment and have not looked back since. -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components
From: meta-xilinx-boun...@yoctoproject.org
on behalf of Jean-Francois Dagenais
Sent: Saturday, December 8, 2018 4:11:51 AM
To: Alejandro Enedino Hernandez Samaniego
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a
multilib hack to build standalone components
On Dec 6, 2018, at 4:56 PM, Alejandro Enedino Hernandez Samaniego
mailto:alejandro.enedino.hernandez-samani...@xilinx.com>>
wrote:
diff --git a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
index 9cf09ff..6233bc8 100644
--- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
+++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
@@ -65,7 +65,7 @@ python () {
if providesbin and d.getVar("SOC_FAMILY") in ["zynqmp"]:
# depend on the pmu-firmware build
-d.appendVar("DEPENDS", " virtual/pmu-firmware")
+#d.appendVar("DEPENDS", " virtual/pmu-firmware")
Just delete the line, let's not accumulate stale, commented code around.
# determine the path relative to the source tree
relpath =
os.path.relpath(d.expand("${DEPLOY_DIR_IMAGE}/pmu-${MACHINE}.bin"),
d.getVar("S"))
# setup PMU Firmware path via MAKEFLAGS
--
2.7.4
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components
From: meta-xilinx-boun...@yoctoproject.org
on behalf of Jean-Francois Dagenais
Sent: Saturday, December 8, 2018 4:11 AM
To: Alejandro Enedino Hernandez Samaniego
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a
multilib hack to build standalone components
On Dec 6, 2018, at 4:56 PM, Alejandro Enedino Hernandez Samaniego
mailto:alejandro.enedino.hernandez-samani...@xilinx.com>>
wrote:
diff --git a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
index 9cf09ff..6233bc8 100644
--- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
+++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
@@ -65,7 +65,7 @@ python () {
if providesbin and d.getVar("SOC_FAMILY") in ["zynqmp"]:
# depend on the pmu-firmware build
-d.appendVar("DEPENDS", " virtual/pmu-firmware")
+#d.appendVar("DEPENDS", " virtual/pmu-firmware")
Just delete the line, let's not accumulate stale, commented code around.
I assume this dependency would need to be adapted into the multi-config setup,
however I am surprised it is completely removed - it still exists (in case of
SPL) right? Perhaps I am missing it, but I don't see it reintroduced anywhere?
The multi-config setup (as described here:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-November/004087.html),
fails to build 'virtual/bootloader' due to missing PMUFW file:
"Cannot read
../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-pmu.bin"
which is fair enough, since no one requested the build of it. This appears to
be a regression since Sumo, where the dependency indeed was in place (because
of the above definition):
bitbake virtual/bootloader -e | grep ^DEPENDS=
DEPENDS="virtual/aarch64-gomspace-linux-gcc
virtual/aarch64-gomspace-linux-compilerlibs virtual/libc swig-native
python-native bc-native dtc-native openssl-native virtual/pmu-firmware"
It looks to me as Manju's proposal of adding it as an image dependency may work
when building the image, but appears to be subject to a race condition between
pmu-firmware and virtual/bootloader.
Br,
Martin
# determine the path relative to the source tree
relpath =
os.path.relpath(d.expand("${DEPLOY_DIR_IMAGE}/pmu-${MACHINE}.bin"),
d.getVar("S"))
# setup PMU Firmware path via MAKEFLAGS
--
2.7.4
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [[meta-xilinx-bsp][PATCH v2]] device-tree.bb: add missing include path
Ping? Manju?
From: Martin Siegumfeldt
Sent: Thursday, June 21, 2018 2:36 PM
To: meta-xilinx@yoctoproject.org
Cc: Martin Siegumfeldt
Subject: [[meta-xilinx][meta-xilinx-bsp][PATCH v2]] device-tree.bb: add missing
include path
This patch adds a missing include path for generic kernel DTC
includes.
Signed-off-by: Martin Siegumfeldt
Reviewed-by: Nathan Rossi
---
meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
index dc49cbb..d1b6771 100644
--- a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
+++ b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
@@ -30,6 +30,7 @@ SYSROOT_DIRS += "/boot/devicetree"
KERNEL_DTS_INCLUDE ??= " \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/include \
+ ${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
"
# For arm64/zynqmp the xilinx specific includes are subdired under a vendor
directory.
KERNEL_DTS_INCLUDE_append_zynqmp = " \
--
2.14.1
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] [[meta-xilinx-bsp][PATCH v2]] device-tree.bb: add missing include path
This patch adds a missing include path for generic kernel DTC
includes.
Signed-off-by: Martin Siegumfeldt
Reviewed-by: Nathan Rossi
---
meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
index dc49cbb..d1b6771 100644
--- a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
+++ b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
@@ -30,6 +30,7 @@ SYSROOT_DIRS += "/boot/devicetree"
KERNEL_DTS_INCLUDE ??= " \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/include \
+ ${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
"
# For arm64/zynqmp the xilinx specific includes are subdired under a vendor
directory.
KERNEL_DTS_INCLUDE_append_zynqmp = " \
--
2.14.1
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH] device-tree.bb: add missing include path
On 20 June 2018 at 21:14, Martin Siegumfeldt wrote:
> This patch add a missing include path for dt-bindings header-files
> (i.e. gpio, pinctrl etc.)
>
> Signed-off-by: Martin Siegumfeldt
> ---
> meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> index dc49cbb..e01e5b5 100644
> --- a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> +++ b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> @@ -34,6 +34,7 @@ KERNEL_DTS_INCLUDE ??= " \
> # For arm64/zynqmp the xilinx specific includes are subdired under a vendor
>directory.
> KERNEL_DTS_INCLUDE_append_zynqmp = " \
> ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/xilinx \
> + ${STAGING_KERNEL_DIR}/include \
Does "${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes" cover the
includes you are after? Since I don't believe the kernel itself adds
the root include directory for dtc targets.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.lib?h=v4.18-rc1#n167
Regards,
Nathan
Yes it does:
martin@dell:~/work/z7000-distro_sumo/build$ ls -la
tmp/work-shared/nanomind-ultra-zu6eg-uv1/kernel-source/scripts/dtc/include-prefixes/
total 8
drwxr-xr-x 2 martin martin 4096 Jun 20 21:24 .
drwxr-xr-x 4 martin martin 4096 Jun 20 21:24 ..
lrwxrwxrwx 1 martin martin 26 Jun 20 21:24 arc -> ../../../arch/arc/boot/dts
lrwxrwxrwx 1 martin martin 26 Jun 20 21:24 arm -> ../../../arch/arm/boot/dts
lrwxrwxrwx 1 martin martin 28 Jun 20 21:24 arm64 ->
../../../arch/arm64/boot/dts
lrwxrwxrwx 1 martin martin 26 Jun 20 21:24 c6x -> ../../../arch/c6x/boot/dts
lrwxrwxrwx 1 martin martin 27 Jun 20 21:24 cris ->
../../../arch/cris/boot/dts
lrwxrwxrwx 1 martin martin 28 Jun 20 21:24 dt-bindings ->
../../../include/dt-bindings
lrwxrwxrwx 1 martin martin 28 Jun 20 21:24 h8300 ->
../../../arch/h8300/boot/dts
lrwxrwxrwx 1 martin martin 28 Jun 20 21:24 metag ->
../../../arch/metag/boot/dts
lrwxrwxrwx 1 martin martin 33 Jun 20 21:24 microblaze ->
../../../arch/microblaze/boot/dts
lrwxrwxrwx 1 martin martin 27 Jun 20 21:24 mips ->
../../../arch/mips/boot/dts
lrwxrwxrwx 1 martin martin 28 Jun 20 21:24 nios2 ->
../../../arch/nios2/boot/dts
lrwxrwxrwx 1 martin martin 31 Jun 20 21:24 openrisc ->
../../../arch/openrisc/boot/dts
lrwxrwxrwx 1 martin martin 30 Jun 20 21:24 powerpc ->
../../../arch/powerpc/boot/dts
lrwxrwxrwx 1 martin martin 25 Jun 20 21:24 sh -> ../../../arch/sh/boot/dts
lrwxrwxrwx 1 martin martin 29 Jun 20 21:24 xtensa ->
../../../arch/xtensa/boot/dts
martin@dell:~/work/z7000-distro_sumo/build$ file
tmp/work-shared/nanomind-ultra-zu6eg-uv1/kernel-source/include/dt-bindings/gpio/gpio.h
tmp/work-shared/nanomind-ultra-zu6eg-uv1/kernel-source/include/dt-bindings/gpio/gpio.h:
C source, ASCII text
The include part of the device tree being built:
#include "zynqmp.dtsi"
#include "zynqmp-clk-ccf.dtsi"
#include
#include
#include
AFAICS from the Xilinx machines, there are no zynqmp variants utilizing
out-of-tree device trees, only zynq which do not include any of the above
header files. This is why I suspected the scenario to be untested by Xilinx.
Thanks,
Martin
> "
>
> DTS_FILES_PATH ?= "${S}"
> --
> 2.14.1
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] [PATCH] device-tree.bb: add missing include path
This patch add a missing include path for dt-bindings header-files
(i.e. gpio, pinctrl etc.)
Signed-off-by: Martin Siegumfeldt
---
meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
index dc49cbb..e01e5b5 100644
--- a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
+++ b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
@@ -34,6 +34,7 @@ KERNEL_DTS_INCLUDE ??= " \
# For arm64/zynqmp the xilinx specific includes are subdired under a vendor
directory.
KERNEL_DTS_INCLUDE_append_zynqmp = " \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/xilinx \
+ ${STAGING_KERNEL_DIR}/include \
"
DTS_FILES_PATH ?= "${S}"
--
2.14.1
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Generation of psu_init files
Thanks again for responding Luca. Relating to zcu102, it turns out related to the integration of init files - I was originally overwriting the 'new' header file 'arch/arm/include/asm/arch-zynqmp/psu_init_gpl.h'. However, simply adding the Vivado exported header file to 'board/xilinx/zynqmp/zynqmp-zcu102-rev1.0/psu_init_gpl.h' and overwriting the associated existing 'psu_init_gpl.c' yields the SPL generation to succeed. Thanks, Martin From: Luca Ceresoli Sent: Thursday, June 14, 2018 11:16:21 PM To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org Cc: Michal Simek Subject: Re: [meta-xilinx] Generation of psu_init files Hi Martin, On 14/06/2018 21:40, Martin Siegumfeldt wrote: > Thanks Luca, > > > Michal, Manju I appreciate if you could provide some insight into the > plan forward here. On the zcu102 board we are seeing a much improved > QSPI NOR / UBI stack from what is planned to go into the Sumo release. > Unfortunately we can not integrate the init code for our custom board as > exported by any current Vivado version. Is this new structure exported > by an upcoming Vivado release, or how do you expect us to handle this? Strange. I just tried to build the xilinx_zynqmp_zcu106_revA_defconfig config on a mainline U-Boot (v2018.07-rc1-132-g606fddd76c7a), using the psu_init_gpl files from [0] and they built fine. I tried both the latest files (2018.2) and the 2017.1 version. I tried also on current u-boot-xlnx master, it works too. This is expected since the "new format" is nothing but the "old format", which I would rather call the "format produced by Vivado", stripped down of unneeded things such as comments, unused function definitions etc. Can you give some more detail on what you are doing and what happens? What error message do you obtain? Which version of U-Boot? Can you provide your psu_ini_gpl.* files? Your defconfig? [0] https://github.com/Xilinx/hdf-examples Regards, -- Luca -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Generation of psu_init files
Thanks Luca, Michal, Manju I appreciate if you could provide some insight into the plan forward here. On the zcu102 board we are seeing a much improved QSPI NOR / UBI stack from what is planned to go into the Sumo release. Unfortunately we can not integrate the init code for our custom board as exported by any current Vivado version. Is this new structure exported by an upcoming Vivado release, or how do you expect us to handle this? Thanks, Martin From: Luca Ceresoli Sent: Thursday, June 7, 2018 6:10:38 PM To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org Cc: Michal Simek Subject: Re: [meta-xilinx] Generation of psu_init files Hi Martin, On 04/06/2018 21:45, Martin Siegumfeldt wrote: > Hi, > > Since > https://github.com/Xilinx/u-boot-xlnx/commit/a38ad86e46b940dd53cb328ed19761dbb084d6e5#diff-ff33c47fd7e88097b7ebeba1d14fe072 > / > https://github.com/Xilinx/u-boot-xlnx/commit/9fd6056f5329d2d1178ef675f53641461c2e183d#diff-7f268ae597d9cb8d64ad0d46931fdb1b > the psu_init files have changed format. AFAICS, Vivado 2018.1 still outputs > the old format which is also the case for > https://github.com/Xilinx/hdf-examples. What is the process for generating > the files in the new format? I added in Cc Michal Simek who did the commits you mentioned. I think he has a script to convert the "old format" (generated by Vivado) to the "new format", which is basically the same file, with comments and other unneeded code removed. Michal, do you think that script could be published, maybe in mainline U-Boot? Regards, -- Luca -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Generation of psu_init files
Hi Manju, any clues here? The newly pushed 2018.2 release of https://github.com/Xilinx/hdf-examples still seems to describe the init code in the "old format"? Br, Martin From: meta-xilinx-boun...@yoctoproject.org on behalf of Martin Siegumfeldt Sent: Monday, June 4, 2018 9:45:02 PM To: meta-xilinx@yoctoproject.org Subject: [meta-xilinx] Generation of psu_init files Hi, Since https://github.com/Xilinx/u-boot-xlnx/commit/a38ad86e46b940dd53cb328ed19761dbb084d6e5#diff-ff33c47fd7e88097b7ebeba1d14fe072 / https://github.com/Xilinx/u-boot-xlnx/commit/9fd6056f5329d2d1178ef675f53641461c2e183d#diff-7f268ae597d9cb8d64ad0d46931fdb1b the psu_init files have changed format. AFAICS, Vivado 2018.1 still outputs the old format which is also the case for https://github.com/Xilinx/hdf-examples. What is the process for generating the files in the new format? Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Generation of psu_init files
Hi, Since https://github.com/Xilinx/u-boot-xlnx/commit/a38ad86e46b940dd53cb328ed19761dbb084d6e5#diff-ff33c47fd7e88097b7ebeba1d14fe072 / https://github.com/Xilinx/u-boot-xlnx/commit/9fd6056f5329d2d1178ef675f53641461c2e183d#diff-7f268ae597d9cb8d64ad0d46931fdb1b the psu_init files have changed format. AFAICS, Vivado 2018.1 still outputs the old format which is also the case for https://github.com/Xilinx/hdf-examples. What is the process for generating the files in the new format? Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
Hi Nathan, From: Nathan Rossi Sent: Wednesday, May 16, 2018 13:20 To: Martin Siegumfeldt Cc: meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] On 16 May 2018 at 18:24, Martin Siegumfeldt wrote: > Hi Nathan, > > > I don't quite follow you here - the PMU provider of zcu102 is: > > > martin@dell:~/work/petalinux/build$ cat > ../sources/meta-xilinx/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf | > grep PREFERRED_PROVIDER_virtual/pmu > PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware" > > however, it is built using XSDK - from the compile log: > > > + eval xsct > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl > -ws > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build > -pname pmu-firmware -rp > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git > -do_compile 1 You are looking in the wrong work directory for the meta-xilinx-bsp built pmu-firmware. It is under "zcu102_zynqmp-oe-elf" or likely in your setup "zcu102_zynqmp-xilinx-elf". Since the zynqmp-pmu extender has the target os as "elf" due to it being a baremetal build. e.g. work/zcu102_zynqmp-oe-elf/zynqmp-pmu-pmu-firmware/ I am not considering log files but the terminal output: martin@dell:~/work/petalinux/build$ bitbake virtual/pmu-firmware -v | egrep -i xsct + echo cmd is: xsct /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl -ws /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build -pname pmu-firmware -rp /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git -processor psu_pmu_0 -hdf /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf -arch 32 -app "ZynqMP PMU Firmware" -yamlconf /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml cmd is: xsct /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl -ws /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build -pname pmu-firmware -rp /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git -processor psu_pmu_0 -hdf /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf -arch 32 -app "ZynqMP PMU Firmware" -yamlconf /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml + eval xsct /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl -ws /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build -pname pmu-firmware -rp /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git -processor psu_pmu_0 -hdf /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf -arch 32 -app "ZynqMP PMU Firmware" -yamlconf /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml + xsct /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl -ws /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build -pname pmu-firmware -rp /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git -processor psu_pmu_0 -hdf /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf -arch 32 -app ZynqMP PMU Firmware -yamlconf /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml XSCTHELPER INFO: Empty WorkSpace XSCTHELPER INFO: No BSP Configuration + eval xsct /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl -ws /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build -pname pmu-firmware -rp /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa
Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
Hmm, thanks for your input Nathan... Br, Martin From: Nathan Rossi Sent: Wednesday, May 16, 2018 3:01:02 PM To: Martin Siegumfeldt Cc: meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] On 16 May 2018 at 22:43, Martin Siegumfeldt wrote: > So you have a distro configuration overriding a machine defined provider - I > did not see that coming, thanks for pointing that out. It seems to be of > version 2017.3: > > > martin@dell:~/work/petalinux/build$ ll tmp/deploy/images/zcu102-zynqmp/pmu-* > -rw-r--r-- 2 martin martin 129760 May 16 14:34 > tmp/deploy/images/zcu102-zynqmp/pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.bin > -rw-r--r-- 2 martin martin 155572 May 16 14:34 > tmp/deploy/images/zcu102-zynqmp/pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.elf > lrwxrwxrwx 2 martin martin 30 May 16 14:34 > tmp/deploy/images/zcu102-zynqmp/pmu-firmware-zcu102-zynqmp.bin -> > pmu-firmware-zcu102-zynqmp.bin > lrwxrwxrwx 2 martin martin 79 May 16 14:34 > tmp/deploy/images/zcu102-zynqmp/pmu-firmware-zcu102-zynqmp.elf -> > pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.elf > lrwxrwxrwx 2 martin martin 30 May 16 14:34 > tmp/deploy/images/zcu102-zynqmp/pmu-firwmare-zcu102-zynqmp.elf -> > pmu-firmware-zcu102-zynqmp.elf > > , is that expected? I was expecting the same version, just build using > different toolchains. Thats expected, looks like Xilinx did not update it in their rel-v2018.1 release version. https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware/pmu-firmware_2017.3.bb Regards, Nathan > > Br, > Martin > > ____ > From: Nathan Rossi > Sent: Wednesday, May 16, 2018 2:21:03 PM > > To: Martin Siegumfeldt > Cc: meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] > > On 16 May 2018 at 22:01, Martin Siegumfeldt wrote: >> Hi Nathan, >> >> >> >> From: Nathan Rossi >> Sent: Wednesday, May 16, 2018 13:20 >> To: Martin Siegumfeldt >> Cc: meta-xilinx@yoctoproject.org >> Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] >> >> On 16 May 2018 at 18:24, Martin Siegumfeldt wrote: >>> Hi Nathan, >>> >>> >>> I don't quite follow you here - the PMU provider of zcu102 is: >>> >>> >>> martin@dell:~/work/petalinux/build$ cat >>> ../sources/meta-xilinx/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf | >>> grep PREFERRED_PROVIDER_virtual/pmu >>> PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware" >>> >>> however, it is built using XSDK - from the compile log: >>> >>> >>> + eval xsct >>> >>> >>> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl >>> -ws >>> >>> >>> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build >>> -pname pmu-firmware -rp >>> >>> >>> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git >>> -do_compile 1 >> >> You are looking in the wrong work directory for the meta-xilinx-bsp >> built pmu-firmware. It is under "zcu102_zynqmp-oe-elf" or likely in >> your setup "zcu102_zynqmp-xilinx-elf". Since the zynqmp-pmu extender >> has the target os as "elf" due to it being a baremetal build. >> >> e.g. work/zcu102_zynqmp-oe-elf/zynqmp-pmu-pmu-firmware/ >> >> I am not considering log files but the terminal output: >> >> martin@dell:~/work/petalinux/build$ bitbake virtual/pmu-firmware -v | >> egrep >> -i xsct >> + echo cmd is: xsct >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl >> -ws >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build >> -pname pmu-firmware -rp >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git >> -processor psu_pmu_0 -hdf >> >> /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf >> -arch 32 -app "ZynqMP PMU Firmware" -yamlconf >> >> /home/marti
Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
So you have a distro configuration overriding a machine defined provider - I did not see that coming, thanks for pointing that out. It seems to be of version 2017.3: martin@dell:~/work/petalinux/build$ ll tmp/deploy/images/zcu102-zynqmp/pmu-* -rw-r--r-- 2 martin martin 129760 May 16 14:34 tmp/deploy/images/zcu102-zynqmp/pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.bin -rw-r--r-- 2 martin martin 155572 May 16 14:34 tmp/deploy/images/zcu102-zynqmp/pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.elf lrwxrwxrwx 2 martin martin 30 May 16 14:34 tmp/deploy/images/zcu102-zynqmp/pmu-firmware-zcu102-zynqmp.bin -> pmu-firmware-zcu102-zynqmp.bin lrwxrwxrwx 2 martin martin 79 May 16 14:34 tmp/deploy/images/zcu102-zynqmp/pmu-firmware-zcu102-zynqmp.elf -> pmu-firmware--v2017.3+gitAUTOINC+3c9f0cfde9-r0-zcu102-zynqmp-20180516122848.elf lrwxrwxrwx 2 martin martin 30 May 16 14:34 tmp/deploy/images/zcu102-zynqmp/pmu-firwmare-zcu102-zynqmp.elf -> pmu-firmware-zcu102-zynqmp.elf , is that expected? I was expecting the same version, just build using different toolchains. Br, Martin From: Nathan Rossi Sent: Wednesday, May 16, 2018 2:21:03 PM To: Martin Siegumfeldt Cc: meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] On 16 May 2018 at 22:01, Martin Siegumfeldt wrote: > Hi Nathan, > > > > From: Nathan Rossi > Sent: Wednesday, May 16, 2018 13:20 > To: Martin Siegumfeldt > Cc: meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1] > > On 16 May 2018 at 18:24, Martin Siegumfeldt wrote: >> Hi Nathan, >> >> >> I don't quite follow you here - the PMU provider of zcu102 is: >> >> >> martin@dell:~/work/petalinux/build$ cat >> ../sources/meta-xilinx/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf | >> grep PREFERRED_PROVIDER_virtual/pmu >> PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware" >> >> however, it is built using XSDK - from the compile log: >> >> >> + eval xsct >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl >> -ws >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build >> -pname pmu-firmware -rp >> >> /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git >> -do_compile 1 > > You are looking in the wrong work directory for the meta-xilinx-bsp > built pmu-firmware. It is under "zcu102_zynqmp-oe-elf" or likely in > your setup "zcu102_zynqmp-xilinx-elf". Since the zynqmp-pmu extender > has the target os as "elf" due to it being a baremetal build. > > e.g. work/zcu102_zynqmp-oe-elf/zynqmp-pmu-pmu-firmware/ > > I am not considering log files but the terminal output: > > martin@dell:~/work/petalinux/build$ bitbake virtual/pmu-firmware -v | egrep > -i xsct > + echo cmd is: xsct > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl > -ws > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build > -pname pmu-firmware -rp > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git > -processor psu_pmu_0 -hdf > /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf > -arch 32 -app "ZynqMP PMU Firmware" -yamlconf > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml > cmd is: xsct > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl > -ws > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build > -pname pmu-firmware -rp > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git > -processor psu_pmu_0 -hdf > /home/martin/work/petalinux/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf > -arch 32 -app "ZynqMP PMU Firmware" -yamlconf > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/pmu-firmware.yaml > + eval xsct > /home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl >
Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
Hi Nathan,
I don't quite follow you here - the PMU provider of zcu102 is:
martin@dell:~/work/petalinux/build$ cat
../sources/meta-xilinx/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf | grep
PREFERRED_PROVIDER_virtual/pmu
PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware"
however, it is built using XSDK - from the compile log:
+ eval xsct
/home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/app.tcl
-ws
/home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/build
-pname pmu-firmware -rp
/home/martin/work/petalinux/build/tmp/work/zcu102_zynqmp-xilinx-linux/pmu-firmware/2018.1+gitAUTOINC+aaa566bc3f-r0/git
-do_compile 1
martin@dell:~/work/petalinux/build$ ll tmp/deploy/images/zcu102-zynqmp/pmu-*
-rw-r--r-- 2 martin martin 116744 May 15 10:31
tmp/deploy/images/zcu102-zynqmp/pmu-firmware-2018.1+gitAUTOINC+aaa566bc3f-r0-zcu102-zynqmp-20180515083059.elf
lrwxrwxrwx 2 martin martin 77 May 15 10:31
tmp/deploy/images/zcu102-zynqmp/pmu-firmware-zcu102-zynqmp.elf ->
pmu-firmware-2018.1+gitAUTOINC+aaa566bc3f-r0-zcu102-zynqmp-20180515083059.elf
lrwxrwxrwx 2 martin martin 30 May 15 10:31
tmp/deploy/images/zcu102-zynqmp/pmu-zcu102-zynqmp.elf ->
pmu-firmware-zcu102-zynqmp.elf
Br,
Martin
From: Nathan Rossi
Sent: Tuesday, May 15, 2018 6:19:43 PM
To: Martin Siegumfeldt
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
On 15 May 2018 at 20:54, Martin Siegumfeldt wrote:
> Hi,
>
> Based on
> https://github.com/Xilinx/meta-xilinx-tools/commit/a516c3a4a8b29e07233b5f2ecf91a2a3e63a1ff7
> I would like to switch from building the pmu-firmware using the XSDK (i.e.
> through meta-xilinx-tools) to the generated toolchain (i.e. through
> meta-xilinx). However the latter layer seems not (directly at least) to
> provide this:
>
> martin@dell:~/work/tmp/xilinx$ ack ^'PROVIDES = "virtual/pmu-firmware'
> meta-xilinx-tools/ meta-xilinx
> meta-xilinx-tools/recipes-bsp/pmu-firmware/pmu-firmware_git.bb
> 3:PROVIDES = "virtual/pmu-firmware"
>
> Inspecting
> https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware/pmu-firmware_2017.3.bb
>
> provides the following information:
>
> # force this recipe to provide a target virtual/pmu-firmware. this is applied
> # after any class extender mapping and results in this recipe always providing
> # 'virtual/pmu-firmware'.
> python append_target_provides () {
> d.appendVar("PROVIDES", " virtual/pmu-firmware")
> }
This is to work around the recipe only providing
"virtual/zynqmp-pmu-pmu-firmware" since the recipe is only valid for
the microblaze 'multilib'.
>
> which is not exactly clear to me? In any case, the recipes are named the same
> and I don't see how to switch between the providers? I tried deleting
> 'meta-xilinx-tools/recipes-bsp/pmu-firmware/pmu-firmware_git.bb' after which
> the meta-xilinx variant seems to be built but does not boot.
>
> Am I missing something or is the provider concept broken/incomplete?
The preferred provider selection should work, however due to the
naming of the recipes it might be a bit confusing.
To use the pmu-firmware (aka zynqmp-pmu-pmu-firmware) built in oe via
the meta-xilinx-bsp pmu-firmware recipe you should set the provider
like so:
PREFERRED_PROVIDER_virtual/pmu-firmware = "zynqmp-pmu-pmu-firmware"
(like how the zcu102-zynqmp machine does
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L28)
To use the pmu-firmware built using XSDK/xsct via the
meta-xilinx-tools pmu-firmware recipe you should set the provider like
so:
PREFERRED_PROVIDER_virtual/pmu-firmware = "pmu-firmware"
Regards,
Nathan
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Provider of pmu-firmware [rel-v2018.1]
Hi,
Based on
https://github.com/Xilinx/meta-xilinx-tools/commit/a516c3a4a8b29e07233b5f2ecf91a2a3e63a1ff7
I would like to switch from building the pmu-firmware using the XSDK (i.e.
through meta-xilinx-tools) to the generated toolchain (i.e. through
meta-xilinx). However the latter layer seems not (directly at least) to provide
this:
martin@dell:~/work/tmp/xilinx$ ack ^'PROVIDES = "virtual/pmu-firmware'
meta-xilinx-tools/ meta-xilinx
meta-xilinx-tools/recipes-bsp/pmu-firmware/pmu-firmware_git.bb
3:PROVIDES = "virtual/pmu-firmware"
Inspecting
https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware/pmu-firmware_2017.3.bb
provides the following information:
# force this recipe to provide a target virtual/pmu-firmware. this is applied
# after any class extender mapping and results in this recipe always providing
# 'virtual/pmu-firmware'.
python append_target_provides () {
d.appendVar("PROVIDES", " virtual/pmu-firmware")
}
which is not exactly clear to me? In any case, the recipes are named the same
and I don't see how to switch between the providers? I tried deleting
'meta-xilinx-tools/recipes-bsp/pmu-firmware/pmu-firmware_git.bb' after which
the meta-xilinx variant seems to be built but does not boot.
Am I missing something or is the provider concept broken/incomplete?
Br,
Martin
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
Thanks Nathan, It turns out, through further exploration of the SDK, that when the image is built by the individual application developer (i.e. 'devtool build-image) the qemu config is generated relative to the location within the SDK installation folder location and the absolute paths are thus not an issue. For now, the only obstacle for an efficient SDK workflow using the emulator is the missing SSH/SCP access as reported in a different thread. Br, Martin From: Nathan Rossi Sent: Monday, January 29, 2018 1:58:19 PM To: Martin Siegumfeldt Cc: Alistair Francis; meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] qemuboot.conf On 29 January 2018 at 05:51, Martin Siegumfeldt wrote: > > > > > From: Nathan Rossi > Sent: Sunday, January 28, 2018 13:44 > To: Alistair Francis > Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] qemuboot.conf > > On 24 January 2018 at 09:04, Alistair Francis wrote: >> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt >> wrote: >>> Hi, >>> >>> We are rendering a custom piece of HW based on Ultrascale+, and have the >>> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >>> the application developers and to close the loop we would like to be capable >>> of delivering also the QEMU instance. The machine image- and qemuboot.conf >>> is not part of the eSDK and is thus delivered next to the eSDK. >>> Unfortunately, the Xilinx conf file describes a few absolute path variables >>> (caused by e.g. >>> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >>> I believe) prohibiting this conf file to be shared between the application >>> developers. AFACICS, this is in contrast to the generic QEMU machine configs >>> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >>> which only describes relative path variables - I assume this is related to >>> the "custom" Xilinx PMU. > > These are not directly related to the PMU part of QEMU execute, since > that part is executed by runqemu. It is simply that runqemu does not > make generic find/replace with all args, only specific ones. > >>> >>> Do you see any way around these absolute paths, which thus enables >>> directly sharing the QEMU instance with eSDK developers? >> >> All of these files should be in the deploy directory, I don't see any >> reason why they need to be absolute. How do the other configs point to >> the images? > > They need to be absolute because the runqemu script does not rewrite > the paths for those arguments, and in turn with runqemu not executing > with the cwd being the deploy directory it is not known where the > intended path to these files are. > > Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings > that are substituted during runqemu execution. > > http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 > > Unfortunately I don't think there is a good solution to remove these > fields without improving runqemu itself. Since the paths are only > known by runqemu and cannot be relative to an unknown execution > working directory. > > Thanks Nathan, I was kind of expecting this answer - it can fairly easy > worked around with a sed command. However, for the "staging_bindir_native" > variable, is there a reason this is absolute as apposed to the other > "staging_dir_..." variables? AFAICS, other machines describe this variable > in a relative manner? > That is simply a case of qemuboot.bbclass getting changes that are not reflected in the qemuboot-xilinx.bbclass in meta-xilinx. This change in oe-core added relative pathing, http://git.openembedded.org/openembedded-core/commit/?id=55a0028a961c0ad3c2e5729a9e3919cbbf256fe1 But qemuboot-xilinx.bbclass modifies staging_bindir_native to put in the qemu-xilinx-helper-native specific path. Which doesn't do the relative path logic, since it was created before the oe-core change. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/classes/qemuboot-xilinx.bbclass#n20 Please send a patch to fix it if you need the relative paths. Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Ethernet functionality of QEMU (zcu102-zynqmp)
Hi, Are there any limitations regarding the ethernet capabilities of the QEMU instance of the zcu102-zynqmp machine? runqemu seems to allocate IP address to the tap interface, no obvious errors are present from the kernel log, however no IP address is assigned to eth0. I have manually tried to assign address, gateway etc., however I am not able to gain ssh access. The qemux86 seems to automatically gain the 'runqemu' allocated IP address. Similar observations seem reported for Zynq (https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Zynq-QEMU-Network-Issues/td-p/797050) however no definite conclusion seems drawn. Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
From: Nathan Rossi Sent: Sunday, January 28, 2018 13:44 To: Alistair Francis Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] qemuboot.conf On 24 January 2018 at 09:04, Alistair Francis wrote: > On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt > wrote: >> Hi, >> >> We are rendering a custom piece of HW based on Ultrascale+, and have the >> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >> the application developers and to close the loop we would like to be capable >> of delivering also the QEMU instance. The machine image- and qemuboot.conf >> is not part of the eSDK and is thus delivered next to the eSDK. >> Unfortunately, the Xilinx conf file describes a few absolute path variables >> (caused by e.g. >> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >> I believe) prohibiting this conf file to be shared between the application >> developers. AFACICS, this is in contrast to the generic QEMU machine configs >> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >> which only describes relative path variables - I assume this is related to >> the "custom" Xilinx PMU. These are not directly related to the PMU part of QEMU execute, since that part is executed by runqemu. It is simply that runqemu does not make generic find/replace with all args, only specific ones. >> >> Do you see any way around these absolute paths, which thus enables directly >> sharing the QEMU instance with eSDK developers? > > All of these files should be in the deploy directory, I don't see any > reason why they need to be absolute. How do the other configs point to > the images? They need to be absolute because the runqemu script does not rewrite the paths for those arguments, and in turn with runqemu not executing with the cwd being the deploy directory it is not known where the intended path to these files are. Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings that are substituted during runqemu execution. http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 Unfortunately I don't think there is a good solution to remove these fields without improving runqemu itself. Since the paths are only known by runqemu and cannot be relative to an unknown execution working directory. Thanks Nathan, I was kind of expecting this answer - it can fairly easy worked around with a sed command. However, for the "staging_bindir_native" variable, is there a reason this is absolute as apposed to the other "staging_dir_..." variables? AFAICS, other machines describe this variable in a relative manner? Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] qemuboot.conf
Hi, We are rendering a custom piece of HW based on Ultrascale+, and have the Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to the application developers and to close the loop we would like to be capable of delivering also the QEMU instance. The machine image- and qemuboot.conf is not part of the eSDK and is thus delivered next to the eSDK. Unfortunately, the Xilinx conf file describes a few absolute path variables (caused by e.g. https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 I believe) prohibiting this conf file to be shared between the application developers. AFACICS, this is in contrast to the generic QEMU machine configs (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) which only describes relative path variables - I assume this is related to the "custom" Xilinx PMU. Do you see any way around these absolute paths, which thus enables directly sharing the QEMU instance with eSDK developers? Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Device tree generation failure (2017.3)
I am using 'master' of meta-xilinx and meta-xilinx-tools but 'rocko' of poky
and meta-openembedded combined with XSDK 2017.3. It is my intention to switch
to all 'rocko' when Xilinx releases 'rocko'.
Thanks,
Martin
From: Manjukumar Harthikote Matha
Sent: Monday, December 11, 2017 6:18:04 PM
To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Are you using rel-v2017.3 branches from Xilinx?
If not, I think the issue is having KMACHINE instead of SOC_FAMILY.
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xilinx-bootbin.bbclass#L77
Change to SOC_FAMILY instead of KMACHINE.
Thanks,
Manju
> -Original Message-
> From: Martin Siegumfeldt [mailto:m...@gomspace.com]
> Sent: Monday, December 11, 2017 1:50 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Subject: Re: Device tree generation failure (2017.3)
>
> Hmm, next obstacle seems to be the boot.bin generation:
>
> ERROR: core-image-minimal-1.0-r0 do_xilinx_bootbin: Function failed:
> do_xilinx_bootbin (log file is located at
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
> ERROR: Logfile of failure stored in:
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057
> Log data follows:
> | DEBUG: Executing shell function do_xilinx_bootbin
> | ERROR: syntax error
> | ... bif -arch -w -o BOOT.bin
> | ^^
> |
> | [ERROR] : Command line parsing failed with code 1
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_xilinx_bootbin (log file is located at
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
>
>
> the logfile contains no more information.
>
>
>
>
> It looks like bootgen is complaining about missing the 'arch' parameter.
> Forcing this
> into 'zynqmp' rather than '${KMACHINE}' from the recipe enables BOOT.bin to be
> generated.
>
>
>
>
> AFAICS, it occurs also for the zcu102 machine - any ideas?
>
>
>
>
> Cheers,
>
> Martin
>
>
>
>
>
> From: meta-xilinx-boun...@yoctoproject.org boun...@yoctoproject.org> on behalf of Martin Siegumfeldt
>
> Sent: Friday, December 8, 2017 22:11
> To: Manjukumar Harthikote Matha; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] Device tree generation failure (2017.3)
>
>This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing <http://aka.ms/LearnAboutSpoofing>
> Feedback <http://aka.ms/SafetyTipsFeedback>
>
> Ok sounds good - looking forwards to it...
>
>
>
>
> Cheers,
>
> Martin
>
>
>
> From: Manjukumar Harthikote Matha
> Sent: Friday, December 8, 2017 10:02:18 PM
> To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
> Subject: RE: Device tree generation failure (2017.3)
>
>
> Hi Martin,
>
>
>
> Yes we are looking into it actively, including possible changes to xsct tool
> itself.
>
>
>
> One patch which includes /usr/bin also works, we are more leaning towards this
> patch.
>
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html
> <https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html>
>
>
>
> I am thinking to limit the path append to places where xsct is being invoked
> instead
> of it being append by the layer completely.
>
>
>
> Please let me know your feedback.
>
>
>
> Thanks,
>
> Manju
>
>
>
>
>
> From: Martin Siegumfeldt [mailto:m...@gomspace.com]
> Sent: Friday, December 08, 2017 12:57 PM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Subject: Re: Device tree generation failure (2017.3)
>
>
>
> Hi Manju,
>
>
>
> It is (almost) empty:
>
>
>
> martin@martin-Precision-5510:~/work/rocko/build$ cat
> /home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-
> linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-
> generation.yaml
> {}
>
>
>
> Setting 'YAML_MAIN_MEMORY_CONFIG' seems to enable the DTG to succeed -
> thanks.
>
>
>
> Btw., are there any intentions of a proper fix for the missing DISPLAY
> variable from
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-September/003162.html
> <https://lists.yoctoproject.org/pip
Re: [meta-xilinx] Device tree generation failure (2017.3)
Ok, thx
From: Manjukumar Harthikote Matha
Sent: Monday, December 11, 2017 8:25:43 PM
To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
We will send out the patches for meta-xilinx-tools to use SOC_FAMLIY instead of
KMACHINE.
Thanks,
Manju
From: Martin Siegumfeldt [mailto:m...@gomspace.com]
Sent: Monday, December 11, 2017 11:18 AM
To: Manjukumar Harthikote Matha ;
meta-xilinx@yoctoproject.org
Subject: Re: Device tree generation failure (2017.3)
I am using 'master' of meta-xilinx and meta-xilinx-tools but 'rocko' of poky
and meta-openembedded combined with XSDK 2017.3. It is my intention to switch
to all 'rocko' when Xilinx releases 'rocko'.
Thanks,
Martin
From: Manjukumar Harthikote Matha
mailto:manju...@xilinx.com>>
Sent: Monday, December 11, 2017 6:18:04 PM
To: Martin Siegumfeldt;
meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Are you using rel-v2017.3 branches from Xilinx?
If not, I think the issue is having KMACHINE instead of SOC_FAMILY.
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xilinx-bootbin.bbclass#L77
Change to SOC_FAMILY instead of KMACHINE.
Thanks,
Manju
> -Original Message-
> From: Martin Siegumfeldt [mailto:m...@gomspace.com]
> Sent: Monday, December 11, 2017 1:50 AM
> To: Manjukumar Harthikote Matha
> mailto:manju...@xilinx.com>>; meta-
> xil...@yoctoproject.org<mailto:xil...@yoctoproject.org>
> Subject: Re: Device tree generation failure (2017.3)
>
> Hmm, next obstacle seems to be the boot.bin generation:
>
> ERROR: core-image-minimal-1.0-r0 do_xilinx_bootbin: Function failed:
> do_xilinx_bootbin (log file is located at
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
> ERROR: Logfile of failure stored in:
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057
> Log data follows:
> | DEBUG: Executing shell function do_xilinx_bootbin
> | ERROR: syntax error
> | ... bif -arch -w -o BOOT.bin
> | ^^
> |
> | [ERROR] : Command line parsing failed with code 1
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_xilinx_bootbin (log file is located at
> /home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-
> image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
>
>
> the logfile contains no more information.
>
>
>
>
> It looks like bootgen is complaining about missing the 'arch' parameter.
> Forcing this
> into 'zynqmp' rather than '${KMACHINE}' from the recipe enables BOOT.bin to be
> generated.
>
>
>
>
> AFAICS, it occurs also for the zcu102 machine - any ideas?
>
>
>
>
> Cheers,
>
> Martin
>
>
>
>
>
> From:
> meta-xilinx-boun...@yoctoproject.org<mailto:meta-xilinx-boun...@yoctoproject.org>
> boun...@yoctoproject.org<mailto:boun...@yoctoproject.org>> on behalf of
> Martin Siegumfeldt
> mailto:m...@gomspace.com>>
> Sent: Friday, December 8, 2017 22:11
> To: Manjukumar Harthikote Matha;
> meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
> Subject: Re: [meta-xilinx] Device tree generation failure (2017.3)
>
>This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing <http://aka.ms/LearnAboutSpoofing>
> Feedback <http://aka.ms/SafetyTipsFeedback>
>
> Ok sounds good - looking forwards to it...
>
>
>
>
> Cheers,
>
> Martin
>
>
>
> From: Manjukumar Harthikote Matha
> mailto:manju...@xilinx.com>>
> Sent: Friday, December 8, 2017 10:02:18 PM
> To: Martin Siegumfeldt;
> meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
> Subject: RE: Device tree generation failure (2017.3)
>
>
> Hi Martin,
>
>
>
> Yes we are looking into it actively, including possible changes to xsct tool
> itself.
>
>
>
> One patch which includes /usr/bin also works, we are more leaning towards this
> patch.
>
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html
> <https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html>
>
>
>
> I am thinking to limit the path append to places where xsct is being invoked
> instead
> of it being append by the layer completely.
>
>
>
> Ple
Re: [meta-xilinx] Device tree generation failure (2017.3)
Hmm, next obstacle seems to be the boot.bin generation:
ERROR: core-image-minimal-1.0-r0 do_xilinx_bootbin: Function failed:
do_xilinx_bootbin (log file is located at
/home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
ERROR: Logfile of failure stored in:
/home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057
Log data follows:
| DEBUG: Executing shell function do_xilinx_bootbin
| ERROR: syntax error
| ... bif -arch -w -o BOOT.bin
| ^^
|
| [ERROR] : Command line parsing failed with code 1
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_xilinx_bootbin (log file is located at
/home/martin/work/tmp/build/tmp/work/zcu102_zynqmp-poky-linux/core-image-minimal/1.0-r0/temp/log.do_xilinx_bootbin.14057)
the logfile contains no more information.
It looks like bootgen is complaining about missing the 'arch' parameter.
Forcing this into 'zynqmp' rather than '${KMACHINE}' from the recipe enables
BOOT.bin to be generated.
AFAICS, it occurs also for the zcu102 machine - any ideas?
Cheers,
Martin
From: meta-xilinx-boun...@yoctoproject.org
on behalf of Martin Siegumfeldt
Sent: Friday, December 8, 2017 22:11
To: Manjukumar Harthikote Matha; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Device tree generation failure (2017.3)
This sender failed our fraud detection checks and may not be who they appear to
be. Learn about spoofing<http://aka.ms/LearnAboutSpoofing>
Feedback<http://aka.ms/SafetyTipsFeedback>
Ok sounds good - looking forwards to it...
Cheers,
Martin
From: Manjukumar Harthikote Matha
Sent: Friday, December 8, 2017 10:02:18 PM
To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Yes we are looking into it actively, including possible changes to xsct tool
itself.
One patch which includes /usr/bin also works, we are more leaning towards this
patch.
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html
I am thinking to limit the path append to places where xsct is being invoked
instead of it being append by the layer completely.
Please let me know your feedback.
Thanks,
Manju
From: Martin Siegumfeldt [mailto:m...@gomspace.com]
Sent: Friday, December 08, 2017 12:57 PM
To: Manjukumar Harthikote Matha ;
meta-xilinx@yoctoproject.org
Subject: Re: Device tree generation failure (2017.3)
Hi Manju,
It is (almost) empty:
martin@martin-Precision-5510:~/work/rocko/build$ cat
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
{}
Setting 'YAML_MAIN_MEMORY_CONFIG' seems to enable the DTG to succeed - thanks.
Btw., are there any intentions of a proper fix for the missing DISPLAY variable
from
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-September/003162.html
(5) ? Your proposal worked for me, however soon there will be a larger team
within my organization working on this particular baseline and an "upstream"
fix is thus highly appreciated.
Thanks,
Martin
From: Manjukumar Harthikote Matha
mailto:manju...@xilinx.com>>
Sent: Friday, December 8, 2017 8:40:02 PM
To: Martin Siegumfeldt;
meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Can you check if this is empty?
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
We have a bug when this file is empty it causes DTG recipe to fail, I will send
out a patch soon
You can set either YAML_MAIN_MEMORY_CONFIG or YAML_CONSOLE_DEVICE_CONFIG as a
workaround
For example:
https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25
[https://avatars0.githubusercontent.com/u/3189299?s=400&v=4]<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
Xilinx/meta-xilinx-tools<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
github.com
Contribute to meta-xilinx-tools development by creating an account on GitHub.
Thanks,
Manju
From:
meta-xilinx-boun...@yoctoproject.org<mailto:meta-xilinx-boun...@yoctoproject.org>
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Martin Siegumfeldt
Sent: Friday, December 08, 2017 7:07 AM
To: meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: [meta-xilinx] Device tre
Re: [meta-xilinx] Device tree generation failure (2017.3)
Hi Manju,
It is (almost) empty:
martin@martin-Precision-5510:~/work/rocko/build$ cat
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
{}
Setting 'YAML_MAIN_MEMORY_CONFIG' seems to enable the DTG to succeed - thanks.
Btw., are there any intentions of a proper fix for the missing DISPLAY variable
from
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-September/003162.html
(5) ? Your proposal worked for me, however soon there will be a larger team
within my organization working on this particular baseline and an "upstream"
fix is thus highly appreciated.
Thanks,
Martin
From: Manjukumar Harthikote Matha
Sent: Friday, December 8, 2017 8:40:02 PM
To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Can you check if this is empty?
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
We have a bug when this file is empty it causes DTG recipe to fail, I will send
out a patch soon
You can set either YAML_MAIN_MEMORY_CONFIG or YAML_CONSOLE_DEVICE_CONFIG as a
workaround
For example:
https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25
[https://avatars0.githubusercontent.com/u/3189299?s=400&v=4]<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
Xilinx/meta-xilinx-tools<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
github.com
Contribute to meta-xilinx-tools development by creating an account on GitHub.
Thanks,
Manju
From: meta-xilinx-boun...@yoctoproject.org
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Martin Siegumfeldt
Sent: Friday, December 08, 2017 7:07 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Device tree generation failure (2017.3)
Hi,
I am struggling with device tree generation (using meta-xilinx-tools) of a
custom machine pretty much replicating zcu102, which in turn generates device
tree successfully. local.conf defines version 2017.3 and a local HDF file:
XILINX_VER_MAIN = "2017.3"
EXTERNAL_TOOLCHAIN_microblaze =
"/opt/Xilinx/SDK/2017.3/gnu/microblaze/linux_toolchain/lin64_le"
XILINX_SDK_TOOLCHAIN = "/opt/Xilinx/SDK/${XILINX_VER_MAIN}"
HDF_BASE = "file://"
HDF_PATH = "${TOPDIR}/../meta-z7000/recipes-bsp/system.hdf"
Please consider below error:
martin@martin-Precision-5510:~/work/rocko/build$ MACHINE="nanomind-zcu102"
bitbake device-tree-generation
Loading cache: 100%
||
Time: 0:00:00
Loaded 261 entries from dependency cache.
##| Time: 0:00:36
Parsing of 1961 .bb files complete (160 cached, 1801 parsed). 2777 targets, 309
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.36.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-17.04"
TARGET_SYS= "aarch64-oe-linux"
MACHINE = "nanomind-zcu102"
DISTRO= "gomspace"
DISTRO_VERSION= "2.0"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-poky = "rocko:f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284"
meta-xilinx = "master:eb16f4088bf2043501abcea6d2beea91349574b3"
meta-xilinx-tools = "master:1063db48e44d5098590d39fe0018be5bb21a0a6d"
meta-oe
meta-filesystems
meta-networking
meta-python = "rocko:6e3fc5b8d904d06e3aa77e9ec9968ab37a798188"
meta-z7000= "rocko:f2c81712c48725820ed2600a669d1614095445d5"
Initialising tasks: 100%
|###|
Time: 0:00:00
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: device-tree-generation-xilinx+gitAUTOINC+5b21302249-r0 do_configure:
Function failed: do_configure (log file is located at
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/temp/log.do_configure.30813)
ERROR: Logfile of failure stored in:
/home/martin/work/rocko/buil
Re: [meta-xilinx] Device tree generation failure (2017.3)
Ok sounds good - looking forwards to it...
Cheers,
Martin
From: Manjukumar Harthikote Matha
Sent: Friday, December 8, 2017 10:02:18 PM
To: Martin Siegumfeldt; meta-xilinx@yoctoproject.org
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Yes we are looking into it actively, including possible changes to xsct tool
itself.
One patch which includes /usr/bin also works, we are more leaning towards this
patch.
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-July/003027.html
I am thinking to limit the path append to places where xsct is being invoked
instead of it being append by the layer completely.
Please let me know your feedback.
Thanks,
Manju
From: Martin Siegumfeldt [mailto:m...@gomspace.com]
Sent: Friday, December 08, 2017 12:57 PM
To: Manjukumar Harthikote Matha ;
meta-xilinx@yoctoproject.org
Subject: Re: Device tree generation failure (2017.3)
Hi Manju,
It is (almost) empty:
martin@martin-Precision-5510:~/work/rocko/build$ cat
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
{}
Setting 'YAML_MAIN_MEMORY_CONFIG' seems to enable the DTG to succeed - thanks.
Btw., are there any intentions of a proper fix for the missing DISPLAY variable
from
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-September/003162.html
(5) ? Your proposal worked for me, however soon there will be a larger team
within my organization working on this particular baseline and an "upstream"
fix is thus highly appreciated.
Thanks,
Martin
From: Manjukumar Harthikote Matha
mailto:manju...@xilinx.com>>
Sent: Friday, December 8, 2017 8:40:02 PM
To: Martin Siegumfeldt;
meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: RE: Device tree generation failure (2017.3)
Hi Martin,
Can you check if this is empty?
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
We have a bug when this file is empty it causes DTG recipe to fail, I will send
out a patch soon
You can set either YAML_MAIN_MEMORY_CONFIG or YAML_CONSOLE_DEVICE_CONFIG as a
workaround
For example:
https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25
[https://avatars0.githubusercontent.com/u/3189299?s=400&v=4]<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
Xilinx/meta-xilinx-tools<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L24-L25>
github.com
Contribute to meta-xilinx-tools development by creating an account on GitHub.
Thanks,
Manju
From:
meta-xilinx-boun...@yoctoproject.org<mailto:meta-xilinx-boun...@yoctoproject.org>
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Martin Siegumfeldt
Sent: Friday, December 08, 2017 7:07 AM
To: meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: [meta-xilinx] Device tree generation failure (2017.3)
Hi,
I am struggling with device tree generation (using meta-xilinx-tools) of a
custom machine pretty much replicating zcu102, which in turn generates device
tree successfully. local.conf defines version 2017.3 and a local HDF file:
XILINX_VER_MAIN = "2017.3"
EXTERNAL_TOOLCHAIN_microblaze =
"/opt/Xilinx/SDK/2017.3/gnu/microblaze/linux_toolchain/lin64_le"
XILINX_SDK_TOOLCHAIN = "/opt/Xilinx/SDK/${XILINX_VER_MAIN}"
HDF_BASE = "file://"
HDF_PATH = "${TOPDIR}/../meta-z7000/recipes-bsp/system.hdf"
Please consider below error:
martin@martin-Precision-5510:~/work/rocko/build$ MACHINE="nanomind-zcu102"
bitbake device-tree-generation
Loading cache: 100%
||
Time: 0:00:00
Loaded 261 entries from dependency cache.
##| Time: 0:00:36
Parsing of 1961 .bb files complete (160 cached, 1801 parsed). 2777 targets, 309
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.36.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-17.04"
TARGET_SYS= "aarch64-oe-linux"
MACHINE = "nanomind-zcu102"
DISTRO= "gomspace"
DISTRO_VERSION= "2.0"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-p
[meta-xilinx] Device tree generation failure (2017.3)
Hi,
I am struggling with device tree generation (using meta-xilinx-tools) of a
custom machine pretty much replicating zcu102, which in turn generates device
tree successfully. local.conf defines version 2017.3 and a local HDF file:
XILINX_VER_MAIN = "2017.3"
EXTERNAL_TOOLCHAIN_microblaze =
"/opt/Xilinx/SDK/2017.3/gnu/microblaze/linux_toolchain/lin64_le"
XILINX_SDK_TOOLCHAIN = "/opt/Xilinx/SDK/${XILINX_VER_MAIN}"
HDF_BASE = "file://"
HDF_PATH = "${TOPDIR}/../meta-z7000/recipes-bsp/system.hdf"
Please consider below error:
martin@martin-Precision-5510:~/work/rocko/build$ MACHINE="nanomind-zcu102"
bitbake device-tree-generation
Loading cache: 100%
||
Time: 0:00:00
Loaded 261 entries from dependency cache.
##| Time: 0:00:36
Parsing of 1961 .bb files complete (160 cached, 1801 parsed). 2777 targets, 309
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.36.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "ubuntu-17.04"
TARGET_SYS= "aarch64-oe-linux"
MACHINE = "nanomind-zcu102"
DISTRO= "gomspace"
DISTRO_VERSION= "2.0"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-poky = "rocko:f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284"
meta-xilinx = "master:eb16f4088bf2043501abcea6d2beea91349574b3"
meta-xilinx-tools = "master:1063db48e44d5098590d39fe0018be5bb21a0a6d"
meta-oe
meta-filesystems
meta-networking
meta-python = "rocko:6e3fc5b8d904d06e3aa77e9ec9968ab37a798188"
meta-z7000= "rocko:f2c81712c48725820ed2600a669d1614095445d5"
Initialising tasks: 100%
|###|
Time: 0:00:00
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: device-tree-generation-xilinx+gitAUTOINC+5b21302249-r0 do_configure:
Function failed: do_configure (log file is located at
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/temp/log.do_configure.30813)
ERROR: Logfile of failure stored in:
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/temp/log.do_configure.30813
Log data follows:
| DEBUG: Executing shell function do_configure
| MISC_ARG is -yamlconf
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
| APP_ARG is -app "device-tree"
| cmd is: xsct
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/dtgen.tcl
-ws
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/build
-pname device-tree-generation -rp
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/git
-processor psu_cortexa53_0 -hdf
/home/martin/work/rocko/build/tmp-glibc/deploy/images/nanomind-zcu102/Xilinx-nanomind-zcu102.hdf
-arch 64 -app "device-tree" -yamlconf
/home/martin/work/rocko/build/tmp-glibc/work/nanomind_zcu102-oe-linux/device-tree-generation/xilinx+gitAUTOINC+5b21302249-r0/device-tree-generation.yaml
| WARNING: [Hsi 55-1434] Error
/opt/Xilinx/SDK/2017.3/data/embeddedsw/XilinxProcessorIPLib/drivers/rfdc_v2_1/data/rfdc.mdd:49
Unrecognized Option name. List of possible Option names are : DRC, DESC,
COPYFILES, DEPENDS, SUPPORTED_PERIPHERALS, DRIVER_STATE, DEFAULT_OS, NAME,
VERSION
|
| INFO: [Hsi 55-1698] elapsed time for repository loading 0 seconds
| hsi::open_hw_design: Time (s): cpu = 00:00:06 ; elapsed = 00:00:06 . Memory
(MB): peak = 475.559 ; gain = 136.270 ; free physical = 10766 ; free virtual =
51512
| {} is not a huddle.
| while executing
| "error "\{$src\} is not a huddle.""
| (procedure "checkHuddle" line 3)
| invoked from within
| "checkHuddle $src"
| (procedure "::huddle::type" line 2)
| invoked from within
| "::huddle::type {}"
| ("eval" body line 1)
| invoked from within
| "eval ::huddle::$command $args"
| (procedure "huddle" line 19)
| invoked from within
| "huddle type $value"
| (procedure "_composePlain" line 2)
| invoked from within
| "_composePlain $result"
| (procedure "_parseBlockNode" line 118)
| invoked from within
| "_parseBlockNode"
| (procedure "::yaml::yaml2dict" line 4)
| invoked from within
| "::yaml::yaml2dict -file $yamlconf"
|
[meta-xilinx] QSPI Issues related to Linux 4.9
Hi, I recently updated the Linux kernel for a custom board based on z7k from Xilinx version 4.6 to 4.9, and spend a few days debugging issues related to the QSPI flash (n25q512a13). By coincidence I stumbled upon https://github.com/topic-embedded-products/linux/commit/8f89736e4e4c116b442f56b3414c33b36f99bc18#diff-49f4e70fe9e60ff773b57164b9e03dbb (thanks Mike) which resolved the issue. It looks like this commit has been left out during the 4.9 transition. Since I am apparently not the only one encountering this issue I wonder if this is planned fixed upstream (upstream as in the Xilinx fork I mean) Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Build error with latest pyro (Could not inherit file classes/image_types_uboot.bbclass)
From: meta-xilinx-boun...@yoctoproject.org on behalf of Peter Smith Sent: Tuesday, November 14, 2017 10:04:30 AM To: meta-xilinx@yoctoproject.org Subject: [meta-xilinx] Build error with latest pyro (Could not inherit file classes/image_types_uboot.bbclass) With the latest commits on the pyro branch of poky, meta-openembedded and meta-xilinx, I get the error : Could not inherit file classes/image_types_uboot.bbclass when bitbakin'g core-image-minimal. I think this is something to do with IMAGES_CLASSES needing modification in the meta-xilinx machine definitions, but i'm no expert. Hi Peter, I believe this is fixed on master branch: https://github.com/Xilinx/meta-xilinx/commit/07783c3cea24768ffc08d9102de6ae0c666a841e Br, Martin Best Regards Peter -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Rocko Release of meta-xilinx
From: Nathan Rossi Sent: Monday, November 6, 2017 17:36 To: Martin Siegumfeldt Cc: meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] Rocko Release of meta-xilinx On 6 November 2017 at 22:15, Martin Siegumfeldt wrote: > Hi, > > Is there a time schedule of when the Rocko release of meta-xilinx will be > available? Hi Martin, There is no scheduled date, but the goal is to have a release branch available at the latest 1 month after the respective OE/Yocto release is made. Which would be the end of November. However the current master of meta-xilinx should work with rocko, though changes are still being made to master at the moment. Regards, Nathan Thanks > > Thanks, > Martin > -- > ___ > meta-xilinx mailing list > meta-xilinx@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-xilinx Thanks I'll play around with master and keep an eye on the mailing list at the end of the month. Br, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Rocko Release of meta-xilinx
Hi, Is there a time schedule of when the Rocko release of meta-xilinx will be available? Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] How to boot the ZynqMP?
Thanks Manju, I now have it building and it also seems to boot the artifacts. The missing display-variable exporting and the potentially also the missing reference to the tools-variant of the device-tree-generation seems to be the culprit. Br, Martin From: Manjukumar Harthikote Matha Sent: Friday, September 1, 2017 04:40 To: Manjukumar Harthikote Matha; Mike Looijmans; Brian Hutchinson; Martin Siegumfeldt Cc: meta-xilinx@yoctoproject.org Subject: RE: [meta-xilinx] How to boot the ZynqMP? Hi All, Sorry for writing on top. I wanted to summarize the flow which worked for me without meta-petalinux layer. I have poky, meta-xilinx, meta-openembedded and meta-xilinx-tools (all on master branch) If you have a build, please make sure to cleansstate fsbl,pmu-firmware, device-tree-generation, bitstream-extraction recipes before you start 1) Make sure you have meta-oe and meta-python in bblayers.conf (Will apply Mike's patch on meta-xilinx-tools) 2)Either copy https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc to local.conf or include this file from your custom machine 3) Provide the HDF file using a) Local path: HDF_BASE = "file://" HDF_PATH = "/system.hdf" b) Or using git https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/hdf/external-hdf.bb#L9-L10 4) Provide the path to the installed XSDK in local.conf XILINX_SDK_TOOLCHAIN = "" 5) I had to add export DISPLAY=:1 before this line here https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L48 and https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L56 https://avatars0.githubusercontent.com/u/3189299?v=4&s=400 Xilinx/meta-xilinx-tools github.com Contribute to meta-xilinx-tools development by creating an account on GitHub. We did not observe this issue in Morty, seems to have changed in Pyro or master. I am still checking how to make a patch using WHITELIST rather than above approach. Any suggestions? 6) there are two device-tree recipes one in meta-xilinx and one meta-xilinx-tools, set the preferred provider to one in meta-xilinx-tools in local.conf PREFERRED_PROVIDER_virtual/dtb ?= "device-tree-generation" 7) bitbake the image Once the image builds you see the following BOOT.bin (this will contain fsbl, pmu, atf, bitstream and u-boot) fsbl-.elf pmu-firmware-.elf -system.dts (DTG generated dts using the HDF provided) -system.dtb (DTG generated dtb using the HDF provided) Other images pmu- is from meta-xilinx recipe Thanks, Manju > -Original Message- > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx- > boun...@yoctoproject.org] On Behalf Of Manjukumar Harthikote Matha > Sent: Thursday, August 31, 2017 2:33 PM > To: Mike Looijmans ; Brian Hutchinson > > Cc: meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] How to boot the ZynqMP? > > [This sender failed our fraud detection checks and may not be who they appear > to > be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > Hi Mike, > > > -Original Message- > > From: Mike Looijmans [mailto:mike.looijm...@topic.nl] > > Sent: Thursday, August 31, 2017 10:52 AM > > To: Brian Hutchinson ; Manjukumar Harthikote > > Matha > > Cc: Giordon Stark ; Jean-Francois Dagenais > > ; meta-xilinx@yoctoproject.org > > Subject: Re: [meta-xilinx] How to boot the ZynqMP? > > > > On 30-08-17 22:20, Brian Hutchinson wrote: > > > I too have been wrestling with generating the required images to > > > boot the > > > ZCU102 from SD Card using the Yocto + meta-xilinx + meta-xilinx-tools > > > method. > > > > > > I'm totally striking out. And I'm working with a Xilinx FAE and > > > striking out! No problem at all doing this kind of thing for ZCU107 > > > or Zedboard but > > > ZCU102 is different beast for sure. > > > > > > I have Ubuntu 16.04 box, I've tried yocto 2.2.1 (morty) and 2.3 > > > (pyro) and I get the same result ... my builds die with: > > > > > ... > > > | DEBUG: Executing shell function do_deploy > > > | install: cannot stat > > > '/home/hutch/yocto_2.2.1- > > morty_zcu102/layers/poky/build/tmp/work/zcu102_zynqmp-poky-linux/pmu- > > firmware/2017.1+gitAUTOINC+122565ec40-r0/build/pmu-firmware/Release/pm > > u- > > firmware.elf': > > > No such file or directory > > > > > > Most likely the problem is that the "Release" directory was not > > created yet. I have seen this race condition several times in makefiles. > > As a workaround, add a do_compile_prepend with
[meta-xilinx] meta-xilinx-tools fails on "device-tree-generation" script
Hi, I am seeing the same issue, despite xvfb being installed. I am able run xsdb/xsdk outside the build context. martin@martin-Precision-5510:~/work/zcu102_os/build$ bitbake core-image-minimal Parsing recipes: 100% |##| Time: 0:00:51 Parsing of 1799 .bb files complete (0 cached, 1799 parsed). 2597 targets, 167 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.35.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "ubuntu-17.04" TARGET_SYS = "aarch64-poky-linux" MACHINE = "zcu102-zynqmp" DISTRO = "poky" DISTRO_VERSION = "2.3+snapshot-20170831" TUNE_FEATURES = "aarch64" TARGET_FPU = "" meta meta-poky = "master:489e2e3243d7acdcb9c1f9de110139b6636d5594" meta-oe meta-python = "master:28d2c9b4474844516a9e8328bb497cdf3bec88ef" meta-xilinx = "master:74a0d90e52cca346d05a69bbd628c6ec9e49fbcb" meta-xilinx-tools = "master:34e96ca0dfd2cfe101d07bc6db06fc9ae1629ce4" NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.7/x86_64-nativesdk-libc.tar.bz2;sha256sum=ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e [10]+ Stopped bitbake core-image-minimal martin@martin-Precision-5510:~/work/zcu102_os/build$ vim ../meta-xilinx/conf/machine/include/machine-xilinx-default.inc martin@martin-Precision-5510:~/work/zcu102_os/build$ fg bitbake core-image-minimal Initialising tasks: 100% |###| Time: 0:00:02 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks Currently 2 rCurrently 2 running tasks (1514 of 2461) 61% |### ERROR: device-tree-generation-xilinx+gitAUTOINC+43551819a1-r0 do_compile: Function failed: do_compile (log file is located at /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.18302) ERROR: Logfile of failure stored in: /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.18302 Log data follows: | DEBUG: Executing shell function do_compile | gcc: error: /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build/device-tree-generation/system-top.dts: No such file or directory | gcc: warning: ‘-x assembler-with-cpp’ after last input file has no effect | gcc: fatal error: no input files | compilation terminated. | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.18302) ERROR: Task (/home/martin/work/zcu102_os/poky/../meta-xilinx-tools/recipes-bsp/device-tree/device-tree-generation_git.bb:do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 1719 tasks of which 6 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/martin/work/zcu102_os/poky/../meta-xilinx-tools/recipes-bsp/device-tree/device-tree-generation_git.bb:do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. martin@martin-Precision-5510:~/work/zcu102_os/build$ cat /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_configure DEBUG: Executing shell function do_configure MISC_ARG is -yamlconf /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/device-tree-generation.yaml APP_ARG is -app "device-tree" cmd is: xsct /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/dtgen.tcl -ws /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build -pname device-tree-generation -rp /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/git -processor psu_cortexa53_0 -hdf /home/martin/work/zcu102_os/build/tmp/deploy/images/zcu102-zynqmp/Xilinx-zcu102-zynqmp.hdf -arch 64 -app "device-tree" -yamlconf /home/martin/work/zcu102_os/build/tmp/work/zcu102_zynqmp-poky-l
