On Wed, Apr 20, 2011 at 12:08:56AM +0800, Shawn Guo wrote:
On Tue, Apr 19, 2011 at 04:23:09PM +0100, Dave Martin wrote:
Hopefully this explains what's going on, but what are you trying to achieve exactly?
Thanks a ton, Dave. It does explain what I'm seeing, and your explanation looks like a very good learning material.
I'm running into a problem with John Bonies' append-dtb-to-zImage patch. That is the header of dtb was overwritten by uart_base value. John's patch did fix up .bss entries in .got to move them behind dtb image. But as you explained, when uart_base is defined as static one, its address is fixed up in pc-relative way at link time, and John's patch does not help it, hence the write to uart_base at runtime overwrites dtb image.
What do you think is the right fix to this problem? Forbid the use of static uninitialized variable? I'm afraid not. Is it possible to fix up the cases like uart_base here at runtime?
So, if I understand correctly, because .bss doesn't take space in the zImage, when the dtb is appended, it effectively ends up on top of the bss/stack area?
Since the compressed kernel loader knows how big bss and the stack are, maybe the early zImage boot code can move the dtb out of the way before touching the stack or zeroing bss -- basically, it sounds like we need to move the dtb to the end of the stack in order for it to be safe.
We also need to avoid the space used beyond the end of the stack for heap memory: in compressed/head.S, it looks like the maximum heap is 0x10000 bytes, starting at the end of the stack. Maybe it would be better to declare this heap space explicitly in the linker script or some .s file -- we can then define a label at the end of it in the linker script, instead of the magic number arithmetic which is done currently.
Cheers ---Dave