* [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice @ 2025-06-17 20:58 Neal Frager via buildroot 2025-07-09 15:08 ` Luca Ceresoli via buildroot 0 siblings, 1 reply; 5+ messages in thread From: Neal Frager via buildroot @ 2025-06-17 20:58 UTC (permalink / raw) To: buildroot Cc: ibai.erkiaga-elorza, luca.ceresoli, Neal Frager, brandon.maier, ju.o, thomas.petazzoni, romain.naour, michal.simek, romain.naour 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice 2025-06-17 20:58 [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice Neal Frager via buildroot @ 2025-07-09 15:08 ` Luca Ceresoli via buildroot 2025-07-09 23:13 ` Frager, Neal via buildroot 0 siblings, 1 reply; 5+ messages in thread From: Luca Ceresoli via buildroot @ 2025-07-09 15:08 UTC (permalink / raw) To: Neal Frager Cc: ibai.erkiaga-elorza, buildroot, brandon.maier, ju.o, thomas.petazzoni, romain.naour, michal.simek, romain.naour 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice 2025-07-09 15:08 ` Luca Ceresoli via buildroot @ 2025-07-09 23:13 ` Frager, Neal via buildroot 2025-08-13 8:20 ` Luca Ceresoli via buildroot 0 siblings, 1 reply; 5+ messages in thread From: Frager, Neal via buildroot @ 2025-07-09 23:13 UTC (permalink / raw) To: Luca Ceresoli Cc: Erkiaga Elorza, Ibai, buildroot@buildroot.org, brandon.maier@collins.com, ju.o@free.fr, thomas.petazzoni@bootlin.com, romain.naour@smile.fr, Simek, Michal, romain.naour@gmail.com [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice 2025-07-09 23:13 ` Frager, Neal via buildroot @ 2025-08-13 8:20 ` Luca Ceresoli via buildroot 2025-08-13 10:33 ` Thomas Petazzoni via buildroot 0 siblings, 1 reply; 5+ messages in thread From: Luca Ceresoli via buildroot @ 2025-08-13 8:20 UTC (permalink / raw) To: Frager, Neal, arnout@rnout.be, thomas.petazzoni@bootlin.com, peter@korsgaard.com, romain.naour@smile.fr Cc: buildroot@buildroot.org, Simek, Michal, ju.o@free.fr, brandon.maier@collins.com, romain.naour@gmail.com, Erkiaga Elorza, Ibai 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice 2025-08-13 8:20 ` Luca Ceresoli via buildroot @ 2025-08-13 10:33 ` Thomas Petazzoni via buildroot 0 siblings, 0 replies; 5+ messages in thread From: Thomas Petazzoni via buildroot @ 2025-08-13 10:33 UTC (permalink / raw) To: Luca Ceresoli Cc: Erkiaga Elorza, Ibai, buildroot@buildroot.org, brandon.maier@collins.com, ju.o@free.fr, Frager, Neal, romain.naour@smile.fr, Simek, Michal, romain.naour@gmail.com 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-08-13 10:33 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-06-17 20:58 [Buildroot] [PATCH v1 1/1] boot/xilinx-embeddedsw: add family variant choice Neal Frager via buildroot 2025-07-09 15:08 ` Luca Ceresoli via buildroot 2025-07-09 23:13 ` Frager, Neal via buildroot 2025-08-13 8:20 ` Luca Ceresoli via buildroot 2025-08-13 10:33 ` Thomas Petazzoni via buildroot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.