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%20yocto > 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 ... >> 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.html > See: https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-May/003841.html 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/xsctap >>>>> 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 >>>>> 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. [...] -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
