Hi, i test this serie on Spacemit K3 board which use UFS to boot, no issue so :
Tested-by: Guillaume La Roque<[email protected]> Regards Guillaume Le 06/10/2026 à 11:27, Jan Kehren a écrit :
Thanks for the review, and no worries at all about the delay. AVB in U-Boot assumes its partitions are on mmc. bootmeth_android accepts any bootdev but passes only the device number to avb_ops_alloc(), dropping the uclass, so an Android bootflow found on nvme 0 or usb 0 is verified against mmc 0. Patch 1 is the rename, split out as you asked, with no functional change. Patch 2 adds the uclass and the optional "avb init <interface> <dev>" form. On your bootmeth_android point: it has other mmc-specific logic such as bootflow_iter_check_mmc(), so booting Android from another medium through bootstd needs more than this series. The avb_ops_alloc() hunk here stops the verification being aimed at the wrong device; the rest is left for a follow-up. Tested on Raspberry Pi 4 and Raspberry Pi 5, verifying and booting Android from SD on both and from USB mass storage on the Pi 4. Those boards boot through a downstream command rather than bootstd, so the bootmeth_android hunk is build tested only. On the Pi 4 "avb init usb 0" then "avb verify _a" passes, "avb init 0" still resolves to mmc, and an unknown interface or an out-of-range index on either bus is rejected without disturbing ops that were already initialised. Build tested with khadas-vim3_android_defconfig and khadas-vim3l_android_ab_defconfig; each patch also builds on its own. Jan Kehren (2): avb: Drop the mmc naming from the block IO helpers avb: Take a storage interface in the AVB operations boot/bootmeth_android.c | 2 +- cmd/avb.c | 24 +++- common/Kconfig | 7 +- common/avb_verify.c | 167 ++++++++++++++----------- doc/android/avb2.rst | 7 +- include/avb_verify.h | 38 ++++-- test/py/tests/test_android/test_avb.py | 28 +++++ 7 files changed, 181 insertions(+), 92 deletions(-) base-commit: 25a459fd4d2eeef909dd4ea8a577ba82b1fc5e43
