> -----Original Message----- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Wednesday, May 23, 2018 2:49 AM > To: Manjukumar Harthikote Matha <manju...@xilinx.com>; Rajan Vaja > <raj...@xilinx.com> > Cc: mon...@monstr.eu; Albert Aribaud <albert.u.b...@aribaud.net>; Jolly Shah > <jol...@xilinx.com>; Michal Simek <michal.si...@xilinx.com>; u- > b...@lists.denx.de; Moritz Fischer <moritz.fisc...@ettus.com> > Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0 > > On 05/22/2018 06:44 PM, Manjukumar Harthikote Matha wrote: > [...] > >> So I should use this pmu-firmware from meta-xilinx-bsp rel-v2018.1 > >> (the one on github, not the one on git.yoctoproject) without version > >> which provides the ABI 1.0 rather than the v2017.03 one from > >> meta-xilinx rel-v2018.1. And then the new release of meta-xilinx > >> rel-v2018.2 will get PMUFW v2018.1 . > >> > >> But why is such vital component as the working PMUFW recipe stashed > >> in some other repo than meta-xilinx , while meta-xilinx contains a > >> non working one is not clear to me. Anyway. > >> > > > > Release branches in github are related to Xilinx tools release to > > support PetaLinux, xsct etc The flow using github release uses a layer > > stack and how to use is documented here > > > http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct > o > > and manifest is here > > https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1 > > > > We don’t support a flow where you use only one layer instead of the entire > stack. > > Then the obvious question is, why is it not a single metalayer ... >
The proposal was sent out, there are dependencies on why the merge has not happened https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-November/003309.html We plan to resolve in the next release (Thud) > >> It is also becoming less and less clear to me which PMUFW provides > >> which ABI based on the recipe versions, since they do not reflect the > >> ABI in any way. And, back to my original question-ish, there is an > >> ABI break between PMUFW v0.3 and PMUFW v1.0 which may render systems > >> unbootable if everything is not updated in tandem, right ? > >> > > > > I was not aware of the breakage, I will have to check. > > Try using mainline U-Boot 2018.05 with PMUFW v0.3 and load FPGA image from > U-Boot, it'll fail. > > > If you use our entire layer stack for rel-v2018.1 (manifest) then you > > shouldn’t > see the issue. > > > > As far as master branch is considred, we are in process of updating it for > > sumo > release. > > If you are on mailing list, you will see the patches sent for review and is > > on 4th > version. > > We hope to get it merged if there are no hiccups by end of week. > > See : > > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003838.h > > tml > > See: > > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.h > > tml > > Great > > >>>> btw I presume you do mean OpenEmbedded. > >>>> > >>> > >>> > >>> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ > >>> > >>> > >>>>>> So it's this pmu-firmware_git recipe which provides different ABI > >>>>>> in different versions of meta-xilinx-bsp, yet this is not in any > >>>>>> way indicated by the package version, right ? > >>>>> > >>>>> Didn’t get what you mean here? Package version is set according to > >>>>> the release under use > >>>>> https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xs > >>>>> ctap > >>>>> p.bbclass#L9 > >>>> > >>>> Ah, I see, so unlike any other regular recipe which encodes the > >>>> version in the recipe file name, Xilinx stuff has custom class > >>>> which is inherited into version- > >> less > >>>> recipe and sets the version. This is horrid. > >>>> > >>> > >>> Not true, any recipe which includes version can be in an include > >>> file or in a class > >> or in a conf file. > >>> There is no strict guidelines on where this version should be set > >>> (recipe, include, > >> conf or class). > >>> Just because you are familiar with one way of doing things, does not > >>> mean > >> everything else is horrid. > >> > >> Well, I think I've seen my share of recipes over the years, both good > >> and bad. OE gives the user a lot of freedom to do all kinds of hacks, > >> which still doesn't mean it's a good idea to do them. > >> > >> Writing your own bbclass as a sort-of header file to be included by a > >> recipe is one of the bad ideas. With the ABI break at hand, there is > >> also no migration strategy for this PMUFW recipe, the platform just > >> breaks during the update and stops booting or misbehaves, which is > >> grueling. > >> > > > > The same class is shared for multiple components, FSBL, DTG etc hence > > the reasoning to use a class However, this something for us to consider and > work in future releases. > > This seems to be long overdue > Debatable according to me. > >>>>> This should indicate, release version with a part of commit id of > >>>>> git being > >> used. > >>>> > >>>> Right ... > >>>> > >>>>>> Also, do I understand it correctly that Xilinx doesn't support > >>>>>> arm64 with multilib? > >>>>>> > >>>>> > >>>>> Yes Xilinx does not support multilib way of building PMUFW > >>>> > >>>> What are you talking about ? PMUFW is microblaze, which doesn't do > >>>> multilib > >> in > >>>> the first place. > >>>> > >>> > >>> Exactly, when you are building for zynqmp (zcu102 board) > >> > >> No, I am not building for zcu102. > >> > >>> , it is aarch64. Yocto build system needs to understand mixed > >>> architectures when > >> building in the same project, hence the use of multilib to be build PMUFW. > >> > >> But you never build the microblaze toolchain, so how do you use > >> multilib here at all ? From what I see, the pmu-firmware is compiled > >> with toolchain referenced from outside of the OE build, in fact from > >> vivado, see my comment below from using external tools like that. > >> > > > > I am not sure how your dependencies are wired in: > > We have a dependency like this for zcu102 > > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/ > > conf/machine/zcu102-zynqmp.conf#n34 > > > > If you are using meta-xilinx-bsp rocko/master branch, it uses multilib > > builds the MB toolchain using newlib and libgloss to build pmufw > > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/ > > classes/zynqmp-pmu.bbclass > > http://git.yoctoproject.org/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/ > > recipes-core/newlib > > I think I mentioned it before, but I am using the repo from github. That one > does > NOT build microblaze toolchain to compile pmufw. > I am really lost here, PMUFW needs a MB baremetal toolchain to build as far as I know. There are only two possible ways to build it 1) Use XSCT with MB baremetal toolchain binaries (AKA meta-xilinx-tools layer) or 2) Use multilib, newlib/libgloss to build MB baremetal toolchain from source I don’t see any other possibility of making it work Thanks, Manju _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
