Re: [PATCH v2] bootm: set os.arch for Android boot images

["Junhui Liu" <junhui.liu@pigmoral.tech>]

Hi Igor,

On Tue Oct 13, 2026 at 4:43 AM CST, Igor Opaniuk wrote:
> bootm_find_os() leaves images.os.arch at IH_ARCH_INVALID for Android boot
> images: unlike the legacy and FIT headers, the Android boot image header
> carries no architecture field. The arm64 Image relocation in
> bootm_load_os() (booti_setup()) is therefore skipped, and a kernel that
> is executed in place, which android_image_get_kernel_addr() arranges for
> any uncompressed kernel whose header holds the default kernel address
> (or with ANDROID_BOOT_IMAGE_IGNORE_BLOB_ADDR), whatever the header
> version, runs from boot.img + page size, which is not 2 MiB aligned. The
> kernel reports "Kernel image misaligned at boot, please fix your
> bootloader!" and dies early (observed as a stack overflow in
> start_kernel() with a GKI 6.12 kernel on QEMU virt).
>
> Set IH_ARCH_DEFAULT, the one architecture this U-Boot can boot and the
> only value available for this image format, so that booti_setup() moves
> the kernel to a properly aligned address. The other readers of os.arch
> are not affected:
>
> - arch/arm/lib/bootm.c switches to AArch32 only for IH_ARCH_ARM, so an
>   Android image keeps taking the AArch64 path exactly as it does with
>   IH_ARCH_INVALID. Its update_os_arch_secondary_cores() hook, implemented
>   by Layerscape, marks the spin table entries OS_ARCH_SAME only when
>   os_arch equals IH_ARCH_DEFAULT, so with IH_ARCH_INVALID an Android
>   boot currently releases the secondary cores as if the kernel were a
>   different architecture; this is fixed as well.
> - the x86 setup.bin lookup in bootm.c is only reached on an x86 U-Boot,
>   where the Android format is not bootable through bootm anyway.
> - ARM32 and RISC-V do not read os.arch after bootm_find_os().
>
> For a v0-v2 image whose ramdisk is used in place, booti_setup() can now
> move the kernel forward by up to 2 MiB, and the memmove() of image_size
> bytes (which includes BSS) overwrites the start of the ramdisk that
> follows the kernel in boot.img. Executing in place already had the same
> problem, since the kernel clears its BSS early, so this is not a
> regression; the ramdisk is relocated by the ramdisk_high logic when it is
> in use, and loading the kernel to kernel_addr_r instead of executing it
> in place, like the compressed case, is a separate change. The LMB
> reservation also still covers the original load range, as it does for
> FIT.
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
> Changes in v2:
> - reword the commit message (Simon Glass): the Android header has no
>   architecture field, the in-place execution is not specific to header
>   v3/v4, why IH_ARCH_DEFAULT is safe for the other readers of os.arch
>   (and fixes the Layerscape secondary core release), note on the
>   ramdisk overlap for v0-v2 images booted in place and on the LMB
>   reservation; code unchanged, kept unconditional
> - add Simon's Reviewed-by
> - Link to v1: https://patch.msgid.link/20261011-upstream-bootm_android_b4-v1-1-3e82462ac206@oss.qualcomm.com
> ---
>  boot/bootm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index b6ae0163b27..75b34f39cca 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -432,6 +432,7 @@ static int bootm_find_os(const char *cmd_name, const char *addr_fit)
>  		images.os.type = IH_TYPE_KERNEL;
>  		images.os.comp = android_image_get_kcomp(boot_img, vendor_boot_img);
>  		images.os.os = IH_OS_LINUX;
> +		images.os.arch = IH_ARCH_DEFAULT;
>  		images.os.end = android_image_get_end(boot_img, vendor_boot_img);
>  		images.os.load = android_image_get_kload(boot_img, vendor_boot_img);
>  		images.ep = images.os.load;

Thanks. With this change, I no longer need to specify --kernel-offset
or --page-size when booting a kernel Image via fastboot boot.

However, I did encounter the ramdisk overlap issue in my testing on
an Allwinner ARM64 platform. The ramdisk is relocated afterwards by
boot_ramdisk_high(), but by then its source data has already been
overwritten. As noted in your commit message, let's address it in a
separate patch.

Also, RISC-V boots successfully when combined with this patch:
https://lore.kernel.org/u-boot/20261020-bootm-riscv-image-relocation-v1-1-e583a2dd1d14@pigmoral.tech

Reviewed-by: Junhui Liu <junhui.liu@pigmoral.tech>
Tested-by: Junhui Liu <junhui.liu@pigmoral.tech>

>
> ---
> base-commit: ed869863c7e2aca50d57a05d843830dd843138c4
> change-id: 20261011-upstream-bootm_android_b4-4e94dca526b5
>
> Best regards,
> --  
> Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>

-- 
Best regards,
Junhui Liu