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

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

On Monday, February 18, 2013 7:02:49 PM, Scott Wood wrote:
> 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?

To save a config setting (there are already many for SPL) if this is not
strictly required, but also for the reason below.

>  Maybe it's easier for the SPL to load
> from a particular offset (e.g. NAND starting at the beginning of a
> block)?

CONFIG_SPL_MAX_SIZE would be closer to a NAND mapping in that case (e.g. size of
1 NAND Flash block) than CONFIG_SPL_PAD_TO (address within RAM that should be
considered relatively to CONFIG_SPL_TEXT_BASE to get the NAND offset).

Also, CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE depend on each other: If both
can be defined, you may change one forgetting the other one, which could e.g.
result in an overlapping of SPL and U-Boot that won't show up at build time
(with CONFIG_SPL_MAX_SIZE = 0x1000 and CONFIG_SPL_PAD_TO = CONFIG_SPL_TEXT_BASE
+ 0x800, the SPL would build fine, and objcopy wouldn't complain).

Best regards,
Beno?t