On Fri, Aug 06, 2021 at 05:36:41PM +0200, Mattijs Korpershoek wrote: > Hi Neil, Tom, > > Neil Armstrong <narmstr...@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
signature.asc
Description: PGP signature
