On 7/17/24 12:44, Tom Rini wrote:
On Wed, Jul 17, 2024 at 11:59:50AM +0100, Peter Robinson wrote:
On Tue, 16 Jul 2024 at 18:21, Tom Rini trini@konsulko.com wrote:
On Tue, Jul 16, 2024 at 02:16:02PM -0300, Walter Lozano wrote:
ARM and Aarch64 have different restrictions and trying to accommodate larger kernels like the ones used in distros can be challenging. For this reason, separate the layout and rearrange the map for Aarch64 to support kernels larger than 36 MB.
Signed-off-by: Walter Lozano walter.lozano@collabora.com
board/raspberrypi/rpi/rpi.env | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env index 30228285edd..37c7f6a920e 100644 --- a/board/raspberrypi/rpi/rpi.env +++ b/board/raspberrypi/rpi/rpi.env @@ -42,13 +42,19 @@ dfu_alt_info+=zImage fat 0 1
- 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. However, loading it at 0x80000
- will allow to reserve only up to 0x02400000 which permits medium size
- kernels (roughly 36M). This is good enough for customized kernels but
- not for distros which by default enable drivers for many different
- boards. Under these circumstances, using 0x00200000 provides room for
- larger 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.
- 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty for ARM.
- For Aarch64, since the kernel is placed in different location,
- accommodate them to reserver 1M for each of them.
- 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
@@ -62,16 +68,21 @@ dfu_alt_info+=zImage fat 0 1
- large initrds before they start colliding with U-Boot.
*/ #ifdef CONFIG_ARM64 +pxefile_addr_r=0x00080000 +scriptaddr=0x00100000 +kernel_addr_r=0x00200000 +fdt_addr_r=0x03400000 +ramdisk_addr_r=0x03500000 fdt_high=ffffffffffffffff initrd_high=ffffffffffffffff #else -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 +fdt_high=ffffffff +initrd_high=ffffffff +#endif
boot_targets=mmc usb pxe dhcp
We need to drop the disabling of device tree / initrd relocation as that's sure not going to help matters. What's the minimum amount of memory an aarch64 Pi will have? I really prefer reserving 128MiB (even if that's not the maximum Linux Kernel Image size anymore) and then device tree and then initrd.
512Mb on the Zero2W and RPi3A.
We've not seen an issue here on the very large Fedora kernel, but I suspect that's because using UEFI mitigates this somewhat because here we're actually loading shim/grub.
OK, that should be enough to put a 128MiB spot for kernel, then 512KiB for device tree, and then rest for initrd, and not be disabling relocation (and thus preventing U-Boot from fixing failures).
Thanks for the feedback! If I understood it correctly a layout like the the one bellow would be the right thing. The only difference is in device tree for which is reserved a bit more.
pxefile_addr_r=0x00080000 scriptaddr=0x00100000 kernel_addr_r=0x00200000 fdt_addr_r=0x09800000 ramdisk_addr_r=0x09900000
If this matches the expectations I will prepare the V2.
Thanks in advance,
Walter