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.
We will keep looking into this.
For now, we have mostly worked on cleaning up/syncing the downstream [1] yukawa tree in order to enable AOSP users to rebuild their U-Boot from mainline.
[1] http://patchwork.ozlabs.org/project/uboot/patch/20170402084952.5102-7-deymo@... [2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
We've been thinking about that, but the Android boot flow doesn't really leave place for other methods.
In our implementation we decided to use the distro_bootcmd helper to setup the different Android boot flow steps, it permits to have a much simpler cmd definition than the other implementation, but makes mixing with the default boot steps more complex (or maybe there is something we can use to enable/disable easily some distro BOOT_TARGET_DEVICES ?)
Neil