Intel Community Case
Issue description
Short background
As drawn in schematics, Intel Arria10 soc P/N 10AS032H2F34I2LG SPI1 master controller pins are connected to Infineon TPM P/N SLB9672AU20FW1613XTM.
The SOC SPI module 1 master controller at base address @FFDA5000 communicates with the TPM in SPI communication mode 0.
In addition, to ensure the correct initialization of the TPM,
HPS shared GPIOs GPIO1_io7 (Q3_8) and GPIO1_io8 (Q3_9) are connected from SOC to TPM as reset_n and interrupt_n signals respectively.
The problem
Attached boot pwr up log.txt describes this issue as seen at the HPS UART.
The SPIM1 controller in base address FFDA5000 is probed and mapped in SDRAM ( for example seen by cat /proc/iomem), but TPM is not probed neither in u-boot stage while writing CLI command "tpm2 init" nor during kernel loading, so /dev/tpm device driver isn't opened.
It assumed that the problem occurs due to CS signals toggles from LOW to HIGH every data byte instead of staying LOW for the whole 4 bytes header message sent on MOSI (we wait for TPM to responds "ready" by update tpmEstablishment bit 0 in the TPM_ACCESS_0 register ).
This toggle might stuck/reset the TPM state machine.
We encountered the same issue at all cards (not a singular issue).
Furthermore, released working custom design consist of Xilinx MPSOC project, connected to the same TPM P/N with same connectivity.
sources
u-boot version: socfpga_v2024.07 from altera github opensource
Kernel version: socfpga-6.6.51-lts
File system ubuntu 22.04.5 LTS from ubuntu center.
What checked?
Board Design HW
HW connectivity validation : schematics attached ( U33 to U42 connections)
Pins from SOC to TPM are connected correctly according to intel document, where a formal table for the relevant SOC (F34 tab) describes Q3_1 to Q3_4 pins functionality ( F20, G20, E18, E17
PCB and its assembly (signals connectivity between SOC and TPM, resistors value, voltages level to TPM and SOC bank) checked by flux according to schematics and based on TPM datasheet.
HPS Pins are mapped and connected correctly.
Pins direction and voltage bank level are correct.
SLB9672FW16 TPM PIN CONNECTION# | ACTUAL FUNCTIONALITY | SELECTION | SOC SHARED I/O | SOC HW PIN |
19 | CLK | SCLK | Q3_1 | E17 |
21 | MOSI | MOSI | Q3_2 | E18 |
24 | MISO | MISO | Q3_3 | G20 |
20 | CS0_n | SS0_N | Q3_4 | F20 |
17 | Reset_n | GPIO1:io6 | Q3_7 | F19 |
18 | INT_n | GPIO1:io7 | Q3_8 | E19 |
FW: QUARTUS 24.03 PRIME PRO tool
At HPS QSYS there is a full compliance to the above described pins connectivity table and the expected functionality (Q3_1-Q3_4 , Q3_8 and Q3_9):
Pin Assignment file output produced by Quartus 24.3 prime pro, correct as expected:
U-BOOT 2024.07
HANDOFF between Quartus to U-BOOT device tree
relevant pins are configured and mapped correctly according to Intel® Arria® 10 HPS Register Address Map and Definitions
document.
Each shared i/o selection value of SPIM1 controller is: 3
as required, for example :
in handoff file and its include header:
<0x00000060 PINMUX_SHARED_IO_Q3_1_SEL>,
<0x00000064 PINMUX_SHARED_IO_Q3_2_SEL>,
<0x00000068 PINMUX_SHARED_IO_Q3_3_SEL>,
<0x0000006c PINMUX_SHARED_IO_Q3_4_SEL>,
my_handoff_qspi_h.txt:
#define PINMUX_SHARED_IO_Q3_1_SEL 3
#define PINMUX_SHARED_IO_Q3_2_SEL 3
#define PINMUX_SHARED_IO_Q3_3_SEL 3
#define PINMUX_SHARED_IO_Q3_4_SEL 3
This indicates that these pins are configured for SPIM1 (SPI Master 1), which aligns with your note that the TPM is connected via spim1 @ 0xffda5000.
In addition, the PINMUX_SPIM1_USEFPGA_SEL is set to 0, which means HPS is using SPIM1, not FPGA:
#define PINMUX_SPIM1_USEFPGA_SEL 0
The relevant 4 consecutive address registers that corresponded to the SPI functionality and selected by pin mux were correctly read from physical memory :
Each shared i/o selection value of SPIM1 controller is: 3
as required for correct pin functionality.
u-boot .config
SPI & DRIVER enabled:
CONFIG_DESIGNWARE_SPI=y ( with ALTERA_SPI=y get the same bottom line and waveforms).
CONFIG_SPL_DM_SPI=y
CONFIG_SPL_SPI=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_SPI_MEM=y
CONFIG_CMD_SPI=y
CONFIG_DEFAULT_SPI_BUS=1
CONFIG_DEFAULT_SPI_MODE=0x0 ( correlated to TPM SPI mode :0 only)
TPM support is enabled:
CONFIG_TPM=y
CONFIG_TPM_V2=y
CONFIG_TPM2_TIS_SPI=y
CONFIG_CMD_TPM=y
CONFIG_CMD_TPM_V2=y
socfpga_arria10_socdk_dtsi
&spi1 {
status = "okay";
num-cs = <1>;
#address-cells=<1>;
#size-cells=<0>;
u-boot,dm-pre-reloc;
tpm@0 {
compatible = "tcg,tpm_tis-spi";
reg = <0>; //cs 0
spi-max-frequency = <1000000>; //for init
reset-gpios = <&portb 6 GPIO_ACTIVE_LOW>;
};
};
DTC -I DTS -O
spi@ffda5000 {
compatible = "snps,dw-apb-ssi-3.23a\0snps,dw-apb-ssi";
#address-cells = <0x01>;
#size-cells = <0x00>;
reg = <0xffda5000 0x100>;
interrupts = <0x00 0x66 0x04>;
num-cs = <0x01>;
tx-dma-channel = <0x1f 0x10>;
rx-dma-channel = <0x1f 0x11>;
clocks = <0x1e>;
resets = <0x04 0x32>;
status = "okay";
u-boot,dm-pre-reloc;
tpm@0 {
compatible = "tcg,tpm_tis-spi";
reg = <0x00>;
spi-max-frequency = <0xf4240>;
reset-gpios = <0x20 0x06 0x01>;
};
};
Debug signals with driver high log level and scope
During boot when stop during u-boot countdown I see the boot messages(highest log level for SPL and u-boot):
It seems the SPI master controller binds the TPM with CS0 as expected.
Dm tree command in CLI also supports it:
Dm drivers command in CLI also supports it:
Driver uid uclass Devices
----------------------------------------------------------
dw_spi 114 spi spi@ffda5000
tpm_tis_spi 124 tpm tpm@0
I added sone debug prints to understand the line where stuck.
The gpio reset occurred during the u-boot while using tpm2_tis_spi.c driver
With" tpm2 init" CLI command:
The reset signal toggles to '0' and back to '1' and complies minimal pulse
width and timing specifications.
In log I get print lines that describe the proceeding sequence in the u-boot driver:
I get probe error in any sspi or tpm command , the same sequence occurs:
Reset signal toggles correctly (probing the relevant gpio-reset).
According driver correlated to tis spi specifications 1.3 version, we send correct data as hard coded described in the driver and complies to the specifications:
0x80= '1000 0000' means read 1 byte from address 0x0:
0xD4 is an offset described in the specification:
0x00 and 0x00 assemble the TPM ACESS locality 0 register to sample from TPM ready bit:
In scope or logic analyzer I see the same pictures, the key:
Green-CS0
Blue-MOSI
Yellow- SCLK (500KHz as required for initialize).
PINK- MISO(last picture)
0x80 means read 1 byte from address 0x0.
0xd4 offset required
0x00 as sent twice(I attached only this picture. 0x00 twice in a row is the same picture in scope)
Because TPM ready doesn’t rise to '1',
I proceed to wait state and send 0XFF in MOSI blue signal till timeout arrives because MISO stays LOW and ready bit sampled is '0' always as also described in the log below:
Zoom out , all 4 CS toggle cycles for the 4 bytes are seen:
It seems the problem is that the CS signals toggles to HIGH every byte instead of staying LOW for the whole 32 bits message of the SPI header till TPM responds it is ready and update tpmEstablishment bit 0 in the ACCESS register :
According to the specifications, page 102 the signals drawn as CS should stay LOW and support this assumption:
The driver toggles CS every SPI MOSI 8 bits/clock cycles and the TPM state machine is stuck.
How can we solve it and update the u-boot and linux drivers so the CS staying LOW for the whole transaction?
Link Copied
