SLB 9670VQ2.0 timeout error

[ataulmanan]

Hi, 

I am trying to interface SLB 9670VQ2.0 via SPI BUS and after configuring kernel to enable the required module, The device is going into time out mode.  I also found a kernel patch which corresponds the problem of timeout but the patch is not currently integrated into the main line kernel. 

https://lore.kernel.org/lkml/1229fbc4-0abd-376e-a9d7-ccdd6d56c2ae@gmx.de/t/

My question is, 

If I spare a GPIO pin as a reset pin and assigned it to SLB 9670VQ2.0 then it will be enough for the SLB 9670VQ2.0 to come out of timeout phase or do i also need an implementation at the Linux kernel driver level to toggle the reset pin?

Regards

Ata

[Sneha_P]

Hi @ataulmanan,

Please provide the following information to understand the issue better:

Information about the design:
TPM FW version:
Linux kernel version:
host processor:
Infineon AppNote you referred to bring up the TPM driver (link):
any test log/dmesg:

[ataulmanan]

Hi Snehapra, 

Thank you for your reply. 

TPM FW version: Infineon did not provide any firmware when we bought the TPM SLB 9670VQ2.0 . So we think its a plug and play device. The correct device is Xenon - SPI TPM. 

Linux kernel version: 5.15.35

host processor: IMX6ULL

Infineon AppNote you referred to bring up the TPM driver (link): 
https://www.infineon.com/dgdl/Infineon-App-Note-SLx9670-TPM2.0_Embedded_RPi_DI_SLx-ApplicationNotes-...

dmesg:

[ 2447.329589] bus: 'spi': add driver tpm_tis_spi
[ 2447.329669] spi spi2.0: probing driver tpm_tis_spi asynchronously
[ 2447.329769] bus: 'spi': __driver_probe_device: matched device spi2.0 with driver tpm_tis_spi
[ 2447.329806] bus: 'spi': really_probe: probing driver tpm_tis_spi with device spi2.0
[ 2447.329851] tpm_tis_spi spi2.0: no pinctrl handle
[ 2447.329918] DEBUG: Entering Function(): tpm_tis_spi_driver_probe
[ 2447.379632] tpm_tis_spi: probe of spi2.0 failed with error -110
[ 2447.386824] spi spi2.0: driver tpm_tis_spi async attach completed: 110

[Sharath_V]

Hi @ataulmanan ,

The provided patch poses a security issue. The reset line of the TPM resets some internal state that should only happen during boot of the host platform. Thus, access to the TPM's reset behavior from the driver contradicts the security architecture.
It is hard to tell, why the TPM is not coming out of reset without having access to the wiring schematics and/or osci / logic traces. In general the RST line needs to be not asserted for the TPM to start operations. The RST line also has a weak pull-up that might be handy here.
Beyond this, the recommendation for non-PC platforms would be to use an IRIDIUM evaluation board following the linked guidance and not a PC evaluation board.

[ataulmanan]

Hi @Sharath_V , 

Thank you very much for your reply. 

I have checked the wiring schematics and they are correctly wired. The TPM line remains active low which can be the reason for TPM to remain in reset mode. I have tried to keep the GPIO in a pull up state but still no success.

Can you please explain what can be the difference between PC and Non-PC TPM platforms?. I thought that the SPI protocol is a standard or not?. 

[Sharath_V]

Hi @ataulmanan ,

We have raised an internal ticket to try and reproduce your issue on our side. Please wait for our detailed response on the same.

[ataulmanan]

Hi @Sharath_V , 

Thank you.

Regards

Ata

[ataulmanan]

Hello, 

Do you have any more updated information for me?. I was waiting for some information from your side. 

Best Regards

[Sharath_V]

Hi @ataulmanan , 

Please check the response below from Kissinger and provide the details asked.

[Kissinger]

Hello @ataulmanan, 

its sound like more like a hardware issue instead of a software problem. 

1. Please could you provide a schematic with all pins you have connected from the Xenon board to the host board. 
2. Please provide additionally the PinState (High/Low) of every pin after power up.
3. Please may it possible to clarify which "TPM line" you mean? RST/CS/MISO/MOSI/CLK?

Thanks for that, best Regards, 

@Kissinger Paul

[ataulmanan]

Hello, 

Sorry for being too late as the project went in to background. I am again working on the TPM Problem and collected information as you have discussed.

I am connecting the pins on Xenon Board as following

1: PIN 7 ---> SPI CLOCK

2: PIN 13---> TPM_CS

3: PIN 17---> PIRQ

4: PIN 5 ----> GND

5: PIN 6 ----> VDD(3.3V)

6: PIN 10 ---> MISO

7: PIN 12 ---> MOSI

I am also attaching a Logic analyzer trace for better understanding. 

SPI Operating frequency is 20MHz.

D0 ----> CLOCK

D1 ----> CS

D2 ----> Interrupt

D3 ----> MOSI

D4 ----> MISO

Please let me know if you need more information from my side.

Regards

Ata

[Kissinger]

Hello @ataulmanan,

the pinning for the Xenon Board looks very well.

The driver tries to read out the VID DID, so this looks also good. 

Some questions:
1. Is there more communication on the interface?
2. Please, could you provide the SPI Master configuration of the IMX6?

Best Regards,

Paul

[Sneha_P]

Please let us know if your query was resolved. We will lock the thread in 3 days. In case your problem is not resolved, please create a new thread and we will be happy to help.