On 02/18/2013 12:00:52 PM, Benoît Thébaudeau wrote:
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?
They're logically different things.
> 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.
Why not allow that possibility? Maybe it's easier for the SPL to load
from a particular offset (e.g. NAND starting at the beginning of a
block)?
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
