[PATCH] rpi: Redefine memory offsets for increased kernel image size

[Jian-Hong Pan]

The uncompressed kernel image size increases along the kernel's
development. It might be more than 36MB, which will overlap the script
address, even the device tree blob and initial RAM disk memory area.

This patch extends the reserved memory of kernel image up to 0x02900000
permits fairly large (roughly 40.5M) kernels. Also, moves the other
offset addresses.

Buglink: https://lists.denx.de/pipermail/u-boot/2021-February/439578.html
Signed-off-by: Jian-Hong Pan <jhp at endlessos.org>
---
 include/configs/rpi.h | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index d5e064fb37..166408d3f8 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -105,33 +105,34 @@
  *   For Aarch64, the kernel image is uncompressed and must be loaded at
  *   text_offset bytes (specified in the header of the Image) into a 2MB
  *   boundary. The 'booti' command relocates the image if necessary. Linux uses
- *   a default text_offset of 0x80000.  In summary, loading at 0x80000
- *   satisfies all these constraints and reserving memory up to 0x02400000
- *   permits fairly large (roughly 36M) kernels.
+ *   a default text_offset of 0x80000. In some cases, it may be relocated to
+ *   offset 0x200000. In summary, loading at 0x80000 satisfies all these
+ *   constraints and reserving memory up to 0x02900000 permits fairly large
+ *   (roughly 40.5M) kernels.
  *
  * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
  * conflict with something else. Reserving 1M for each of them at
- * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
+ * 0x02900000-0x02A00000 and 0x02A00000-0x02B00000 should be plenty.
  *
  * On ARM, both the DTB and any possible initrd must be loaded such that they
  * fit inside the lowmem mapping in Linux. In practice, this usually means not
  * more than ~700M away from the start of the kernel image but this number can
  * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
  * parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x02700000.
+ * satisfies this constraint again. Reserving 1M at 0x02B00000-0x02C00000 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02C00000.
  * Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x02700000 should allow quite
+ * only 64M, the remaining 20M starting at 0x02C00000 should allow quite
  * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
 	"fdt_high=" FDT_HIGH "\0" \
 	"initrd_high=" INITRD_HIGH "\0" \
 	"kernel_addr_r=0x00080000\0" \
-	"scriptaddr=0x02400000\0" \
-	"pxefile_addr_r=0x02500000\0" \
-	"fdt_addr_r=0x02600000\0" \
-	"ramdisk_addr_r=0x02700000\0"
+	"scriptaddr=0x02900000\0" \
+	"pxefile_addr_r=0x02A00000\0" \
+	"fdt_addr_r=0x02B00000\0" \
+	"ramdisk_addr_r=0x02C00000\0"
 
 #if CONFIG_IS_ENABLED(CMD_MMC)
 	#define BOOT_TARGET_MMC(func) \
-- 
2.35.1