Hi Aurelien,
Thanks for tracking this down. I would like to loop in Masahiro and
upstream to see if something can/should be done on upstream side.
Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
special treatment for the link order of head.o") (which got backported
as well to 6.1.14) caused the vmlinuz size to icrease significantly,
causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
parameters previously working. Full quoting the Debian report below
> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
> @@ -95,32 +95,32 @@
> * 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 0x02a00000
> + * permits fairly large (roughly 42M) 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.
> + * 0x02a00000-0x02b00000 and 0x02c00000-0x02d00000 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 0x02c00000-0x02d00000 for
> + * the DTB leaves rest of the free RAM to the initrd starting at 0x02d00000.
> * 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 19M starting at 0x02d00000 should allow quite
> * large initrds before they start colliding with U-Boot.
> */
> #define ENV_MEM_LAYOUT_SETTINGS \
> "fdt_high=" FDT_HIGH "\0" \
> "initrd_high=" INITRD_HIGH "\0" \
> "kernel_addr_r=0x00080000\0" \
> - "scriptaddr=0x02400000\0" \
> - "pxefile_addr_r=0x02500000\0" \
> - "fdt_addr_r=0x02600000\0" \
> - "ramdisk_addr_r=0x02700000\0"
> + "scriptaddr=0x02a00000\0" \
> + "pxefile_addr_r=0x02b00000\0" \
> + "fdt_addr_r=0x02c00000\0" \
> + "ramdisk_addr_r=0x02d00000\0"
>
> #if CONFIG_IS_ENABLED(CMD_MMC)
> #define BOOT_TARGET_MMC(func) \
Any ideas?
Regards,
Salvatore