GNU bug report logs -
#72987
[PATCH] gnu: u-boot: Enlarge space available for kernel.
Previous Next
Full log
Message #53 received at 72987 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2024-12-13, Herman Rimm wrote:
> diff --git a/gnu/packages/patches/u-boot-50M-kernel.patch b/gnu/packages/patches/u-boot-50M-kernel.patch
> new file mode 100644
> index 0000000000..c4d054dd42
> --- /dev/null
> +++ b/gnu/packages/patches/u-boot-50M-kernel.patch
> @@ -0,0 +1,55 @@
> +From: Herman Rimm <herman <at> rimm.ee>
> +Date: Mon, Sep 16 2024 19:24:02 +0200
> +Subject: [PATCH] Configure Raspberry Pis to reserve 50 MB for linux kernels.
> +
> +---
> +The 6.9 and newer linux-libre-arm64-generic kernels for Guix can be
> +larger than the allocated 36 MB. This patch is not submitted upstream.
I know you got a response from Simon Glass that it seemed reasonable,
but is there any intention to submit this patch upstream? I would feel
more comfortable applying it if I knew we would eventually be able to
drop it.
With that in mind, please move this to the last patch in the series on
another iteration so it does not block remaining patches.
live well,
vagrant
> +diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> +index 30228285edd..666883e9212 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
> --
> 2.45.2
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.