[T5000] SPI3 connect to TPM fail

pomelo_hsieh · March 16, 2026, 11:59am

Hi Nvidia,

I used the Jetpack 7.1 R38.4 SDK on our custom-designed carrier board.

The SPI3 connected to the NPCT760AAEYX TPM chip and the driver probed the failure.

[10.366133] tpm_tis_spi: Probe of SPI3.0 failed with error -110.

pinmux :

        spi3_sck_ph6 {

            nvidia,pins = "spi3_sck_ph6";

            nvidia,function = "spi3_sck";

            nvidia,pull = <TEGRA_PIN_PULL_NONE>;

            nvidia,tristate = <TEGRA_PIN_DISABLE>;

            nvidia,enable-input = <TEGRA_PIN_ENABLE>;

            nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;

            nvidia,e-io-od = <TEGRA_PIN_DISABLE>;

            nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;

        };

        spi3_miso_ph7 {

            nvidia,pins = "spi3_miso_ph7";

            nvidia,function = "spi3_din";

            nvidia,pull = <TEGRA_PIN_PULL_NONE>;

            nvidia,tristate = <TEGRA_PIN_DISABLE>;

            nvidia,enable-input = <TEGRA_PIN_ENABLE>;

            nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;

            nvidia,e-io-od = <TEGRA_PIN_DISABLE>;

            nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;

        };

        spi3_mosi_pj0 {

            nvidia,pins = "spi3_mosi_pj0";

            nvidia,function = "spi3_dout";

            nvidia,pull = <TEGRA_PIN_PULL_NONE>;

            nvidia,tristate = <TEGRA_PIN_DISABLE>;

            nvidia,enable-input = <TEGRA_PIN_ENABLE>;

            nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;

            nvidia,e-io-od = <TEGRA_PIN_DISABLE>;

            nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;

        };

        spi3_cs0_pj1 {

            nvidia,pins = "spi3_cs0_pj1";

            nvidia,function = "spi3_cs0";

            nvidia,pull = <TEGRA_PIN_PULL_NONE>;

            nvidia,tristate = <TEGRA_PIN_DISABLE>;

            nvidia,enable-input = <TEGRA_PIN_ENABLE>;

            nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;

            nvidia,e-io-od = <TEGRA_PIN_DISABLE>;

            nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;

        };

DTS :

    spi@810c440000 {

        status = "okay";

        num-cs = <1>;

        tpm@0 {

            compatible = "tcg,tpm_tis-spi";

            reg = <0>;

            spi-max-frequency = <5000000>;

            status = "okay";

        };

    };

The figure below shows the oscilloscope waveform from the measurement.

I don’t know why the SPI3 clock isn’t generating a signal.

Do you have any suggestions on how I should go about debugging this?

Thanks.

KevinFFF · March 17, 2026, 12:16am

Hi pomelo_hsieh,

Do you use the pinmux spreadsheet to configure the pinmux for SPI correctly?

Have you verified SPI loopback test working as expected with SCK output?

Please provide the full device tree and dmesg for further check.

pomelo_hsieh · March 18, 2026, 1:24am

Hi Kevin,

Do you use the pinmux spreadsheet to configure the pinmux for SPI correctly?

Yes.

Have you verified SPI loopback test working as expected with SCK output?

No.

kernel_tegra264-p4071-0000+p3834-0008-nv-pe3000n-t5000.txt (331.7 KB)

dmesg.txt (114.9 KB)

According to this thread: Jetson Thor SPI2对应哪个设备树节点？
and the URL mentioned therein: https://elinux.org/Jetson/L4T/peripheral/#Mapping
Moving the original TPM device to the SPI@810c440000 node.

If I follow the instructions in the document “Jetson_Thor_Series_Modules_DesignGuide_DG12084001_v1.4.pdf,”

I may not be able to map to the correct SPI controller.

Thanks.

pomelo_hsieh · March 18, 2026, 11:26am

Hi Kevin,

I tried shorting the MOSI and MISO pins on SPI3 to test them.

The signal waveform at power-on is shown below; at this point, the system has not yet booted up.

After booting into Ubuntu, I ran the spidev_test command.

But the receiver did not receive any data.

Thanks.

KevinFFF · March 19, 2026, 7:42am

We would suggest verifying with SPI loopback test before connecting the SPI device like TPM.

Could you share the full dmesg and device tree in this case for further check?

pomelo_hsieh · March 19, 2026, 1:00pm

Hi Kevin,

Disconnect SPI3_CLK, SPI3_MISO, SPI3_MOSI, and SPI3_CS from the TPM and SOM, and short SPI3_MOSI to SPI3_MISO, then run the SPI loopback test.

From the oscilloscope waveforms, I can only see that the CS pin is active when a message is transmitted, but there are no changes in the CLK, MOSI, or MOSI waveforms.

update dmesg and dts.

dmesg (1).txt (108.9 KB)

kernel_tegra264-p4071-0000+p3834-0008-nv-pe3000n-t5000.txt (331.5 KB)

Thanks.

KevinFFF · March 20, 2026, 10:24am

Do you mean that there’s no SPI3_CLK output when you perform loopback test with the data received correctly?

I don’t find any unexpected error for SPI in the dmesg you shared.

pomelo_hsieh · March 20, 2026, 11:24am

Hi Kevin,

Yes, when testing the SPI loopback, can see changes in the MISO, MOSI, and clock waveforms on the oscilloscope?

Thanks.

KevinFFF · March 23, 2026, 3:16am

Do you mean SPI3_CLK output the expected waveform when you run SPI loopback test?
If so, SPI function of Thor has been working correctly.

[   12.413441] tpm tpm0: TPM_DBG: Request locality 0 timeout. Final Access Reg: 0xff
[   12.413624] tpm_tis_spi spi2.0: tpm_tis_request_locality rc -1

The issue may be caused from your TPM driver.
Please also check above errors in TPM driver with your vendor.

pomelo_hsieh · March 23, 2026, 4:18am

Hi Kevin,

Let’s first clarify some hardware signal issues.

When performing an SPI loopback test, will there be any changes in the MISO, MOSI, and CLK waveforms on the oscilloscope?

I ran an SPI loopback test and saw the transmitted and received data in the terminal, but I didn’t see any changes in the MISO, MOSI, and CLK waveforms on the oscilloscope.

Thanks.

KevinFFF · March 24, 2026, 3:14am

It is not the expected result to me.

As you can receive the expected data, there should be the waveform on MOSI line.
Have you confirmed that you measure the correct pin?

pomelo_hsieh · March 26, 2026, 12:36pm

Hi Kevin,

Updated video demonstrating SPI3 loopback testing with an oscilloscope.
Green represents MISO/MOSI, red represents PLTRST, blue represents CS0, and yellow represents CLK.
As shown, after running the spidev_test command in the terminal, the screen displays data being sent and received, but MISO/MOSI no changes are visible on the oscilloscope.

Update the circuit:

图像 (3)

For SPI pinmux configuration, is it sufficient to simply replace the files with the pinmux DTS and GPIO DTS files generated by Jetson_Thor_Series_Modules_Pinmux_Template_v1.5.xlsm? No further modifications are needed in the /source/hardware/nvidia/t264/nv-public/nv-platform/ directory, correct?

Thanks.

pomelo_hsieh · March 27, 2026, 9:50am

Hi Kevin,

I checked the clock-related debug filesystem and found that the spi3 enable_count value is 0. Additionally, when I checked the on attribute of the SPI3 clock in /sys/kernel/debug/bpmp/debug/clk/clk_tree, it was set to 0.

cat /sys/kernel/debug/clk/clk_summary | grep spi3
enable prepare protect duty hardware connection
clock count count count rate accuracy phase cycle enable consumer id

spi3 0 0 0 101250000 0 0 50000 Y 810c440000.spi spi

cat /sys/kernel/debug/bpmp/debug/clk/clk_tree

spll_out3                                          1  810000000    3    1
    spll_out5                                      1  810000000    1    1
    pllp_out_pdiv                                  1  405000000    3    1
        pllp_out0                                  1  202500000   18    1
            host1x                                 1  202500000    2    1 vdd_core@630000
            spi1                                   0  101250000    0    0
            spi3                                   0  101250000    0    0
            spi4                                   0  101250000    0    0
            top_i2c                                1   50625000    2    1
            tsec                                   1  202500000    1    1
            tsec_pka                               1  202500000    1    1

Thanks.

jack_lan · March 30, 2026, 7:40am

Hi pomelo

We also encountered problems using TPM on the JP7.1 Thor platform, even while using SPI3.

Our SPI, CLK, MISO, MOSI, and CS all function correctly. Our PinMux DTSI is generated through an XLSX table. Here’s a breakdown of our PinMux DTSI settings:

spi3_sck_ph6 {

nvidia,pins = "spi3_sck_ph6";

nvidia,function = "spi3_sck";

nvidia,pull = <TEGRA_PIN_PULL_NONE>;

nvidia,tristate = <TEGRA_PIN_DISABLE>;

nvidia,enable-input = <TEGRA_PIN_DISABLE>;

nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;

nvidia,e-io-od = <TEGRA_PIN_DISABLE>;

nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;

};`

spi3_miso_ph7 {
nvidia,pins = "spi3_miso_ph7";
nvidia,function = "spi3_din";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
};

spi3_mosi_pj0 {
nvidia,pins = "spi3_mosi_pj0";
nvidia,function = "spi3_dout";
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
};

spi3_cs0_pj1 {
nvidia,pins = "spi3_cs0_pj1";
nvidia,function = "spi3_cs0";
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
};

spi3_cs3_pj2 {
nvidia,pins = "spi3_cs3_pj2";
nvidia,function = "spi3_cs3";
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
};

Unfortunately, even with this, TPM doesn’t work. The same Device-tree setting works fine in JP6.2, but fails in JP7.1. I’m unsure if NVIDIA has any suggestions or directions?

Waveform:

pomelo_hsieh · March 30, 2026, 8:19am

Hi Jack,

I’m still waiting for a response from NVIDIA.
The TPM chip’s PLTRST is linked to the system’s PLTRST.
After power-on, I noticed that when the PLTRST is pulled high, the CS pin is immediately pulled low. I’m not sure if this behaviour causes the TPM chip to think it needs to communicate.

I’m not sure at which stage, whether MB1, MB2 or UEFI, the CS pin is pulled low after power-on.
Could this be why the TPM chip is no longer able to communicate by the time the Linux kernel’s SPI host controller driver takes control?

Thanks.

jack_lan · March 30, 2026, 8:27am

Hi pomelo

The timeframe you mentioned likely refers to the period from boot to UEFI. In my experience, when mounting the TPM driver, as long as the TPM reset pin isn’t pulled low after entering the Linux kernel and starting to load kernel modules following UEFI, it should be fine.

As for the CS pin, I only care whether the CS pin is actually pulled low when the kernel module starts loading and the clock signal is sent.

We’re using the SLB9672, but I don’t think the difference will be significant.

Best Regard
Jack Lan

KevinFFF · March 31, 2026, 6:35am

I suspect that you measured the wrong pins from scope.
How could it transmit/receive the expected data w/o the signal from scope..?
Could you receive the data if you disconnect MISO/MOSI in the SPI loopback test?

Is the current issue specific to SPI3? (i.e. is there the similar issue on SPI1?)
Please also share the result of ls -l /dev/spidev* on your board and also the dmesg.

pomelo_hsieh · April 9, 2026, 6:54am

Hi Kevin,

When the oscilloscope is connected, the SPI3 loopback test fails to receive data; however, when the oscilloscope is disconnected, the SPI3 loopback test receives data normally. I suspect that the MOSI and MISO signals are being interfered with by the oscilloscope.

No, if I disconnect the MOSI and MISO will not receive any data.

Although the SPI3 loopback test is currently running normally, communication with the TPM chip (NPCT760AAEYX) is still failed after power-on. We are currently working with the chip manufacturer, Nuvoton, to debug the issue using an SPI signal analyzer.

When configuring the SPI3 pin functions using the Jetson_Thor_Series_Modules_Pinmux_Template_v1.5.xlsm, the SPI3 CS pin goes low immediately after power-on. Is this normal behavior?

Thanks.

KevinFFF · April 10, 2026, 5:12am

CS pin may be probed during driver loading so it is pulled to low, but it should recover to high after boot up.
How did you configure SPI3_CS0 in pinmux spreadsheet?

Is there any error reported from your TPM driver?

Have you tried using LA instead?

pomelo_hsieh · April 10, 2026, 7:36am

Hi Kevin,

Update the experimental data from the previous TPM connection

Update the circuit:

The spi3_miso and spi3_cs0 pins have a pull-up resistor set to 1.8V.

pinmux settings :

tegra264-mb1-bct-pinmux-p3834-xxxx-p4071-0000.txt (89.5 KB)

kernel dts settings:

tegra264-p4071-0000+p3834-0008-nv-common.txt (2.9 KB)

The state of the SPI3_CS0 pin when the system powers on the waveform :

You will observe that the SPI3_CS0 pin is pulled low immediately after power-on and remains low until the TPM driver intervenes.

Here is the debugging information I’ve included:

kernel diff:
debug_tpm_patch.txt (3.9 KB)

root@tegra-ubuntu:~# dmesg | grep TPM_DBG

[   12.173390] TPM_DBG: Reading DID_VID(0) at address 0x00000f00: 0xffffffff
[   12.182414] TPM_DBG: INT_ENABLE: 0xffffffff
[   12.191870] TPM_DBG: TPM interface capabilities (0xffffffff):
[   12.225383] tpm tpm1: TPM_DBG: Entering request_locality(0), Access Reg: 0xff
[   12.310326] tpm tpm1: TPM_DBG: Writing TPM_ACCESS_REQUEST_USE (0x02) to Locality 0
[   12.321160] tpm tpm1: TPM_DBG: Write TPM_ACCESS failed, rc = -110
[   12.336560] TPM_DBG: tpm_tis_request_locality rc -110

root@tegra-ubuntu:~# dmesg | grep spi

[   11.979122] spi-tegra114 c6c0000.spi: Adding to iommu group 28
[   11.994319] spi spi1.0: setup 8 bpw, ~cpol, ~cpha, 25000000Hz
[   12.030856] spi-tegra114 810c590000.spi: Adding to iommu group 29
[   12.042953] spi spi0.0: setup 8 bpw, ~cpol, ~cpha, 25000000Hz
[   12.045939] spi-tegra114 810c440000.spi: Adding to iommu group 30
[   12.112158] spi spi2.0: setup 8 bpw, ~cpol, ~cpha, 10000000Hz
[   12.131830] spi-tegra114 810c450000.spi: Adding to iommu group 32
[   12.197902] spi spi3.0: setup 8 bpw, ~cpol, ~cpha, 25000000Hz

update dmesg :
dmesg.txt (165.8 KB)

I only use an LA analyzer to measure the SPI3 connection between the TPM with the chip manufacturer.

Coldboot:

Rebind: Execute : echo spi2.0 > /sys/bus/spi/drivers/tpm_tis_spi/bind

Thanks.

Topic		Replies	Views
Enable SPI TPM 2.0 with tpm_tis_spi Jetson Orin NX spi	28	1399	December 2, 2024
[Xavier NX]TPM 2.0(Nuvoton_NPCT754AADYX) Bring Up Jetson Xavier NX spi	13	2037	July 27, 2022
Jetson Nano Devkit with Letstrust TPM2 / infineon slb9672 Jetson Nano spi , gpio	29	718	August 28, 2024
TPM on SPI2 in Uboot Jetson Nano security , device-tree , uboot	35	3496	November 9, 2022
SPI3 issue Jetson AGX Orin spi	9	212	October 22, 2025
Infineon SLB9670 TPM2.0 module with Jetson Nano Jetson Nano spi , security	13	4503	October 15, 2021
How to enable TPM2.0 module in Xavier? Jetson AGX Xavier spi	14	4166	October 18, 2021
Infineon TPM2.0 SLB9672 module with Jetson AGX Orin Jetson AGX Orin spi	15	2151	August 16, 2023
Did anybody get SPI interface working on TX1? Jetson TX1	37	12506	October 18, 2021
SPI TPM module support fail on jetpack 5.0.2/5.1 on jetson xavier agx Jetson AGX Xavier spi	22	3844	May 3, 2023

[T5000] SPI3 connect to TPM fail

Related topics