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

[Trent Piepho]

On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> Dear Trent Piepho,
>
> In message <1223941151-13969-2-git-send-email-tpiepho at freescale.com> you wrote:
>>
>> B) The U-Boot image is over 4MB in size.  The image size for this is from
>> TEXT_BASE to the end of the reset vector.  It's not the size of the U-Boot
>> code as there could be a huge gap between the end of the code and the reset
>> vector.  The BSS section does not count for this size, as it goes after the
>> reset vector (and it not actually present in the image).  This should be
>> the same as the size of the u-boot.bin file.
>
> 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.

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.

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
linker scripts that have done that.  But that doesn't work on mpc8572ds for
example, which should be 0xf0000000.

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.

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