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

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2013 12:26 PM, Beno?t Th?baudeau wrote:

[snip]
> But I've just seen that commit 74752ba did something for that in
> u-boot/master, and this commit is not in u-boot-imx/master on which
> I based this series. Why is u-boot-imx/master not sync'ed with
> u-boot/master? How am I supposed to handle patch sets depending on
> several custodian repositories?

I'm not sure why u-boot-imx is out of sync at the moment.  My rule of
thumb is to start working on u-boot/master and cherry-pick out things
I need from other places into a -test branch.

I know the kernel folks have to deal with a lot of this as well, but I
think it ends up being a developer choice on what best fits their
needs when they need N different series to be applied for their
starting point.

> 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

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRImSWAAoJENk4IS6UOR1W0DkP/3VBLW0gdRoIfvNHpO3cI0Db
FfjKGQoCgAmrlCE4PyGo2SkkBPl/doxLWYCOr8DJ/BDnjF04r/8NMT/wn/a9xrvv
d5fCpIxQPme356SfMS23LVnTmJR4mOKLdHjJ2QXxyrFXXTnI7W80iPgfslgCTJje
kxbH5chVQq7LYN9ZeynOP9XEZYT9rTcAXG9LVPqStWi73izpMa/D0adc/FqdWfi3
qcstiSxSQyPWmF7O7dRYzs9J4BMcT749NuQmkvbrh64/XL81emynfrYCgBU70QMr
uQV9qxq+zALmUuMTdWRD0ATLQiybuN5Mbam7X4ACAmi8THfSEuUWtS3g0PR9+FH+
/HYICi8l2WDONRCWDcj5PLpQNYaNeunSPj+8q4g4i/OiEO+1rWZqtrgXxcH/WTlT
dz6C6w/YFhfCakKwB8r2+5H3GyIpoDgbqsCfxI8LTNDA69/zXohbH6uDNMqWDPAV
IS0+7Z3iC+MPmfkAXL2vz02CoiUiX2YwgYrhVrmPAbbsHSLndh2oAmGkdl8Hc2BK
zhCKW75bv1flXwBIE3skocKZTDTjiMsMKoqosiFtSIaXQsn6Zz7YYh4ZpCNE0U3C
P3GRpeotnXk0jRp6DOGKceWfVQLbY3rAZKWoMAjTujGIh3YfXRVU+KWLqi8APjNK
a2aPpMFx6Oy72BQvV11W
=zJru
-----END PGP SIGNATURE-----