[Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Neal Frager via buildroot]

This patch adds a family variant choice to xilinx-embeddedsw for two reasons.

1. It does not make sense to build a zynqmp_pmufw for a versal platform or
versal_plm and versal_psmfw applications for a zynqmp platform.  With this
solution, users can only select applications which are targeted for their
device family.

2. Buildroot will soon be adding support for the versal_2ve_2vm second gen
family. This family has a plm boot application that generates a plm.elf just
like the current versal platform. If a user was to select both the versal_plm
and the versal_2ve_2vm_plm, two different plm.elf files will be generated
causing a conflict at the installation step and a run-time failure when the
wrong plm.elf gets included in the boot.bin.  By having a family variant,
only one plm.elf can be built at a time depending on the choice of family
variant being "versal" or "versal_2ve_2vm".

The issue can be seen by comparing the two Makefiles which both create a
plm.elf.

versal plm:
https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal

versal_2ve_2vm plm:
https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal_2ve_2vm

Signed-off-by: Neal Frager <neal.frager@amd.com>
---
 boot/xilinx-embeddedsw/Config.in | 15 +++++++++++++++
 configs/versal_vck190_defconfig  |  1 +
 configs/versal_vek280_defconfig  |  1 +
 configs/versal_vpk180_defconfig  |  1 +
 4 files changed, 18 insertions(+)

diff --git a/boot/xilinx-embeddedsw/Config.in b/boot/xilinx-embeddedsw/Config.in
index 0dd6433608..7af8d59929 100644
--- a/boot/xilinx-embeddedsw/Config.in
+++ b/boot/xilinx-embeddedsw/Config.in
@@ -28,8 +28,21 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSION
 	  Release version of Xilinx/embeddedsw.
 	  Must be xilinx_v2023.1 or newer.
 
+choice
+	bool "family variant"
+	default BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
+
+config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
+	bool "versal"
+
+config BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
+	bool "zynqmp"
+
+endchoice
+
 config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PLM
 	bool "versal plm"
+	depends on BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
 	help
 	  Build versal plm application from Xilinx/embeddedsw repo.
 	  If selected, the xilinx-prebuilt package will not install
@@ -40,6 +53,7 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PLM
 
 config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PSMFW
 	bool "versal psmfw"
+	depends on BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
 	help
 	  Build versal psmfw application from Xilinx/embeddedsw repo.
 	  If selected, the xilinx-prebuilt package will not install
@@ -50,6 +64,7 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PSMFW
 
 config BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP_PMUFW
 	bool "zynqmp pmufw"
+	depends on BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
 	help
 	  Build zynqmp pmufw application from Xilinx/embeddedsw repo.
 	  If selected, the xilinx-prebuilt package will not install
diff --git a/configs/versal_vck190_defconfig b/configs/versal_vck190_defconfig
index c9d99876d5..44bf9bc376 100644
--- a/configs/versal_vck190_defconfig
+++ b/configs/versal_vck190_defconfig
@@ -40,6 +40,7 @@ BR2_TARGET_UBOOT_FORMAT_DTB=y
 BR2_TARGET_UBOOT_FORMAT_REMAKE_ELF=y
 BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=versal-vck190-rev1.1"
 BR2_TARGET_XILINX_EMBEDDEDSW=y
+BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PLM=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PSMFW=y
 BR2_TARGET_XILINX_PREBUILT=y
diff --git a/configs/versal_vek280_defconfig b/configs/versal_vek280_defconfig
index 4aa25f8d67..0bd24b304f 100644
--- a/configs/versal_vek280_defconfig
+++ b/configs/versal_vek280_defconfig
@@ -40,6 +40,7 @@ BR2_TARGET_UBOOT_FORMAT_DTB=y
 BR2_TARGET_UBOOT_FORMAT_REMAKE_ELF=y
 BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=versal-vek280-revB"
 BR2_TARGET_XILINX_EMBEDDEDSW=y
+BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PLM=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PSMFW=y
 BR2_TARGET_XILINX_PREBUILT=y
diff --git a/configs/versal_vpk180_defconfig b/configs/versal_vpk180_defconfig
index 500298c2f4..746c36fb18 100644
--- a/configs/versal_vpk180_defconfig
+++ b/configs/versal_vpk180_defconfig
@@ -40,6 +40,7 @@ BR2_TARGET_UBOOT_FORMAT_DTB=y
 BR2_TARGET_UBOOT_FORMAT_REMAKE_ELF=y
 BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=versal-vpk180-revA"
 BR2_TARGET_XILINX_EMBEDDEDSW=y
+BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PLM=y
 BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL_PSMFW=y
 BR2_TARGET_XILINX_PREBUILT=y
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Luca Ceresoli via buildroot]

On Tue, 17 Jun 2025 21:58:01 +0100
Neal Frager <neal.frager@amd.com> wrote:

> This patch adds a family variant choice to xilinx-embeddedsw for two reasons.
> 
> 1. It does not make sense to build a zynqmp_pmufw for a versal platform or
> versal_plm and versal_psmfw applications for a zynqmp platform.  With this
> solution, users can only select applications which are targeted for their
> device family.

I think ZynqmMP is based on Cortex-A53 and Versal on Cortex-A72, so
could the various Kconfig symbols depend on either  BR2_cortex_a53
or BR2_cortex_a72, without additional symbols?

> 2. Buildroot will soon be adding support for the versal_2ve_2vm second gen
> family. This family has a plm boot application that generates a plm.elf just
> like the current versal platform. If a user was to select both the versal_plm
> and the versal_2ve_2vm_plm, two different plm.elf files will be generated
> causing a conflict at the installation step and a run-time failure when the
> wrong plm.elf gets included in the boot.bin.  By having a family variant,
> only one plm.elf can be built at a time depending on the choice of family
> variant being "versal" or "versal_2ve_2vm".

Is this new family based on A53 or A72? If it is, clearly the above
idea won't work for the new family, so in that case see my discussion
below.

> The issue can be seen by comparing the two Makefiles which both create a
> plm.elf.
> 
> versal plm:
> https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal
> 
> versal_2ve_2vm plm:
> https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal_2ve_2vm
> 
> Signed-off-by: Neal Frager <neal.frager@amd.com>
> ---
>  boot/xilinx-embeddedsw/Config.in | 15 +++++++++++++++
>  configs/versal_vck190_defconfig  |  1 +
>  configs/versal_vek280_defconfig  |  1 +
>  configs/versal_vpk180_defconfig  |  1 +
>  4 files changed, 18 insertions(+)
> 
> diff --git a/boot/xilinx-embeddedsw/Config.in b/boot/xilinx-embeddedsw/Config.in
> index 0dd6433608..7af8d59929 100644
> --- a/boot/xilinx-embeddedsw/Config.in
> +++ b/boot/xilinx-embeddedsw/Config.in
> @@ -28,8 +28,21 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSION
>  	  Release version of Xilinx/embeddedsw.
>  	  Must be xilinx_v2023.1 or newer.
>  
> +choice
> +	bool "family variant"
> +	default BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> +
> +config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
> +	bool "versal"
> +
> +config BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> +	bool "zynqmp"
> +
> +endchoice

I agree about the overall idea. I'm not sure the xilinx-embeddedsw
package is the ideal place, though. We already have
BR2_TARGET_UBOOT_ZYNQMP in the u-boot options, and similar
setting might be needed in the future for other packages. Users are in
charge of configuring all those consistently, in different sub-menus.

So I wonder whether it might make sense to add a family selection in a
global place, and then have both uboot and xilinx-embeddedsw follow it.

I'm not sure where that might be added, though. The "Target options"
menu looks like the obvious place, but currently it is used only for
core-specific options, not SoC-specific ones.

Another possible place is the "Bootloaders" menu. While less ambitious,
the need for family selection is limited to bootloader-related packages.

Other opinions?

Best regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Frager, Neal via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 4595 bytes --]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Luca,

> This patch adds a family variant choice to xilinx-embeddedsw for two reasons.
>
> 1. It does not make sense to build a zynqmp_pmufw for a versal platform or
> versal_plm and versal_psmfw applications for a zynqmp platform.  With this
> solution, users can only select applications which are targeted for their
> device family.

> I think ZynqmMP is based on Cortex-A53 and Versal on Cortex-A72, so
> could the various Kconfig symbols depend on either  BR2_cortex_a53
> or BR2_cortex_a72, without additional symbols?

Yes, this could work.

zynqmp is cortex_a53
versal is cortex_a72
versal_gen2 is cortex_a78

> 2. Buildroot will soon be adding support for the versal_2ve_2vm second gen
> family. This family has a plm boot application that generates a plm.elf just
> like the current versal platform. If a user was to select both the versal_plm
> and the versal_2ve_2vm_plm, two different plm.elf files will be generated
> causing a conflict at the installation step and a run-time failure when the
> wrong plm.elf gets included in the boot.bin.  By having a family variant,
> only one plm.elf can be built at a time depending on the choice of family
> variant being "versal" or "versal_2ve_2vm".

> Is this new family based on A53 or A72? If it is, clearly the above
> idea won't work for the new family, so in that case see my discussion
> below.

Even though your above idea works, I still like the global family idea.

> The issue can be seen by comparing the two Makefiles which both create a
> plm.elf.
>
> versal plm:
> https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal
>
> versal_2ve_2vm plm:
> https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal_2ve_2vm
>
> Signed-off-by: Neal Frager <neal.frager@amd.com>
> ---
>  boot/xilinx-embeddedsw/Config.in | 15 +++++++++++++++
>  configs/versal_vck190_defconfig  |  1 +
>  configs/versal_vek280_defconfig  |  1 +
>  configs/versal_vpk180_defconfig  |  1 +
>  4 files changed, 18 insertions(+)
>
> diff --git a/boot/xilinx-embeddedsw/Config.in b/boot/xilinx-embeddedsw/Config.in
> index 0dd6433608..7af8d59929 100644
> --- a/boot/xilinx-embeddedsw/Config.in
> +++ b/boot/xilinx-embeddedsw/Config.in
> @@ -28,8 +28,21 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSION
>          Release version of Xilinx/embeddedsw.
>          Must be xilinx_v2023.1 or newer.
>
> +choice
> +     bool "family variant"
> +     default BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> +
> +config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
> +     bool "versal"
> +
> +config BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> +     bool "zynqmp"
> +
> +endchoice

> I agree about the overall idea. I'm not sure the xilinx-embeddedsw
> package is the ideal place, though. We already have
BR2_TARGET_UBOOT_ZYNQMP in the u-boot options, > and similar
> setting might be needed in the future for other packages. Users are in
> charge of configuring all those consistently, in different sub-menus.

> So I wonder whether it might make sense to add a family selection in a
> global place, and then have both uboot and xilinx-embeddedsw follow it.

> I'm not sure where that might be added, though. The "Target options"
> menu looks like the obvious place, but currently it is used only for
> core-specific options, not SoC-specific ones.

> Another possible place is the "Bootloaders" menu. While less ambitious,
> the need for family selection is limited to bootloader-related packages.

> Other opinions?

> Best regards,
> Luca

Perhaps a global SoC family definition for bootloaders could make sense.

For Xilinx SoCs, there are three packages which would use it:

uboot
xilinx-embeddedsw
xilinx-prebuilt

However, if we do this, both uboot and xilinx-prebuilt already have family definitions.

We would need to remain backwards compatible with these already defined definitions.

Also, we would need to think about how to handle zynqmp and kria.

For xilinx-embeddedsw and uboot, zynqmp and kria are the same,
but for xilinx-prebuilt, this is not the case.

Also, since versal products boot with a microblaze running the plm app,
and not the u-boot spl, I am not sure if uboot will ever need a versal specific config.

When I get back from vacation, I will resubmit this patch
using the BR2_cortex configs.

We can then think about whether creating a global SoC family definition
makes sense as a next step.

Best regards,
Neal Frager
AMD

[-- Attachment #1.2: Type: text/html, Size: 10539 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Luca Ceresoli via buildroot]

Hello core Buildroot developers,

On Wed, 9 Jul 2025 23:13:09 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:

> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> Hi Luca,
> 
> > This patch adds a family variant choice to xilinx-embeddedsw for two reasons.
> >
> > 1. It does not make sense to build a zynqmp_pmufw for a versal platform or
> > versal_plm and versal_psmfw applications for a zynqmp platform.  With this
> > solution, users can only select applications which are targeted for their
> > device family.  
> 
> > I think ZynqmMP is based on Cortex-A53 and Versal on Cortex-A72, so
> > could the various Kconfig symbols depend on either  BR2_cortex_a53
> > or BR2_cortex_a72, without additional symbols?  
> 
> Yes, this could work.
> 
> zynqmp is cortex_a53
> versal is cortex_a72
> versal_gen2 is cortex_a78
> 
> > 2. Buildroot will soon be adding support for the versal_2ve_2vm second gen
> > family. This family has a plm boot application that generates a plm.elf just
> > like the current versal platform. If a user was to select both the versal_plm
> > and the versal_2ve_2vm_plm, two different plm.elf files will be generated
> > causing a conflict at the installation step and a run-time failure when the
> > wrong plm.elf gets included in the boot.bin.  By having a family variant,
> > only one plm.elf can be built at a time depending on the choice of family
> > variant being "versal" or "versal_2ve_2vm".  
> 
> > Is this new family based on A53 or A72? If it is, clearly the above
> > idea won't work for the new family, so in that case see my discussion
> > below.  
> 
> Even though your above idea works, I still like the global family idea.
> 
> > The issue can be seen by comparing the two Makefiles which both create a
> > plm.elf.
> >
> > versal plm:
> > https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal
> >
> > versal_2ve_2vm plm:
> > https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/versal_plm/src/versal_2ve_2vm
> >
> > Signed-off-by: Neal Frager <neal.frager@amd.com>
> > ---
> >  boot/xilinx-embeddedsw/Config.in | 15 +++++++++++++++
> >  configs/versal_vck190_defconfig  |  1 +
> >  configs/versal_vek280_defconfig  |  1 +
> >  configs/versal_vpk180_defconfig  |  1 +
> >  4 files changed, 18 insertions(+)
> >
> > diff --git a/boot/xilinx-embeddedsw/Config.in b/boot/xilinx-embeddedsw/Config.in
> > index 0dd6433608..7af8d59929 100644
> > --- a/boot/xilinx-embeddedsw/Config.in
> > +++ b/boot/xilinx-embeddedsw/Config.in
> > @@ -28,8 +28,21 @@ config BR2_TARGET_XILINX_EMBEDDEDSW_VERSION
> >          Release version of Xilinx/embeddedsw.
> >          Must be xilinx_v2023.1 or newer.
> >
> > +choice
> > +     bool "family variant"
> > +     default BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> > +
> > +config BR2_TARGET_XILINX_EMBEDDEDSW_VERSAL
> > +     bool "versal"
> > +
> > +config BR2_TARGET_XILINX_EMBEDDEDSW_ZYNQMP
> > +     bool "zynqmp"
> > +
> > +endchoice  
> 
> > I agree about the overall idea. I'm not sure the xilinx-embeddedsw
> > package is the ideal place, though. We already have  
> BR2_TARGET_UBOOT_ZYNQMP in the u-boot options, > and similar
> > setting might be needed in the future for other packages. Users are in
> > charge of configuring all those consistently, in different sub-menus.  
> 
> > So I wonder whether it might make sense to add a family selection in a
> > global place, and then have both uboot and xilinx-embeddedsw follow it.  
> 
> > I'm not sure where that might be added, though. The "Target options"
> > menu looks like the obvious place, but currently it is used only for
> > core-specific options, not SoC-specific ones.  
> 
> > Another possible place is the "Bootloaders" menu. While less ambitious,
> > the need for family selection is limited to bootloader-related packages.  
> 
> > Other opinions?  
> 
> > Best regards,
> > Luca  
> 
> Perhaps a global SoC family definition for bootloaders could make sense.

For the need discussed in this thread, a shortcut was found based on
the fortunate coincidence that all SoC families impacted by
xilinx-embeddedsw are based on a different CPU core (a72, a53...).
However this is not necessarily happening in similar future use cases.

So I'm raising this topic to the attention of core Buildroot developers
as the next Buildroot Developer Days are coming in a short time. Some
discussion there may be useful to bring ideas and opinions about how to
handle such SoC-family-specific differentiation within packages ina
generic way.

> For Xilinx SoCs, there are three packages which would use it:
> 
> uboot
> xilinx-embeddedsw
> xilinx-prebuilt
> 
> However, if we do this, both uboot and xilinx-prebuilt already have family definitions.
> 
> We would need to remain backwards compatible with these already defined definitions.
> 
> Also, we would need to think about how to handle zynqmp and kria.
> 
> For xilinx-embeddedsw and uboot, zynqmp and kria are the same,
> but for xilinx-prebuilt, this is not the case.
> 
> Also, since versal products boot with a microblaze running the plm app,
> and not the u-boot spl, I am not sure if uboot will ever need a versal specific config.
> 
> When I get back from vacation, I will resubmit this patch
> using the BR2_cortex configs.
> 
> We can then think about whether creating a global SoC family definition
> makes sense as a next step.
> 
> Best regards,
> Neal Frager
> AMD



-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice

[Thomas Petazzoni via buildroot]

On Wed, 13 Aug 2025 10:20:24 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:

> > Perhaps a global SoC family definition for bootloaders could make sense.  
> 
> For the need discussed in this thread, a shortcut was found based on
> the fortunate coincidence that all SoC families impacted by
> xilinx-embeddedsw are based on a different CPU core (a72, a53...).
> However this is not necessarily happening in similar future use cases.
> 
> So I'm raising this topic to the attention of core Buildroot developers
> as the next Buildroot Developer Days are coming in a short time. Some
> discussion there may be useful to bring ideas and opinions about how to
> handle such SoC-family-specific differentiation within packages ina
> generic way.

I haven't followed the whole discussion. We do already have some SoC
selection for i.MX platforms somewhere in package/freescale-imx/.

I am a bit balanced with this idea of having a top-level SoC selection.
On one hand it would indeed help to show/not show relevant packages. On
the other hand, people will think "my SoC is not in this list, so
Buildroot doesn't support it" just like people already think "there is
no defconfig in Buildroot, so Buildroot doesn't support my platform".
Also, it would be a quite long list to maintain. So I'm not fully
against, but I'm not super sold to it as well.

So far on the bootloaders side, I believe what matters is appropriate
help text describing for which platform a given package is designed, if
it's a platform-specific package.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot