Infineon SLB9670 TPM2.0 module with Jetson Nano

Hi all,

I’m trying to enable Infineon SLB9670 TPM2 evaluation module (IRIDIUM9670 TPM2.0 LINUX - Infineon Technologies). I’m using L4T R32.4.3. Jetson Nano Production module + B01 carrier board.
The 40pins GPIO header on Nano is compatible with Pi3/4, so I plug the SLB9670 module into pins 1 → 26 of 40pins GPIO header.
I updated the device tree pinmux and gpio, to use SPI1 (pins 19->26) as below:

spi1_mosi_pc0 {
	nvidia,pins = "spi1_mosi_pc0";
	nvidia,function = "spi1";
	nvidia,pull = <TEGRA_PIN_PULL_NONE>;
	nvidia,tristate = <TEGRA_PIN_DISABLE>;
	nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};

spi1_miso_pc1 {
	nvidia,pins = "spi1_miso_pc1";
	nvidia,function = "spi1";
	nvidia,pull = <TEGRA_PIN_PULL_UP>;
	nvidia,tristate = <TEGRA_PIN_DISABLE>;
	nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};

spi1_sck_pc2 {
	nvidia,pins = "spi1_sck_pc2";
	nvidia,function = "spi1";
	nvidia,pull = <TEGRA_PIN_PULL_NONE>;
	nvidia,tristate = <TEGRA_PIN_DISABLE>;
	nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};

spi1_cs0_pc3 {
	nvidia,pins = "spi1_cs0_pc3";
	nvidia,function = "spi1";
	nvidia,pull = <TEGRA_PIN_PULL_NONE>;
	nvidia,tristate = <TEGRA_PIN_DISABLE>;
	nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};

spi1_cs1_pc4 {
	nvidia,pins = "spi1_cs1_pc4";
	nvidia,function = "spi1";
	nvidia,pull = <TEGRA_PIN_PULL_NONE>;
	nvidia,tristate = <TEGRA_PIN_DISABLE>;
	nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};

The slb9670 node was added into spi0 tree:
spi@7000d400 {
status = “okay”;

	slb9670: slb9670@0{
		compatible = "infineon,slb9670";
		reg = <0>;
		spi-max-frequency = <32000000>;
		status = "okay";

		controller-data {
			nvidia,enable-hw-based-cs;
			nvidia,rx-clk-tap-delay = <7>;
		};
	};
};

Then I enabled TPM in kernel:

CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS_SPI=y

But TPM is failed to probe. I added some debug printing into tpm_tis_spi.c and tpm_tis_core.c, and it prints out:

root@jetson-nano:~# dmesg | grep -i spi
[    0.452947] iommu: Adding device 7000d400.spi to group 7
[    0.453285] iommu: Adding device 7000d600.spi to group 8
[    5.096867] LLL tpm_tis_spi_probe(): 
[    5.096871] LLL tpm_tis_spi_probe(): irq -1
[    5.096890] LLL tpm_tis_spi_transfer(): addr 0 len 1
[    5.183053] LLL tpm_tis_spi_transfer(): timeout
[    5.187614] LLL tpm_tis_spi_transfer(): ok ret -110
[    5.280585] LLL tpm_tis_spi_transfer(): addr 8 len 4
[    5.297818] LLL tpm_tis_spi_transfer(): timeout
[    5.322813] LLL tpm_tis_spi_transfer(): ok ret -110
[    5.322816] LLL tpm_tis_spi_transfer(): addr 8 len 4
[    5.352542] LLL tpm_tis_spi_transfer(): timeout
[    5.352545] LLL tpm_tis_spi_transfer(): ok ret -110
[    5.352548] LLL tpm_tis_spi_transfer(): addr 0 len 1
[    5.354176] LLL tpm_tis_spi_transfer(): timeout
[    5.354178] LLL tpm_tis_spi_transfer(): ok ret -110
[    5.354181] LLL tpm_tis_spi_probe(): ret -19

So, it looks like the communication with SLB9670 modules was failed here: linux-tegra-4.9/tpm_tis_spi.c at oe4t-patches-l4t-r32.4 · OE4T/linux-tegra-4.9 · GitHub

Interrupt count of SPIs

root@jetson-jano:~# cat /proc/interrupts | grep spi
 66:        204          0          0          0       LIC  59 Level     7000d400.spi
 67:          0          0          0          0       LIC  82 Level     7000d600.spi

Does anyone have had the same problem or any idea to troubleshoot/solve this? Thank you.

hello nvl1109,

according to Topic 139831, we do not have TPM at current Jetson platforms.
you may implement it by the support from TPM vendor through SPI interface and a PIRQ interrupt pin.

please access Product Design Guide and check three of the SoC SPI interfaces.
you might access sysfs to check the GPIO values, please refer to GPIO Changes session to check the GPIO number;
please also refer to Topic 58607 for tutorials to use GPIO.
there’s pinmux spreadsheet that indicate the signaling name and also its pin muxing. you may have customization to generate a cfg file for flashing the board to adapt your platform.
thanks

Thank you @JerryChang for your reply. I’m aware that Nvidia doesn’t support TPM on current platforms. That why I have to add myself :).
For now, I’m following instructions for Raspberry Pi3/4 & Infineon TPM2 SPI module due to the 40 pins header of these two boards are compatible. The PIRQ interrupt pin is not mentioned in the instructions. Do you think it is needed?

I have made pinmux changes, device tree changes in the first post. The problem is what I received from Infineon TPM2 chip is all 0x00.

I tried to use spidev communicating with TPM2 SPI chip, send similar command as TPM2 driver did (linux-tegra-4.9/tpm_tis_spi.c at oe4t-patches-l4t-r32.4 · OE4T/linux-tegra-4.9 · GitHub) but all I got is 0x00 in response. I use spidev_test app with little modification.

root@jetson-uwcam:~# tpm2-test -s 5000000 -v                                                                                                                                                                                                                                         
fd: 3
mode: 0
set/get mode
set/get bits/word
set max speed
spi mode: 0x0
bits per word: 8
max speed: 5000000 Hz (5000 KHz)
TX | 80 D4 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | Ԁ.
RX | 00 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | ....
RETRY 0
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 1
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 2
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 3
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 4
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 5
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 6
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 7
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 8
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RETRY 9
TX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
RX | 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  | .
ERROR: NO RESPONSE IN TIME.

hello nvl1109,

did you perform a full flash to update pinmux modification?
since Nano’s pinmux configuration is included in device tree blob. you may disassembler the dtb file into text file for examination.
for example, $ dtc -I dtb -O dts -o output.txt tegra210.dtb

Hi @JerryChang,
Yes, I did full flash by flash.sh script.
Disassembler device tree attached. I realized that the TPM module use CS1 (pin 26) instead of CS0, so I have changed the device tree to CS1. But result is same as above.

test.dts (290.8 KB)

It looks like the TXB level shifter is the problem. When I measure voltage on CS1 pin, but its voltage is 1v when CS1 pin is asserted (active low), the TPM2 chip require <0.4v as low level.

Hi @JerryChang ,
Do you have any more ideas on this? Does device tree has problem regarding to SPI pins? Or maybe I should pending this task until I have our own carrier board, where no TXB level shifter involves.

hello nvl1109,

is this <0.4v requirement according to TPM specification?

Hi Jerry,

<0.4v is due to Infineon chip specs.

Regards,
Linh Nguyen

Hello, we’re trying basically the same and to overcome 0.4V issue we changed some pull resistor on infineon board. I tried suggestion above but I don’t have any spi communication flowing (hooked probes on MOSI and CLK and it shows no activity) and also in dmesg there is no message about TPM. I double checked dts + kernel config and options are enabled. Any ideas? Thanks.

marek

hello marek.belisko,

since there’s level shifters.
please check application note, 40-Pin Expansion Header GPIO Usage Considerations for reference,
it describes how to work with the signals on the 40-pin expansion header,
thanks

Hi Jerry,

could you explain what exactly do you mean about level shifters? On 40-pin expansion header and Iridium - SPI TPM is 3V3 logic. What is the suggested problem?

Hi automatykp,

Please help to open a new topic. Thanks

Hi kayccc,

I can start new topic, but why if we have the same problem? :)
We want to connect TPM evaluation board to Nano devkit and we have trouble with it.
We resolved problem with voltage levels on CS and now it’s ok, but another problem still exist.
Jerry mentioned level shifters without any details. What’s wrong with them? Those level shifters are very weak, but there are no additional pull up/down resistors on SPI bus so should work good? Any ideas?