I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Let me address your questions about the Ivy Plus carrier board and TPM configuration.
TPM Support on Ivy Plus Carrier Board
The Ivy Plus carrier board includes a TPM 2.0 IC on the SPI bus, which is one of the key differences from the standard Ivy board (1). According to the datasheet, the TPM component is part number SLM9670 on SPI_1, with GPIO1 (SODIMM 206) used for chip select (2).
Device Tree Configuration Issue
Your current tcbuild.yaml references imx8mp-verdin-nonwifi-ivy.dts, but this appears to be for the standard Ivy board, not the Ivy Plus variant. The TPM error you’re seeing suggests the device tree isn’t properly configured for the Ivy Plus’s TPM hardware.
Ivy vs Ivy Plus Differences
The key differences between the two boards are (1):
Feature
Ivy (0175XXXX)
Ivy Plus (0178XXXX)
TPM
Not included
Included
FRAM
Not included
32KB
Power Supply Range
8 to 32V
21 to 72V
CAN/RS-232/RS-485
Non-isolated
Isolated
Analog Input
Non-isolated
Isolated
Device Tree File Availability
Based on the available documentation, there are preliminary schematics available for both Ivy and Ivy Plus boards (3), but the sources don’t explicitly mention separate device tree files for the Ivy Plus variant. The community forum discussions suggest users have been working with custom device trees for the Ivy boards (4).
Recommendation
Since the Ivy Plus includes additional hardware (TPM, FRAM) not present in the standard Ivy board, you may need to:
Verify if there’s a specific device tree file for Ivy Plus in your kernel sources
If not available, create a custom device tree overlay that properly configures the TPM and other Ivy Plus-specific components
Ensure the TPM driver and SPI configuration are properly enabled in your device tree
The TPM error (256) typically indicates a self-test failure, which could be due to incorrect device tree configuration or missing driver support.
Can you create a feature request for the development team to create an Ivy Plus specific device tree or overlay for the TPM and FRAM adding them to the respective git.toradex.com repositories?
The TPM Device Tree node is already included in the Ivy device tree. Please double-check that your build includes the correct Device Tree source and that the corresponding DTB blob is properly applied
Thanks for pointing me to the correct dt node (my oversight). I did confirm that the node is in the running system with cat /proc/device-tree/soc@0/bus@30800000/spba-bus@30800000/spi@30820000/tpm@1/compatible.
I’ll take a deeper look at the driver and SPI traffic to see if I can understand why I’m getting the boot error of tpm tpm0: A TPM error (256) occurred attempting the self test.
Digging deeper, it appears that in the driver (tpm2-cmd.c) function tpm2_auto_startup the first call to tpm2_do_selftest fails with TPM2_RC_INITIALIZE (256) but then calls tpm2_startup which succeeds and then calls tpm2_do_selftest again which succeeds.
At the moment, anything TPM related with Torizon requires working at the Yocto Layer rather than with torizoncore-builder. All of our security work is being done on github and you may be best off posting there for support from the security devs directly.
That said, I am having a conversation early next week with Product Management to figure out what and how to better support this, especially in the Ivy Plus board. Do you have a list of features and use cases you want to implement with the onboard TPM?
Thanks for following up and discussing this topic with PM. Right now my interest is mostly out of curiosity as to why the TPM was put on this carrier board. Was it for secure boot or device identity (key storage). My PM is noticing TPMs being included in other competing products but I’m trying to understand the use case(s) that the microprocessor security features (secure enclave etc.) would not be able to accommodate and have been tasked to evaluate the TPM on the Ivy Plus board to understand it’s capabilities/advantages.
I’m also in the process of evaluating Torizon to see how far we can go without having to create our own Yocto layer/build and thought that a peripheral on a standard Toradex carrier board would have “off-the-shelf” support
We do not use the TPM for Secure Boot. We use the SOC built-in components so that external parts are not required. On the NXP chips we use their HAB or AHAB subsystems and on TI, it’s the HSM subsystem. Details here: Secure Boot | Toradex Developer Center
The TPM has other features mostly usable for applications. I think only the Ivy Plus has a TPM on it so we cannot rely on one being present. I’ll let you know what specific details I get.
Mallow carrier bard also features the optiga SLM9670 TPM
TPM 2.0 Features:
The TPM provides the following features and extension possibilities to a platform:
Secure storage of data
o This storage is protected against unauthorized access through hardware and software attacks.
Genuine trust anchor
o During the process of personalization (that is one of the last manufacturing steps) a unique
Endorsement Key and an Endorsement Certificate issued by the TPM manufacturer are being
externally generated, imported and securely stored in the TPM’s non-volatile memory.
o The personalization happens in a highly secured and certified manufacturing environment, so
by validating the Endorsement Certificate, one can verify that the TPM is genuine and thus
trustworthy.
Key hierarchy
o A TPM key is always generated by derivation from a parent key (except for the storage root key
(SRK)) and can in turn have multiple child keys.
o Except for the SRK, every parent key also has a parent key.
o Eventually, all keys are derived from the SRK. Thus, the SRK is the root for all keys.
o By deleting a parent key, all of its child keys become invalid.
o A TPM can have multiple keys for multiple users, applications and purposes.
o Access to critical keys is secured by a secret, for example a user password in case of a user key,
so the keys of one user can be protected from being accessed by another user.
Ability to securely generate, store and use keys
o The generated keys are protected by encryption with a parent key.
o Before usage, this key must be loaded into the TPM, where it will be decrypted for usage.
o Thus, data protected by this key is to be decrypted inside the TPM.
Support for non-migratable keys
o Such keys cannot be migrated to other TPMs; they are bound to the chip and the platform.
o The parent key of a non-migratable key must also be non-migratable, thus obviously the SRK is
always non-migratable.
o A non-migratable key can have both migratable and non-migratable child keys.
o The migration ability is set during key generation or import and cannot be changed afterwards.
Hardware random number generator
o Can generate non-predictable, cryptographically strong random numbers
o This hardware random number generator (RNG) is protected against manipulation, thus these
numbers are more reliable than numbers generated with a software RNG.
Dictionary attack prevention mechanisms
o Implemented in hardware and delays brute force attacks on the TPM by disabling the chip after
a certain amount of failed authentication attempts. It is exponentially increasing the lockout
time after every further failing attempt. This makes brute force attacks with a larger number of
tries extremely time consuming and thereby nearly practically impossible which effectively
hinders a successful attack.
I have worked with the PM and docs team and they have the next steps here. For now I am going to close this ticket but if you have specific use cases you need help with please create a new ticket and you can @-mention me directly to ensure I get notified.
