[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:
> 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.
>
>
> Have you actually tested this code? Didn't you run into such problems?

It's locate the same place it is now!  I'm telling you, these patches don't
change the resulting u-boot binaries.  How could the same binary stop working
because a better build process was used to make it?

And yes I tested the code.

The u-boot image doesn't contain bss.  The code is linked to expect bss at a
certain location, relative to the rest of the code (because it's compiled
PIC).  But in the image, and when u-boot is executing from flash, bss doesn't
exist.  There was a bug in Timur's speed setting patch to the FSL I2C code
because of that: it tried to write to bss while running out of flash.  When
u-boot gets moved from flash to ram, the bss section is created at the new
location.

For instance, suppose u-boot is linked at 0xfff8_0000 and bss placed at
0x0000_0000.  That how most 85xx platforms work now.  After ram is enabled,
u-boot is moved to ram at say 0x0010_0000.  The bss segment will be created
(space in ram set aside and zeroed) at 0x0018_0000.  All the PIC code in
u-boot that uses variables in bss will use this region starting at
0x0018_0000, because the relative position of 0x0018_0000 vs 0x0010_0000 is
the same as 0xfff8_0000 vs 0x0000_0000.  Yes, the calculations in the
relocation code handle the wrap around correctly.  If they didn't nothing
would work now.