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 <[email protected]> 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
