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 <tr...@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.loz...@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
--
Walter Lozano
Collabora Ltd.
