On Sun, Feb 14, 2021 at 08:25:27AM +0100, Roger Pau Monné wrote:
On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote:
Hi Roger,
Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne:
From: Roger Pau Monné royger@FreeBSD.org
Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. Removing the setting from the defconfig allows U-Boot to load successfully.
Hmm, I'd disagree slightly.
In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as
/* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */ #define CONFIG_SPL_PAD_TO 8355840
so it's a static value but based on the MMCSD_RAW_MODE... config option.
So instead of mandating one specific MMCSD_RAW_MODE... value that CONFIG_SPL_PAD_TO should be defined based on the the actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and not some static number that then gets enforced for all boards.
Sure, I can fix CONFIG_SPL_PAD_TO to be calculated based on MMCSD_RAW_MODE...
So that's easier said that done. CONFIG_SPL_PAD_TO ends up being used by the call to objcopy, so using an expression instead of an absolute number leads to:
aarch64-none-elf-objcopy --gap-fill=0xff -j .text -j .secure_text -j .secure_data -j .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j .binman_sym_table -j .text_rest -j .dtb.i nit.rodata -I binary -O binary --pad-to="((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)" --gap-fill=0xff idbloader.img u-boot-rockchip.bin && cat u-boot.itb >> u-boot-rockchip.bin || { rm - f u-boot-rockchip.bin; false; } aarch64-none-elf-objcopy: --pad-to: bad number: ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)
And fixing this seems like a much bigger issue to tackle than the original patch. The current way to propagate CONFIG_ values to Makefiles is by the output of `cc -E -dM`, which won't perform the arithmetic.
We could create a small tool using HOSTCC to print the values of the macros, but as said above that's not trivial IMO.
Thanks, Roger.