[U-Boot] [PATCH] soc: zynqmp: Update required API version to 1.0

Wed May 23 17:31:28 UTC 2018

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Wednesday, May 23, 2018 2:49 AM
> To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; Rajan Vaja
> <RAJANV at xilinx.com>
> Cc: monstr at monstr.eu; Albert Aribaud <albert.u.boot at aribaud.net>; Jolly Shah
> <JOLLYS at xilinx.com>; Michal Simek <michal.simek at xilinx.com>; u-
> boot at lists.denx.de; Moritz Fischer <moritz.fischer at 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