From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 18 Feb 2013 12:02:49 -0600
Subject: [U-Boot] [PATCH v7 13/19] Makefile: u-boot-with-spl.bin: Fix
 SPL padding
In-Reply-To: <1440655831.1552569.1361210452143.JavaMail.root@advansee.com>
	(from benoit.thebaudeau@advansee.com on Mon Feb 18 12:00:52 2013)
References: <1360961665-10693-1-git-send-email-benoit.thebaudeau@advansee.com>
	<1360961665-10693-13-git-send-email-benoit.thebaudeau@advansee.com>
	<1954515158.1528901.1361117809127.JavaMail.root@advansee.com>
	<20130218165059.GB30970@bill-the-cat>
	<28742411.1551753.1361208406225.JavaMail.root@advansee.com>
	<51226496.8070509@ti.com>
	<1440655831.1552569.1361210452143.JavaMail.root@advansee.com>
Message-ID: <1361210569.14186.2@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:00:52 PM, Beno?t Th?baudeau wrote:
> On Monday, February 18, 2013 6:27:50 PM, Tom Rini wrote:
> > > Commit 74752ba performs a '--pad-to=$(or $(CONFIG_SPL_PAD_TO),0)'
> > > on u-boot-spl. I could use this CONFIG_SPL_PAD_TO for this series
> > > too, but is it really necessary to have both CONFIG_SPL_PAD_TO and
> > > CONFIG_SPL_MAX_SIZE? In other words, is there any case for which
> > > CONFIG_SPL_PAD_TO could be different from CONFIG_SPL_TEXT_BASE +
> > > CONFIG_SPL_MAX_SIZE for a valid reason?

They're logically different things.

> > I was wondering along those lines.  I don't _think_ we need both
> > CONFIG_SPL_PAD_TO and CONFIG_SPL_MAX_SIZE, but we can't combine
> > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_TEXT_BASE as on TI platforms we
> > start quite well above zero (0x402F0400 on am33xx, etc).  That  
> said, I
> > guess we do need CONFIG_SPL_PAD_TO so that some platforms can do:
> > #define CONFIG_SPL_PAD_TO (CONFIG_SPL_TEXT_BASE +  
> CONFIG_SPL_MAX_SIZE)
> > and others just
> > #define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE
> 
> If we did like my patch here, i.e. use objcopy with u-boot-spl.bin  
> instead of
> u-boot-spl, objcopy would always get a fake 0x0 address at the  
> beginning of the
> .bin, so CONFIG_SPL_MAX_SIZE could be used with --pad-to, and  
> CONFIG_SPL_PAD_TO
> would be useless.
> 
> 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?  Maybe it's easier for the SPL to load  
from a particular offset (e.g. NAND starting at the beginning of a  
block)?

-Scott