Re: [meta-xilinx] Xilinx, why are you breaking the meta-xilinx-bsp layer?

[Jean-François Dagenais]

Ditto on all Martin said. We also wish to move away from bloated, slow and 
buggy meta-xilinx-tools. 

Sent from my iPhone

> On May 15, 2018, at 10:55, Peter Smith  wrote:
> 
> I shall second this
-- 
___
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]

[Nathan Rossi]

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]

[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] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with error "fdt_root: FDT_ERR_BADMAGIC"

[Martin Lund]

Hi,


I've been debugging some more and I can confirm that it jumps successfully to 
the ATF but the ATF crashes before it writes anything to the uart, such as its 
usual version notice information.


Debugging the ATF I've found that it crashes trying to retrieve the chip id via 
the pm_get_chipid() call in plat/xilinx/zynqmp/aarch64/zynqmp_common.c. This 
call results in a request to the PMU.


This makes me think maybe something is wrong with the PMU firmware?



Further investigation reveals that the pmu-firmware defined in the rel-v2018.1 
branch of meta-xilinx seems to be out of date - it still uses 
pmu-firmware_2017.3.bb file (see 
https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware)
 despite the fact that there is clearly a v2018.1 release available with many 
updates (see https://github.com/Xilinx/embeddedsw/releases/tag/xilinx-v2018.1).


Now, the big question is what happened to the meta-xilinx-bsp layer in the 
v2018.1 release to break a normally bootable system?


And why didn't Xilinx provide an updated pmu-firmware bb definition for the 
v2018.1 release in the meta-xilinx-bsp layer?



As it turns out, Xilinx are tossing things around and have introduced a new way 
of building the pmu-firmware but it forces/requires you to use the 
meta-xilinx-tools layer!


This new approach uses all the spokes and wheels of the proprietary xilinx 
toolchain with all sorts of cumbersome tools and components involved (xsdk, 
X/gtk3, xsct, tcl, yaml, etc.) which makes it quite troublesome to deploy on 
common build servers.


For this reason we want to avoid using meta-xilinx-tools so I tried simply 
upgrading the existing pmu-firmware_2017.3.bb to pmu-firmware_2018.1.bb 
(attached). While it builds fine the ATF software still crashes in the call to 
pm_get_chipid() so apparently the new PMU firmware made no difference or 
something is missing or broken in how the PMU firmware is built using the old 
approach but with updated references to new v2018.1 git version.


Also, is it even possible to use the old v2017.3 pmu-firmware with the 2018.1 
released components (u-boot, kernel, etc.)?



Any thoughts?


It would be great to hear from Xilinx on this matter so we can get issue 
resolved and get back a functional meta-xilinx-bsp layer.


Thanks.


/Martin


From: meta-xilinx-boun...@yoctoproject.org 
 on behalf of Martin Lund 

Sent: Wednesday, May 9, 2018 3:55:13 PM
To: Andreas Galauner; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with 
error "fdt_root: FDT_ERR_BADMAGIC"


Hi Andy,

Thank you for your patches - good stuff.

I have applied your xlnx.patch succesfully on the u-boot xilinx-v2018.1 branch.

I have also added your .bb changes to u-boot-xlnx_2018.1.bb which seems to 
result in a valid u-boot.itb:


$ mkimage -l build/tmp/deploy/images/zcu102-zynqmp/u-boot.itb
FIT description: FIT image with U-Boot proper, ATF bl31, DTB
Created: Wed May  9 14:33:54 2018
 Image 0 (uboot)
  Description:  U-Boot (64-bit)
  Created:  Wed May  9 14:33:54 2018
  Type: Standalone Program
  Compression:  uncompressed
  Data Size:unavailable
  Architecture: AArch64
  Load Address: 0x0800
  Entry Point:  unavailable
 Image 1 (atf)
  Description:  ARM Trusted Firmware
  Created:  Wed May  9 14:33:54 2018
  Type: Firmware
  Compression:  uncompressed
  Data Size:unavailable
  Architecture: AArch64
  Load Address: 0xfffea000
 Image 2 (fdt)
  Description:  ZynqMP flat device-tree
  Created:  Wed May  9 14:33:54 2018
  Type: Flat Device Tree
  Compression:  uncompressed
  Data Size:unavailable
  Architecture: Unknown Architecture
 Default Configuration: 'conf'
 Configuration 0 (conf)
  Description:  Xilinx ZynqMP board with ATF, main u-boot and dtb
  Kernel:   unavailable
  FDT:  fdt
  Loadables:uboot



However, it seems it is still getting stuck when jumping to the ATF:


 Debug uart enabled

U-Boot SPL 2018.01 (May 09 2018 - 14:17:05)
EL Level:   EL3
Trying to boot from MMC1
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
Board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and 
dtb'board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and 
dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and dtb'loadables: 
'uboot'
board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and dtb'no string 
for index 1
Jumping to U-Boot via ARM Trusted Firmware
spl_fit_images_get_entry: entry point 0x800

At this point it has crashed looping in the reset vector at 0xfffea928 again.


I have to trace the code path more - perhaps it