On Tue, 14 Oct 2008, Wolfgang Denk wrote:
Dear Trent Piepho,
In message 1223941151-13969-2-git-send-email-tpiepho@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.