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

[Wolfgang Denk <wd@denx.de>]

Dear Peter Tyser,

In message <1254870618.24664.3061.camel@localhost.localdomain> you wrote:
>
> I understand that the final addresses in RAM of all the sections are
> calculated by U-Boot during relocation based on memory size.  However,

True. And nothing is ever written to the bss addresses as recorded in
the linked image as running from flash, may thei be 0x0 0r 0x10 or
any other random address.

> the section addresses are the same relative to each other at link time
> as well as after relocation.  Eg before relocation I print out:
> 
> (408) &_start = fff80000
> (409) &__bss_start = (null)
> (410) &_end = 00008184
> Now running in RAM - U-Boot at: 7ff70000 (After relocation)
> (665) &_start = 7ff70000
> (666) &__bss_start = 7fff0000
> (667) &_end = 7fff8184
> 
> The values all changed and are dependent on RAM size, but their
> relationship to one another didn't - they all just increased by
> 0x7fff0000.  So practically speaking, we do need to know where the bss
> is at link time - its address is not dynamic like the malloc pool or
> stack - its tied directly to the address of the other sections at link
> time.  (Unless we added some bss-specific fixups I imagine)

Right, that's the current situation.

My suggestion was NOT to put the bss  at  a  fixed  _offset_  to  the
U-Boot  image,  but to a fixed absolute address. My hope is that this
might simplify the linker scripts at the cost of adding a little code
to the relocation routine - for addresses in the bss we would have to
add a different relocation offset.

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
Love sometimes expresses itself in sacrifice.
	-- Kirk, "Metamorphosis", stardate 3220.3