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:
Before this patch, PAD_TO was used, but there is no such
definition
for this board for generic SPL, so this board seems broken,
"--pad-to=" with no argument behaves the same as "--pad-to=0",
though
since it's undocumented we now avoid relying on that behavior as you observed in a followup post.
OK.
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?
Best regards, Benoît