tpm: SLM9670 does not work on T1023

tpm: SLM9670 does not work on T1023

[Alexander Wilhelm]

Hello devs,

I'm trying to bring up the SLM9670 TPM 2.0 device connected via SPI on a QorIQ
T1023-based board. Pin control is fully configured through the RCW, so I haven't
added any additional properties in the device tree. The SPI controller accesses
the TPM using `#CS0`.

However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
the startup sequence. A logic analyzer shows that the chip select line goes high
immediately after transmitting 4 bytes, which, according to various forum
discussions, does not comply with the TPM specification. Unfortunately, I
haven't found a definitive solution to this issue.

Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
limitation of the T1023? I've come across some suggestions that involve using a
GPIO as an alternative chip select instead of the one provided by the SPI
controller. Can anyone confirm whether this workaround is viable? I’d prefer to
avoid a PCB redesign unless it's absolutely necessary.


Best regards
Alexander Wilhelm

Re: tpm: SLM9670 does not work on T1023

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:

> However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> the startup sequence. A logic analyzer shows that the chip select line goes high
> immediately after transmitting 4 bytes, which, according to various forum
> discussions, does not comply with the TPM specification. Unfortunately, I
> haven't found a definitive solution to this issue.

That sounds like the controller is configured in word mode and is
bouncing chip select after every word it sends.  The Freescale
controllers are fond of implementing and using that, no idea about this
specific one.  I see there's some non-standard DT properties it has
which look like they're related to chip select modes but no idea what
they do.

> Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> limitation of the T1023? I've come across some suggestions that involve using a
> GPIO as an alternative chip select instead of the one provided by the SPI
> controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> avoid a PCB redesign unless it's absolutely necessary.

Can you not pinmux the signal from the SoC to a GPIO instead of the SPI
controller?  It's fairly common to do that since controllers often have
regrettably limited or unhelpful chip select features so GPIOs are often
the better choice.  The controller does what it likes with the chip
select signal but it's not actually connected to anything and we do
everything in software.

I'd recommend contacting whoever looks after the relevant controller
driver, though it looks rather abandoned TBH.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: tpm: SLM9670 does not work on T1023

[Alexander Wilhelm]

On Thu, Sep 11, 2025 at 03:26:38PM +0100, Mark Brown wrote:
> On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:
> 
> > However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> > the startup sequence. A logic analyzer shows that the chip select line goes high
> > immediately after transmitting 4 bytes, which, according to various forum
> > discussions, does not comply with the TPM specification. Unfortunately, I
> > haven't found a definitive solution to this issue.
> 
> That sounds like the controller is configured in word mode and is
> bouncing chip select after every word it sends.  The Freescale
> controllers are fond of implementing and using that, no idea about this
> specific one.  I see there's some non-standard DT properties it has
> which look like they're related to chip select modes but no idea what
> they do.

Which DT properties are you referring to? I’ve only used the default ones
provided by the QorIQ DTS files in the kernel.

> > Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> > limitation of the T1023? I've come across some suggestions that involve using a
> > GPIO as an alternative chip select instead of the one provided by the SPI
> > controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> > avoid a PCB redesign unless it's absolutely necessary.
> 
> Can you not pinmux the signal from the SoC to a GPIO instead of the SPI
> controller?  It's fairly common to do that since controllers often have
> regrettably limited or unhelpful chip select features so GPIOs are often
> the better choice.  The controller does what it likes with the chip
> select signal but it's not actually connected to anything and we do
> everything in software.

The problem here is that RCW allows either both enabled SPI + CS or disabled SPI
and CS-pins set to GPIO. Furthermore it is unfortunatelly connected, so I cannot
simple cut the path on PCB and need a more complicated re-design of it.

The issue here is that the RCW configuration either enables both SPI and CS
together, or disables SPI and sets the CS pins to GPIO. Unfortunately, the PCB
traces are laid out in a way that prevents me from simply cutting the
connection. A more complex redesign would be required.

> I'd recommend contacting whoever looks after the relevant controller
> driver, though it looks rather abandoned TBH.

Hopefully, someone with experience in this kind of setup will respond via the
mailing list.


Best regards
Alexander Wilhelm

Re: tpm: SLM9670 does not work on T1023

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

On Thu, Sep 11, 2025 at 04:51:24PM +0200, Alexander Wilhelm wrote:
> On Thu, Sep 11, 2025 at 03:26:38PM +0100, Mark Brown wrote:

> > That sounds like the controller is configured in word mode and is
> > bouncing chip select after every word it sends.  The Freescale
> > controllers are fond of implementing and using that, no idea about this
> > specific one.  I see there's some non-standard DT properties it has
> > which look like they're related to chip select modes but no idea what
> > they do.

> Which DT properties are you referring to? I’ve only used the default ones
> provided by the QorIQ DTS files in the kernel.

The various "fsl," ones the driver reads.  Though now I grep for docs
they seem timing related and irrelevant :/ .  You could also look at the
datasheet and see if you can fix the configuration in the driver for
this case, possibly there might be some performance overhead if it's
possible.

> > Can you not pinmux the signal from the SoC to a GPIO instead of the SPI
> > controller?  It's fairly common to do that since controllers often have
> > regrettably limited or unhelpful chip select features so GPIOs are often
> > the better choice.  The controller does what it likes with the chip
> > select signal but it's not actually connected to anything and we do
> > everything in software.

> The problem here is that RCW allows either both enabled SPI + CS or disabled SPI
> and CS-pins set to GPIO. Furthermore it is unfortunatelly connected, so I cannot
> simple cut the path on PCB and need a more complicated re-design of it.

Oh, well - that's unfortunate pinmuxing.  Glad to see innovation!

> > I'd recommend contacting whoever looks after the relevant controller
> > driver, though it looks rather abandoned TBH.

> Hopefully, someone with experience in this kind of setup will respond via the
> mailing list.

I'd try to explicitly CC people in TBH.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: tpm: SLM9670 does not work on T1023

[Jarkko Sakkinen]

On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:
> Hello devs,
> 
> I'm trying to bring up the SLM9670 TPM 2.0 device connected via SPI on a QorIQ
> T1023-based board. Pin control is fully configured through the RCW, so I haven't
> added any additional properties in the device tree. The SPI controller accesses
> the TPM using `#CS0`.
> 
> However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> the startup sequence. A logic analyzer shows that the chip select line goes high
> immediately after transmitting 4 bytes, which, according to various forum
> discussions, does not comply with the TPM specification. Unfortunately, I
> haven't found a definitive solution to this issue.

So, at least the vendor ID is bogus meaning that TPM driver is doing
right thing.

> 
> Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> limitation of the T1023? I've come across some suggestions that involve using a
> GPIO as an alternative chip select instead of the one provided by the SPI
> controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> avoid a PCB redesign unless it's absolutely necessary.

My first guess would be that the firmware inside TPM actually does throw
a broken vendor ID but it is exactly a guess :-)

I'll follow this, and please cc me also to future threads but right now
I'm clueless.

> 
> 
> Best regards
> Alexander Wilhelm


BR, Jarkko

Re: tpm: SLM9670 does not work on T1023

[Jarkko Sakkinen]

On Sun, Sep 14, 2025 at 08:06:15PM +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:
> > Hello devs,
> > 
> > I'm trying to bring up the SLM9670 TPM 2.0 device connected via SPI on a QorIQ
> > T1023-based board. Pin control is fully configured through the RCW, so I haven't
> > added any additional properties in the device tree. The SPI controller accesses
> > the TPM using `#CS0`.
> > 
> > However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> > the startup sequence. A logic analyzer shows that the chip select line goes high
> > immediately after transmitting 4 bytes, which, according to various forum
> > discussions, does not comply with the TPM specification. Unfortunately, I
> > haven't found a definitive solution to this issue.
> 
> So, at least the vendor ID is bogus meaning that TPM driver is doing
> right thing.
> 
> > 
> > Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> > limitation of the T1023? I've come across some suggestions that involve using a
> > GPIO as an alternative chip select instead of the one provided by the SPI
> > controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> > avoid a PCB redesign unless it's absolutely necessary.
> 
> My first guess would be that the firmware inside TPM actually does throw
> a broken vendor ID but it is exactly a guess :-)

Ugh, no. Probably it is device tree given false data. I recall we have
some ways to override device tree, so find the data sheet for the TPM
and rewrite the ids I suppose.

BR, Jarkko

Re: tpm: SLM9670 does not work on T1023

[Alexander Wilhelm]

On Sun, Sep 14, 2025 at 08:06:11PM +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:
> > Hello devs,
> > 
> > I'm trying to bring up the SLM9670 TPM 2.0 device connected via SPI on a QorIQ
> > T1023-based board. Pin control is fully configured through the RCW, so I haven't
> > added any additional properties in the device tree. The SPI controller accesses
> > the TPM using `#CS0`.
> > 
> > However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> > the startup sequence. A logic analyzer shows that the chip select line goes high
> > immediately after transmitting 4 bytes, which, according to various forum
> > discussions, does not comply with the TPM specification. Unfortunately, I
> > haven't found a definitive solution to this issue.
> 
> So, at least the vendor ID is bogus meaning that TPM driver is doing
> right thing.

I think so. When the first transmission occurs, the TPM sets the very last bit
to 1. This seems to be some kind of acknowledgment flag. So when I output a
32-bit value, it appears as 0x01000000. After that, the chip select (#CS) line
goes high. In the next read operation, nothing is written, but the TPM again
returns 0x01000000. This doesn’t look like an incorrect Vendor ID, but rather
another acknowledgment flag.

I’ve looked into the TPM driver code, and it uses a `cs_change` flag to indicate
that chip select should remain active after the last transmission. Some SPI
driver implementations, like `spi-fsl-dspi`, use this flag to configure
additional registers. However, `spi-fsl-espi` I'm using does not use this flag
at all, not in a single line of code. I believe this might be the root of the
issue. By the way, the same TPM works flawlessly on an x86 platform, which uses
a different SPI controller.

I was considering using an alternative GPIO for chip select. But if the code
doesn’t make use of `cs_change` anyway, that probably wouldn’t help, right?

> > Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> > limitation of the T1023? I've come across some suggestions that involve using a
> > GPIO as an alternative chip select instead of the one provided by the SPI
> > controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> > avoid a PCB redesign unless it's absolutely necessary.
> 
> My first guess would be that the firmware inside TPM actually does throw
> a broken vendor ID but it is exactly a guess :-)
> 
> I'll follow this, and please cc me also to future threads but right now
> I'm clueless.

Sure, you've been on CC since the very first message.


Best regards
Alexander Wilhelm