From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 5 Apr 2013 12:00:30 -0400 Subject: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts In-Reply-To: <300263803.1207216.1365170206861.JavaMail.root@advansee.com> 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> Message-ID: <20130405160030.GG32357@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: