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

[Neil Armstrong]

Hi,

On 06/08/2021 17:56, Tom Rini wrote:
> On Fri, Aug 06, 2021 at 05:36:41PM +0200, Mattijs Korpershoek wrote:
>> 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.
> 
> I guess I'm a little disappointed that there was no follow up to the
> question about boot_android.  I would like to see the Android support
> made easier to work with.
> 

We share the same disappointment, the Android boot flow is incredibly hard
to implement and test. And completely changes in incompatible ways between
new releases.

Neil