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 15:53:03 -0500 [thread overview]
Message-ID: <1254862383.24664.2742.camel@localhost.localdomain> (raw)
In-Reply-To: <4ACBA9BA.809@comcast.net>
On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote:
> 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
> >
> FWIW, I think an arbitrary address disjoint from the u-boot addresses is
> best. While u-boot is in ROM, you can't use the bss anyway. The bss will
> actually be located at an address selected by the u-boot code itself
> after memory is sized. All references to the bss will be re-located by
> subtracting the arbitrary start address and adding the run-time chosen
> start address. So the linked start address is not important, except that
> is cannot be NULL or it may confuse the relocation code that doesn't
> want to re-locate NULL pointers. Some of the confusion in this
> discussion probably stems from the fact that the linker scripts make the
> bss look like "part of u-boot", when it is really not. It is just a
> chunk of "zero'ed" ram, located anywhere the u-boot code decides to put
> it. An arbitrary strange address would make this more apparent.
Hi Bill,
What's the advantage of having the bss not be located next to U-Boot?
The big disadvantage of picking an arbitrary address for the bss is that
there's now 1 more magical section of SDRAM that the user needs to know
shouldn't be used. I already field enough question from people that
corrupt their exception vectors or stack/malloc pool/u-boot code, I
don't want to add more bss questions:)
Best,
Peter
PS. please keep the original email recipients on CC
next prev parent reply other threads:[~2009-10-06 20:53 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 [this message]
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
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=1254862383.24664.2742.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