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

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

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