On Tue, Feb 04, 2020 at 09:17:07PM -0300, Fabio Estevam wrote:
Hi Baruch,
On Tue, Feb 4, 2020 at 1:57 PM Baruch Siach baruch@tkos.co.il wrote:
fdt_high value of 0xffffffff disables fdt relocation on boot. We don't need that for Cubox-i/Hummingboard. Rely on generic code to find the optimal fdt location at boot time.
Signed-off-by: Baruch Siach baruch@tkos.co.il
include/configs/mx6cuboxi.h | 1 - 1 file changed, 1 deletion(-)
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h index 6d47e28fc72b..a6690367f8c5 100644 --- a/include/configs/mx6cuboxi.h +++ b/include/configs/mx6cuboxi.h @@ -66,7 +66,6 @@ "ramdisk_addr_r=0x13000000\0" \ "ramdiskaddr=0x13000000\0" \ "initrd_high=0xffffffff\0" \
"fdt_high=0xffffffff\0" \ "ip_dyn=yes\0" \ "console=" CONSOLE_DEV ",115200\0" \ "bootm_size=0x10000000\0" \Maybe initrd_high could also be removed?
In general, it's not as dangerous to not move it, so long as the rest of the addresses in use are reasonable. Whereas if the FDT isn't 8 byte aligned (but only say 4) on arm64 everything blows up, and initrd: "must reside entirely within a 1 GB aligned physical memory window of up to 32 GB in size that fully covers the kernel Image as well."
So it's less risky to let it be. Also, while relocating the DTB is usually very quick (being kilobytes in size) initrds are megabytes.
All that said, no, I don't object too initrd_high=0xffffffff being removed everywhere maintainers are happy with the trade-offs of doing so.