On Tue, 14 Oct 2008, Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot