[PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR

["Roger Pau Monné" <royger@freebsd.org>]

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.