On Tue, 14 Oct 2008, Wolfgang Denk wrote:
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.
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.