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

Tue May 15 09:15:08 PDT 2018

Hi Martin,

> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> bounces at yoctoproject.org] On Behalf Of Martin Lund
> Sent: Tuesday, May 15, 2018 7:31 AM
> To: meta-xilinx at yoctoproject.org
> Subject: [meta-xilinx] Xilinx, why are you breaking the meta-xilinx-bsp layer?
> 
> Hi Xilinx and friends,
> 
> 
> 
> 
> What is going on with the meta-xilinx-bsp layer in the v2018.1 release?
> 
> 
> 
> 
> 
> 
> 
> We are trying to put together a system built on top of the meta-xilinx-bsp layer
> and we have done so successfully up until the v2017.4 release with a few helpful
> patches from this excellent community. That is, we have been able to create our
> system without using the meta-xilinx-tools and meta-petalinux layers. Meaning
> meta-xilinx-bsp has offered a fairly independent and functional BSP layer, in our
> case, for the zcu102 dev board.

I am not sure how you achieved to build pmu firmware in OSS/OSL flow, using a rel-v2017.4 branch.
https://github.com/Xilinx/meta-xilinx/tree/rel-v2017.4/recipes-bsp
There was no recipe available to build one nor support to build SPL.

> 
> 
> 
> 
> However, with the introduction of Xilinx release v2018.1 it seems some basic BSP
> things are broken or split out and moved to the meta-xilinx-tools or meta-
> petalinux for no apparent good reason - basically breaking the independence of
> the meta-xilinx-bsp layer. Up until this point we are still struggling to get meta-
> xilinx-bsp booting on our zcu102 board.
> 
> 

Release branches in github is very specific for Xilinx tool release. Meaning all the rel-v2018.x are supposed to work with the layer stack (meta-petalinux, meta-xilinx-tools, meta-xilinx-bsp and meta-xilinx-contrib). This is the same practice which has been done since 2017. If you see older releases like rel-v2017.1, SPL support, certain board support code is not present in release branches.

Please see
https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-October/002174.html

Saying that, 2018.2 release branch will be fixed to include u-boot-mkimage, and fw-utils.
This will be pushed mid-june.

One more thing to add, Xilinx release branches works on top of a previous version of the available Yocto release.
Meaning rel-v2018.1 (and rest of rel-v2018.x ) is based on rocko branch of meta-xilinx-bsp.
rel-v2019.1 will be based on thud (v2.6) branch of meta-xilinx-bsp etc

We don't change any of the OSS/OSL flow related recipes in the Xilinx tool related releases.

> 
> 
> 
> 
> 
> 
> For example, instead of putting updated versions of u-boot-fw-utils, u-boot-
> mkimage, and u-boot-common in meta-xilinx-bsp (see
> https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-
> bsp/u-boot <https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-
> bsp/recipes-bsp/u-boot> ) they have been placed in meta-petalinux (see
> https://github.com/Xilinx/meta-petalinux/tree/rel-v2018.1/recipes-bsp/u-boot
> <https://github.com/Xilinx/meta-petalinux/tree/rel-v2018.1/recipes-bsp/u-boot>
> ). Having an up-to-date u-boot-mkimage is important for producing valid
> bootloader images so one would assume it to belong in the primary BSP layer,
> namely meta-xilinx-bsp. Perhaps I'm missing something here but I don't see any
> good reason for putting these in meta-petalinux.
> 

Same as the above point on how to use release branches.

> 
> 
> 
> 
> 
> Another more important example is the omission of an updated pmu-firmware in
> meta-xilinx-bsp for the v2018.1 release. A simple and straightforward way of
> building the pmu-firmware used to reside in meta-xilinx-bsp (see
> https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-
> bsp/pmu-firmware <https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-
> xilinx-bsp/recipes-bsp/pmu-firmware> ) but now a new way of building the pmu-
> firmware has been introduced/forced in meta-xilinx-tools (see
> https://github.com/Xilinx/meta-xilinx-tools/tree/rel-v2018.1/recipes-bsp/pmu-
> firmware).

Using xsct to build pmu-firmware is not new, this layer and recipes has been introduced probably in 2016 timeframe.

 As mentioned in https://lists.yoctoproject.org/pipermail/meta-
> xilinx/2018-May/003809.html, this new approach uses all the spokes and wheels
> of the proprietary xilinx toolchain involving all sorts of cumbersome tools and
> components (xsdk, X/gtk3, xsct, tcl, yaml, etc.) which makes it quite troublesome
> to deploy on common build servers. I can't understand why Xilinx thinks it is a
> good idea to go down this route. They take something simple and make it
> complicated, much slower, and storage demanding. Additionally, what makes
> matters even worse is that the build definition for is pmu-firmware is actually
> placed in a bbclass (see https://github.com/Xilinx/meta-xilinx-tools/blob/rel-
> v2018.1/classes/xsctapp.bbclass <https://github.com/Xilinx/meta-xilinx-
> tools/blob/rel-v2018.1/classes/xsctapp.bbclass> ) but it really belongs in the pmu-
> firmware_*.bb file. Either way, the end result is that if one is using only the
> v2018.1 meta-xilinx-bsp layer then the old v2017.3 pmu-firmware is built which
> does not seem to be compatible with v2018.1 atf, u-boot, kernel etc.
>

Same as the above, recipes are tied together with the above mentioned layers for release branches.

> 
> 
> 
> 
> 
> 
> 
> Seen from the outside, it all seems like a bit of a mess.

Xilinx tools release cannot be independent, the workflow is different.
If you continue to use rel-v2018 (release branches), then the recommendation is to use all layers.
If you use yocto based release branches (rocko, pyro, etc), meta-xilinx-bsp should fairly work.

Look out for patches that are being posted for sumo branch.

> 
> 
> 
> 
> 
> 
> 
> 
> From https://github.com/Xilinx/meta-
> xilinx/commit/a18947c20dba2c0c38db8bde1ad4684995df4bbd
> <https://github.com/Xilinx/meta-
> xilinx/commit/a18947c20dba2c0c38db8bde1ad4684995df4bbd>  I see that Xilinx
> is restructuring meta-xilinx into the following 4 layers:
> 
> 
>   ->meta-xilinx-bsp
>   ->meta-petalinux
>   ->meta-xilinx-tools
>   ->meta-xilinx-contrib
> 
> Which sounds perfectly fine.
> 
> My only wish is for Xilinx to keep a clear split between the layers. In particular,
> keep meta-xilinx-bsp an independent layer which can be used to build a basic
> bootable system without the need for meta-xilinx-tools or meta-petalinux!
>

The Xilinx tool releases rely on having all the layers not one single layer. The yocto releases that we make for example like rocko, pyro, krogoth etc are supposed to work with OSL flows. 

We have been sending patches to mailing list to update the meta-xilinx-bsp master for Sumo release, this will include newer kernel etc

> I understand that Xilinx only tests meta-petalinux in combination with the rest but
> I really want to make a plea for Xilinx to also start testing meta-xilinx-bsp in the
> aim to keep it independent and functional.
> 

Xilinx tools release cannot be independent, the workflow is different and needs all the layers.
If you continue to use rel-v2018 (release branches), then the recommendation is to use all layers.
If you use yocto based release branches, meta-xilinx-bsp should fairly work ( except master as changes to OE-Core master might cause breakages)

> If what we see is intentional and if Xilinix continues the current path of adding
> inter-dependencies between the layers then Xilinx might as well collapse
> everything into one single layer and call it meta-petalinux and force that upon all
> their customers. I think Xilinx would be wise to offer more choices to it's
> customers than simply that.

The plan to collapse all layers under meta-xilinx is proposed, and the first step of splitting has happened. 
We will continue to make all the necessary changes to have all layers under meta-xilinx later this year.
There are certain dependencies which needs to be addressed before having meta-petalinux in meta-xilinx umbrella.
We are working with OE-core to resolve some of these depedencies
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-November/003309.html

Thanks,
Manju