From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 5 Apr 2013 21:28:21 +0200 Subject: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts In-Reply-To: <20130405211740.72080ec0@lilith> 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> <30209879.1303556.1365183174121.JavaMail.root@advansee.com> <20130405175521.GI32357@bill-the-cat> <20130405211740.72080ec0@lilith> Message-ID: <20130405212821.33d664b9@lilith> 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, 5 Apr 2013 21:17:40 +0200, Albert ARIBAUD wrote: > Hi Tom, > > On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini wrote: > > > On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: > > > 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. > > > > I didn't audit the PowerPC targets, but on ARM we have, roughly: > > - Tegra (covered in Stephen's email, and in short, must include BSS in > > size check) which uses SPL_MAX_SIZE to include BSS > > - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE > > - DaVinci which must also constrain BSS to the initial RAM, but for > > different reasons. > > - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the > > rest of the program. > > How about this? > > 1. In the u-boot*.lds files, doing separate asserts for SPL and SPL BSS > max size, with the SPL assert being further divided in two cases > depending on BSS max size being defined or not: > > #if defined(CONFIG_SPL_MAX_SIZE) > #if defined(CONFIG_SPL_BSS_MAX_SIZE) > ASSERT( __bss_end - __image_copy_start < (CONFIG_SPL_TEXT_BASE + \ > CONFIG_SPL_MAX_SIZE), "SPL image code+BSS too big"); > #else > ASSERT( __bss_end - __image_copy_start < CONFIG_SPL_TEXT_BASE, \ > CONFIG_SPL_MAX_SIZE), "SPL image code too big"); > #endif #endif (sorry) > #if defined(CONFIG_SPL_BSS_MAX_SIZE) > ASSERT( __bss_end - __bss_start < CONFIG_SPL_TEXT_BASE, \ > CONFIG_SPL_BSS_MAX_SIZE), "SPL image BSS too big"); > #endif > > 2. Defining CONFIG_SPL_BSS_MAX_SIZE only for Tegra, Davinci, IMX (where > CONFIG_SPL_BSS_MAX_SIZE is actually the gap size) > > 3. *Not* defining CONFIG_SPL_MAX_SIZE or CONFIG_SPL_BSS_MAX_SIZE for > OMAP*/AM3* > > 4. Adjusting README descriptions of CONFIG_SPL_[BSS_]MAX_SIZE and > ensuring Makefile uses the right size for --pad-to, as well as > the few other files which use CONFIG_SPL_MAX_SIZE. > > Amicalement, Amicalement, -- Albert.