[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

[Peter Tyser <ptyser@xes-inc.com>]

On Wed, 2009-10-07 at 01:07 +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1254862383.24664.2742.camel@localhost.localdomain> you wrote:
> >
> > What's the advantage of having the bss not be located next to U-Boot?
> 
> One advantage is that we might chose the same address for all boards,
> and eventually for all Power processor families.

We could achieve this wherever we end up putting the bss.  eg if people
think putting the bss right after the u-boot image is best, we can
update the 44x linker script, etc to do the same thing.  I think this
discussion is applicable to most any PPC board.

> One disadvantage is that we need to relocate it separately, or we will
> have a gap in the RAm memory map which is IMO not acceptable.

What does "relocating the bss separately" entail?

> > 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
> 
> Why should it not be used?  You seem to be pretty fixed on that idea,
> which is wrong. No code will ever be written to RAM at list location.

When I say user, I'm refering to an end user, eg a customer.  Not a
developer.

For arguments sake, lets say we developers put the bss at a "fixed
(random, non-zero) address" of 0x80000.  A user tftps an image to
0x80000 and suddenly their board starts acting up.

> In the current setup, we don't write any code to RAM at 0x0 either.

Right, and this limitation causes headaches.  I personally get lots of
questions from customers about why their board hangs when they tftp an
image to 0x0.  In a perfect world we'd only have 1 reserved section of
memory which contained the interrupt vectors, text, bss, malloc, stack,
etc.



> > corrupt their exception vectors or stack/malloc pool/u-boot code, I
> > don't want to add more bss questions:)

Its crappy to have 2 sections of memory that a user has to know not to
touch, I don't want to have 3:)

Maybe I'm not understanding your suggestion "to chose a fixed (random,
non-zero) address" for the bss.  That implies to me we choose an address
low memory (eg 0x10000) and put the bss there.  I think it'd be more
plausible for someone to blow this away accidentally than high memory by
U-Boot, and you also couldn't use any data stored in the bss after you
blow it away, eg right before jumping to a linux kernel.

Best,
Peter