Starting with a deactivated tpm sometimes seems to be leading to confiusing behavior in firmware. Showing "no bootable kernel found on disk" on recovery screen 0x5b (issue 763561), possibly switching from dev to normal mode (only possible - relation not confirmed yet, issue 767933).

Can be reproduced by doing 'tpmc clear' from recovery mode w/o subsequent 'tpmc enable' and 'tpmc activate' and rebooting. (See issue 767999 and  issue 468140 ).

The newer coreboot seems to have the code that detects disabled/deactivated state and fixes it by setting the deactivated and disabled flags to proper values. It has to reboot after that since these changes are picked up by the TPM only after reset. See setup_tpm() in coreboot/src/vboot/secdata_tpm.c

On older coreboot revisions, similar actions seem to be performed by VbInit() from vboot_wrapper.  This is what happens on squawks from issue 763561 iiuc.

Still, the errors when reading the antirollback firmware space (and the secdata stored there) - and this is where setup_tpm() is done on newer coreboot - are ignored and vb2api_fw_phase1 is relied upon for catching incorrect state. So, the reboot doesn't actually happen till then. Can that lead to confusing behavior?

It may be worth investigating what exactly happens on deactivated-tpm paths. But it's not critical, as we normally shouldn't end up with a deactivated tpm on a running system. And though the behavior may be confusing, the recovery is simple reboot.