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@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