u-boot: rpi: Enlarge space available for kernel.

[Vagrant Cascadian]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240916/b722eb27/attachment.sig>