Hi Igor, On Mon, Oct 12, 2026 at 20:23, Igor Opaniuk <[email protected]> wrote:
> Hi Mattijs, > > On Sun, Oct 11, 2026 at 4:42 PM Igor Opaniuk > <[email protected]> wrote: >> >> Android's fastboot client changes the device lock state with >> "fastboot flashing lock|unlock" and asks "flashing get_unlock_ability" >> first. U-Boot has the state in the AVB TA (avb_write_lock_state(), used by >> the "avb lock/unlock" shell commands) but no fastboot front end for it, so >> a device could only be unlocked from the serial console. >> >> Add the three commands and the "unlocked" variable behind >> CONFIG_FASTBOOT_CMD_FLASHING. As AVB requires, both transitions erase >> userdata (and metadata, which holds the file based encryption keys) before >> the state changes and are refused when userdata cannot be erased; the TA >> resets the rollback indexes on a state change. get_unlock_ability always >> reports 1 since U-Boot does not evaluate the "OEM unlocking" setting >> Android keeps in the frp partition. >> >> Tested on QEMU virt with OP-TEE over "fastboot tcp": unlock and lock >> erase the partitions and flip the state reported by getvar unlocked and >> "avb is_unlocked". >> > > This exact patch ("avb: device lock state, root key provisioning and > in-place verification") > fails to compile in every configuration that has fastboot but not > FASTBOOT_CMD_FLASHING. > The extended CI job run just caught that. I’ll address it in v2. Thanks for the notice. I'll look at v2. Mattijs
