On 02/18/2013 12:22:58 PM, Benoît Thébaudeau wrote:
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:
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).
CONFIG_SPL_PAD_TO is for the placement of the payload -- and it's not a RAM address. Currently it is a link address (or zero if the linker script handles padding, or padding is not required for other reasons). With your patch it it is a file offset, IIUC.
CONFIG_SPL_MAX_SIZE is what it says -- the maximum size that the SPL may be, ideally to be enforced by the linker script.
They are different. An SPL wanting the payload to begin as a block boundary does not mean the hardware is suddenly capable of loading an entire block of SPL.
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).
So add a check that CONFIG_SPL_PAD_TO >= CONFIG_SPL_MAX_SIZE (assuming the new interpretation of CONFIG_SPL_PAD_TO as a file offset), and let CONFIG_SPL_PAD_TO default to CONFIG_SPL_MAX_SIZE if not set.
-Scott