Dear Peter Tyser,
In message 1254871741.24664.3117.camel@localhost.localdomain you wrote:
One disadvantage is that we need to relocate it separately, or we will have a gap in the RAm memory map which is IMO not acceptable.
What does "relocating the bss separately" entail?
The relocation routine would have to check the relocated address; if it falls into the bss, it has to add a different offset than otherwise. This way the location of the bss after relocation is moved close to the U-Boot image, avoiding gaps that just cost memory.
Why should it not be used? You seem to be pretty fixed on that idea, which is wrong. No code will ever be written to RAM at list location.
When I say user, I'm refering to an end user, eg a customer. Not a developer.
Me too.
For arguments sake, lets say we developers put the bss at a "fixed (random, non-zero) address" of 0x80000. A user tftps an image to 0x80000 and suddenly their board starts acting up.
No, it doesn't. It works perfectly well. The 0x80000 address is something that is ONLY used in the image as created by the linker, i. e. _before_ relocation. We no data gets ever written there. The end user who runs TFTP sees the system _after_ relocation, when the real bss has been allocated in high memory (just as it is now) and all symbols have been fixed up.
In the current setup, we don't write any code to RAM at 0x0 either.
Right, and this limitation causes headaches. I personally get lots of questions from customers about why their board hangs when they tftp an image to 0x0. In a perfect world we'd only have 1 reserved section of memory which contained the interrupt vectors, text, bss, malloc, stack, etc.
But this has _nothing_ to do with the fact that the bss is at 0x0. The problem is caused by overwriting the exception vectors, which is a completely different story.
corrupt their exception vectors or stack/malloc pool/u-boot code, I don't want to add more bss questions:)
Its crappy to have 2 sections of memory that a user has to know not to touch, I don't want to have 3:)
Neither do I. This would not change.
Maybe I'm not understanding your suggestion "to chose a fixed (random, non-zero) address" for the bss. That implies to me we choose an address low memory (eg 0x10000) and put the bss there. I think it'd be more
Yes, but ONLY for linking the image. Here the bss address is just _any_ address, more or less a virtual thing that just needs to be there so we can calculate the size later.
After relocation, i. e. when the end user sees it, the setupo shall be exactly the same as now, i. e. allocation of memory starting from end of available RAM downward would look like that:
[End of RAM] if configured: area that won't get touched by U-Boot and Linux if configured: shared log buffer if configured: pRAM (Protected RAM - unchanged by reset) if configured: LCD or video framebuffer .bss .u_boot_cmd .data .rodata .text malloc arena board info struct stack (growing downward)
Except for gaps caused for alignment purposes, these parts shall be tightly packed to make for as small a memory footprint as possible.
plausible for someone to blow this away accidentally than high memory by U-Boot, and you also couldn't use any data stored in the bss after you blow it away, eg right before jumping to a linux kernel.
You still fail to understand that the bss "address" as used for the linking of the image is unrelated to the storage area that later gets zeroed and used as bss. The former is before, the later after relocation to RAM.
Best regards,
Wolfgang Denk