[PATCH 0/3] u-boot chain-loading LineageOS bootimg

[PATCH 0/3] u-boot chain-loading LineageOS bootimg

[George Chan]

This is a series of patches to enable chainloading LineageOS on qcom SOC.

First patch is to workaround kernel/ramdisk invalid addr by identify
its physical memory address out-of-range. Since qcom SOC usually have
0x80000000 as start/base/real memory address but androidboot img
specified to around 0x0. If other vendor bootloader behave similar then
this patch can also workaround it as well.

Second patch is enable bootmeth-android to have chance for extra mem block.
Usually the fastboot mem block, to hold androidboot img, and loadaddr for
unzipped kernel. If other SOC have extra mem block available but
fastboot block, we can add extra logic to take care of it.

Third patch is optional to enable snapdragon board to have extra cmdline
found from original bootloader that is required for LineageOS boot init. 
An alternate method is to put the append string into a dummy device-tree
file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
encapsulate as androidboot img and let u-boot as kernel binary. Below is
an example for Xiaomi Miatoll device.

/dts-v1/;

/ {
        qcom,msm-id = <443 0x0>;
        qcom,board-id = <0 0>, 
			<0x10022 1>,
			<0x20022 1>,
			<0x30022 1>,
			<0x40022 1>,
			<0x50022 1>;

        #address-cells = <2>;
        #size-cells = <2>;

        memory {
                ddr_device_type = <0x07>;
                /* We expect the bootloader to fill in the size */
                reg = <0 0 0 0>;
        };

	chosen {
		bootargs = "";
	};
};

Signed-off-by: George Chan <gchan9527@gmail.com>
---
George Chan (3):
      boot/image-android.c: Workaround androidboot kernel/ramdisk addr
      boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel
      mach-snapdragon: Add support to append string to kernel cmdline

 arch/arm/mach-snapdragon/Kconfig | 11 +++++
 arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
 boot/bootmeth_android.c          | 12 +++++
 boot/image-android.c             | 10 +++++
 4 files changed, 130 insertions(+)
---
base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
change-id: 20250427-android-boot-ecbb768cda72

Best regards,
-- 
George Chan <gchan9527@gmail.com>

[PATCH 0/3] u-boot chain-loading LineageOS bootimg

[George Chan via B4 Relay]

This is a series of patches to enable chainloading LineageOS on qcom SOC.

First patch is to workaround kernel/ramdisk invalid addr by identify
its physical memory address out-of-range. Since qcom SOC usually have
0x80000000 as start/base/real memory address but androidboot img
specified to around 0x0. If other vendor bootloader behave similar then
this patch can also workaround it as well.

Second patch is enable bootmeth-android to have chance for extra mem block.
Usually the fastboot mem block, to hold androidboot img, and loadaddr for
unzipped kernel. If other SOC have extra mem block available but
fastboot block, we can add extra logic to take care of it.

Third patch is optional to enable snapdragon board to have extra cmdline
found from original bootloader that is required for LineageOS boot init. 
An alternate method is to put the append string into a dummy device-tree
file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
encapsulate as androidboot img and let u-boot as kernel binary. Below is
an example for Xiaomi Miatoll device.

/dts-v1/;

/ {
        qcom,msm-id = <443 0x0>;
        qcom,board-id = <0 0>, 
			<0x10022 1>,
			<0x20022 1>,
			<0x30022 1>,
			<0x40022 1>,
			<0x50022 1>;

        #address-cells = <2>;
        #size-cells = <2>;

        memory {
                ddr_device_type = <0x07>;
                /* We expect the bootloader to fill in the size */
                reg = <0 0 0 0>;
        };

	chosen {
		bootargs = "";
	};
};

Signed-off-by: George Chan <gchan9527@gmail.com>
---
George Chan (3):
      boot/image-android.c: Workaround androidboot kernel/ramdisk addr
      boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel
      mach-snapdragon: Add support to append string to kernel cmdline

 arch/arm/mach-snapdragon/Kconfig | 11 +++++
 arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
 boot/bootmeth_android.c          | 12 +++++
 boot/image-android.c             | 10 +++++
 4 files changed, 130 insertions(+)
---
base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
change-id: 20250427-android-boot-ecbb768cda72

Best regards,
-- 
George Chan <gchan9527@gmail.com>

[PATCH 1/3] boot/image-android.c: Workaround androidboot kernel/ramdisk addr

[George Chan]

Some vendor bootloader ignored kernel/ramdisk addr and use
their own addr. Even those addr are pointing to out-of-reach
memory block at 0, and available address start at 0x80000000.

So we also need to use our own available addr for loadaddr.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 boot/image-android.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/boot/image-android.c b/boot/image-android.c
index 1746b018900..36822d788b0 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -12,6 +12,7 @@
 #include <asm/unaligned.h>
 #include <mapmem.h>
 #include <linux/libfdt.h>
+#include <dm/of.h>
 
 #define ANDROID_IMAGE_DEFAULT_KERNEL_ADDR	0x10008000
 #define ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR	0x11000000
@@ -281,6 +282,13 @@ static ulong android_image_get_kernel_addr(struct andr_image_data *img_data,
 	if (img_data->kernel_addr == 0 && img_data->ramdisk_addr == 0)
 		return env_get_ulong("kernel_addr_r", 16, 0);
 
+	/*
+	 * Some vendor bootloader ignore kernel and ramdisk address also
+	 * default value are out of physical mem base... so we use ours.
+	 */
+	if (img_data->kernel_addr < gd->ram_base)
+		return env_get_ulong("kernel_addr_r", 16, 0);
+
 	return img_data->kernel_addr;
 }
 
@@ -490,6 +498,8 @@ int android_image_get_ramdisk(const void *hdr, const void *vendor_boot_img,
 		if (img_data.ramdisk_addr == 0 ||
 		    img_data.ramdisk_addr == ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR) {
 			*rd_data = img_data.ramdisk_ptr;
+		} else if (img_data.ramdisk_addr < gd->ram_base) {
+                        *rd_data = img_data.ramdisk_ptr;
 		} else {
 			ramdisk_ptr = img_data.ramdisk_addr;
 			*rd_data = ramdisk_ptr;

-- 
2.43.0

[PATCH 1/3] boot/image-android.c: Workaround androidboot kernel/ramdisk addr

[George Chan via B4 Relay]

From: George Chan <gchan9527@gmail.com>

Some vendor bootloader ignored kernel/ramdisk addr and use
their own addr. Even those addr are pointing to out-of-reach
memory block at 0, and available address start at 0x80000000.

So we also need to use our own available addr for loadaddr.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 boot/image-android.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/boot/image-android.c b/boot/image-android.c
index 1746b018900..36822d788b0 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -12,6 +12,7 @@
 #include <asm/unaligned.h>
 #include <mapmem.h>
 #include <linux/libfdt.h>
+#include <dm/of.h>
 
 #define ANDROID_IMAGE_DEFAULT_KERNEL_ADDR	0x10008000
 #define ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR	0x11000000
@@ -281,6 +282,13 @@ static ulong android_image_get_kernel_addr(struct andr_image_data *img_data,
 	if (img_data->kernel_addr == 0 && img_data->ramdisk_addr == 0)
 		return env_get_ulong("kernel_addr_r", 16, 0);
 
+	/*
+	 * Some vendor bootloader ignore kernel and ramdisk address also
+	 * default value are out of physical mem base... so we use ours.
+	 */
+	if (img_data->kernel_addr < gd->ram_base)
+		return env_get_ulong("kernel_addr_r", 16, 0);
+
 	return img_data->kernel_addr;
 }
 
@@ -490,6 +498,8 @@ int android_image_get_ramdisk(const void *hdr, const void *vendor_boot_img,
 		if (img_data.ramdisk_addr == 0 ||
 		    img_data.ramdisk_addr == ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR) {
 			*rd_data = img_data.ramdisk_ptr;
+		} else if (img_data.ramdisk_addr < gd->ram_base) {
+                        *rd_data = img_data.ramdisk_ptr;
 		} else {
 			ramdisk_ptr = img_data.ramdisk_addr;
 			*rd_data = ramdisk_ptr;

-- 
2.43.0

[PATCH 2/3] boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel

[George Chan]

Some androidboot images have gzipped kernel so we need to reuse
extra mem block for holding gzipped boot.img, and let loadaddr
to hold unzipped kernel data. Here we choose fastboot memory for
reuse and avoid dramatically increase memory footprint.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 boot/bootmeth_android.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
index 654ebfdf1fc..27ca2907052 100644
--- a/boot/bootmeth_android.c
+++ b/boot/bootmeth_android.c
@@ -518,6 +518,18 @@ static int boot_android_normal(struct bootflow *bflow)
 	int ret;
 	ulong loadaddr = env_get_hex("loadaddr", 0);
 	ulong vloadaddr = env_get_hex("vendor_boot_comp_addr_r", 0);
+	ulong fastboot_addr_r = env_get_hex("fastboot_addr_r", 0);
+
+	/*
+	 * Since there are some soc with very constrain mem footprint
+	 * so dont borther to allocate extra block for androidboot img
+	 * instead, reuse fastboot mem block for androidboot img
+	 *
+	 * The idea is to let loadaddr as source boot.img for unzip,
+	 * and the original loadaddr is for holding unzipped kernel.
+	 */
+	if (fastboot_addr_r)
+		loadaddr = fastboot_addr_r;
 
 	ret = run_avb_verification(bflow);
 	if (ret < 0)

-- 
2.43.0

[PATCH 2/3] boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel

[George Chan via B4 Relay]

From: George Chan <gchan9527@gmail.com>

Some androidboot images have gzipped kernel so we need to reuse
extra mem block for holding gzipped boot.img, and let loadaddr
to hold unzipped kernel data. Here we choose fastboot memory for
reuse and avoid dramatically increase memory footprint.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 boot/bootmeth_android.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
index 654ebfdf1fc..27ca2907052 100644
--- a/boot/bootmeth_android.c
+++ b/boot/bootmeth_android.c
@@ -518,6 +518,18 @@ static int boot_android_normal(struct bootflow *bflow)
 	int ret;
 	ulong loadaddr = env_get_hex("loadaddr", 0);
 	ulong vloadaddr = env_get_hex("vendor_boot_comp_addr_r", 0);
+	ulong fastboot_addr_r = env_get_hex("fastboot_addr_r", 0);
+
+	/*
+	 * Since there are some soc with very constrain mem footprint
+	 * so dont borther to allocate extra block for androidboot img
+	 * instead, reuse fastboot mem block for androidboot img
+	 *
+	 * The idea is to let loadaddr as source boot.img for unzip,
+	 * and the original loadaddr is for holding unzipped kernel.
+	 */
+	if (fastboot_addr_r)
+		loadaddr = fastboot_addr_r;
 
 	ret = run_avb_verification(bflow);
 	if (ret < 0)

-- 
2.43.0

[PATCH 3/3] mach-snapdragon: Add support to append string to kernel cmdline

[George Chan]

Add support for blindly appending string to bootargs env_param and let
boot process take care of it.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 arch/arm/mach-snapdragon/Kconfig | 11 +++++
 arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 108 insertions(+)

diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index 976c0e35fce..ee65bbd1313 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -45,4 +45,15 @@ config SYS_CONFIG_NAME
 	  Based on this option include/configs/<CONFIG_SYS_CONFIG_NAME>.h header
 	  will be used for board configuration.
 
+config SYS_BOARD_CMDLINE_APPEND
+        bool "Snapdragon SoCs based board cmdline append string"
+        help
+          Allows to specify the Snapdragon SoCs based board kernel cmdline override.
+          will be used as the custom board bootloader cmdline booting OS like Android.
+
+config SYS_BOARD_CMDLINE_APPEND_STRING
+	string "String to append"
+	default ""
+	depends on SYS_BOARD_CMDLINE_APPEND
+
 endif
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index deae4d32378..9b1dad8752d 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -46,6 +46,103 @@ static struct {
 	phys_size_t size;
 } prevbl_ddr_banks[CONFIG_NR_DRAM_BANKS] __section(".data") = { 0 };
 
+#ifdef CONFIG_SYS_BOARD_CMDLINE_APPEND
+/* (1) kernel cmdline support length is limited, which is (256..4096)
+ * (2) detain ref to COMMAND_LINE_SIZE of kernel header.
+ * (3) assumed null terminated.
+ * (4) Test shows that 1024 is working...
+ */
+#define COMMAND_LINE_SIZE_4_14		1024 /* ok make it default */
+static char bootargs[COMMAND_LINE_SIZE_4_14] = { 0 };
+const static char *soc_bootargs = CONFIG_SYS_BOARD_CMDLINE_APPEND_STRING;
+
+/* sort by importance to avoid some important value got wiped out */
+const static char *soc_bootargs_default = \
+" msm_drm.dsi_display0=dsi_nt36675_tianma_vid_display:" \
+" androidboot.lcmtype=dsi_nt36672c_tianma_fhd_video_display" \
+" androidboot.hwname=joyeuse" \
+" androidboot.secureboot=1" \
+" androidboot.keymaster=1"  \
+" androidboot.bootdevice=1d84000.ufshc" \
+" androidboot.boot_devices=soc/1d84000.ufshc" \
+" androidboot.verifiedbootstate=orange" \
+" androidboot.multisim_config=dsds" \
+" androidboot.cpuid=0xdc1467b8 " \
+" androidboot.dp=0x0 androidboot.baseband=msm" \
+" androidboot.fpsensor=fpc" \
+" androidboot.hwc=VDF_TWO" \
+" androidboot.hwlevel=MP" \
+" androidboot.AdcVol1=463 androidboot.AdcVol2=1306" \
+" androidboot.hwversion=4.90.0";
+
+/* fixups are put here:
+ * (1) androidboot.android_dt_dir this is to abuse the param to get rid of
+ * old fstab in device tree, and let search fail.
+ * (2) in case of fstab.qcom is in use but default boot.img have cmdline but
+ * do not specify the value, it will result expecting "fstab" instead of
+ * "fstab.qcom" and boot fail. so add a default value at last of cmd here.
+ */
+const static char *fix_bootargs = \
+" androidboot.android_dt_dir=/tmp/" \
+" androidboot.fstab_suffix=default" \
+" console=ramoops ";
+
+const char *get_board_support_bootargs(void)
+{
+        return soc_bootargs;
+}
+
+const char *get_board_support_bootargs_fixup(void)
+{
+        return fix_bootargs;
+}
+
+const char *board_fdt_chosen_bootargs(const struct fdt_property *fdt)
+{
+	int j;
+	char *env_prop = env_get("bootargs");
+	const char *soc_prop;
+	const char *fix_prop = fix_bootargs;
+	const char *fdt_prop;
+
+	soc_prop = (strlen(soc_bootargs) == 0) ? soc_bootargs_default : soc_bootargs;
+
+	fdt_prop = (fdt == NULL) ? "" : fdt->data;
+
+	if (env_prop == NULL)
+		env_prop = "";
+
+	debug("\n");
+	debug("fdt bootargs: %s\n", fdt_prop);
+	debug("env bootargs: %s\n", env_prop);
+	debug("soc bootargs: %s\n", soc_prop);
+	debug("fix bootargs: %s\n", fix_prop);
+
+	/* since android init parse androidboot property on a
+	 * first-come-first-serve manner so dtb valus come first and
+	 * then u-boot defaults and board specific fixups
+	 */
+	snprintf(bootargs, COMMAND_LINE_SIZE_4_14 - 2, "%s %s %s %s",
+		env_prop , fdt_prop, fix_prop, soc_prop);
+
+	/* remove all carriage return */
+	for (j = 0; j < COMMAND_LINE_SIZE_4_14; j++) {
+		if (bootargs[j] == '\0')
+			break;
+
+		if ((bootargs[j] == '\n') || (bootargs[j] == '\r'))
+			bootargs[j] = ' ';
+	}
+
+	/* trim to max length */
+	bootargs[COMMAND_LINE_SIZE_4_14 - 1] = '\0';
+
+	debug("out bootargs: %s\n", bootargs);
+	debug("total length: %d\n", j);
+	return bootargs;
+}
+#endif
+
 int dram_init(void)
 {
 	/*

-- 
2.43.0

[PATCH 3/3] mach-snapdragon: Add support to append string to kernel cmdline

[George Chan via B4 Relay]

From: George Chan <gchan9527@gmail.com>

Add support for blindly appending string to bootargs env_param and let
boot process take care of it.

Signed-off-by: George Chan <gchan9527@gmail.com>
---
 arch/arm/mach-snapdragon/Kconfig | 11 +++++
 arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 108 insertions(+)

diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index 976c0e35fce..ee65bbd1313 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -45,4 +45,15 @@ config SYS_CONFIG_NAME
 	  Based on this option include/configs/<CONFIG_SYS_CONFIG_NAME>.h header
 	  will be used for board configuration.
 
+config SYS_BOARD_CMDLINE_APPEND
+        bool "Snapdragon SoCs based board cmdline append string"
+        help
+          Allows to specify the Snapdragon SoCs based board kernel cmdline override.
+          will be used as the custom board bootloader cmdline booting OS like Android.
+
+config SYS_BOARD_CMDLINE_APPEND_STRING
+	string "String to append"
+	default ""
+	depends on SYS_BOARD_CMDLINE_APPEND
+
 endif
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index deae4d32378..9b1dad8752d 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -46,6 +46,103 @@ static struct {
 	phys_size_t size;
 } prevbl_ddr_banks[CONFIG_NR_DRAM_BANKS] __section(".data") = { 0 };
 
+#ifdef CONFIG_SYS_BOARD_CMDLINE_APPEND
+/* (1) kernel cmdline support length is limited, which is (256..4096)
+ * (2) detain ref to COMMAND_LINE_SIZE of kernel header.
+ * (3) assumed null terminated.
+ * (4) Test shows that 1024 is working...
+ */
+#define COMMAND_LINE_SIZE_4_14		1024 /* ok make it default */
+static char bootargs[COMMAND_LINE_SIZE_4_14] = { 0 };
+const static char *soc_bootargs = CONFIG_SYS_BOARD_CMDLINE_APPEND_STRING;
+
+/* sort by importance to avoid some important value got wiped out */
+const static char *soc_bootargs_default = \
+" msm_drm.dsi_display0=dsi_nt36675_tianma_vid_display:" \
+" androidboot.lcmtype=dsi_nt36672c_tianma_fhd_video_display" \
+" androidboot.hwname=joyeuse" \
+" androidboot.secureboot=1" \
+" androidboot.keymaster=1"  \
+" androidboot.bootdevice=1d84000.ufshc" \
+" androidboot.boot_devices=soc/1d84000.ufshc" \
+" androidboot.verifiedbootstate=orange" \
+" androidboot.multisim_config=dsds" \
+" androidboot.cpuid=0xdc1467b8 " \
+" androidboot.dp=0x0 androidboot.baseband=msm" \
+" androidboot.fpsensor=fpc" \
+" androidboot.hwc=VDF_TWO" \
+" androidboot.hwlevel=MP" \
+" androidboot.AdcVol1=463 androidboot.AdcVol2=1306" \
+" androidboot.hwversion=4.90.0";
+
+/* fixups are put here:
+ * (1) androidboot.android_dt_dir this is to abuse the param to get rid of
+ * old fstab in device tree, and let search fail.
+ * (2) in case of fstab.qcom is in use but default boot.img have cmdline but
+ * do not specify the value, it will result expecting "fstab" instead of
+ * "fstab.qcom" and boot fail. so add a default value at last of cmd here.
+ */
+const static char *fix_bootargs = \
+" androidboot.android_dt_dir=/tmp/" \
+" androidboot.fstab_suffix=default" \
+" console=ramoops ";
+
+const char *get_board_support_bootargs(void)
+{
+        return soc_bootargs;
+}
+
+const char *get_board_support_bootargs_fixup(void)
+{
+        return fix_bootargs;
+}
+
+const char *board_fdt_chosen_bootargs(const struct fdt_property *fdt)
+{
+	int j;
+	char *env_prop = env_get("bootargs");
+	const char *soc_prop;
+	const char *fix_prop = fix_bootargs;
+	const char *fdt_prop;
+
+	soc_prop = (strlen(soc_bootargs) == 0) ? soc_bootargs_default : soc_bootargs;
+
+	fdt_prop = (fdt == NULL) ? "" : fdt->data;
+
+	if (env_prop == NULL)
+		env_prop = "";
+
+	debug("\n");
+	debug("fdt bootargs: %s\n", fdt_prop);
+	debug("env bootargs: %s\n", env_prop);
+	debug("soc bootargs: %s\n", soc_prop);
+	debug("fix bootargs: %s\n", fix_prop);
+
+	/* since android init parse androidboot property on a
+	 * first-come-first-serve manner so dtb valus come first and
+	 * then u-boot defaults and board specific fixups
+	 */
+	snprintf(bootargs, COMMAND_LINE_SIZE_4_14 - 2, "%s %s %s %s",
+		env_prop , fdt_prop, fix_prop, soc_prop);
+
+	/* remove all carriage return */
+	for (j = 0; j < COMMAND_LINE_SIZE_4_14; j++) {
+		if (bootargs[j] == '\0')
+			break;
+
+		if ((bootargs[j] == '\n') || (bootargs[j] == '\r'))
+			bootargs[j] = ' ';
+	}
+
+	/* trim to max length */
+	bootargs[COMMAND_LINE_SIZE_4_14 - 1] = '\0';
+
+	debug("out bootargs: %s\n", bootargs);
+	debug("total length: %d\n", j);
+	return bootargs;
+}
+#endif
+
 int dram_init(void)
 {
 	/*

-- 
2.43.0

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[Casey Connolly]

Hi George,

Thanks a lot for the series, it's super exciting to see support for 
booting Android on top of U-Boot :D

On 4/27/25 13:25, George Chan via B4 Relay wrote:
> This is a series of patches to enable chainloading LineageOS on qcom SOC.
> 
> First patch is to workaround kernel/ramdisk invalid addr by identify
> its physical memory address out-of-range. Since qcom SOC usually have
> 0x80000000 as start/base/real memory address but androidboot img
> specified to around 0x0. If other vendor bootloader behave similar then
> this patch can also workaround it as well.

I'm curious to know what values are there, tbh I think U-Boot should 
entirely ignore the values in the boot image but I guess that could 
break some other platforms.

How about adding a config option CONFIG_ANDROID_BOOTIMG_IGNORE_ADDRS and 
just ORing it in all the places that have checks like 
"img_data->kernel_addr == 0". Then you can enable this for 
mach-snapdragon by selecting it in the ARCH_SNAPDRAGON config definition.

> 
> Second patch is enable bootmeth-android to have chance for extra mem block.
> Usually the fastboot mem block, to hold androidboot img, and loadaddr for
> unzipped kernel. If other SOC have extra mem block available but
> fastboot block, we can add extra logic to take care of it.

There is a small hack in mach-snapdragon that we put kernel_addr_r and 
loadaddr at the same address to avoid using up too much memory on 
devices that only have 1GB which explains this crash because we try to 
decompress the kernel to the same address it got loaded too.

I think we can get away with giving loadaddr its own allocation of 64M 
or so, maybe 96. This would make your second patch redundant (and feels 
like the right fix to me)

> 
> Third patch is optional to enable snapdragon board to have extra cmdline
> found from original bootloader that is required for LineageOS boot init.
> An alternate method is to put the append string into a dummy device-tree
> file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
> encapsulate as androidboot img and let u-boot as kernel binary. Below is
> an example for Xiaomi Miatoll device.

I assume you're chainloading U-Boot on this device? If so, isn't it 
enough to just copy the boot args that ABL gives us and maybe tweak a few?

I'd also rather keep this constrained, maybe an android specific board 
callback to set boot args (if there isn't one already) and have the FDT 
fixup code be alongside some other generic FDT fixup stuff. I'd rather 
not have this stuff in board specific code.

I hope this makes sense, feel free to ask for clarifications on anything.

Thanks and kind regards,

> 
> /dts-v1/;
> 
> / {
>          qcom,msm-id = <443 0x0>;
>          qcom,board-id = <0 0>,
> 			<0x10022 1>,
> 			<0x20022 1>,
> 			<0x30022 1>,
> 			<0x40022 1>,
> 			<0x50022 1>;
> 
>          #address-cells = <2>;
>          #size-cells = <2>;
> 
>          memory {
>                  ddr_device_type = <0x07>;
>                  /* We expect the bootloader to fill in the size */
>                  reg = <0 0 0 0>;
>          };
> 
> 	chosen {
> 		bootargs = "";
> 	};
> };
> 
> Signed-off-by: George Chan <gchan9527@gmail.com>
> ---
> George Chan (3):
>        boot/image-android.c: Workaround androidboot kernel/ramdisk addr
>        boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel
>        mach-snapdragon: Add support to append string to kernel cmdline
> 
>   arch/arm/mach-snapdragon/Kconfig | 11 +++++
>   arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
>   boot/bootmeth_android.c          | 12 +++++
>   boot/image-android.c             | 10 +++++
>   4 files changed, 130 insertions(+)
> ---
> base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
> change-id: 20250427-android-boot-ecbb768cda72
> 
> Best regards,
-- 
Casey (she/they)

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[george chan]

Hi Casey,

Thx for reply. Sorry for a bit long message for explain the problem.

在 2025年4月28日週一 21:53，Casey Connolly <casey.connolly@linaro.org> 寫道：

> Hi George,
>
> Thanks a lot for the series, it's super exciting to see support for
> booting Android on top of U-Boot :D
>
> On 4/27/25 13:25, George Chan via B4 Relay wrote:
> > This is a series of patches to enable chainloading LineageOS on qcom SOC.
> >
> > First patch is to workaround kernel/ramdisk invalid addr by identify
> > its physical memory address out-of-range. Since qcom SOC usually have
> > 0x80000000 as start/base/real memory address but androidboot img
> > specified to around 0x0. If other vendor bootloader behave similar then
> > this patch can also workaround it as well.
>
> I'm curious to know what values are there, tbh I think U-Boot should


I don't know either. I figured it out a failure memcpy kernel to addr 0,
and failure at right after first 16k succes. Since kernel is relocatable so
I ignored it. I know you are dealing with memory mapping on xbl and chain
loading case with some kind of smem value. Good job!


> entirely ignore the values in the boot image but I guess that could
> break some other platforms.


I agreed your below suggested alternative approach apply can ease for
maintaining, and less concern. I am willing to help draft a patch worked as
your mentioned approach.

Maybe it is more optimistic than what you see here. Below are some reasons
might be worth to rethink.

(1) This is specific to bootm dealing androidboot img only.
(2)A similar approach applied to check specific kernel address already.
(3)The proposed logic is to cater extra case that is never works.
(4)unless there is a need for soc that mmap() high (physical) memory addr
to low (nonexistent) addr, aka 0, and use low address as kernel data.
Sounds like hyperizer iommu work. Looks redundance.
(5)if checking gd->base_mem is not safe then we can add extra checking for
gd null. The logic only affect valid gd and base_mem value. Either null or
0 won't have any side effect.

So it less likely breaks. In the end, if apply your suggested approach,
then mine and existing one are redundance and could be removed for clean
up. I am not sure what happened and concluded for existing code but the
code exists. Maybe some senior contributor knows more about it.

Removing code would be a big behavioral change require broader
acknowledgement. Or just leave existing logic and apply only your suggested
approach anyway. Both are fine for me. I prefer to wait for some feedback
before new revision roll.


> How about adding a config option CONFIG_ANDROID_BOOTIMG_IGNORE_ADDRS and
> just ORing it in all the places that have checks like
> "img_data->kernel_addr == 0". Then you can enable this for
> mach-snapdragon by selecting it in the ARCH_SNAPDRAGON config definition.
>

As stated as above.

>
> > Second patch is enable bootmeth-android to have chance for extra mem
> block.
> > Usually the fastboot mem block, to hold androidboot img, and loadaddr for
> > unzipped kernel. If other SOC have extra mem block available but
> > fastboot block, we can add extra logic to take care of it.
>
> There is a small hack in mach-snapdragon that we put kernel_addr_r and
> loadaddr at the same address to avoid using up too much memory on
> devices that only have 1GB which explains this crash because we try to
> decompress the kernel to the same address it got loaded too.
>

Reasonable.

I think we can get away with giving loadaddr its own allocation of 64M
> or so, maybe 96. This would make your second patch redundant (and feels
> like the right fix to me)
>

I don't know how memory constrain affected, and have virtually no knowledge
on memory arrangement. So I can't comment on this.

There is a third way. Add one more env_var like androidboot_addr_r and
pointed to same as fastboot_addr_r then use it in bootmeth-android if this
new env exists. If var not exists, fallback to existing logic. That balance
with minimal logic change and readability.


> >
> > Third patch is optional to enable snapdragon board to have extra cmdline
> > found from original bootloader that is required for LineageOS boot init.
> > An alternate method is to put the append string into a dummy device-tree
> > file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
> > encapsulate as androidboot img and let u-boot as kernel binary. Below is
> > an example for Xiaomi Miatoll device.
>
> I assume you're chainloading U-Boot on this device? If so, isn't it
> enough to just copy the boot args that ABL gives us and maybe tweak a few?
>

Yes, I am doing chain loading u-boot. And yes, patch 3 is doing exactly you
mentioned.

I mentioned here is 2nd approach that I feels cleaner for chain loading
case. I really have no idea on how prev_blob and target_blob works all the
way fdt handling (difference of replace xbl and chain loading). If
non-chain-loading case there have no prev_blob, then 1st approach is
preferable.


> I'd also rather keep this constrained, maybe an android specific board
> callback to set boot args (if there isn't one already) and have the FDT
> fixup code be alongside some other generic FDT fixup stuff. I'd rather
> not have this stuff in board specific code.
>

Reasonably. I can't figure out the difference board specific fixup and
android specific fixup. My limited knowledge is fdt_support.c have weak
board_fdt_chosen_bootargs func to board.c as my 1st approach do as patch 3.
I wonder if you are talking about adding one more fdt-support.c weak func
like board_fdt_chosen_bootargs_android. And leave board_fdt_chosen_bootargs
empty for further use case on purpose. I also curious if you are targeting
to make it generic enough for mach-* and/or enhanced API with full fdt for
fixup because the existing one is incapable. And this is reasonable too.

I wanna to express some though about additional fixups here. As you knows
those androidboot param are half baked and soc/machine/device/os dependent.
So it can't be one-sized-fit-all. Currently we have some approaches to put
it in.

(1) In upstream dts, block the merge.
(2) In a dummy dts, might not work for xbl case.
(3) In board.c/Kconfig compile-time config. Not flexible. Can't do it with
constrained way unless a string parser is needed (I wrote one similar thing
but found useless
https://github.com/99degree/u-boot/commit/3240054aa85f4cb70daa8671150bf4a9ca885a61
)

Since all added Androidboot param are android specific, my approach is very
simple. Let the android init to get rid of it.

Here is how to do so. Android Init treat Androidboot.* param as ro.boot.*
and set-once-read-only and first-come-first-serve so any taylor-made param
we put in the head will mandate the value even the same appears in the
tail. In other words, params in tail are failsafe as result. This behavior
is good enough to make an approach to balance flexible and function. We can
have wanted param in chainloaded Androidboot (boot.) img dtb, and 'default'
param live in board specific fixup logic. Since env_bootargs have param
from Android boot img and board can do fixup by append android specific
param to end of env_bootargs. Then we do not need to have constrained param
(to append env_bootargs, my own understanding) unless overflow bootargs
length. Well, this is the core idea of my impl in patch 3. Also patch 3
have Kconfig string to override SOC specific fixup so param value can set
by config file.

One more thing worth mentioning, I made boot.img repacked with dtb from
/sys/firmware/fdt and do u-boot chain load because of well known dtbo
issue. Maybe u-boot support dtbo partition but I have not tried. I cant
assumed people get used to familiar with android param so a dummy way is do
less-is-more. It is easy to repack boot.img with new fdt (by tool like e.g.
magisk) but not easy to figure which param to append bootargs is needed.
Even duplicated param as result.


> I hope this makes sense, feel free to ask for clarifications on anything.
>

Yes your suggestions are valuable


> Thanks and kind regards,
>

kind regards,
George


> >
> > /dts-v1/;
> >
> > / {
> >          qcom,msm-id = <443 0x0>;
> >          qcom,board-id = <0 0>,
> >                       <0x10022 1>,
> >                       <0x20022 1>,
> >                       <0x30022 1>,
> >                       <0x40022 1>,
> >                       <0x50022 1>;
> >
> >          #address-cells = <2>;
> >          #size-cells = <2>;
> >
> >          memory {
> >                  ddr_device_type = <0x07>;
> >                  /* We expect the bootloader to fill in the size */
> >                  reg = <0 0 0 0>;
> >          };
> >
> >       chosen {
> >               bootargs = "";
> >       };
> > };
> >
> > Signed-off-by: George Chan <gchan9527@gmail.com>
> > ---
> > George Chan (3):
> >        boot/image-android.c: Workaround androidboot kernel/ramdisk addr
> >        boot/bootmeth-android.c: Reuse fastboot memory block for unzip
> kernel
> >        mach-snapdragon: Add support to append string to kernel cmdline
> >
> >   arch/arm/mach-snapdragon/Kconfig | 11 +++++
> >   arch/arm/mach-snapdragon/board.c | 97
> ++++++++++++++++++++++++++++++++++++++++
> >   boot/bootmeth_android.c          | 12 +++++
> >   boot/image-android.c             | 10 +++++
> >   4 files changed, 130 insertions(+)
> > ---
> > base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
> > change-id: 20250427-android-boot-ecbb768cda72
> >
> > Best regards,
> --
> Casey (she/they)
>
>

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[Mattijs Korpershoek]

Hi George,

Thank you for contributing.

On lun., avril 28, 2025 at 15:53, Casey Connolly <casey.connolly@linaro.org> wrote:

> Hi George,
>
> Thanks a lot for the series, it's super exciting to see support for 
> booting Android on top of U-Boot :D
>
> On 4/27/25 13:25, George Chan via B4 Relay wrote:
>> This is a series of patches to enable chainloading LineageOS on qcom SOC.
>> 
>> First patch is to workaround kernel/ramdisk invalid addr by identify
>> its physical memory address out-of-range. Since qcom SOC usually have
>> 0x80000000 as start/base/real memory address but androidboot img
>> specified to around 0x0. If other vendor bootloader behave similar then
>> this patch can also workaround it as well.
>
> I'm curious to know what values are there, tbh I think U-Boot should 
> entirely ignore the values in the boot image but I guess that could 
> break some other platforms.

Yes, some platforms actually use the values from the boot.img.
We had some breakage on Khadas VIM3 in this area. See:
https://lore.kernel.org/all/20241003-android-fix-boot-v2-v1-1-13e8e44af4b7@baylibre.com/

The above thread also mentions how to repack a boot.img, where we can
specify a different ramdisk address.

It's a bit unclear to me why it's impractical to repack the boot.img and
specify the appropriate address. Could you elaborate ?

>
> How about adding a config option CONFIG_ANDROID_BOOTIMG_IGNORE_ADDRS and 
> just ORing it in all the places that have checks like 
> "img_data->kernel_addr == 0". Then you can enable this for 
> mach-snapdragon by selecting it in the ARCH_SNAPDRAGON config definition.

If we need to add this in U-Boot, I'd prefer this option as suggested by Casey.

>
>> 
>> Second patch is enable bootmeth-android to have chance for extra mem block.
>> Usually the fastboot mem block, to hold androidboot img, and loadaddr for
>> unzipped kernel. If other SOC have extra mem block available but
>> fastboot block, we can add extra logic to take care of it.
>
> There is a small hack in mach-snapdragon that we put kernel_addr_r and 
> loadaddr at the same address to avoid using up too much memory on 
> devices that only have 1GB which explains this crash because we try to 
> decompress the kernel to the same address it got loaded too.
>
> I think we can get away with giving loadaddr its own allocation of 64M 
> or so, maybe 96. This would make your second patch redundant (and feels 
> like the right fix to me)

I was not aware of this hack, but I agree with Casey.

>
>> 
>> Third patch is optional to enable snapdragon board to have extra cmdline
>> found from original bootloader that is required for LineageOS boot init.
>> An alternate method is to put the append string into a dummy device-tree
>> file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
>> encapsulate as androidboot img and let u-boot as kernel binary. Below is
>> an example for Xiaomi Miatoll device.
>
> I assume you're chainloading U-Boot on this device? If so, isn't it 
> enough to just copy the boot args that ABL gives us and maybe tweak a few?
>
> I'd also rather keep this constrained, maybe an android specific board 
> callback to set boot args (if there isn't one already) and have the FDT 
> fixup code be alongside some other generic FDT fixup stuff. I'd rather 
> not have this stuff in board specific code.

I also agree with Casey here. Looking at patch: "[PATCH 3/3]
mach-snapdragon: Add support to append string to kernel cmdline", the
android bootmethod already takes care of some androidboot.* arguments.
See:

https://source.denx.de/u-boot/u-boot/-/blob/master/boot/bootmeth_android.c?ref_type=heads#L504

For androidboot.verifiedbootstate=orange, this is done via
avb_append_commandline_arg() when AVB is enabled in U-Boot.

>
> I hope this makes sense, feel free to ask for clarifications on anything.
>
> Thanks and kind regards,
>
>> 
>> /dts-v1/;
>> 
>> / {
>>          qcom,msm-id = <443 0x0>;
>>          qcom,board-id = <0 0>,
>> 			<0x10022 1>,
>> 			<0x20022 1>,
>> 			<0x30022 1>,
>> 			<0x40022 1>,
>> 			<0x50022 1>;
>> 
>>          #address-cells = <2>;
>>          #size-cells = <2>;
>> 
>>          memory {
>>                  ddr_device_type = <0x07>;
>>                  /* We expect the bootloader to fill in the size */
>>                  reg = <0 0 0 0>;
>>          };
>> 
>> 	chosen {
>> 		bootargs = "";
>> 	};
>> };
>> 
>> Signed-off-by: George Chan <gchan9527@gmail.com>
>> ---
>> George Chan (3):
>>        boot/image-android.c: Workaround androidboot kernel/ramdisk addr
>>        boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel
>>        mach-snapdragon: Add support to append string to kernel cmdline
>> 
>>   arch/arm/mach-snapdragon/Kconfig | 11 +++++
>>   arch/arm/mach-snapdragon/board.c | 97 ++++++++++++++++++++++++++++++++++++++++
>>   boot/bootmeth_android.c          | 12 +++++
>>   boot/image-android.c             | 10 +++++
>>   4 files changed, 130 insertions(+)
>> ---
>> base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
>> change-id: 20250427-android-boot-ecbb768cda72
>> 
>> Best regards,
> -- 
> Casey (she/they)

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[george chan]

Hi Mattijs,
CC: Casey,

Thx for your reply.


在 2025年4月29日週二 16:30，Mattijs Korpershoek <mkorpershoek@kernel.org> 寫道：

> Hi George,
>
> Thank you for contributing.
>
> On lun., avril 28, 2025 at 15:53, Casey Connolly <
> casey.connolly@linaro.org> wrote:
>
> > Hi George,
> >
> > Thanks a lot for the series, it's super exciting to see support for
> > booting Android on top of U-Boot :D
> >
> > On 4/27/25 13:25, George Chan via B4 Relay wrote:
> >> This is a series of patches to enable chainloading LineageOS on qcom
> SOC.
> >>
> >> First patch is to workaround kernel/ramdisk invalid addr by identify
> >> its physical memory address out-of-range. Since qcom SOC usually have
> >> 0x80000000 as start/base/real memory address but androidboot img
> >> specified to around 0x0. If other vendor bootloader behave similar then
> >> this patch can also workaround it as well.
> >
> > I'm curious to know what values are there, tbh I think U-Boot should
> > entirely ignore the values in the boot image but I guess that could
> > break some other platforms.
>
> Yes, some platforms actually use the values from the boot.img.
> We had some breakage on Khadas VIM3 in this area. See:
>
> https://lore.kernel.org/all/20241003-android-fix-boot-v2-v1-1-13e8e44af4b7@baylibre.com/
>
> The above thread also mentions how to repack a boot.img, where we can
> specify a different ramdisk address.
>
> It's a bit unclear to me why it's impractical to repack the boot.img and
> specify the appropriate address. Could you elaborate ?


It is hard to ask less experience people to modify the boot img....I do
prefer no mod is the best. Why get life so complicated, my friend?


> >
> > How about adding a config option CONFIG_ANDROID_BOOTIMG_IGNORE_ADDRS and
> > just ORing it in all the places that have checks like
> > "img_data->kernel_addr == 0". Then you can enable this for
> > mach-snapdragon by selecting it in the ARCH_SNAPDRAGON config definition.
>
> If we need to add this in U-Boot, I'd prefer this option as suggested by
> Casey.
>

No problem. If this approach have wider audience and also benefit other
soc/device, I am glad to know. Lets wait for user of below code and see if
any willingness to migrate.

https://github.com/u-boot/u-boot/blob/d75998b476de439a05b2f7ec95d426410bcaae18/boot/image-android.c#L271

And

https://github.com/u-boot/u-boot/blob/d75998b476de439a05b2f7ec95d426410bcaae18/boot/image-android.c#L281


> >
> >>
> >> Second patch is enable bootmeth-android to have chance for extra mem
> block.
> >> Usually the fastboot mem block, to hold androidboot img, and loadaddr
> for
> >> unzipped kernel. If other SOC have extra mem block available but
> >> fastboot block, we can add extra logic to take care of it.
> >
> > There is a small hack in mach-snapdragon that we put kernel_addr_r and
> > loadaddr at the same address to avoid using up too much memory on
> > devices that only have 1GB which explains this crash because we try to
> > decompress the kernel to the same address it got loaded too.
> >
> > I think we can get away with giving loadaddr its own allocation of 64M
> > or so, maybe 96. This would make your second patch redundant (and feels
> > like the right fix to me)
>
> I was not aware of this hack, but I agree with Casey.
>

Hmm... I have no idea/experience about it. Casey will you follow this issue
with a proper patch?


> >
> >>
> >> Third patch is optional to enable snapdragon board to have extra cmdline
> >> found from original bootloader that is required for LineageOS boot init.
> >> An alternate method is to put the append string into a dummy device-tree
> >> file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
> >> encapsulate as androidboot img and let u-boot as kernel binary. Below is
> >> an example for Xiaomi Miatoll device.
> >
> > I assume you're chainloading U-Boot on this device? If so, isn't it
> > enough to just copy the boot args that ABL gives us and maybe tweak a
> few?
> >
> > I'd also rather keep this constrained, maybe an android specific board
> > callback to set boot args (if there isn't one already) and have the FDT
> > fixup code be alongside some other generic FDT fixup stuff. I'd rather
> > not have this stuff in board specific code.
>
> I also agree with Casey here. Looking at patch: "[PATCH 3/3]
> mach-snapdragon: Add support to append string to kernel cmdline", the
> android bootmethod already takes care of some androidboot.* arguments.
> See:
>
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/boot/bootmeth_android.c?ref_type=heads#L504
>
> For androidboot.verifiedbootstate=orange, this is done via
> avb_append_commandline_arg() when AVB is enabled in U-Boot.
>

Reasonable. My plan is remove all default params. I still not decided to
let kconfig do it or leave it as a new env var. And put that post-pending
logic into fdt-support.c

Thx again,
George


> >
> > I hope this makes sense, feel free to ask for clarifications on anything.
> >
> > Thanks and kind regards,
> >
> >>
> >> /dts-v1/;
> >>
> >> / {
> >>          qcom,msm-id = <443 0x0>;
> >>          qcom,board-id = <0 0>,
> >>                      <0x10022 1>,
> >>                      <0x20022 1>,
> >>                      <0x30022 1>,
> >>                      <0x40022 1>,
> >>                      <0x50022 1>;
> >>
> >>          #address-cells = <2>;
> >>          #size-cells = <2>;
> >>
> >>          memory {
> >>                  ddr_device_type = <0x07>;
> >>                  /* We expect the bootloader to fill in the size */
> >>                  reg = <0 0 0 0>;
> >>          };
> >>
> >>      chosen {
> >>              bootargs = "";
> >>      };
> >> };
> >>
> >> Signed-off-by: George Chan <gchan9527@gmail.com>
> >> ---
> >> George Chan (3):
> >>        boot/image-android.c: Workaround androidboot kernel/ramdisk addr
> >>        boot/bootmeth-android.c: Reuse fastboot memory block for unzip
> kernel
> >>        mach-snapdragon: Add support to append string to kernel cmdline
> >>
> >>   arch/arm/mach-snapdragon/Kconfig | 11 +++++
> >>   arch/arm/mach-snapdragon/board.c | 97
> ++++++++++++++++++++++++++++++++++++++++
> >>   boot/bootmeth_android.c          | 12 +++++
> >>   boot/image-android.c             | 10 +++++
> >>   4 files changed, 130 insertions(+)
> >> ---
> >> base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
> >> change-id: 20250427-android-boot-ecbb768cda72
> >>
> >> Best regards,
> > --
> > Casey (she/they)
>

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[Mattijs Korpershoek]

Hi George,

On mer., avril 30, 2025 at 11:58, george chan <gchan9527@gmail.com> wrote:

> Hi Mattijs,
> CC: Casey,
>
> Thx for your reply.
>
>
> 在 2025年4月29日週二 16:30，Mattijs Korpershoek <mkorpershoek@kernel.org> 寫道：
>
>> Hi George,
>>
>> Thank you for contributing.
>>
>> On lun., avril 28, 2025 at 15:53, Casey Connolly <
>> casey.connolly@linaro.org> wrote:
>>
>> > Hi George,
>> >
>> > Thanks a lot for the series, it's super exciting to see support for
>> > booting Android on top of U-Boot :D
>> >
>> > On 4/27/25 13:25, George Chan via B4 Relay wrote:
>> >> This is a series of patches to enable chainloading LineageOS on qcom
>> SOC.
>> >>
>> >> First patch is to workaround kernel/ramdisk invalid addr by identify
>> >> its physical memory address out-of-range. Since qcom SOC usually have
>> >> 0x80000000 as start/base/real memory address but androidboot img
>> >> specified to around 0x0. If other vendor bootloader behave similar then
>> >> this patch can also workaround it as well.
>> >
>> > I'm curious to know what values are there, tbh I think U-Boot should
>> > entirely ignore the values in the boot image but I guess that could
>> > break some other platforms.
>>
>> Yes, some platforms actually use the values from the boot.img.
>> We had some breakage on Khadas VIM3 in this area. See:
>>
>> https://lore.kernel.org/all/20241003-android-fix-boot-v2-v1-1-13e8e44af4b7@baylibre.com/
>>
>> The above thread also mentions how to repack a boot.img, where we can
>> specify a different ramdisk address.
>>
>> It's a bit unclear to me why it's impractical to repack the boot.img and
>> specify the appropriate address. Could you elaborate ?
>
>
> It is hard to ask less experience people to modify the boot img....I do
> prefer no mod is the best. Why get life so complicated, my friend?

Sorry, In my opinion this is not a valid argument. Why is patching the
bootloader more complicated than repacking the boot.img ?

Can you maybe illustrate with a detailed example?

The offsets can also be configured via the Android build system directly
by modifying BOARD_MKBOOTIMG_ARGS, see:
https://cs.android.com/android/platform/superproject/main/+/main:device/amlogic/yukawa/BoardConfig.mk;l=114?q=BOARD_MKBOOTIMG_ARGS&start=1
https://cs.android.com/android/platform/superproject/main/+/main:device/linaro/dragonboard/linaro_swr/BoardConfig.mk;l=17?q=BOARD_MKBOOTIMG_ARGS&start=21

>
>
>> >
>> > How about adding a config option CONFIG_ANDROID_BOOTIMG_IGNORE_ADDRS and
>> > just ORing it in all the places that have checks like
>> > "img_data->kernel_addr == 0". Then you can enable this for
>> > mach-snapdragon by selecting it in the ARCH_SNAPDRAGON config definition.
>>
>> If we need to add this in U-Boot, I'd prefer this option as suggested by
>> Casey.
>>
>
> No problem. If this approach have wider audience and also benefit other
> soc/device, I am glad to know. Lets wait for user of below code and see if
> any willingness to migrate.
>
> https://github.com/u-boot/u-boot/blob/d75998b476de439a05b2f7ec95d426410bcaae18/boot/image-android.c#L271
>
> And
>
> https://github.com/u-boot/u-boot/blob/d75998b476de439a05b2f7ec95d426410bcaae18/boot/image-android.c#L281
>
>
>> >
>> >>
>> >> Second patch is enable bootmeth-android to have chance for extra mem
>> block.
>> >> Usually the fastboot mem block, to hold androidboot img, and loadaddr
>> for
>> >> unzipped kernel. If other SOC have extra mem block available but
>> >> fastboot block, we can add extra logic to take care of it.
>> >
>> > There is a small hack in mach-snapdragon that we put kernel_addr_r and
>> > loadaddr at the same address to avoid using up too much memory on
>> > devices that only have 1GB which explains this crash because we try to
>> > decompress the kernel to the same address it got loaded too.
>> >
>> > I think we can get away with giving loadaddr its own allocation of 64M
>> > or so, maybe 96. This would make your second patch redundant (and feels
>> > like the right fix to me)
>>
>> I was not aware of this hack, but I agree with Casey.
>>
>
> Hmm... I have no idea/experience about it. Casey will you follow this issue
> with a proper patch?
>
>
>> >
>> >>
>> >> Third patch is optional to enable snapdragon board to have extra cmdline
>> >> found from original bootloader that is required for LineageOS boot init.
>> >> An alternate method is to put the append string into a dummy device-tree
>> >> file, as /chosen/bootarg ofnode porperty, that also contain msm-id. Then
>> >> encapsulate as androidboot img and let u-boot as kernel binary. Below is
>> >> an example for Xiaomi Miatoll device.
>> >
>> > I assume you're chainloading U-Boot on this device? If so, isn't it
>> > enough to just copy the boot args that ABL gives us and maybe tweak a
>> few?
>> >
>> > I'd also rather keep this constrained, maybe an android specific board
>> > callback to set boot args (if there isn't one already) and have the FDT
>> > fixup code be alongside some other generic FDT fixup stuff. I'd rather
>> > not have this stuff in board specific code.
>>
>> I also agree with Casey here. Looking at patch: "[PATCH 3/3]
>> mach-snapdragon: Add support to append string to kernel cmdline", the
>> android bootmethod already takes care of some androidboot.* arguments.
>> See:
>>
>>
>> https://source.denx.de/u-boot/u-boot/-/blob/master/boot/bootmeth_android.c?ref_type=heads#L504
>>
>> For androidboot.verifiedbootstate=orange, this is done via
>> avb_append_commandline_arg() when AVB is enabled in U-Boot.
>>
>
> Reasonable. My plan is remove all default params. I still not decided to
> let kconfig do it or leave it as a new env var. And put that post-pending
> logic into fdt-support.c
>
> Thx again,
> George
>
>
>> >
>> > I hope this makes sense, feel free to ask for clarifications on anything.
>> >
>> > Thanks and kind regards,
>> >
>> >>
>> >> /dts-v1/;
>> >>
>> >> / {
>> >>          qcom,msm-id = <443 0x0>;
>> >>          qcom,board-id = <0 0>,
>> >>                      <0x10022 1>,
>> >>                      <0x20022 1>,
>> >>                      <0x30022 1>,
>> >>                      <0x40022 1>,
>> >>                      <0x50022 1>;
>> >>
>> >>          #address-cells = <2>;
>> >>          #size-cells = <2>;
>> >>
>> >>          memory {
>> >>                  ddr_device_type = <0x07>;
>> >>                  /* We expect the bootloader to fill in the size */
>> >>                  reg = <0 0 0 0>;
>> >>          };
>> >>
>> >>      chosen {
>> >>              bootargs = "";
>> >>      };
>> >> };
>> >>
>> >> Signed-off-by: George Chan <gchan9527@gmail.com>
>> >> ---
>> >> George Chan (3):
>> >>        boot/image-android.c: Workaround androidboot kernel/ramdisk addr
>> >>        boot/bootmeth-android.c: Reuse fastboot memory block for unzip
>> kernel
>> >>        mach-snapdragon: Add support to append string to kernel cmdline
>> >>
>> >>   arch/arm/mach-snapdragon/Kconfig | 11 +++++
>> >>   arch/arm/mach-snapdragon/board.c | 97
>> ++++++++++++++++++++++++++++++++++++++++
>> >>   boot/bootmeth_android.c          | 12 +++++
>> >>   boot/image-android.c             | 10 +++++
>> >>   4 files changed, 130 insertions(+)
>> >> ---
>> >> base-commit: 5a0a93a768487e55ebe50a34cc90d751bf99cc56
>> >> change-id: 20250427-android-boot-ecbb768cda72
>> >>
>> >> Best regards,
>> > --
>> > Casey (she/they)
>>

Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg

[george chan]

Hi Mattijs,

Thx for reply. I like your attitude and appreciate it. There are many topic
get silent in the end.


> >> It's a bit unclear to me why it's impractical to repack the boot.img and
> >> specify the appropriate address. Could you elaborate ?
> >
> >
> > It is hard to ask less experience people to modify the boot img....I do
> > prefer no mod is the best. Why get life so complicated, my friend?
>
> Sorry, In my opinion this is not a valid argument. Why is patching the
> bootloader more complicated than repacking the boot.img ?
>

No, i mean repacking or modding boot.img is a very complicated thing for
less experience(not me! well, lazy, in other words, thats me!) people.
Sorry to get you confused.

Lets get it clear, for not going back and forth, in case of typo.

If you are talking about modding/repacking is easier than changing uboot
logic. Or there is already a similar logic exists, only make a small mod
for bootimg will solve the chain loading kind of thing. And then my opinion
is, it might be a short term solution for engineer and as the shorter the
better. I prefer to make "uboot for dummy" in mind. And it benefits those
lineage os phone user (including me) who also wanted to dual boot other os.
And easily update official los bootimg without any modding for every time;
that's why I hate dtbo partition.

If you agreed making uboot change is easier than modding bootimg then we
are same side, man.

Btw my proposed change of the loadaddr and kernel_addr_r conflict issue can
work like a band-aid short term solution and easily get reverted. I forsee
the proper fix is hard to get ready in short term.

Thx for letting me explain how I thought. Appreciated!

Regards,
George