I shall second this as I will very soon face the same issue. I help to maintain a custom distribution (using a lot of the functionality provided by the by Yocto project). Currently I am using Yocto pyro and the meat-xilinx and I am able to take advantage of the independence of this layer. We will need to move to 2018.1 as our custom distribution (which runs on more than Xilinx devices) is scheduled to move to Yocto rocko. If I cannot use the meta-xilinx-bsp without pulling in loads of other layers this will prove difficult.
Best Regards Peter On Tue, 15 May 2018 at 15:47, Martin Lund <m...@gomspace.com> wrote: > 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 > > > > > > -- > _______________________________________________ > 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
