u-boot: rpi: Enlarge space available for kernel.
On 2024-09-16, Herman Rimm wrote:
--- /dev/null +++ b/gnu/packages/patches/u-boot-50M-kernel.patch @@ -0,0 +1,51 @@ +This patch configures the U-Boot for Raspberry Pis to reserve 50 MB for +linux kernels, because the 6.9 and newer linux-libre-arm64-generic +kernels can be larger than 36 MB. It was created by Herman Rimm +herman@rimm.ee in August 2024 and is not submitted upstream yet. +diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env +index 30228285ed..54a8e9e5ae 100644 +--- a/board/raspberrypi/rpi/rpi.env ++++ b/board/raspberrypi/rpi/rpi.env +@@ -43,22 +43,22 @@ dfu_alt_info+=zImage fat 0 1
- 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. ++ * satisfies all these constraints and reserving memory up to 0x03400000 ++ * permits fairly large (roughly 50M) 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. ++ * 0x03200000-0x03300000 and 0x03300000-0x03400000 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 0x03400000-0x03500000 for ++ * the DTB leaves rest of the free RAM to the initrd starting at 0x03500000.
- 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 11M starting at 0x03500000 should allow quite
- large initrds before they start colliding with U-Boot.
- */
- #ifdef CONFIG_ARM64
+@@ -69,9 +69,9 @@ fdt_high=ffffffff
- initrd_high=ffffffff
- #endif
- kernel_addr_r=0x00080000
+-scriptaddr=0x02400000 +-pxefile_addr_r=0x02500000 +-fdt_addr_r=0x02600000 +-ramdisk_addr_r=0x02700000 ++scriptaddr=0x03200000 ++pxefile_addr_r=0x03300000 ++fdt_addr_r=0x03400000 ++ramdisk_addr_r=0x03500000
- boot_targets=mmc usb pxe dhcp
I would really like to hear comments from the upstream u-boot maintainers on adjusting these values...
live well, vagrant
Hi,
On Mon, 16 Sept 2024 at 23:06, Vagrant Cascadian vagrant@debian.org wrote:
On 2024-09-16, Herman Rimm wrote:
--- /dev/null +++ b/gnu/packages/patches/u-boot-50M-kernel.patch @@ -0,0 +1,51 @@ +This patch configures the U-Boot for Raspberry Pis to reserve 50 MB for +linux kernels, because the 6.9 and newer linux-libre-arm64-generic +kernels can be larger than 36 MB. It was created by Herman Rimm +herman@rimm.ee in August 2024 and is not submitted upstream yet. +diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env +index 30228285ed..54a8e9e5ae 100644 +--- a/board/raspberrypi/rpi/rpi.env ++++ b/board/raspberrypi/rpi/rpi.env +@@ -43,22 +43,22 @@ dfu_alt_info+=zImage fat 0 1
- 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. ++ * satisfies all these constraints and reserving memory up to 0x03400000 ++ * permits fairly large (roughly 50M) 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. ++ * 0x03200000-0x03300000 and 0x03300000-0x03400000 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 0x03400000-0x03500000 for ++ * the DTB leaves rest of the free RAM to the initrd starting at 0x03500000.
- 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 11M starting at 0x03500000 should allow quite
- large initrds before they start colliding with U-Boot.
- */
- #ifdef CONFIG_ARM64
+@@ -69,9 +69,9 @@ fdt_high=ffffffff
- initrd_high=ffffffff
- #endif
- kernel_addr_r=0x00080000
+-scriptaddr=0x02400000 +-pxefile_addr_r=0x02500000 +-fdt_addr_r=0x02600000 +-ramdisk_addr_r=0x02700000 ++scriptaddr=0x03200000 ++pxefile_addr_r=0x03300000 ++fdt_addr_r=0x03400000 ++ramdisk_addr_r=0x03500000
- boot_targets=mmc usb pxe dhcp
I would really like to hear comments from the upstream u-boot maintainers on adjusting these values...
It is fine to adjust them, so long as the memory is actually there. I don't know of anything special about the current values.
Regards, Simon
participants (2)
-
Simon Glass -
Vagrant Cascadian