Have more gap between DTB destination and payload_end
Detailed discussion is here: http://lists.infradead.org/pipermail/linux-riscv/2019-February/003048.html
Doesn’t this make it impossible to boot with less than 36 or so MB of RAM? Is there a more precise way to do it?
cc @palmer-dabbelt
For raw images passed as payload, we don't have option except use some heuristic value as gap between payload_end and DTB.
For ELF images, we can parse size of BSS+SBSS section in Makefile and pass BBL_PAYLOAD_BSS_SIZE as define to C code. The C code will place DTB at next 2MB aligned address after payload_end + BBL_PAYLOAD_BSS_SIZE.
Seems like a design flaw. Maybe having the BSS in the middle of the kernel is the better choice, or perhaps having it memmove the device tree if it happens to overlap the BSS.
In any case, I guess I'm not going to succeed in getting the kernel changed. What’s the largest BSS you get when you make a fully-loaded kernel? I’m sure it’s nowhere near 32 MB, so we could use a smaller guard band, right?
I don't like the solution where we just have a fixed BSS size in BBL. An allyesconfig kernel ends up with 52MiB of BSS, we don't want to allocate that staticly.
$ size vmlinux
text data bss dec hex filename
70827977 51857727 12101272 134786976 808afa0 vmlinux