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

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

[Michal Simek]

From: Rajan Vaja <rajan.vaja@xilinx.com>

Existing EEMI version is to as 1.0 (available from xilinx v2018.1
version). Update required API version to match with EEMI API version.

New PMUFW version is required for operations with programmable logic.

Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---

 arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 792a3e1b655f..e122be59c747 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -173,8 +173,8 @@ int __maybe_unused invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2,
 
 #define ZYNQMP_SIP_SVC_GET_API_VERSION		0xC2000001
 
-#define ZYNQMP_PM_VERSION_MAJOR		0
-#define ZYNQMP_PM_VERSION_MINOR		3
+#define ZYNQMP_PM_VERSION_MAJOR		1
+#define ZYNQMP_PM_VERSION_MINOR		0
 #define ZYNQMP_PM_VERSION_MAJOR_SHIFT	16
 #define ZYNQMP_PM_VERSION_MINOR_MASK	0xFFFF
 
-- 
2.17.0

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

[Marek Vasut]

On 05/14/2018 03:39 PM, Michal Simek wrote:
> From: Rajan Vaja <rajan.vaja@xilinx.com>
> 
> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
> version). Update required API version to match with EEMI API version.

Not sure I understand this sentence.

> New PMUFW version is required for operations with programmable logic.

Seems the meta-xilinx 2018.1 comes with PMUFW 2017.3
https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware

Is this out of date ?

> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> 
>  arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
> index 792a3e1b655f..e122be59c747 100644
> --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
> +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
> @@ -173,8 +173,8 @@ int __maybe_unused invoke_smc(u32 pm_api_id, u32 arg0, u32 arg1, u32 arg2,
>  
>  #define ZYNQMP_SIP_SVC_GET_API_VERSION		0xC2000001
>  
> -#define ZYNQMP_PM_VERSION_MAJOR		0
> -#define ZYNQMP_PM_VERSION_MINOR		3
> +#define ZYNQMP_PM_VERSION_MAJOR		1
> +#define ZYNQMP_PM_VERSION_MINOR		0
>  #define ZYNQMP_PM_VERSION_MAJOR_SHIFT	16
>  #define ZYNQMP_PM_VERSION_MINOR_MASK	0xFFFF
>  
> 


-- 
Best regards,
Marek Vasut

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

[Michal Simek]

On 14.5.2018 22:55, Marek Vasut wrote:
> On 05/14/2018 03:39 PM, Michal Simek wrote:
>> From: Rajan Vaja <rajan.vaja@xilinx.com>
>>
>> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
>> version). Update required API version to match with EEMI API version.
> 
> Not sure I understand this sentence.

PMUFW contains EEMI api which has also changed and the biggest reason
for bumping up PMUFW version were changes in EEMI api. And these
versions are also aligned.

Thanks,
Michal

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

[Marek Vasut]

On 05/17/2018 03:59 PM, Michal Simek wrote:
> On 14.5.2018 22:55, Marek Vasut wrote:
>> On 05/14/2018 03:39 PM, Michal Simek wrote:
>>> From: Rajan Vaja <rajan.vaja@xilinx.com>
>>>
>>> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
>>> version). Update required API version to match with EEMI API version.
>>
>> Not sure I understand this sentence.
> 
> PMUFW contains EEMI api which has also changed and the biggest reason
> for bumping up PMUFW version were changes in EEMI api. And these
> versions are also aligned.

So uh, the meta-xilinx 2018.1 release which contains pmufw 2017.3 uses
the new API 1.0 , while meta-xilinx 2018.1 release which contains pmufw
2017.3 as well does not use the API 1.0 ? I think the versioning is a
complete CF then ...

-- 
Best regards,
Marek Vasut

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

[Rajan Vaja]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: 15 May 2018 02:26 AM
> To: Michal Simek <michal.simek@xilinx.com>; u-boot at lists.denx.de
> Cc: Rajan Vaja <RAJANV@xilinx.com>; monstr at monstr.eu; Albert Aribaud
> <albert.u.boot@aribaud.net>
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/14/2018 03:39 PM, Michal Simek wrote:
> > From: Rajan Vaja <rajan.vaja@xilinx.com>
> >
> > Existing EEMI version is to as 1.0 (available from xilinx v2018.1
> > version). Update required API version to match with EEMI API version.
> 
> Not sure I understand this sentence.
> 
> > New PMUFW version is required for operations with programmable logic.
> 
> Seems the meta-xilinx 2018.1 comes with PMUFW 2017.3
> https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-
> bsp/recipes-bsp/pmu-firmware
> 
> Is this out of date ?
[Rajan] PMU firmware is built using meta-xilinx-tools layer and not meta-xilinx-bsp.
The recipe in meta-xilinx-bsp is to build OSL flow (using multilib) this is not recommended nor supported from Xilinx.

> 
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> > ---
> >
> >  arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c
> b/arch/arm/cpu/armv8/zynqmp/cpu.c
> > index 792a3e1b655f..e122be59c747 100644
> > --- a/arch/arm/cpu/armv8/zynqmp/cpu.c
> > +++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
> > @@ -173,8 +173,8 @@ int __maybe_unused invoke_smc(u32 pm_api_id,
> u32 arg0, u32 arg1, u32 arg2,
> >
> >  #define ZYNQMP_SIP_SVC_GET_API_VERSION		0xC2000001
> >
> > -#define ZYNQMP_PM_VERSION_MAJOR		0
> > -#define ZYNQMP_PM_VERSION_MINOR		3
> > +#define ZYNQMP_PM_VERSION_MAJOR		1
> > +#define ZYNQMP_PM_VERSION_MINOR		0
> >  #define ZYNQMP_PM_VERSION_MAJOR_SHIFT	16
> >  #define ZYNQMP_PM_VERSION_MINOR_MASK	0xFFFF
> >
> >
> 
> 
> --
> Best regards,
> Marek Vasut

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

[Marek Vasut]

On 05/21/2018 06:53 AM, Rajan Vaja wrote:
> Hi Marek,
> 
>> -----Original Message-----
>> From: Marek Vasut [mailto:marex at denx.de]
>> Sent: 15 May 2018 02:26 AM
>> To: Michal Simek <michal.simek@xilinx.com>; u-boot at lists.denx.de
>> Cc: Rajan Vaja <RAJANV@xilinx.com>; monstr at monstr.eu; Albert Aribaud
>> <albert.u.boot@aribaud.net>
>> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
>>
>> On 05/14/2018 03:39 PM, Michal Simek wrote:
>>> From: Rajan Vaja <rajan.vaja@xilinx.com>
>>>
>>> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
>>> version). Update required API version to match with EEMI API version.
>>
>> Not sure I understand this sentence.
>>
>>> New PMUFW version is required for operations with programmable logic.
>>
>> Seems the meta-xilinx 2018.1 comes with PMUFW 2017.3
>> https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-
>> bsp/recipes-bsp/pmu-firmware
>>
>> Is this out of date ?
> [Rajan] PMU firmware is built using meta-xilinx-tools layer and not meta-xilinx-bsp.
> The recipe in meta-xilinx-bsp is to build OSL flow (using multilib) this is not recommended nor supported from Xilinx.

Ah, I see, so there are three versions of pmu-firmware in a single
release, but the one which is actually needed for the system to boot
correctly is not in the meta-xilinx repo as one would expect, but in
some other repo. That ... doesn't make any sense, but so be it.

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 ?

Also, do I understand it correctly that Xilinx doesn't support arm64
with multilib?

-- 
Best regards,
Marek Vasut

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

[Manjukumar Harthikote Matha]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Monday, May 21, 2018 2:45 AM
> To: Rajan Vaja <RAJANV@xilinx.com>
> Cc: monstr at monstr.eu; Albert Aribaud <albert.u.boot@aribaud.net>;
> Manjukumar Harthikote Matha <MANJUKUM@xilinx.com>; Jolly Shah
> <JOLLYS@xilinx.com>; Michal Simek <michal.simek@xilinx.com>; u-
> boot at lists.denx.de
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/21/2018 06:53 AM, Rajan Vaja wrote:
> > Hi Marek,
> >
> >> -----Original Message-----
> >> From: Marek Vasut [mailto:marex at denx.de]
> >> Sent: 15 May 2018 02:26 AM
> >> To: Michal Simek <michal.simek@xilinx.com>; u-boot at lists.denx.de
> >> Cc: Rajan Vaja <RAJANV@xilinx.com>; monstr at monstr.eu; Albert Aribaud
> >> <albert.u.boot@aribaud.net>
> >> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> >>
> >> On 05/14/2018 03:39 PM, Michal Simek wrote:
> >>> From: Rajan Vaja <rajan.vaja@xilinx.com>
> >>>
> >>> Existing EEMI version is to as 1.0 (available from xilinx v2018.1
> >>> version). Update required API version to match with EEMI API version.
> >>
> >> Not sure I understand this sentence.
> >>
> >>> New PMUFW version is required for operations with programmable logic.
> >>
> >> Seems the meta-xilinx 2018.1 comes with PMUFW 2017.3
> >> https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-
> >> bsp/recipes-bsp/pmu-firmware
> >>
> >> Is this out of date ?
> > [Rajan] PMU firmware is built using meta-xilinx-tools layer and not meta-xilinx-
> bsp.
> > The recipe in meta-xilinx-bsp is to build OSL flow (using multilib) this is not
> recommended nor supported from Xilinx.
> 
> Ah, I see, so there are three versions of pmu-firmware in a single
> release, but the one which is actually needed for the system to boot
> correctly is not in the meta-xilinx repo as one would expect, but in
> some other repo. That ... doesn't make any sense, but so be it.
> 

If you are planning to use rel-v2018.x Xilinx tools release branches, stick with all the layers provided by Xilinx. The same is documented in wiki as well

http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto

If you want to use Yocto open-source release stick with branches likes rocko, morty etc. These branches will not have dependencies on Xilinx tools.
 
> 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/xsctapp.bbclass#L9

This should indicate, release version with a part of commit id of git being used.

> 
> Also, do I understand it correctly that Xilinx doesn't support arm64
> with multilib?
> 

Yes Xilinx does not support multilib way of building PMUFW. The official support is in meta-xilinx-tools layer with a dependency on xsct tool

Thanks,
Manju

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

[Marek Vasut]

On 05/21/2018 06:27 PM, Manjukumar Harthikote Matha wrote:

[...]

>> Ah, I see, so there are three versions of pmu-firmware in a single
>> release, but the one which is actually needed for the system to boot
>> correctly is not in the meta-xilinx repo as one would expect, but in
>> some other repo. That ... doesn't make any sense, but so be it.
>>
> 
> If you are planning to use rel-v2018.x Xilinx tools release branches, stick with all the layers provided by Xilinx. The same is documented in wiki as well
> 
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto
> 
> If you want to use Yocto open-source release stick with branches likes rocko, morty etc. These branches will not have dependencies on Xilinx tools.

I think you missed my point, there are three different PMUFW recipes in
those metalayers. The only one that matters is not in the BSP layer,
which makes no sense to me, but so be it.

btw I presume you do mean OpenEmbedded.

>> 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/xsctapp.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.

> 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.

>. The official support is in meta-xilinx-tools layer with a dependency on xsct tool

Which btw is violating OE assumption that no host tools are pulled into
the build, so this whole thing is broken.

-- 
Best regards,
Marek Vasut

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

[Manjukumar Harthikote Matha]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Monday, May 21, 2018 9:47 AM
> To: Manjukumar Harthikote Matha <MANJUKUM@xilinx.com>; Rajan Vaja
> <RAJANV@xilinx.com>
> Cc: monstr at monstr.eu; Albert Aribaud <albert.u.boot@aribaud.net>; Jolly Shah
> <JOLLYS@xilinx.com>; Michal Simek <michal.simek@xilinx.com>; u-
> boot at lists.denx.de
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/21/2018 06:27 PM, Manjukumar Harthikote Matha wrote:
> 
> [...]
> 
> >> Ah, I see, so there are three versions of pmu-firmware in a single
> >> release, but the one which is actually needed for the system to boot
> >> correctly is not in the meta-xilinx repo as one would expect, but in
> >> some other repo. That ... doesn't make any sense, but so be it.
> >>
> >
> > If you are planning to use rel-v2018.x Xilinx tools release branches,
> > stick with all the layers provided by Xilinx. The same is documented
> > in wiki as well
> >
> >
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct
> o
> >
> > If you want to use Yocto open-source release stick with branches likes rocko,
> morty etc. These branches will not have dependencies on Xilinx tools.
> 
> I think you missed my point, there are three different PMUFW recipes in those
> metalayers. The only one that matters is not in the BSP layer, which makes no
> sense to me, but so be it.

AFAIK, there are two. One in meta-xilinx-bsp and other in meta-xilinx-tools. You can use PREFERRED_PROVIDER to switch between the two in your distro.

I still don’t think you get the difference between Xilinx tools releases from Github and upstream Yocto project repository.
See http://git.yoctoproject.org/cgit.cgi/meta-xilinx/

Also note that none of the Xilinx tool release branches are present at http://git.yoctoproject.org/cgit.cgi/meta-xilinx/

The thing that matters to you is pmu-firmware recipe in meta-xilinx-bsp. The recipe is present and based on 2017.3 in master and Rocko. Stick with Rocko branch till the next release,Sumo branch is cut, which will get 2018.1 version.

> 
> 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.
 
> > 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), 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. 

> >. The official support is in meta-xilinx-tools layer with a dependency
> >on xsct tool
> 
> Which btw is violating OE assumption that no host tools are pulled into the build,
> so this whole thing is broken.
> 

It is part of Xilinx tool release, if you don’t need it, don’t use it. 

Thanks,
Manju

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

[Marek Vasut]

On 05/21/2018 11:26 PM, Manjukumar Harthikote Matha wrote:
[...]
>>>> Ah, I see, so there are three versions of pmu-firmware in a single
>>>> release, but the one which is actually needed for the system to boot
>>>> correctly is not in the meta-xilinx repo as one would expect, but in
>>>> some other repo. That ... doesn't make any sense, but so be it.
>>>>
>>>
>>> If you are planning to use rel-v2018.x Xilinx tools release branches,
>>> stick with all the layers provided by Xilinx. The same is documented
>>> in wiki as well
>>>
>>>
>> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct
>> o
>>>
>>> If you want to use Yocto open-source release stick with branches likes rocko,
>> morty etc. These branches will not have dependencies on Xilinx tools.
>>
>> I think you missed my point, there are three different PMUFW recipes in those
>> metalayers. The only one that matters is not in the BSP layer, which makes no
>> sense to me, but so be it.
> 
> AFAIK, there are two. One in meta-xilinx-bsp and other in meta-xilinx-tools. You can use PREFERRED_PROVIDER to switch between the two in your distro.
> 
> I still don’t think you get the difference between Xilinx tools releases from Github and upstream Yocto project repository.
> See http://git.yoctoproject.org/cgit.cgi/meta-xilinx/

Do I understand it correctly that you have two repositories with the
same name, but with different content ? Talk about confusing. Assume I
use the meta-xilinx stuff from github/xilinx.

> Also note that none of the Xilinx tool release branches are present at http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> 
> The thing that matters to you is pmu-firmware recipe in meta-xilinx-bsp. The recipe is present and based on 2017.3 in master and Rocko. Stick with Rocko branch till the next release,Sumo branch is cut, which will get 2018.1 version.

Ah, I see.

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.

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 ?

>> 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.

>>> 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.

>>> . The official support is in meta-xilinx-tools layer with a dependency
>>> on xsct tool
>>
>> Which btw is violating OE assumption that no host tools are pulled into the build,
>> so this whole thing is broken.
>>
> 
> It is part of Xilinx tool release, if you don’t need it, don’t use it. 

The meta-xilinx-tools bbclasses are calling those tools, thus violating
that assumption, so if I want to get a working result, I effectively cannot.

-- 
Best regards,
Marek Vasut

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

[Manjukumar Harthikote Matha]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Tuesday, May 22, 2018 4:28 AM
> To: Manjukumar Harthikote Matha <MANJUKUM@xilinx.com>; Rajan Vaja
> <RAJANV@xilinx.com>
> Cc: monstr at monstr.eu; Albert Aribaud <albert.u.boot@aribaud.net>; Jolly Shah
> <JOLLYS@xilinx.com>; Michal Simek <michal.simek@xilinx.com>; u-
> boot at lists.denx.de; Moritz Fischer <moritz.fischer@ettus.com>
> Subject: Re: [PATCH] soc: zynqmp: Update required API version to 1.0
> 
> On 05/21/2018 11:26 PM, Manjukumar Harthikote Matha wrote:
> [...]
> >>>> Ah, I see, so there are three versions of pmu-firmware in a single
> >>>> release, but the one which is actually needed for the system to boot
> >>>> correctly is not in the meta-xilinx repo as one would expect, but in
> >>>> some other repo. That ... doesn't make any sense, but so be it.
> >>>>
> >>>
> >>> If you are planning to use rel-v2018.x Xilinx tools release branches,
> >>> stick with all the layers provided by Xilinx. The same is documented
> >>> in wiki as well
> >>>
> >>>
> >>
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yoct
> >> o
> >>>
> >>> If you want to use Yocto open-source release stick with branches likes rocko,
> >> morty etc. These branches will not have dependencies on Xilinx tools.
> >>
> >> I think you missed my point, there are three different PMUFW recipes in those
> >> metalayers. The only one that matters is not in the BSP layer, which makes no
> >> sense to me, but so be it.
> >
> > AFAIK, there are two. One in meta-xilinx-bsp and other in meta-xilinx-tools. You
> can use PREFERRED_PROVIDER to switch between the two in your distro.
> >
> > I still don’t think you get the difference between Xilinx tools releases from
> Github and upstream Yocto project repository.
> > See http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> 
> Do I understand it correctly that you have two repositories with the
> same name, but with different content ? Talk about confusing. Assume I
> use the meta-xilinx stuff from github/xilinx.
> 
> > Also note that none of the Xilinx tool release branches are present at
> http://git.yoctoproject.org/cgit.cgi/meta-xilinx/
> >
> > The thing that matters to you is pmu-firmware recipe in meta-xilinx-bsp. The
> recipe is present and based on 2017.3 in master and Rocko. Stick with Rocko
> branch till the next release,Sumo branch is cut, which will get 2018.1 version.
> 
> Ah, I see.
> 
> 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.

> 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.

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

> >> 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 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

 
> >>> . The official support is in meta-xilinx-tools layer with a dependency
> >>> on xsct tool
> >>
> >> Which btw is violating OE assumption that no host tools are pulled into the
> build,
> >> so this whole thing is broken.
> >>
> >
> > It is part of Xilinx tool release, if you don’t need it, don’t use it.
> 
> The meta-xilinx-tools bbclasses are calling those tools, thus violating
> that assumption, so if I want to get a working result, I effectively cannot.
> 

To summarize:

There are two workflows
1) Using Xilinx tool releases from github (branches like: rel-v2018.1, rel-v2017.4 etc)
2) Using upstream only layer http://git.yoctoproject.org/cgit.cgi/meta-xilinx/ (branches like: rocko, morty etc)


If you are using (1) :
-----------------------------------
Use the manifest
https://github.com/Xilinx/yocto-manifests/tree/rel-v2018.1

See some documentation here
http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto

We also need xsct to be installed for this method.

If you just use meta-xilinx rel-v2018.1 branch alone without meta-xilinx-tools and meta-petalinux, this is not supported.
We support the layer stack we publish at this point of time.

If you are using (2) :
-----------------------------------
You will not have dependency on Xilinx tools.
Bootloader is from u-boot SPL and PMUFW built using multilib.
There might be gaps on certain boot methods. There are community based solutions available.
Latest release branch is rocko, sumo release will be mid-June.

You pick your workflow and use them according to your needs. 

One more thing, I am not sure how your layer stack is or was used earlier, because rel-v2017.x branch never supported building pmu-fw.
If you did not use rel-v2017.x branches earlier then you should have used morty/rocko branch from upstream (it's my guess).

Thanks,
Manju

[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

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

[Manjukumar Harthikote Matha]

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