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

[Marek Vasut]

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