[U-Boot] Issue enabling TPM 2.0 on RPI

[Miquel Raynal]

Hi Elena,

Elena Unix <elenaunix01 at gmail.com> wrote on Mon, 17 Jun 2019 15:46:29
+0200:

> Hi Miquèl,
> 
> Thank you for your answer.
> 
> > Miquel Raynal <miquel.raynal at bootlin.com> wrote on Mon, 17 Jun 2019 10:44:52 +0200:
> > 
> > Hi Elena,
> > 
> > Elena Unix <elenaunix01 at gmail.com> wrote on Fri, 14 Jun 2019 09:43:46
> > +0200:
> >   
> >> Hello,
> >> 
> >> I am trying to enable the TPM 2.0 SLB9670 in U-Boot for a Raspberry Pi 3 B+. More precisely, the TPM is on an add-on board, the IRIDIUM SLB9670.
> >> The communication between the RPI and the TPM is ensured by SPI so I enabled the software spi driver (spi-gpio) in U-Boot because the bcm28x spi driver is not available in U-Boot.
> >> 
> >> CONFIG_SPI=y
> >> CONFIG_DM_SPI=y
> >> CONFIG_SOFT_SPI=y  
> > Are you sure the SPI bus is correctly driven? Can you connect anything
> > else and ensure it works? You may also probe all the GPIO lines (using
> > an oscilloscope) and check each of them is clocked correctly.  
> 
> I simply checked by doing a loopback test, i.e connecting MISO and MOSI by a cable and it worked.
> I will test with an oscilloscope when I have one and keep you up to date.
> 
> >   
> >> 
> >> Then, I enabled the TPM support in U-Boot.
> >> 
> >> CONFIG_CMD_TPM_V2=y
> >> CONFIG_CMD_TPM=y  
> > 
> > If you use TPM V2, CMD_TPM is not needed. But that's not your problem.
> >   
> >> CONFIG_TPM_V2=y
> >> CONFIG_TPM2_TIS_SPI=y
> >> CONFIG_TPM=y  
> > 
> > Looks fine.
> >   
> >> 
> >> Finally, I updated my Device Tree.
> >> /dts-v1/
> >> / {
> >> ...
> >>   aliases {
> >>       spi0 = &soft_spi;
> >>   };
> >> 
> >>   soft_spi: soft-spi {
> >>       compatible = "spi-gpio";
> >>       pinctrl-names = "default";
> >>       pinctrl-0 = <&spi0_gpio7>;
> >>       status = "okay";
> >>       gpio-sck = <&gpio 11 0>;
> >>       gpio-mosi = <&gpio 10 0>;
> >>       gpio-miso = <&gpio 9 0>;
> >>       cs-gpios = <&gpio 7 1>;
> >>       #address-cells = <1>;
> >>       #size-cells = <0>;
> >> 
> >>       slb9670: slb9670 at 0 {
> >>           compatible = "tis,tpm2-spi";
> >>           reg = <1>;
> >>           #address-cells = <1>;
> >>           #size-cells = <0>;
> >>           spi-max-frequency = <32000000>;  
> > 
> > You might want to slow down a bit this frequency, try it with 1MHz,
> > just for testing (and see something meaningful with the scope).  
> 
> I tried to lower the frequency to 1MHZ but without success.
> 
> >>           status = "okay";
> >>       };
> >>   };
> >> 
> >>   spio0_gpio7: spio0_gpio7 {
> >>       brcm,pins = <7 8 9 10 11>;
> >>       brcm,function = <4>;  
> > 
> > If you bit-bang the SPI bus, I suppose you must use the GPIO function
> > on each pin, is <4> the GPIO function or the SPI function?  
> 
> No the <4> function is the SPI function, thank you it was a mistake. I changed it to GPIO function but I have the same errors when executing tpm2 commands in U-Boot.
> 
> >   
> >>   };
> >> ...
> >> };
> >> 
> >> But, when I try to execute the following command : 
> >> U-Boot> tpm2 init
> >> 
> >> I have the following response :
> >> 
> >> tpm_tis_spi_probe : missing reset GPIO  
> > 
> > This is indeed harmless, just a warning.
> >   
> >> tpm_tis_spi_request_locality : Timeout getting locality : -2  
> > 
> > This usually means you cannot talk to the chip.
> >   
> >> tpm_tis_spi_probe : could not request locality 0
> >> Could not find TPM (ret=-2)
> >> 
> >> The Iridium board contains a reset circuit on board, which pulls the reset line of the TPM to GND after VCC becomes available, so the reset GPIO is not needed I think.
> >> 
> >> I don’t see what is wrong with my setup, a little help would be very appreciated.
> >> 
> >> Thank you in advance, 
> >> Elena
> >> ___________  
> > 
> > 
> > Good luck,
> > Miquèl  
> 
> Moreover, I commented out the tpm_tis_spi_request_locality() function in the TPM driver just to perform a test by executing the U-Boot> tpm2 init
> I then had the following response :
> tpm_tis_spi_probe() SPI TPMv2.0 found (vid:15d1, did:001b, rid:10)

Right, so it seems that the communication works.

Back to debugging then, you may dump the bytes read/written in your SPI
driver's read/write callbacks. Once you'll have a working solution,
it would be very appreciated if you could contribute it back. Good luck!


Thanks,
Miquèl