From: Mattijs Korpershoek <mkorpershoek@kernel.org>
To: Casey Connolly <casey.connolly@linaro.org>,
gchan9527@gmail.com, Tom Rini <trini@konsulko.com>,
Mattijs Korpershoek <mkorpershoek@kernel.org>,
Simon Glass <sjg@chromium.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Sumit Garg <sumit.garg@kernel.org>
Cc: u-boot@lists.denx.de, u-boot-qcom@groups.io
Subject: Re: [PATCH 0/3] u-boot chain-loading LineageOS bootimg
Date: Tue, 29 Apr 2025 10:30:07 +0200 [thread overview]
Message-ID: <87v7qnwesw.fsf@kernel.org> (raw)
In-Reply-To: <dfe2c6d1-1935-4af3-b7d2-b04fdcbe6f29@linaro.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 ?
>
> 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)
next prev parent reply other threads:[~2025-04-29 8:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-27 11:25 [PATCH 0/3] u-boot chain-loading LineageOS bootimg George Chan
2025-04-27 11:25 ` George Chan via B4 Relay
2025-04-27 11:25 ` [PATCH 1/3] boot/image-android.c: Workaround androidboot kernel/ramdisk addr George Chan
2025-04-27 11:25 ` George Chan via B4 Relay
2025-04-27 11:25 ` [PATCH 2/3] boot/bootmeth-android.c: Reuse fastboot memory block for unzip kernel George Chan
2025-04-27 11:25 ` George Chan via B4 Relay
2025-04-27 11:25 ` [PATCH 3/3] mach-snapdragon: Add support to append string to kernel cmdline George Chan
2025-04-27 11:25 ` George Chan via B4 Relay
2025-04-28 13:53 ` [PATCH 0/3] u-boot chain-loading LineageOS bootimg Casey Connolly
2025-04-29 4:04 ` george chan
2025-04-29 8:30 ` Mattijs Korpershoek [this message]
2025-04-30 3:58 ` george chan
2025-04-30 12:03 ` Mattijs Korpershoek
2025-04-30 15:13 ` george chan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v7qnwesw.fsf@kernel.org \
--to=mkorpershoek@kernel.org \
--cc=casey.connolly@linaro.org \
--cc=gchan9527@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=sjg@chromium.org \
--cc=sumit.garg@kernel.org \
--cc=trini@konsulko.com \
--cc=u-boot-qcom@groups.io \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.