Troubleshooting slb9670 + Xavier bringup

[john.mcmaster]

Hi all,
In short: I’m trying to add an slb9670 TPM to our existing Xavier NX project but I’m running into a few snags. In particular: when I add the pinmux configuration to the device tree, tpm_tis_spi no longer even attempts to probe the device. However if I remove pinmux configuration I get an error (tpm_tis_spi: probe of spi0.0 failed with error -110). My understanding is that tpm_tis_spi and tegra pinmux are fairly isolated kernel modules. Can someone provide guidance why this might happen and/or how to resolve/troubleshoot? I’ve provided reference FDT / patch that shows exactly what I’m trying to do. Thank you!

EDIT: I changed my DTC to be “slb9670@0” which eliminates the warning on the duplicate @1, but doesn’t seem to change anything

Details:
My expectation of what is loosely needed to enable basic probe support:

• Kernel: enable TPM module
• Device tree: add device as SPI slave + configure pinmux. Maybe configure a few GPIOs I’m not currently using
• No changes required to earlier boot (EDK2, BCT, etc)
• TPM should always be powered up

One snag I ran into: I couldn’t get the official pinmux generator spreadsheet to work so I generated my .dts by hand. Maybe something to double check?

I looked a bit through the kernel sources but nothing immediately stuck out to me what could cause this to be silently dropped. However I did see some notes about “pinctrl-0” and/or “cs-gpios” that maybe I should be paying more attention to? My impression though is that “reg = <0x00>;” should take care of the chip select. Similarly from what I can tell IRQ and reset is optional

A few next steps I’m considering:

• Looking at debug flags I might enable
• Probe with scope to see if I can get spidev (say using spidev-test) to at least show the spi device is where I expect it

L4T: v35.2.1
Linux 5.10.104+ (IIRC we are not using the standard kernel)

RPI reference DTS: https://raw.githubusercontent.com/raspberrypi/linux/rpi-5.15.y/arch/arm/boot/dts/overlays/tpm-slb9670-overlay.dts

My TPM specific changes: patch.diff.txt (6.8 KB)

My full FDT: tegra194-p3668-0001-p3509-0000.dts.txt (403 KB)

[KevinFFF]

Hi john.mcmaster,

@john.mcmaster

One snag I ran into: I couldn’t get the official pinmux generator spreadsheet to work so I generated my .dts by hand. Maybe something to double check?

We would suggest using pinmux spreadsheet to generate the dtsi in case you configure something wrong/invalid.

@john.mcmaster

L4T: v35.2.1

It is a quite old release. Could you move to the latest R35.6.0 to verify?

Please also share the block diagram of your connection with TPM module and the dmesg for further check

		spi@1 {
			compatible = "tegra-spidev";
			reg = <0x01>;
			spi-max-frequency = <0x2faf080>;

			controller-data {
				nvidia,enable-hw-based-cs;
				nvidia,rx-clk-tap-delay = <0x10>;
				nvidia,tx-clk-tap-delay = <0x00>;
			};
		};

		slb9670@1 {
			compatible = "infineon,slb9670";
			#address-cells = <0x01>;
			#size-cells = <0x00>;
			reg = <0x00>;
			spi-max-frequency = <0xf4240>;
			status = "okay";
			phandle = <0x2d3>;

			controller-data {
				nvidia,enable-hw-based-cs;
				nvidia,rx-clk-tap-delay = <0x10>;
				nvidia,tx-clk-tap-delay = <0x00>;
			};
		};

I just had a quick check in your device tree.
It seems you have duplicate node for CS1. Please remove spi@1 node in your device tree.

[john.mcmaster]

Hi Kevin,
Thank you very much for the assistance.

Regarding the “@1”, this was the “EDIT” I referenced in the post where I tested that fix shortly after posting. I’ve attached the updated files to be crystal clear. Unfortunately it doesn’t seem to change anything: no attempt is even made to probe the tpm

patch.diff.txt (7.2 KB)

tegra194-p3668-0001-p3509-0000.dts.txt (403 KB)

dmesg.txt (55.4 KB)

Re: L4T release: no, this is not something I can really upgrade in the production system although I could potentially test in another configuration if there was a really good reason. I’m just supporting the main team at this time and the decision to upgrade the OS is beyond my control.

Re: spreadsheet unfortunately last time I tried running it with Office 365 on a Windows desktop the code crashed when I asked it to save the output. So I’m not what I can do to fix that. I don’t have easy access to native Microsoft office (it is not used in our organization) which also makes this difficult to retry

I’ve attached some relevant schematic portions in case this is helpful. However it sounds like its not even trying to probe the hardware? So I think the issue is before the schematic / actual pin mapping is needed.

[KevinFFF]

From your dmesg, i can not find any messages relating to tpm module (slb9760).

How did you build that driver? In kernel image(=y) or as loadable kernel module(=m)?
Have you tried to load it manually?

Have you verified SPI loopback test before porting your tpm module?

[john.mcmaster]

Hi there,
I’m pretty confident the tpm driver is loaded because 1) I’m only modifying the device tree when I’m testing the update. For example without the added mux configuration it tries to probe the tpm (tpm_tis_spi: probe of spi0.0 failed with error -110) 2) I can “modprobe” it and see that it knows its present (ie gives me an error if I try modprobe tpm_tis_xxx instead of tpm_tis_spi)

Sample from .config showing its compiled in and not a module (ie has =y not =m):

CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_SPI=y
CONFIG_SPI_SPIDEV=m

I might try some probing, but due to the lack of the probe message entirely I’m thinking its not even trying to probe. That said I might run some spidev experiments with the mux configuration to see if that helps. But even if that works it won’t answer the question of why tpm_tis_spi doesn’t even try to load once I add the mux configuration.

[KevinFFF]

@john.mcmaster

I’m pretty confident the tpm driver is loaded

Please run sudo lsmod|grep tpm to confirm if the modules are loaded.

@john.mcmaster

But even if that works it won’t answer the question of why tpm_tis_spi doesn’t even try to load once I add the mux configuration.

Verifying SPI loopback test is to help you confirming the pinmux and other related configurations are correct for SPI usage.

The current issue seems relating to your custom driver for TPM not working.
Or it just not prints any debug message.

[john.mcmaster]

Hi there,
Thanks for your questions. To clarify we do not have a custom TPM driver, just the stock driver. I think I forget to include this patch but our relevant KConfig is:

CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS_SPI=y
CONFIG_TCG_TIS=y

Taking a step back, it sounds like the best path forward is to see if I can get a reduced test case on a dev board using the latest BSP. Let me try that and maybe it will help answer a lot of questions. However this will take a larger time investment that I won’t be able to do until after Thanksgiving. So I will get back in a few weeks with an update.