[U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix SPL padding

[Benoît Thébaudeau]

On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote:
> > Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
> > on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
> > too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
> > CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
> > CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
> > CONFIG_SPL_MAX_SIZE for a valid reason?
> 
> I was wondering along those lines.  I don't _think_ we need both
> CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
> CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
> start quite well above zero (0x402F0400 on am33xx, etc).  That said, I
> guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
> #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE)
> and others just
> #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE

If we did like my patch here, i.e. use objcopy with u-boot-spl.bin instead of
u-boot-spl, objcopy would always get a fake 0x0 address at the beginning of the
.bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and CONFIG_SPL_PAD_TO
would be useless.

The only question is if we may need to have an empty gap between the SPL and
U-Boot within the resulting image. I don't think so since that would mean that
the target memory device has an area that is not really available at the
location of this gap.

Best regards,
Benoît