From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Date: Fri, 5 Apr 2013 21:17:40 +0200 [thread overview]
Message-ID: <20130405211740.72080ec0@lilith> (raw)
In-Reply-To: <20130405175521.GI32357@bill-the-cat>
Hi Tom,
On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini <trini@ti.com> 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
#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,
--
Albert.
next prev parent reply other threads:[~2013-04-05 19:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 22:13 [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts Albert ARIBAUD
2013-04-04 23:05 ` Benoît Thébaudeau
2013-04-04 23:13 ` Benoît Thébaudeau
2013-04-04 23:54 ` Albert ARIBAUD
2013-04-05 3:44 ` Benoît Thébaudeau
2013-04-05 6:00 ` Albert ARIBAUD
2013-04-05 13:53 ` Tom Rini
2013-04-05 15:59 ` Stephen Warren
2013-04-11 17:52 ` Tom Warren
2013-04-11 17:59 ` Albert ARIBAUD
2013-04-11 18:13 ` Tom Warren
2013-04-05 13:56 ` Benoît Thébaudeau
2013-04-05 16:00 ` Tom Rini
2013-04-05 17:32 ` Benoît Thébaudeau
2013-04-05 17:55 ` Tom Rini
2013-04-05 19:17 ` Albert ARIBAUD [this message]
2013-04-05 19:28 ` Albert ARIBAUD
2013-04-05 19:44 ` Tom Rini
2013-04-05 20:04 ` Albert ARIBAUD
2013-04-05 20:23 ` Tom Rini
2013-04-08 19:03 ` Albert ARIBAUD
2013-04-08 19:56 ` Tom Rini
2013-04-08 20:05 ` Albert ARIBAUD
2013-04-04 23:12 ` Albert ARIBAUD
2013-04-11 15:30 ` Albert ARIBAUD
2013-04-11 15:43 ` [U-Boot] [PATCH V2] " Albert ARIBAUD
2013-04-12 16:34 ` Albert ARIBAUD
2013-04-13 21:16 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130405211740.72080ec0@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox