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.
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.
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?
These are the results of an experiment on a custom carrier board.
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.
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_csand then reload the f81561 module (or reboot with the parameter set via kernel cmdlinespi_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.
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 (6.1 KB)
Thanks for sharing enable_debug_cs_probe_f81561_dmesg.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?
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.
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.
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.
