On Monday, February 18, 2013 9:06:30 PM, Scott Wood wrote:
On 02/18/2013 02:01:59 PM, Benoît Thébaudeau wrote:
On Monday, February 18, 2013 8:47:28 PM, Scott Wood wrote:
On 02/18/2013 01:52:10 PM, Benoît Thébaudeau wrote:
On Monday, February 18, 2013 8:37:29 PM, Scott Wood wrote:
On 02/17/2013 10:16:49 AM, Benoît Thébaudeau wrote:
all the more none of the various values defined for CONFIG_SYS_TEXT_BASE relatively to CONFIG_SPL_TEXT_BASE would be compatible with an image built
by
appending U-Boot to the generic SPL. Can you confirm?
I don't follow. CONFIG_SYS_TEXT_BASE is for where the payload
gets
loaded to, and has nothing to do with its position in the
SPL-concat
image, nor with the address that the SPL starts running at.
Right, sorry, I meant CONFIG_SYS_NAND_U_BOOT_OFFS. It is 0, which
is
not compatible with the payload being appended to the SPL in the programmed image.
That just means we load the whole thing, including SPL, so that
we're
always loading from the start of the block. Note the difference between CONFIG_SYS_NAND_U_BOOT_DST and CONFIG_SYS_NAND_U_BOOT_START.
OK. Hmm, this difference is CONFIG_SPL_MAX_SIZE, but CONFIG_SPL_PAD_TO is not defined, so the payload is right after the SPL in the image and the SPL jumps to somewhere in the middle of the payload?
It jumps to the beginning of the payload. As mentioned elsewhere in the thread, mpc85xx NAND SPL is always fixed size (done in the linker script) because the reset vector comes at the end. Thus, max size equals actual size without needing --pad-to.
OK, clear.
Benoît