Hi Simon, On Thu, 1 Oct 2026 at 11:20, Simon Glass <[email protected]> wrote: > This seems like a good way to enable the TPM for boards that want it. > It would be good to document this somewhere, e.g. where we mention > MEASURED_BOOT
Thanks. I have added a section to doc/usage/measured_boot.rst for v2. > It seems odd to ignore an error in this case - if the board maintainer > says that a TPM must be present, then I would expect U-Boot to fail if > it is not. The option is meant as "start the TPM if there is one" rather than "a TPM must be present". A non-zero return from an EVT_LAST_STAGE_INIT spy ends up in hang() via INITCALL_EVT(), so a missing or broken TPM would leave the board stuck in U-Boot without a way to diagnose or update it. It would also rule out boards like ours, which share one binary between variants with and without a TPM fitted, where a missing node is the normal case. If a board really must refuse to boot without a TPM, I think that is better handled by a separate, stricter option than by this one. > In any case, uclass_first_device_err() also fails when the TPM is in > the devicetree but fails to probe, e.g. because of a bus or GPIO-reset > problem on a board that has the chip fitted. That is a real fault, but > log_debug() hides it. Please can you stay silent only for -ENODEV and > use log_warning() for anything else? Good point, done for v2. > tpm_auto_start() returns a u32, which may be a negative errno or a TPM > response code (e.g. TPM2_RC_INITIALIZE). A response code printed in > decimal from an int is hard to match against the spec, so please use a > u32 and %#x here, as report_return_code() does for the tpm command. Done. > This is not really a driver, so lib/ (next to tpm_api.c) may be a > better home than drivers/tpm. What do you think? Agreed, moved to lib/tpm_autostart.c, with the Kconfig option next to TPM in lib/Kconfig. Whether the startup should go into probe instead is being discussed in the other part of this thread; I will follow what is agreed there for v2. > Please can you enable this on sandbox and it would be nice to have a > test in test/dm/tpm.c, checking that the TPM is started after init and > that a missing TPM is handled. Your test could send the event. Done. There are two new tests which send EVT_LAST_STAGE_INIT with event_notify_null(): one checks that init_done goes from 0 to 1, the other unbinds the TPMs and checks that the event still succeeds. > A full self-test on a TPMv2 can take a noticeable time, so the help > should mention that this adds to the boot time on every boot, even > when the TPM is not used. Done, in both the help text and the docs. > BTW, since the commit message mentions > board/xilinx/zynqmp/zynqmp_kria.env, you could convert that board in a > follow-up patch to show how the option is used. Yes, I can do that once this has landed. I don't have the hardware though, so it would need testing by someone who does. Regards, Michael
