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". > > 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. >
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
