Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

Re: [meta-xilinx] Generation of psu_init files

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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]

[Martin Siegumfeldt]

Hi Nathan,


From: Nathan Rossi <nat...@nathanrossi.com>
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 <m...@gomspace.com> 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-xil

Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]

[Martin Siegumfeldt]

Hmm, thanks for your input Nathan...


Br,

Martin


From: Nathan Rossi <nat...@nathanrossi.com>
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 <m...@gomspace.com> 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 <nat...@nathanrossi.com>
> 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 <m...@gomspace.com> wrote:
>> Hi Nathan,
>>
>>
>> 
>> From: Nathan Rossi <nat...@nathanrossi.com>
>> 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 <m...@gomspace.com> 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/petalinu

Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]

[Martin Siegumfeldt]

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 <nat...@nathanrossi.com>
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 <m...@gomspace.com> wrote:
> Hi Nathan,
>
>
> 
> From: Nathan Rossi <nat...@nathanrossi.com>
> 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 <m...@gomspace.com> 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/peta

Re: [meta-xilinx] Provider of pmu-firmware [rel-v2018.1]

[Martin Siegumfeldt]

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 <nat...@nathanrossi.com>
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 <m...@gomspace.com> 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]

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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 <nat...@nathanrossi.com>
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 <m...@gomspace.com> wrote:
>
>
>
> 
> From: Nathan Rossi <nat...@nathanrossi.com>
> 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 <alistai...@gmail.com> wrote:
>> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt <m...@gomspace.com>
>> 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)

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

From: Nathan Rossi <nat...@nathanrossi.com>
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 <alistai...@gmail.com> wrote:
> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt <m...@gomspace.com> 
> 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

[Martin Siegumfeldt]

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)

[Martin Siegumfeldt]

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 <manju...@xilinx.com>
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 <manju...@xilinx.com>; 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
> <m...@gomspace.com>
> 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 <manju...@xilinx.com>
> 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 <manju...@xilinx.com>; 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-Sep

Re: [meta-xilinx] Device tree generation failure (2017.3)

[Martin Siegumfeldt]

Ok, thx


From: Manjukumar Harthikote Matha <manju...@xilinx.com>
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 <manju...@xilinx.com>; 
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 
<manju...@xilinx.com<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 
> <manju...@xilinx.com<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
> <m...@gomspace.com<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 
> <manju...@xilinx.com<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

Re: [meta-xilinx] Device tree generation failure (2017.3)

[Martin Siegumfeldt]

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 
<meta-xilinx-boun...@yoctoproject.org> on behalf of Martin Siegumfeldt 
<m...@gomspace.com>
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 <manju...@xilinx.com>
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 <manju...@xilinx.com>; 
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 
<manju...@xilinx.com<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=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-

Re: [meta-xilinx] Device tree generation failure (2017.3)

[Martin Siegumfeldt]

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 <manju...@xilinx.com>
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=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

Re: [meta-xilinx] Device tree generation failure (2017.3)

[Martin Siegumfeldt]

Ok sounds good - looking forwards to it...


Cheers,

Martin


From: Manjukumar Harthikote Matha <manju...@xilinx.com>
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 <manju...@xilinx.com>; 
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 
<manju...@xilinx.com<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=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 =

[meta-xilinx] Device tree generation failure (2017.3)

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

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)

[Martin Siegumfeldt]

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

[Martin Siegumfeldt]

From: Nathan Rossi <nat...@nathanrossi.com>
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 <m...@gomspace.com> 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

[Martin Siegumfeldt]

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?

[Martin Siegumfeldt]

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 <manju...@xilinx.com>
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=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 <mike.looijm...@topic.nl>; Brian Hutchinson
> <b.hutch...@gmail.com>
> 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 <b.hutch...@gmail.com>; Manjukumar Harthikote
> > Matha <manju...@xilinx.com>
> > Cc: Giordon Stark <kra...@gmail.com>; Jean-Francois Dagenais
> > <jeff.dagen...@gmail.com>; 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&quo

[meta-xilinx] meta-xilinx-tools fails on "device-tree-generation" script

[Martin Siegumfeldt]

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