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

[Martin Lund]

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.


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.



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) they have been placed in meta-petalinux (see 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.



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) 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). 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) 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.



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



>From 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!

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.

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.

/Martin





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180515/d099bd3b/attachment.html>