-----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