[PATCH v4 00/14] tpm: Add wolfTPM library support for TPM 2.0

[Ilias Apalodimas]

Hi Aidan

On Wed, 13 May 2026 at 03:26, Aidan Garske <aidan at wolfssl.com> wrote:
>
> Hi all,

Thanks for all the efforts. Unfortunaltely I don't think we can pick
any of these up. WolfTPM is listed as GPLv3, which is incompatible
with U-Boot [0]. Tom am I misunderstanding any of this?

>
> This is v4 of the wolfTPM TPM 2.0 stack integration for U-Boot.
>
> What this series does
> ---------------------
>
> wolfTPM (https://github.com/wolfSSL/wolfTPM) is a portable TPM 2.0
> library that provides a full TPM 2.0 command set, an SPI/MMIO HAL,
> and firmware-update support for Infineon SLB9672/SLB9673 hardware.
> This series wires it into U-Boot as an *optional* alternative
> backend behind the existing 'tpm2' command, plus the supporting
> infrastructure to make it run on QEMU+swtpm, sandbox, and real
> Raspberry Pi 4 + Infineon SLB9672 hardware.
>
> Why a second TPM backend
> ------------------------
>
> U-Boot already has a working TPM 2.0 stack and Peter Robinson asked
> in v3 review what value this brings. The honest answer is:
>
>  1. Firmware update support for Infineon SLB9672/SLB9673.  The
>     existing U-Boot TPM 2.0 stack has no firmware-update command;
>     wolfTPM provides the manifest+image flashing flow used by
>     Infineon's recovery / security-patch tooling.  This is the
>     primary "why now" reason for boards shipping Infineon TPM HATs
>     where the field-updatable firmware is part of the supported
>     lifecycle.
>
>  2. Optional native SPI HAL.  The wolfTPM library can talk to a TPM
>     via either (a) U-Boot's existing TPM driver model (the
>     WOLFTPM_LINUX_DEV path; this is what QEMU+swtpm uses in this
>     series) or (b) its own SPI HAL bypassing driver model.  Path (b)
>     is what lets the BCM2835/BCM2711 driver in patch 3 talk straight
>     to the Infineon HAT on a stock Pi 4 without needing the broader
>     TPM uclass machinery.
>
>  3. Backend selection is a Kconfig switch; CONFIG_TPM_WOLF is
>     default-off and 'tpm2' continues to dispatch to the existing
>     backend unless the user opts in.  No defconfig in tree turns
>     this on today except the new rpi_4_wolftpm one this series adds.
>
> Maintenance
> -----------
>
> wolfTPM is imported as a git subtree under lib/wolftpm (mirroring
> how lib/mbedtls, lib/lwip and dts/upstream are maintained in tree),
> and tools/update-subtree.sh knows about it.  Updates flow through
> the standard `git subtree pull` path, not as separate patches.
>
> Note on license: github.com/wolfSSL/wolfTPM currently shows GPL-3.0
> in its repo badge.  wolfSSL is working on a GPLv2-compatible release
> for upstreaming purposes; this series is being sent now to get
> review on the integration shape, with the understanding that the
> license question is being addressed separately by wolfSSL before
> this is appropriate to merge.  I will follow up on the list when
> that's resolved.
>
> Changes since v3
> ----------------
>
> Addressing review from Peter Robinson on v3:
>
>  - SPI driver copyright attribution fixed to credit the original
>    Linux kernel authors (Chris Boot, Stephen Warren, Martin Sperl)
>    the U-Boot driver is ported from.  The driver is still in this
>    series rather than split off, because nothing else in the tree
>    uses it yet and decoupling it would just create a "blocked on"
>    dependency chain; if reviewers prefer it split, happy to do that
>    in v5.
>  - rpi_4_defconfig is no longer modified.  v3 added CONFIG_LOG /
>    LOGLEVEL=7 / UNIT_TEST / CONSOLE_RECORD / HEXDUMP to it - that
>    was wrong, it's not what the average RPi user wants.  Instead,
>    v4 adds a *new* rpi_4_wolftpm_defconfig that enables only the
>    bits a wolfTPM user actually needs (SPI + TPM + wolfTPM).  No
>    debug / unit-test pollution.  Users who don't want wolfTPM
>    continue to use rpi_4_defconfig untouched.
>  - The TPM device-tree node for the SLB9670/9672 on RPi 4 has been
>    moved out of bcm2711-rpi-4-b.dts (which is Linux-derived and
>    should match upstream) and into bcm2711-rpi-4-b-u-boot.dtsi
>    (which is the U-Boot convention for U-Boot-only DT additions).
>    This means SystemReady firmware-provided FDTs and the upstream
>    Linux DT are no longer polluted by this series.
>  - DT changes are now split into three per-device commits (RPi4,
>    QEMU arm64, sandbox) instead of one combined commit.
>  - Commit messages rewritten to explain *why* the change is being
>    made, not just *what* configs are set.
>


[...]

[0] https://github.com/wolfSSL/wolfTPM/blob/master/LICENSE

Thanks
/Ilias