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
