# \[R38.4\] T4000/5000 SPI TPM issue **URL:** \ **Category:** Jetson Thor\ **Tags:** spi, tpm\ **Created:** [May 19, 2026, 8:35am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586 "2026-05-19T08:35:10Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 19, 2026, 8:35am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/1 "2026-05-19T08:35:10Z")
Hi all We encountered the same problem as described at the following URL when trying to use an SPI TPM on the Jetson Thor platform; unfortunately, we were unable to use the patch provided in that link. This is because using `0001-spi-fix-and-debug-for-SPI3-CS-issue-in-topic-363582.patch` causes problems with SPI devices other than the TPM. We are using a self-developed carrier board paired with Jetson Thor. > [@\[T5000\] SPI3 connect to TPM fail](https://forums.developer.nvidia.com/t/t5000-spi3-connect-to-tpm-fail/363582/48): > > Hi jack\_lan, Could you clarify if your TPM and SPI-to-UART module have the different requirement for CS behavior? You can check from scope or LA before and after applying the patch. Please create another topic to discuss in details. Therefore, we modified tpm\_tis\_spi\_main.c to make tpm\_tis\_spi\_transfer use tpm\_tis\_spi\_transfer\_half(data, addr, len, in, out) by default, as shown in the image below. ![slipt](https://global.discourse-cdn.com/nvidia/original/4X/c/b/8/cb83fdc36ec24b0a8f706760fa03d9e0e9dc968d.png) Simply using it works fine; the TPM mounts correctly. However, during cycle testing, we found that the TPM has a 1% chance of malfunctioning, as shown in the following message. The complete debug UART message is attached. Will the SPI functionality be fixed in JP7.2? ``` [20.369750] WARNING: CPU: 10 PID: 190 at drivers/spi/spi-tegra114.c:1116 tegra_spi_transfer_one_message+0x474/0x50c [spi_tegra114] [20.369765] Modules linked in: nvhost_pva(O) nvhost_capture(O) tegra_se_kds(O) tegra210_adma tpm_tis_spi crypto_engine tegra_camera(O) tpm_tis_core snd_soc_tegra210_ahub host1x_fence(O) v4l2_dv_timings f81561(+) nvvrs_pseq_rtc(O) nvadsp(O) host1x_nvhost(O) crct10dif_ce nvmap(O) nvidia_cspmu sm3_ce snd_hda_codec_hdmi sm3 sha3_ce nvsciipc(O) coresight_trbe sha512_ce nvethernet(O+) sha512_arm64 coresight ivc_cdev(O) tegra_drm(O) tegra_wmark(O) snd_soc_tegra_audio_graph_card drm_display_helper snd_soc_audio_graph_card drm_dp_aux_bus arm_spe_pmu snd_soc_simple_card_utils tegra264_mc_hwpm(O) cec tegra234_oc_event(O) nvpmodel_clk_cap(O) nv_gpu_static_pg(O) ramoops reed_solomon cp210x snd_hda_tegra thermal_trip_event(O) usbserial snd_hda_codec ina3221 ina238 tegra_bpmp_bwmgr(O) tegra_cactmon_mc_all(O) tegra23x_psc(O) ixgbe(+) tegra_aconnect pps_gpio mdio tegra_aocluster(O) nvpps(O) snd_hda_core lm90 nvidia_vrs_pseq(O) snd_soc_max98090 mc_t26x(O) at24 spi_tegra114 tegra_dce(O) pwm_tegra_tachometer(O) nvhwpm(O) arm_cspmu_module [20.369801] host1x(O) tegra_camera_platform(O) mc_utils(O) capture_ivc(O) v4l2_fwnode v4l2_async videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videodev videobuf2_common mc camchar(O) rtcpu_debug(O) tegra_camera_rtcpu(O) ivc_bus(O) fuse hsp_mailbox_client(O) nvme_fabrics nfnetlink ip_tables x_tables ipv6 pwm_fan pwm_tegra tegra_bpmp_thermal tegra_xudc uas ucsi_ccg typec_ucsi typec nvme nvme_core phy_tegra194_p2u pcie_tegra194 ufs_tegra(O) pcie_tegra264(O) [20.369833] CPU: 10 PID: 190 Comm: kworker/u30:1 Tainted: G O 6.8.12-tegra #1 [20.369837] Hardware name: NVIDIA NVIDIA Jetson Thor Developer Kit/Jetson, BIOS r38.4-b4fc9d99 03/16/2026 [20.369840] Workqueue: events_unbound async_run_entry_fn [20.369866] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) [20.369870] pc : tegra_spi_transfer_one_message+0x474/0x50c [spi_tegra114] [20.369872] lr : tegra_spi_transfer_one_message+0x1c4/0x50c [spi_tegra114] [20.369874] sp : ffff800084a8b5b0 [20.369876] x29: ffff800084a8b5b0 x28: ffff800084a8b778 x27: ffff000080bc5d80 [20.369878] x26: ffff00008dca2000 x25: ffff000080bc5d80 x24: 0000000001e84800 [20.369880] x23: 0000000000000000 x22: ffff000080bc5d80 x21: ffff000080bc5e68 [20.369883] x20: ffff800084a8b718 x19: 0000000000000001 x18: 0000000000000000 [20.369884] x17: 0000000000000000 x16: 0000000000000000 x15: 00000092f123a132 [20.369887] x14: 0000000000000001 x13: ffff000088791380 x12: 0000000000000000 [20.369889] x11: ffff000088791380 x10: c3af6d1aaa2efd09 x9 : 03f2024f0ca872d6 [20.369892] x8 : ffff000088792518 x7 : ffff000f57d1b7c0 x6 : 00000000000003e8 [20.369894] x5 : 00000000410fd830 x4 : 0000000000000000 x3 : 0000000000000000 [20.369896] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [20.369899] Call trace: [20.369902] tegra_spi_transfer_one_message+0x474/0x50c [spi_tegra114] [20.369904] __spi_pump_transfer_message+0x214/0x678 [20.369927] __spi_sync+0x2ac/0x44c [20.369929] spi_sync+0x30/0x54 [20.369931] tpm_tis_spi_transfer_half+0xd0/0x288 [tpm_tis_spi] [20.369940] tpm_tis_spi_read_bytes+0x14/0x20 [tpm_tis_spi] [20.369942] tpm_tis_status+0x58/0xf8 [tpm_tis_core] [20.369950] tpm_transmit+0x154/0x36c [20.369960] tpm_transmit_cmd+0x30/0xc0 [20.369961] tpm2_get_tpm_pt+0x114/0x1ac [20.369965] tpm2_get_cc_attrs_tbl+0x44/0x274 [20.369967] tpm2_auto_startup+0x88/0x224 [20.369970] tpm_auto_startup+0x34/0x4c [20.369972] tpm_chip_bootstrap+0x48/0xb0 [20.369974] tpm_tis_core_init+0x418/0x1020 [tpm_tis_core] [20.369976] tpm_tis_spi_probe+0xa4/0xd4 [tpm_tis_spi] [20.369978] tpm_tis_spi_driver_probe+0x34/0x64 [tpm_tis_spi] [20.369980] spi_probe+0x94/0x134 [20.370001] really_probe+0x148/0x2b0 [20.370026] __driver_probe_device+0x78/0x12c [20.370029] driver_probe_device+0x3c/0x15c [20.370032] __driver_attach_async_helper+0x4c/0xb4 [20.370034] async_run_entry_fn+0x34/0xe0 [20.370037] process_one_work+0x170/0x3fc [20.370046] worker_thread+0x320/0x438 [20.370048] kthread+0x110/0x114 [20.370052] ret_from_fork+0x10/0x20 [20.370058] ---[end trace 0000000000000000]--- [20.370070] spi-tegra114 810c440000.spi: spi transfer timeout [20.380929] nvethernet a808b10000.ethernet: Virtualization is not enabled [20.387437] spi_master spi2: failed to transfer one message from queue [20.395599] nvethernet a808b10000.ethernet: failed to read skip mac reset flag, default 0 [20.395601] nvethernet a808b10000.ethernet: failed to read MDIO address [20.410964] spi_master spi2: noqueue transfer failed [20.412087] tpm tpm0: Operation Timed out [20.415835] nvethernet a808b10000.ethernet: Failed to read nvida,pause_frames, so setting to default support as disable [20.421801] tpm tpm0: TPM in field failure mode, requires firmware upgrade ``` Thanks [output.log](https://forums.developer.nvidia.com/uploads/short-url/jANZRE6Hka0YC8FNm3S66br9psh.log) (270.1 KB) ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 19, 2026, 11:26am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/3 "2026-05-19T11:26:34Z")
Hi jack\_lan, Are you using the devkit or custom board for Thor? Could you help to clarify if the SPI TPM issue happens after applying the patch? ```auto [19.038873] tpm_tis_spi spi2.3: 2.0 TPM (device-id 0x1D, rev-id 54) ``` From the log you shared, it seems TPM SPI device is still recognized during boot up. ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 20, 2026, 1:08am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/4 "2026-05-20T01:08:50Z")
Hi Kevin 1. These are the results of an experiment on a custom carrier board. 2. These are not the test results after adding the patch, but rather the results after I modified `tpm_tis_spi_main.c` to force the `return` statement to use `tpm_tis_spi_transfer_half`, which allowed TPM to mount successfully. If the default conditional statement is used, `tpm_tis_spi_transfer_full` will be called, ultimately causing TPM to fail to mount. Thanks ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 20, 2026, 7:56am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/5 "2026-05-20T07:56:39Z")
> [@jack\_lan](#): > > These are not the test results after adding the patch, but rather the results after I modified `tpm_tis_spi_main.c` to force the `return` statement to use `tpm_tis_spi_transfer_half`, which allowed TPM to mount successfully. So, is your issue caused from the patch I shared in [[T5000] SPI3 connect to TPM fail - #41 by KevinFFF](https://forums.developer.nvidia.com/t/t5000-spi3-connect-to-tpm-fail/363582/41)? > [@jack\_lan](#): > > causes problems with SPI devices other than the TPM. What’s the exact error you hit for other SPI device(SPI-to-UART!?)? Could you provide the full log after applying the patch? > [@jack\_lan](#): > > Therefore, we modified tpm\_tis\_spi\_main.c to make tpm\_tis\_spi\_transfer use tpm\_tis\_spi\_transfer\_half(data, addr, len, in, out) by default, as shown in the image below. Please provide the log w/o any custom change. (except for the patch I shared.) ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 21, 2026, 7:56am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/6 "2026-05-21T07:56:57Z")
Hi KevinFFF This is the DMESG message from F81561 before the “[T5000] SPI3 connect to TPM fail - #41 by KevinFFF” patch was added. ![f81561probe](https://global.discourse-cdn.com/nvidia/original/4X/e/b/5/eb5079268a48a40f17a3cc5c62fa1ac5ddd1bfce.png) This is the DMESG message from F81561 after the “[T5000] SPI3 connect to TPM fail - #41 by KevinFFF” patch was added. ![f81561fail](https://global.discourse-cdn.com/nvidia/original/4X/0/1/c/01c21757862185017f98ac5e30df1f63f498c0f8.png) After adding the patch, F81561 fails to mount. Regarding the TPM and cycle tests, we will run them over the weekend to confirm whether this patch has fixed the TPM issue. Thanks ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 21, 2026, 8:07am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/7 "2026-05-21T08:07:09Z")
Okay, it seems the previous patch causing your F81561 SPI-To-UART module failed to be probed. Could you apply the patch from [SPI issue - #15 by KevinFFF](https://forums.developer.nvidia.com/t/spi-issue/370246/15) and provide the full dmesg? ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 21, 2026, 8:18am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/8 "2026-05-21T08:18:56Z")
Hi KevinFFF Apply [SPI issue - #15 by KevinFFF](https://forums.developer.nvidia.com/t/spi-issue/370246/15) dmesg [dmesg\_f81561.log](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/b/2/e/b2ebb00e9f8b73b84911e3f2460d600414f874c8.log) (225.0 KB) Thanks ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 21, 2026, 8:52am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/9 "2026-05-21T08:52:35Z")
> [@jack\_lan](#): > > This is the DMESG message from F81561 before the “[T5000] SPI3 connect to TPM fail - #41 by KevinFFF” patch was added. > > ![f81561probe](https://global.discourse-cdn.com/nvidia/original/4X/e/b/5/eb5079268a48a40f17a3cc5c62fa1ac5ddd1bfce.png) Could you provide the full dmesg as file with default R38.4 (w/o the patch applied)? Please also enable the debug logging:`echo 1 > /sys/module/spi_tegra114/parameters/spi_tegra114_debug_cs`and then reload the f81561 module (or reboot with the parameter set via kernel cmdline`spi_tegra114.spi_tegra114_debug_cs=1`) so we can see what CS mode is being used for the f81561 transactions The `vid: 0 err` means the SPI read returned all zeros, which could be a CS issue or could be something else entirely (wrong chip-select, device not populated, etc.). We need the baseline log to confirm this is actually a regression vs a pre-existing issue on this board. ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 22, 2026, 3:35am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/10 "2026-05-22T03:35:16Z")
Hi KevinFFF This is the complete dmesg without adding any patches. [dmesg\_normal\_f81561.log](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/b/7/6/b76d20d5b209b07ec1ab21a8485cee64554b5597.log) (138.9 KB) This is the dmesg record of re-probe f81561 after starting /sys/module/spi\_tegra114/parameters/spi\_tegra114\_debug\_cs. [enable\_debug\_cs\_probe\_f81561\_dmesg.log](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/a/3/6/a363de8b62e441bcc425e4fad18b48f9b27a8976.log) (6.1 KB) Thanks ---
**Author:** ![va11](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/va11/32/15508_2.png) [@va11](https://forums.developer.nvidia.com/u/va11)\ **Post date:** [May 22, 2026, 10:38am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/11 "2026-05-22T10:38:09Z")
Hi jack\_lan, Thanks for sharing [enable\_debug\_cs\_probe\_f81561\_dmesg.log](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/a/3/6/a363de8b62e441bcc425e4fad18b48f9b27a8976.log). I’ve reviewed it carefully against the patch Kevin shared in post #15, and there’s a mismatch — the binary running on your board is **not** built from that patch. Could you help us confirm the build/install steps? **What the log shows** Your dmesg contains these debug prints: spi-tegra114 810c590000.spi: [DEBUG-SPI-CS] msg: scan xfer[0] len=1 cs\_change=0 is\_last=0 spi-tegra114 810c590000.spi: [DEBUG-SPI-CS] msg: scan xfer[1] len=1 cs\_change=0 is\_last=1 spi-tegra114 810c590000.spi: [DEBUG-SPI-CS] msg: multi xfer → use\_hw\_cs=1 spi-tegra114 810c590000.spi: [DEBUG-SPI-CS] setup\_xfer: using HW CS, cmd1=0x40400007 The patch Kevin shared in post #15 does **not** contain: - any `scan xfer[N]` debug string, and - any code path that produces `use_hw_cs=1` for a multi-transfer message. In that patch, every multi-transfer message must print `msg: multi xfer -> use_hw_cs=0 (SW CS required)` and use SW CS. The strings in your log come from an older intermediate snapshot we discarded earlier, and they are exactly what causes the f81561 `vid: 0` failure (HW CS enabled for a 2-transfer probe → CS glitches between the two 1-byte transactions). So the patch source on your tree may be correct, but the **`spi-tegra114.ko` actually being loaded** on the board is stale. **Why this can happen** In the kernel config we use, `CONFIG_SPI_TEGRA114=m` — the driver is a loadable module, not built-in. So rebuilding only the kernel `Image` is not enough; the new `spi-tegra114.ko` must also be installed onto the target rootfs and any initramfs. Once we confirm the correct module is actually loaded, this CS-glitch regression should be gone for f81561 (and CH9431) while the TPM fix is retained. Thanks for your patience and the detailed logs. ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 25, 2026, 6:54am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/12 "2026-05-25T06:54:43Z")
Hi va11 `scan xfer[N]` indicates the error message displayed by `dmesg` after enabling `echo 1 > /sys/module/spi_tegra114/parameters/spi_tegra114_debug_cs` and the `spi_cs_dbg` function in the patch. The message is shown in the image below. ![Screenshot from 2026-05-25 14-53-43](https://global.discourse-cdn.com/nvidia/original/4X/5/c/f/5cfac8e81ee87adebf107be100b51c2a34944a94.png) Thanks ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 25, 2026, 8:51am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/13 "2026-05-25T08:51:53Z")
Hi Jack, Please apply the following patch instead and share the full dmesg for further check. [0001-spi-debug-SPI-issue-for-Thor-with-r38.4-20260525.patch](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/4/2/9/4297bf948a3e7011f51497846e7e13bd17d1d46d.patch) (7.9 KB) ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 25, 2026, 10:09am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/14 "2026-05-25T10:09:47Z")
Hi KevinFFF This patch for TPM works and maintains the F81561-spi device. The complete dmesg is attached. I will perform a cycle test to see if the TPM issue persists. [dmesg\_new\_patch.log](https://forums.developer.nvidia.com/secure-uploads/nvidia/original/4X/9/f/f/9ff477eca39e6e73b2f76d7d27c099d016006d65.log) (155.5 KB) Thanks ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 26, 2026, 2:39am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/15 "2026-05-26T02:39:45Z")
good to hear that, please let us know if you have further SPI issue on Thor. ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [May 29, 2026, 5:11am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/16 "2026-05-29T05:11:08Z")
Hi KevinFFF We will be conducting long-term cycle testing on this version this weekend to confirm that the issue has been fixed. We will provide updates on the results later. Thank you very much! Thanks! ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [May 29, 2026, 12:57pm UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/17 "2026-05-29T12:57:59Z")
Thanks for your update, please close this ticket if you get good result after the test overweekend. ---
**Author:** ![jack\_lan](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@jack\_lan](https://forums.developer.nvidia.com/u/jack_lan)\ **Post date:** [June 1, 2026, 2:07am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/18 "2026-06-01T02:07:23Z")
Hi Kevin The cycle test was conducted approximately 1307 times over the weekend, and no TPM issues occurred. Thanks ---
**Author:** ![system](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/system/32/68080_2.png) [@system](https://forums.developer.nvidia.com/u/system)\ **Post date:** [June 15, 2026, 2:07am UTC](https://forums.developer.nvidia.com/t/r38-4-t4000-5000-spi-tpm-issue/370586/19 "2026-06-15T02:07:27Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.