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