[PATCH 0/9] meson64_android: Android boot flow using abootimg

[Mattijs Korpershoek]

Hi Neil, Tom,

Neil Armstrong <narmstrong at baylibre.com> writes:

> On 05/08/2021 19:23, Tom Rini wrote:
>> On Thu, Aug 05, 2021 at 05:17:19PM +0200, Mattijs Korpershoek wrote:
>> 
>>> The SEI-610 and SEI-510 boards are well supported in the
>>> Android Open Source project via the yukawa [1] platform.
>>>
>>> Their U-Boot version, despite being public [2] is not in mainline.
>>>
>>> Android 10 and higher have significantly reworked the bootloader
>>> requirements:
>>>
>>> * bootloader should pass slot information in case of A/B
>>> * bootloader should perform AVB verification in case it's supported
>>> * bootloader should read and apply dtb overlays from a dtbo partition
>>>
>>> These series add support for all the above.
>>>
>>> [1] https://android.googlesource.com/device/amlogic/yukawa
>>> [2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
>> 
>> My high level concern with this series is that it takes what I assume is
>> the Android-only boot path, and adds further abstractions to it, it
>> looks like.  Can we just say "Here is the Android 10 boot path" (since
>> AVB has been around for a while) and here is the generic distro boot
>> path for non-Android?  Reading this over it looks like it becomes "Here
>> is the Android + AVB boot path", "Here is the Androidd non-AVB boot
>> path" and then I assume "Here is the generic distro boot path".
Not exactly. Android supports multiple combinations:
- non-AVB + no-A/B  (legacy, no security). This is usually used for
development builds
- AVB + no-A/B
- AVB + A/B
Here, we should be supporting all of the above using compile flags.
>> 
>> I'd also like to know if in general we can make some generic environment
>> macros for "Here is Android AVB boot path", so that we don't need to
>> duplicate this between SoCs.  At the very high level, something like the
>> generic distro boot framework, but that does Android instead.
I agree. It would be really nice if we could have a generic "boot android" framework

TI has a ti_omap5_common.h which seems to support similar things.
However, it does not support the "no-A/B" mode.
In that file, we can also see board specific logic: namely the mapping
between the $board_name and the dtbo index passed to "abootimg".

Google has another approach via the boot_android[1] command.

We will keep looking into this.

For now, we have mostly worked on cleaning up/syncing the downstream [1]
yukawa tree in order to enable AOSP users to rebuild their U-Boot from mainline.

[1] http://patchwork.ozlabs.org/project/uboot/patch/20170402084952.5102-7-deymo@google.com/
[2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
>> 
>
> We've been thinking about that, but the Android boot flow doesn't really leave place
> for other methods.
>
> In our implementation we decided to use the distro_bootcmd helper to setup the different
> Android boot flow steps, it permits to have a much simpler cmd definition than the other
> implementation, but makes mixing with the default boot steps more complex (or maybe there
> is something we can use to enable/disable easily some distro BOOT_TARGET_DEVICES ?)
>
> Neil