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. 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-de...@google.com/ [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
