Infineon’s Trusted Platform Module (TPM) SLB9670 Connection with SPI1 (tpm_tis_spi: probe of spi1.0 failed with error -110)

Need some guidance how do i diagnose the issue…where can i find the relevant material for configuration…
spi@3230000 {
compatible = “nvidia,tegra210-spi”;
reg = <0x00 0x3230000 0x00 0x1000>;
interrupts = <0x00 0x26 0x04>;
#address-cells = <0x01>;
#size-cells = <0x00>;
clocks = <0x03 0x89>;
clock-names = “spi”;
iommus = <0x04 0x04>;
assigned-clocks = <0x03 0x89>;
assigned-clock-parents = <0x03 0x66>;
resets = <0x03 0x5d>;
reset-names = “spi”;
dmas = <0xdf 0x11 0xdf 0x11>;
dma-names = “rx\0tx”;
dma-coherent;
status = “okay”;

		prod-settings {
			#prod-cells = <0x04>;

			prod {
				prod = <0x00 0x194 0x80000000 0x00>;
			};
		};

		spi@0 {
			compatible = "tegra-spidev";
			reg = <0x00>;
			spi-max-frequency = <0x2faf080>;
			status= "disabled";
			controller-data {
				nvidia,enable-hw-based-cs;
				nvidia,rx-clk-tap-delay = <0x10>;
				nvidia,tx-clk-tap-delay = <0x00>;
			};
		};
		 tpm@1 {
    			compatible = "infineon,slb9672", "infineon,slb9670", "tcg,tpm_tis-spi";
    			reg = <0x00>; 
			#address-cells = <0x1>;
			#size-cells = <0x1>;
    			spi-max-frequency = <0x1e84800>; 
    			status = "okay";

			controller-data {
				nvidia,enable-hw-based-cs;
				nvidia,cs-setup-clk-count = <0x1e>;
				nvidia,cs-hold-clk-count = <0x1e>;
				nvidia,rx-clk-tap-delay = <0x1f>;
				nvidia,tx-clk-tap-delay = <0x0>;
				nvidia,cs-inactive-cycles = <0x0>;
				nvidia,rx-clk-tap-delay = <0x10>;
			};
		};

Hi zawarkhan97,

Are you using the devkit or custom board for Orin Nano?
What’s your Jetpack version in use?

Have you verified SPI loopback test before porting TPM module?

It should be provided by your vendor of TPM module.

I am using Custom board, with JP 6.1 version. Let me test SPI loopback test. Vendor provides it only for raspbery Pi

Okay, you can refer to the similar steps in Jetson/L4T/peripheral/ - eLinux.org for SPI loopback test.
Please note that Jetson-IO may not work with your custom carrier board so that you need to configure the pinmux for SPI related pins first.

You can share the porting guide and related resources with us to check.

yes Jetson IO doesnt work with our Custom Board. My Pinmux is default. SPI1-CS0 (PY.03) is set to default. the porting guide is given as https://www.infineon.com/dgdl/Infineon-Optiga_TPM_RPi_Quickstarter_User_Guide-UserManual-v01_00-EN.pdf?fileId=8ac78c8c8e7ead30018ee5a4d85b04bd&da=t

fragment@2 {
target = <0xffffffff>;
overlay {
#address-cells = <0x01>;
#size-cells = <0x00>;
slb9672: slb9670@1 {
compatible = “infineon,slb9672”, “infineon,slb9670”, “tcg,tpm_tis-spi”;
reg = <0x01>;
#address-cells = <0x01>;
#size-cells = <0x00>;
spi-max-frequency = <0x1e84800>;
status = “okay”;
phandle = <0x01>;
};
};
};

One another silly question please. Am i modifying the correct node for SPI1 pins that is spi@3230000

Yes, spi@3230000 is for SPI1 which includes following SPI pins:
PY.00: SPI1_SCK
PY.01: SPI1_MISO
PY.02: SPI1_MOSI
PY.03: SPI1_CS0
PY.04: SPI1_CS1
You can configure them as following in pinmux spreadsheet.

To port TPM on Jetson, you can also refer to the following topics:
How to enable TPM - #5 by DaneLLL
How to enable TPM2.0 module in Xavier?
SPI TPM slb9670 isn't worked on Orin NX JetPack5

  1. Thanks for the solution sir. I applied the above topic solution. i moved on to this error
    [ 7.963013] spi-tegra114 3230000.spi: can not register to master err -517
    [ 8.041094] spi-tegra114 3230000.spi: can not register to master err -517
    [ 9.835335] spi-tegra114 3230000.spi: can not register to master err -517

spi@3210000 {
status = “okay”;
cs-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Z, 6) GPIO_ACTIVE_LOW>;
sbl9670@0 {
compatible = “infineon,slb9670”;
reset-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(A, 2) GPIO_ACTIVE_LOW>;
reg = <0x0>;
spi-max-frequency = <32000000>;
controller-data {
nvidia,variable-length-transfer;
nvidia,rx-clk-tap-delay = <0x31>;
};
};
};

2

just one difference to mine I used values of TEGRA194_MAIN(Y,3)
reset-gpios = <0xe5 474 0x00>;
because of reflashing is not feasible for me. Secondly, changing pinmux dtsi (tegra234-mb1-bct-pinmux-p3767-dp-a03) doesnt seem to effect the result. I still see some gpios set as output as input in gpioinfo. My custom board is for ORIN NX. with JP6.1

  1. Based on Formula given in pinctrl_tegra194.h header file I calculated and set the values to 194 and 195. And it gave again no probe error.
    I did next step I removed the DTB entry and added back the default spi@0 : tegra-spidev entry and tested the 0x80 0xD4 0x00 0x00 is an instruction to read 1 byte out of register TPM_ACCESS_0. which gave me 00000000 against the expected 00000001. I dont know whether this was correct .

Your error is from SPI1 (3230000.spi).

But you are configuring SPI0(3210000.spi) for TPM.

Could you confirm again which SPI interface are you using?

This is not valid to me since it is for T194 series. However, you are using Orin Nano(which is T234 series).
As a result, please specify TEGRA234_MAIN_GPIO instead

Please refer to the configurations for T234 series.

Your error is from SPI1 (3230000.spi).

sorry my mistake I was configuring spi3230000.

I am using SPI1 interface with SPICS0 as CS and SPI1CS1 as TPM reset.

As a result, please specify TEGRA234_MAIN_GPIO instead

Yes I corrected it my CS is TEGRA234_MAIN_GPIO(Y,3) and RESET is TEGRA234_MAIN_GPIO(Y,4)… As per TEGRA_GPIO_CTRL.H header file I calculated the values to be 147 and 148… while based on Jetson Adaptation and bring up guide I calculated it to be 473 and 474 respectively

Please refer to tegra234-gpio.h to calculate the value.
e.g. TEGRA234_MAIN_GPIO(Y,3) should be 18*8+3 = 147 = 0x93

dear @KevinFFF thanks for your response. I did set it to like that but still it did not detect it. I believe its hardware issue. May I know what it means if put default settings tegra-spidev. the spi does not give errors that way.

How did you determine that it is hardware issue?
Have you tried to get a scope to capture the signal to check?

Please share the full device tree you used and dmesg currently.

How did you determine that it is hardware issue? Well Its my assumption because when I set spi to vendor sepcific CTI it gives probe error.
Have you tried to get a scope to capture the signal to check?
No sir. Currently I have limitation but I will check soon.
Please share the full device tree you used and dmesg currently.
here it the dtb
Customised_DTB.txt (323.1 KB)
dmesg has only one thing tpm-spi probe error.

Your configuration in device tree looks good to me.
I would suggest using scope to check SPI signal first.
Or you can add more logs in tpm driver(tpm_tis_spi_main.c) to debug further the root cause.

1 Like