From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Fri, 5 Apr 2013 19:32:54 +0200 (CEST)
Subject: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker
 scripts
In-Reply-To: <20130405160030.GG32357@bill-the-cat>
References: <1365113633-31281-1-git-send-email-albert.u.boot@aribaud.net>
	<436405570.1175811.1365116753714.JavaMail.root@advansee.com>
	<1194440159.1175839.1365117231970.JavaMail.root@advansee.com>
	<20130405015438.1382cb09@lilith>
	<1130429503.1176502.1365133495160.JavaMail.root@advansee.com>
	<20130405080043.531e1b3d@lilith>
	<300263803.1207216.1365170206861.JavaMail.root@advansee.com>
	<20130405160030.GG32357@bill-the-cat>
Message-ID: <30209879.1303556.1365183174121.JavaMail.root@advansee.com>
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

Hi Tom,

On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote:
> On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote:
> > Hi Albert,
> > 
> > On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote:
> > > Hi Beno??t,
> [snip]
> > > IIUC, this future patch would increase the limit for SPL run-time size,
> > > as the constant against which the ASS tests __bss_end for would
> > > necessarily be greater than it is now. Correct? If so, this future
> > > patch should not break any target, as it would loosen the constraint,
> > > not tighten it.
> > 
> > Yes, it would either be the same or relaxed a bit, depending on the chosen
> > option:
> >  - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE +
> >    CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger
> >    than
> >    currently, depending on the new values for CONFIG_SPL_MAX_SIZE and
> >    CONFIG_SPL_BSS_MAX_SIZE.
> >  - Define a new config meaning text + data + rodata + bss (e.g.
> >    CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just
> >    replace
> >    CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds,
> >    taking
> >    care that this was the only meaning those users were giving to
> >    CONFIG_SPL_MAX_SIZE.
> > 
> > The first option would probably be preferable, using the same value for
> > CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE.
> 
> I think the problem is that Tegra really needs the second case as their
> constraint is "must fit below next part of payload".  We can assume the
> users of that linker script today care about footprint and update their
> define I believe.  da850evm and the rest of the davinci platforms would
> also be a case to convert to this, but the omap*/am3* platforms would
> not.

Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different
config name (as in option 2 above) just for Tegra, and another assert for
CONFIG_SPL_MAX_SIZE against __bss_start.

And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there
is not another special case somewhere.

Best regards,
Beno?t