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

[Wolfgang Denk]

Dear Peter Tyser,

In message <1254871741.24664.3117.camel at localhost.localdomain> you wrote:
>
> > 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 relocation routine would have to check the relocated address; if
it falls into the bss, it has to add a different offset than
otherwise. This way the location of the bss after relocation is moved
close to the U-Boot image, avoiding gaps that just cost memory.

> > 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.

Me too.

> 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.

No, it doesn't. It works perfectly well. The 0x80000 address is
something that is ONLY used in the image as created by the linker, i.
e. _before_ relocation. We no data gets ever written there. The end
user who runs TFTP sees the system _after_ relocation, when the real
bss has been allocated in high memory (just as it is now) and all
symbols have been fixed 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.

But this has _nothing_ to do with the fact that the bss is at 0x0. The
problem is caused by overwriting the exception vectors, which is a
completely different story.

> > > 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:)

Neither do I. This would not change.

> 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

Yes, but ONLY for linking the image. Here the bss address is just
_any_ address, more or less a virtual thing that just needs to be
there so we can calculate the size later.

After relocation, i. e. when the end user sees it, the setupo shall be
exactly the same as now, i. e. allocation of memory starting from end
of available RAM downward would look like that:

	[End of RAM]
	if configured: area that won't get touched by U-Boot and Linux
	if configured: shared log buffer
	if configured: pRAM (Protected RAM - unchanged by reset)
	if configured: LCD or video framebuffer
	.bss
	.u_boot_cmd
	.data
	.rodata
	.text
	malloc arena
	board info struct
	stack (growing downward)

Except for gaps caused for alignment purposes, these parts shall be
tightly packed to make for as small a memory footprint as possible.

> 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.

You still fail to understand that the bss "address" as used for the
linking of the image is unrelated to the storage area that later gets
zeroed and used as bss. The former is before, the later after
relocation to RAM.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In order to succeed in any enterprise, one  must  be  persistent  and
patient.  Even  if  one  has to run some risks, one must be brave and
strong enough to meet and overcome vexing challenges  to  maintain  a
successful  business  in  the  long  run.  I  cannot help saying that
Americans lack this necessary challenging spirit today.
- Hajime Karatsu