[U-Boot] [PATCH 2/4] Merge all mpc85xx platforms to use a single ld script

[Wolfgang Denk]

Dear Trent,

In message <Pine.LNX.4.64.0810140859340.3443 at t2.domain.actdsltmp> you wrote:
>
> > Where is bss then, if you try to locate it beyond the end of physical
> > memory? To the best of my understanding there are two  possibilities:
> > tool  chains  running  on  a  32 bit host will simply wrapr addresses
> > around, i. e. start placing bss at physical address 0, which  is  not
> > wrong.  I  don't remember eacty what you get on 64 bit hosts, but the
> > result is not correct either.
> 
> This is where bss goes when u-boot is linked.  It gets relocated to a
> different address in ram.

Where is defined which address it is, then?

Note that this added complexity of image layout is not shared by other
architectures.

> What the linker scripts *were* doing is putting bss at ADDR(.text) + 0x80000,
> which ends up being 0 for most boards and 0xf0000000 for some others.

Let's be careful here in our terminology. Your "most boards" is  most
probably  not  my "most boards". From the global point of view, "most
boards" have a very simple layout like this:

...
  . = ALIGN(256);
  __init_begin = .;
  .text.init : { *(.text.init) }
  .data.init : { *(.data.init) }
  . = ALIGN(256);
  __init_end = .;

  __bss_start = .;
  .bss (NOLOAD)      :
  {
   *(.sbss) *(.scommon)
   *(.dynbss)
   *(.bss)
   *(COMMON)
  }
  _end = . ;
  PROVIDE (end = .);
...

BTW - this example is from a MPC85xx system...

> Unless you try to make a non 512K image.  Then bss might end up at 0x40000
> when it should still be at 0.  You could hard code the address 0, there are

The bss must NEVER, never ever be loated at 0.

> The way I'm finding the location to link bss works for all mpc85xx system and
> for all images sizes.  This lets them share the same linker script.

Are you really talking about *all* MPC85xx systems, oronlyu about the
FSL boards?

And where is bss in your design at run-time, after relocation?

> > Have you actually tested this code?  Didn't you run into such problems?
> 
> The resulting u-boot binary is exactly the same.  This produces the same
> binaries as before using one linker script for all 85xx instead of a different
> one for each board.

Please define "all 85xx". I tend to doubt that.

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 the pitiful, multipage, connection-boxed form to which  the  flow-
chart  has  today  been  elaborated, it has proved to be useless as a
design tool -- programmers draw flowcharts after, not before, writing
the programs they describe.                        - Fred Brooks, Jr.