[Buildroot] [PATCH v2 1/1] boot/uboot/uboot.mk: add stripped u-boot.elf support

[Frager, Neal]

Hello Luca,

> If a user requests a u-boot binary in elf format, they may actually 
> want the stripped u-boot.elf version.
> This patch provides the stripped u-boot.elf binary.
> 
> Signed-off-by: Neal Frager <neal.frager at amd.com>
> ---
> V1->V2:
>   - reduced scope to only 64-bit ARM arch platforms
>   - non-ARM platforms may not have a u-boot.elf by default
> ---
>  boot/uboot/uboot.mk | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk index 
> 0439ec5e4b..61b3074163 100644
> --- a/boot/uboot/uboot.mk
> +++ b/boot/uboot/uboot.mk
> @@ -54,6 +54,9 @@ endif
>  
>  ifeq ($(BR2_TARGET_UBOOT_FORMAT_ELF),y)
>  UBOOT_BINS += u-boot
> +ifeq ($(BR2_aarch64),y)
> +UBOOT_BINS += u-boot.elf
> +endif

> Is it really assured that all arm64 do build this file? And that u-boot.elf is not useful for other architectures?

> Looking at the U-Boot source code, it looks like this file is built if CONFIG_REMAKE_ELF is enabled, which seems independent on the architecture and happens for some non-arm64 defconfigs as well (e.g.
> netgear_dgnd3700v2_ram_defconfig).

> At first glance, it looks like we need (yet) another Kconfig knob in Buildroot to manage this cleanly. Otherwise in UBOOT_INSTALL_IMAGES_CMDS we might just install u-boot.elf if it is present,skip it silently otherwise.

> Not sure which solution is less appealing. :(

Perhaps just checking every file for existence when running the loop below is the best option like below.  The idea is to keep this as simple as possible.  What do you think?

define UBOOT_INSTALL_IMAGES_CMDS
	$(foreach f,$(UBOOT_BINS), \
			$(if test -f $(@D)/$(f), \
			cp -dpf $(@D)/$(f) $(BINARIES_DIR))/
	)

Best regards,
Neal Frager
AMD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 14644 bytes
Desc: not available
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20221122/0aff053c/attachment-0001.bin>