Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

OPTIGA™ TPM Forum Discussions

ataulmanan
Level 1
5 sign-ins First reply posted First question asked
Level 1

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

0 Likes
7 Replies
snehapra
Moderator
Moderator First like received First question asked 25 sign-ins
Moderator

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:

0 Likes
ataulmanan
Level 1
5 sign-ins First reply posted First question asked
Level 1

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

0 Likes
Sharath
Moderator
Moderator 50 replies posted First question asked 10 likes given
Moderator

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.

0 Likes
ataulmanan
Level 1
5 sign-ins First reply posted First question asked
Level 1

Hi @Sharath , 

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?. 

0 Likes
Sharath
Moderator
Moderator 50 replies posted First question asked 10 likes given
Moderator

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.

0 Likes
ataulmanan
Level 1
5 sign-ins First reply posted First question asked
Level 1

Hi @Sharath , 

Thank you.

Regards

Ata

0 Likes
Kissinger
Employee
5 sign-ins First reply posted First question asked
Employee

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

0 Likes