From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
Date: Tue, 06 Oct 2009 16:13:45 -0500 [thread overview]
Message-ID: <1254863625.24664.2804.camel@localhost.localdomain> (raw)
In-Reply-To: <923FBCDE-A82D-409A-8F65-831F49A3F4C2@kernel.crashing.org>
On Tue, 2009-10-06 at 15:46 -0500, Kumar Gala wrote:
> On Oct 6, 2009, at 1:08 PM, Peter Tyser wrote:
>
> > On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote:
> >> Dear Peter Tyser,
> >>
> >> In message <1254843932.24664.2083.camel@localhost.localdomain> you
> >> wrote:
> >>>
> >>> I personally like the current implementation of putting the bss
> >>> after
> >>> the entire U-Boot image. It keeps U-Boot's code, malloc pool,
> >>> stack,
> >>> bss, etc all in the same general area which is nice, and has the
> >>> side
> >>> benefit that the bootpg won't be overwritten.
> >>
> >> OK, if you think so...
> >>
> >>> I know ORing in 0x10 is a bit ugly, but what's the real downside of
> >>> doing it?
> >>
> >> Nothing. I just hate to allocate the bss at 0x0, because this is
> >> actually incorrect - it's the result of an address overflow /
> >> truncation, and pretty much misleading to someone trying to read and
> >> understand the code. For the linked image, it does not _look_ as if
> >> the bss was located _after_ the U-Boot image, it looks detached and
> >> allocated in low RAM.
> >
> > Do you have a preference Kumar? You're probably going to be the first
> > in line to have to deal with any resulting confusion:)
> >
> > I personally would rank the options:
> > 1. OR in an offset to the bss address and leave some good comments in
> > the linker script and commit message
> >
> > 2. Make the bss the last section like other PPC boards which would
> > result in the bootpg sometimes being overwritten
> >
> > 3. Put the bss at an arbitrary address
>
> I don't have a preference, but maybe I missed the answer to my
> question about where does 44x put the BSS.
The 44x boards put the bss after "the rest" of u-boot, but before the
bootpg section. Sometimes the bss might overlap the bootpg which would
mean the bootpg would get zeroed out on bootup and the bss would "wrap
around to 0 (which is fine, just confusing). Eg:
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .resetvec PROGBITS fffffffc 03f2e4 000004 00 AX 0 0 1
[ 2] .bootpg PROGBITS fffff000 03e2e8 000250 00 AX 0 0 1
[ 3] .text PROGBITS fff80000 000094 0303b0 00 AX 0 0 4
[ 4] .rodata PROGBITS fffb03b0 030444 00a14c 00 A 0 0 4
[ 5] .reloc PROGBITS fffba500 03a594 002280 00 WA 0 0 4
[ 6] .data PROGBITS fffbc780 03c814 00088c 00 WA 0 0 4
[ 7] .data.rel.local PROGBITS fffbd00c 03d0a0 000a98 00 WA 0 0 4
[ 8] .data.rel.ro.loca PROGBITS fffbdaa4 03db38 0000b0 00 WA 0 0 4
[ 9] .data.rel PROGBITS fffbdb54 03dbe8 000100 00 WA 0 0 4
[10] .u_boot_cmd PROGBITS fffbdc54 03dce8 000600 00 WA 0 0 4
[11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 0 4
> Is it possible to put it before TEXTBASE?
I looked into that originally but couldn't get it to work via the linker
script alone. If we wanted to hardcode a bss size, we could pass "-Tbss
<TEXTBASE - HARDCODED_BSS_SIZE>" to ld to position it. We could
allocate some relatively huge chunk of memory for it below TEXTBASE, but
I'm not sure we could make it dynamically sized.
Peter
next prev parent reply other threads:[~2009-10-06 21:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-05 23:01 [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 Peter Tyser
2009-10-05 23:01 ` [U-Boot] [PATCH 1/2] 85xx: Preprocess link scripts Peter Tyser
2009-10-06 7:28 ` Wolfgang Denk
2009-10-06 11:13 ` Peter Tyser
2009-10-05 23:01 ` [U-Boot] [PATCH 2/2] 85xx: Ensure BSS segment doesn't start at address 0x0 Peter Tyser
2009-10-06 8:54 ` Wolfgang Denk
2009-10-06 12:10 ` Peter Tyser
2009-10-06 7:32 ` [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0 Wolfgang Denk
2009-10-06 12:01 ` Peter Tyser
2009-10-06 14:01 ` Wolfgang Denk
2009-10-06 14:07 ` Kumar Gala
2009-10-06 14:24 ` Peter Tyser
2009-10-06 15:22 ` Wolfgang Denk
2009-10-06 15:45 ` Peter Tyser
2009-10-06 17:51 ` Wolfgang Denk
2009-10-06 18:08 ` Peter Tyser
2009-10-06 20:34 ` J. William Campbell
2009-10-06 20:53 ` Peter Tyser
2009-10-06 22:34 ` J. William Campbell
2009-10-06 23:10 ` Peter Tyser
2009-10-06 23:25 ` Wolfgang Denk
2009-10-06 23:43 ` Peter Tyser
2009-10-07 0:09 ` Peter Tyser
2009-10-07 1:24 ` Graeme Russ
2009-10-07 6:55 ` Wolfgang Denk
2009-10-07 9:56 ` Graeme Russ
2009-10-07 10:07 ` Graeme Russ
2009-10-07 10:32 ` Joakim Tjernlund
2009-10-07 14:37 ` J. William Campbell
2009-10-07 6:53 ` Wolfgang Denk
2009-10-07 11:57 ` Peter Tyser
2009-10-07 12:19 ` Wolfgang Denk
2009-10-06 23:07 ` Wolfgang Denk
2009-10-06 23:29 ` Peter Tyser
2009-10-07 6:51 ` Wolfgang Denk
2009-10-06 20:46 ` Kumar Gala
2009-10-06 21:13 ` Peter Tyser [this message]
2009-10-06 16:53 ` Stefan Roese
2009-10-06 15:04 ` Wolfgang Denk
2009-10-06 15:20 ` Peter Tyser
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=1254863625.24664.2804.camel@localhost.localdomain \
--to=ptyser@xes-inc.com \
--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