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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210806/3cf7ef93/attachment.sig>