Hi Michael,
On 2026-09-30T09:05:12, Michael Haener <[email protected]> wrote:
> tpm: Add an option to start the TPM during init
>
> Add CONFIG_TPM_AUTOSTART, which runs the TPM startup and self-test
> sequence from an EVT_LAST_STAGE_INIT handler. This is the same thing the
> 'tpm autostart' command does, but it does not depend on a boot script or
> on the environment, so it cannot be skipped by a stale or edited env.
>
> Today a TPM is only started automatically when either CONFIG_MEASURED_BOOT
> is used (and then only from bootm) or when booting via EFI with
> CONFIG_EFI_TCG2_PROTOCOL. A plain booti/bootm therefore leaves the chip
> uninitialised and the OS has to start it itself, which Linux reports as
> "A TPM error (256) occurred attempting the self test". Boards have worked
> around this by putting 'tpm autostart' into their environment, see
> board/xilinx/zynqmp/zynqmp_kria.env.
>
> Boards that share one binary between variants with and without a TPM
> fitted can enable this safely: when no TPM device is found the startup is
> skipped silently.
>
> Signed-off-by: Michael Haener <[email protected]>
>
> drivers/tpm/Kconfig | 15 +++++++++++++++
> drivers/tpm/Makefile | 1 +
> drivers/tpm/tpm_autostart.c | 33 +++++++++++++++++++++++++++++++++
> 3 files changed, 49 insertions(+)
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
> diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c
> @@ -0,0 +1,33 @@
> + /* A board may share one binary between variants without a TPM. */
> + ret = uclass_first_device_err(UCLASS_TPM, &dev);
> + if (ret) {
> + log_debug("No TPM found (err=%d)\n", ret);
> + return 0;
> + }
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.
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?
> diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c
> @@ -0,0 +1,33 @@
> + ret = tpm_auto_start(dev);
> + if (ret)
> + log_warning("TPM startup failed (err=%d)\n", ret);
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.
> diff --git a/drivers/tpm/tpm_autostart.c b/drivers/tpm/tpm_autostart.c
> @@ -0,0 +1,33 @@
> +EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, tpm_evt_autostart);
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?
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.
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.
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.
Regards,
Simon
