Hi, On Mon, 16 Sept 2024 at 23:06, Vagrant Cascadian <[email protected]> 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 > > +<[email protected]> 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
