TPM: SLB-9670 not communicating properly on CM4/Pi SPI3 bus

[RJvdBerg]

Describe the bug

The TPM is timing out with the SPI communication to/from the Raspberry Pi CM4 or Pi4, BUT, works on the normal SPI bus intended for the TPM. I'm using the tpm-slb9670 overlay, with modifications to point to SPI3. (See links)

Please see below for more details: https://forums.raspberrypi.com/viewtopic.php?t=337328 https://forums.raspberrypi.com/viewtopic.php?p=2025999

Steps to reproduce the behaviour

Obtain SLB9670 TPM evalulation board from Infineon or get one from Pi3g. Wire up to SPI-3 lines with jumpers, the CE of the TPM should be GPIO 0 (BCM) or GPIO24, depends on your case, behavior is exactly the same. The Pi 4 may produce different results, but nonetheless unable to communicate with the TPM properly.

Device (s)

Raspberry Pi 4 Mod. B, Raspberry Pi CM4

System

rpi-issue: Raspberry Pi reference 2022-04-04 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 27a8050c3c06e567c794620394a8c2d74262a516, stage2

vcgencmd version: Aug 9 2022 13:44:40 Copyright (c) 2012 Broadcom version 273b410636cf8854ca35af91fd738a3d5f8b39b6 (clean) (release) (start)

uname -a: Linux raspberrypi 5.15.56-v8+ #1575 SMP PREEMPT Fri Jul 22 20:31:26 BST 2022 aarch64 GNU/Linux

Logs

Dmesg output: [ 6.066163] tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics [ 6.066317] tpm_tis_status+0xcc/0xf0 [tpm_tis_core] [ 6.066343] wait_for_tpm_stat+0x60/0x248 [tpm_tis_core] [ 6.066360] tpm_tis_send_data+0xe8/0x2a0 [tpm_tis_core] [ 6.066375] tpm_tis_send_main+0x44/0x120 [tpm_tis_core] [ 6.066389] tpm_tis_send+0x4c/0xe0 [tpm_tis_core] [ 6.066404] tpm_transmit+0xd4/0x380 [tpm] [ 6.066449] tpm_transmit_cmd+0x38/0xc8 [tpm] [ 6.066487] tpm2_probe+0x118/0x1c0 [tpm] [ 6.066523] tpm_tis_core_init+0x24c/0x5a0 [tpm_tis_core] [ 6.066539] tpm_tis_spi_init+0x5c/0x78 [tpm_tis_spi] [ 6.066561] tpm_tis_spi_probe+0x80/0x9c [tpm_tis_spi] [ 6.066579] tpm_tis_spi_driver_probe+0x3c/0x70 [tpm_tis_spi] [ 6.837285] tpm tpm0: tpm_try_transmit: send(): error -62 [ 6.860129] tpm_tis_spi spi3.1: 1.2 TPM (device-id 0x1B, rev-id 255) [ 7.849757] tpm tpm0: tpm_try_transmit: send(): error -62 [ 7.849781] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts [ 7.868870] tpm_tis_spi: probe of spi3.1 failed with error -62

Additional context

Do not have access to the first SPI bus on the CM4 module, but have access to the SPI3 bus.

[pelwell]

spi3 uses GPIOs 1-3 (plus usually GPIO 0 for CS0). while spi1 uses GPIOs 19-21 (plus usually GPIO 18 for CS0). A potential important difference between these two groups of pins is the default pull: GPIOs 0-8 have a default pull up, while GPIOs 9-27 have a default pull down. raspi-gpio get 1-3,19-21 should show you that.

Try adding the following to config.txt as a quick way to change the pulls for GPIOs 1-3:

gpio=1-3=pd

A quick test on a Pi 4 shows that GPIO 1 (MISO) still ends up with a pull up - we can work out why later if necessary - but that can be overridden with raspi-gpio set 1-3 pd or you scan skip the config.txt setting and just run this before your test.

Does that make any difference?

[RJvdBerg]

Hrm. I think that I did configure the pins in the config.txt at a time, but IIRC, that did not change the outcome of the errors.

In userspace, the raspi-gpio get command yields this:

raspi-gpio get 1-3,19-21
GPIO 1: level=1 fsel=7 alt=3 func=SPI3_MISO pull=UP
GPIO 2: level=1 fsel=7 alt=3 func=SPI3_MOSI pull=UP
GPIO 3: level=0 fsel=7 alt=3 func=SPI3_SCLK pull=UP
GPIO 19: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=0 fsel=0 func=INPUT pull=DOWN

After setting the config.txt gpio pins as gpio=1-3=pd, the CM4 reports that the MISO line (GPIO1-BCM) is still a pullup:

raspi-gpio get 1-3,19-21
GPIO 1: level=1 fsel=7 alt=3 func=SPI3_MISO pull=UP
GPIO 2: level=1 fsel=7 alt=3 func=SPI3_MOSI pull=DOWN
GPIO 3: level=0 fsel=7 alt=3 func=SPI3_SCLK pull=DOWN
GPIO 19: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=0 fsel=0 func=INPUT pull=DOWN

After a reboot of said above change, the dmesg log still reports that the communication to the TPM failed.

pi@raspberrypi:~ $ dmesg | grep tpm
[    6.266079] tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
[    6.266164]  tpm_tis_status+0xcc/0xf0 [tpm_tis_core]
[    6.266177]  wait_for_tpm_stat+0x60/0x248 [tpm_tis_core]
[    6.266184]  tpm_tis_send_data+0xe8/0x2a0 [tpm_tis_core]
[    6.266190]  tpm_tis_send_main+0x44/0x120 [tpm_tis_core]
[    6.266196]  tpm_tis_send+0x4c/0xe0 [tpm_tis_core]
[    6.266201]  tpm_transmit+0xd4/0x380 [tpm]
[    6.266224]  tpm_transmit_cmd+0x38/0xc8 [tpm]
[    6.266238]  tpm2_probe+0x118/0x1c0 [tpm]
[    6.266252]  tpm_tis_core_init+0x24c/0x5a0 [tpm_tis_core]
[    6.266259]  tpm_tis_spi_init+0x5c/0x78 [tpm_tis_spi]
[    6.266269]  tpm_tis_spi_probe+0x80/0x9c [tpm_tis_spi]
[    6.266276]  tpm_tis_spi_driver_probe+0x3c/0x70 [tpm_tis_spi]
[    7.036713] tpm tpm0: tpm_try_transmit: send(): error -62
[    7.059614] tpm_tis_spi spi3.1: 1.2 TPM (device-id 0x1B, rev-id 255)
[    8.057159] tpm tpm0: tpm_try_transmit: send(): error -62
[    8.057201] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts
[    8.104995] tpm_tis_spi: probe of spi3.1 failed with error -62

However, when I set the GPIO pins manually from userspace, that one MISO line is now a pull-down as reported:

raspi-gpio get 1-3,19-21
GPIO 1: level=0 fsel=7 alt=3 func=SPI3_MISO pull=DOWN
GPIO 2: level=1 fsel=7 alt=3 func=SPI3_MOSI pull=DOWN
GPIO 3: level=0 fsel=7 alt=3 func=SPI3_SCLK pull=DOWN
GPIO 19: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=0 fsel=0 func=INPUT pull=DOWN

But, when I rmmod the tpm_tis_spi tpm_tis_core tpm modules (in that order), and reloading them again with the reverse order, dmesg still reports a failure:

[  421.838835] tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
[  421.839004]  tpm_tis_status+0xcc/0xf0 [tpm_tis_core]
[  421.839030]  wait_for_tpm_stat+0x60/0x248 [tpm_tis_core]
[  421.839046]  tpm_tis_send_data+0xe8/0x2a0 [tpm_tis_core]
[  421.839061]  tpm_tis_send_main+0x44/0x120 [tpm_tis_core]
[  421.839075]  tpm_tis_send+0x4c/0xe0 [tpm_tis_core]
[  421.839090]  tpm_transmit+0xd4/0x380 [tpm]
[  421.839135]  tpm_transmit_cmd+0x38/0xc8 [tpm]
[  421.839172]  tpm2_probe+0x118/0x1c0 [tpm]
[  421.839208]  tpm_tis_core_init+0x24c/0x5a0 [tpm_tis_core]
[  421.839224]  tpm_tis_spi_init+0x5c/0x78 [tpm_tis_spi]
[  421.839244]  tpm_tis_spi_probe+0x80/0x9c [tpm_tis_spi]
[  421.839262]  tpm_tis_spi_driver_probe+0x3c/0x70 [tpm_tis_spi]
[  422.609347] tpm tpm0: tpm_try_transmit: send(): error -62
[  422.632254] tpm_tis_spi spi3.1: 1.2 TPM (device-id 0x1B, rev-id 255)
[  423.598005] tpm tpm0: tpm_try_transmit: send(): error -62
[  423.598039] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts
[  423.646033] tpm_tis_spi: probe of spi3.1 failed with error -62

And to answer your question, I don't think that this makes a difference, w.r.t the config.txt change, or more direct, the pullup/pulldown configuration of the GPIO pins.

[RJvdBerg]

I can't help to think and wonder if the driver is "sort-of" incompatible with the "extra" SPI busses? Or just that the SPI modes is "incorrect"? I recently read that the other SPI busses, apart from the SPI1 bus, only have support for 2 of the 4 SPI modes? Is that a possibility?

[RJvdBerg]

@pelwell Do you know which SPI modes is supported on the SPI 3-6 bus? Usually, devices operate on SPI mode 0.

[pelwell]

SPI3-6 are the same as SPI0 0 - they should work with all 4 CPHA/CPOL modes. SPI1 and SPI2 are more limited - CPHA is always 0:

    master->mode_bits = (SPI_CPOL | SPI_CS_HIGH | SPI_NO_CS);

[pelwell]

I found your traces hard to read - too long and too small. Try focussing on small, equivalent sections in both traces that show the issue (or at least differences) - probably the first few bytes as the driver comes up will be enough.

[RJvdBerg]

I attached the traces in a zip file, attached in the first post. You can use Pulseview to view the files, I hope? (snap install sigrok-suite)

[pelwell]

I would focus on why the CS line usage varies between the two traces. Is this behaviour consistent for each controller (SPI1 vs SPI3)?

[RJvdBerg]

I would focus on why the CS line usage varies between the two traces. Is this behaviour consistent for each controller (SPI1 vs SPI3)?

I will check that, as soon as I can get my attention to that, been busy with another project. Hopefully by the end of this week, I will have some traces for you.

[capiman]

Was there any update/analysis/outcome since the last discussion? I think we have a device which has the same problem (but CM3+ and same TPM)

[emilm]

I have SPI 0.3 and I get kernel panic or failing to communicate in kernel 5.4 . could this be related ? It is the driver crashing . Also communIcation timing out . It has to be the driver because the overlay works on the OS intended for this device

[capiman]

Look if you see this message in log "invalid TPM_STS.x 0xff, dumping stack for forensics"

[emilm]

Thanks but I only have ethernet access to this device, but maybe I should mock up the same setup on a dev board and enable serial logging.

the kernel panics when I load the driver and everything becomes frozen and inaccessible. Is there a way to see this stack trace over ssh ?

Thanks!

[emilm]

I got a kernel trap because kernel 5.4 has a limitation of 3 SPI devices. Kernel 5.10 has 20, but can be patched. the bcm spi. Now I have _tpm_tisspi: probe of spi0.3 failed with error -110