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

[Luca Ceresoli via buildroot <buildroot@buildroot.org>]

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