On Tue, 19 Apr 2011, Dave Martin wrote:
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?
Yes. However...
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.
What the current code does is to leave the DTB in place and modify the GOT to move .bss references and the stack away instead. The XIPable zImage also relies on that "feature". See for example this line in arch/arm/boot/compressed/uncompress.c:
#define STATIC_RW_DATA /* non-static please */
It is also much cheaper to modify the GOT rather than relocating the DTB. And given that some people would like to use the same trick with ramdisk images then this is even more significant.
Once upon a time the kernel decompressor was built with -Dstatic="" but that didn't work with the zlib code rewrite as this affects functions as well as const data.
Nicolas