From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 18 Feb 2013 12:24:51 -0600
Subject: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix
 SPL padding
In-Reply-To: <845050354.1555601.1361211777995.JavaMail.root@advansee.com>
	(from benoit.thebaudeau@advansee.com on Mon Feb 18 12:22:58 2013)
Message-ID: <1361211891.14186.9@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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