TPM Error 256 and "TPM interrupt not working" on SPI TPM (tpm_tis_spi spi0.1)

Hi everyone,

I’m running into an issue during boot with a TPM module connected via SPI. Here’s the output from dmesg:

[ 12.650192] tpm_tis_spi spi0.1: 2.0 TPM (device-id 0x1B, rev-id 22)
[ 12.668792] tpm tpm0: A TPM error (256) occurred attempting the self test
[ 12.682978] tpm tpm0: starting up the TPM manually
[ 12.895531] remoteproc remoteproc0: 30074000.pru is available
[ 12.909241] remoteproc remoteproc1: 30078000.pru is available
[ 13.275874] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

Context: Mallow carrier Board with AM62 som
What does TPM error 256 typically indicate during the self-test?
Is “TPM interrupt not working” a sign of misconfigured hardware (e.g., missing IRQ) or a known kernel issue?
Is it safe to rely on polling instead of interrupts for TPM communication?

Any advice or direction on how to debug this would be greatly appreciated.

Thanks in advance!

Hi, I’m the Toradex AI Assistant.

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? :+1: :-1:


Hello and thank you for your detailed question!

Let’s address your points regarding the TPM module connected via SPI on your Mallow carrier board with the AM62 SoM:

1. TPM Error 256 During Self-Test

  • Meaning: Error code 256 (0x100) in the TPM context often refers to a failure or abnormal result from the TPM’s built-in self-test routine. This could be due to communication timing issues, incorrect initialization, power supply instability at startup, or compatibility problems with the TPM device and driver.
  • Recommendation: Ensure that your device tree is correctly configured for the SPI bus and TPM chip. Make sure all dependencies (like regulator settings and reset timings) are correct. Consult the TPM datasheet for required startup sequences.

2. “TPM Interrupt Not Working, Polling Instead”

  • Significance: This message typically indicates that the kernel driver could not set up an interrupt handler for the TPM device and, therefore, falls back to polling.
    • This is usually due to a missing or incorrectly assigned IRQ line between the SoM and the TPM module. Double-check your DTB (Device Tree Blob) to ensure the IRQ property is set correctly for the TPM SPI node.
    • It can also happen if the chosen SoM’s GPIO-to-IRQ mapping does not match the hardware configuration or if the TPM lacks an IRQ connection altogether.
  • Action: If possible, wire the TPM IRQ line to a usable GPIO and reference it in your device tree. Example for device tree:
    dts tpm_tis_spi@1 { compatible = "infineon,slb9670"; reg = <1>; irq-gpio = <&gpioX Y GPIO_ACTIVE_HIGH>; ... };

3. Is Polling Safe for TPM?

  • Functionality: Polling is a supported fallback when interrupts are unavailable. While functionally acceptable, it can increase CPU load and cause higher latencies for TPM operations, especially if your system frequently interacts with the TPM.
  • Recommendation: For production and security-sensitive systems, it’s best to use interrupts for efficiency and responsiveness. Polling is generally fine for light or infrequent TPM usage, but not ideal if your use case involves heavy TPM activity.

Debugging Steps

  1. Check Device Tree: Validate that your TPM SPI node specifies an irq-gpio and that it matches actual hardware wiring.
  2. Hardware Checks: Confirm the IRQ line is actually connected between the TPM and the SoM. Use an oscilloscope or multimeter if unsure.
  3. Kernel Logs: Review dmesg for additional TPM or SPI errors.
  4. Kernel Version: Ensure your kernel version supports your TPM module; occasionally, kernel bugs or missing support can cause issues like these.

Helpful Links

If you clarify your device tree configuration and kernel version, I can help with more specific guidance.

Best regards,
Toradex AI Assistant.