On Wed, Nov 6, 2019 at 2:09 AM <[email protected]> wrote:

> Hi All
>
> I have to following problem. I'm trying to setup a custom cape with and
> SPI TPM based on SLB9670VQ2.0 chip.
>
> What I've done so far is:
> 1 - building and deploying a custom kernel with SPI TPM 2.0 support
> enabled.
> 2 - Writing a dtbo to configure the right pins in their right modes for
> the TPM and to instruct the u-boot to load the specific kernel objects.
>
> After many problems and a lot of research, I managed to to build the DTBO
> activate it by including
> uboot_overlay_addr5=/lib/firmware/TPM-SLB9670-00A0.dtbo in the
> /boot/uEnv.txt and making sure the DTBO is loaded and does it's thing.
>
> Now, the DTBO IS loading and causes the respective modules to be loaded:
>
> ivan@beaglebone:~$ lsmod
> Module                  Size  Used by
> 8021q                  32768  0
> garp                   16384  1 8021q
> stp                    16384  1 garp
> mrp                    20480  1 8021q
> llc                    16384  2 garp,stp
> usb_f_acm              16384  2
> u_serial               20480  3 usb_f_acm
> usb_f_ecm              20480  2
> usb_f_rndis            32768  4
> u_ether                20480  2 usb_f_ecm,usb_f_rndis
> libcomposite           61440  16 usb_f_ecm,usb_f_acm,usb_f_rndis
> iptable_nat            16384  0
> nf_nat_ipv4            16384  1 iptable_nat
> nf_nat                 36864  1 nf_nat_ipv4
> nf_conntrack          155648  2 nf_nat_ipv4,nf_nat
> nf_defrag_ipv6         20480  1 nf_conntrack
> nf_defrag_ipv4         16384  1 nf_conntrack
> iptable_mangle         16384  0
> iptable_filter         16384  0
>
>
>
> *tpm_tis_spi            16384  0tpm_tis_core           24576  1
> tpm_tis_spitpm                    57344  2 
> tpm_tis_spi,tpm_tis_core*uio_pdrv_genirq
> 16384  0
> uio                    20480  1 uio_pdrv_genirq
> ip_tables              24576  3 iptable_mangle,iptable_filter,iptable_nat
> x_tables               32768  3 iptable_mangle,ip_tables,iptable_filter
>
> While researching, I was led to believe that the modules would create the
> "all-important" device file in the /dev directory, i.e. /dev/tpm0
> But that doesn't happen?!
>

Can you also provide the dmesg log output? Since the module is loaded, I'd
be inclined to think it would create whatever interfaces it would
provide...if the probe was successful.


> I tried modifying the dts file for my dtbo in every way I could imagine.
> It doesn't work.
>
> This is the complete dts file for my TPM dtbo:
>
> /*
> * Device Tree overlay for Infineon SLx 9670
> */
>
> #include <dt-bindings/board/am335x-bbw-bbb-base.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pinctrl/am33xx.h>
> #include <dt-bindings/gpio/gpio.h>
>
> /dts-v1/;
> /plugin/;
>
> / {
>         compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>         /* Identification */
>         part-number = "TPM-SLB9670";
>         version     = "00A0";
>
>         exclusive-use = "P9.21", // Used as SPI0 MISO and is the Default +/
>                         "P9.18", // Used as SPI0 MOSI and is the Default +/
>                         "P9.22", // Used as SPI0 SCKL and is the Default +/
>                         "P9.17", // Used as SPI0 CS0 +/
>
>                         "P9.15", // GPIO1_16 aka GPIO_48 used as input to
> handle the IRQ from the TPM.
>                         "P9.13", // GPIO0_31 aka GPIO_31 used as output to
> drive the reset pin of the TPM
>
>                         "spi0",
>                         "i2c0",
>                         "i2c2";
>
>         fragment@0 // Releasing the spi0 pins from their current
> assignments. (Tried without this fragment no difference)
>         {
>                 target = <&ocp>;
>
>                 __overlay__
>                 {
> //                      P9_21_pinmux { status = "disabled"; };
> //                      P9_18_pinmux { status = "disabled"; };
> //                      P9_22_pinmux { status = "disabled"; };
> //                      P9_17_pinmux { status = "disabled"; };
>

Odd. I'd think you'd need to disable the pinmuxes if you want the default
to be SPI mode.

Check with 'sudo /opt/scripts/device/bone/show-pins.pl'.  I really need to
create a flag that removes the color printing on that utility and put it in
the standard path. Anyway, strip the color info and provide the output for
all the relevant pins.


>
>                         P9_15_pinmux { status = "disabled"; };
>                         P9_13_pinmux { status = "disabled"; };
>                 };
>         };
>
>         fragment@1 // Disabling both i2c interfaces since there are some
> pin conflicts, in the off chance they moght interfere (Tried without those
> two fragments - No difference)
>         {
>                 target = <&i2c0>;
>
>                 __overlay__
>                 {
>                         status = "disabled";
>

Isn't this the on-board i2c? Disabling that would be bad.


>                 };
>         };
>
>         fragment@2
>         {
>                 target = <&i2c2>;
>
>                 __overlay__
>                 {
>                         status = "disabled";
>                 };
>         };
>
>         fragment@3
>         {
>                 target = <&am33xx_pinmux>;
>
>                 __overlay__
>                 {
>                         pb_spi0_pins: pinmux_pb_spi0_pins // I checked if
> a got the right pins several times, tried with or without pullups no
> difference
>                         {                                 // My only doubt
> is did I get the inputs anoutputs right?
>                                 pinctrl-single,pins = < BONE_P9_21
> (PIN_INPUT_PULLUP  | MUX_MODE0)      // Used as SPI0 MISO +/
>                                                         BONE_P9_18
> (PIN_OUTPUT_PULLUP | MUX_MODE0)      // Used as SPI0 MOSI +/
>                                                         BONE_P9_22
> (PIN_OUTPUT_PULLUP | MUX_MODE0)      // Used as SPI0 SCKL +/
>                                                         BONE_P9_17
> (PIN_OUTPUT | MUX_MODE0)>;   // Used as SPI0 CS0 (This pin has a physical
> pullup resistor) +/
>
> //                                                      BONE_P9_15
> (PIN_INPUT_PULLUP  | MUX_MODE7)      // Used as GPIO_48 for IRQ to TPM
> //                                                      BONE_P9_13
> (PIN_OUTPUT_PULLUP | MUX_MODE7)>;    // Used as GPIO_31 for RST to TPM
>
                        };
>                 };
>         };
>
>         fragment@4 // Every example I looked at has the spi configuring
> fragmet as separate form the actual TPM config fragmet even though they can
> be one...
>         {          // Here I assign the actual pins to the SPI interface
> and disable both channels since I want the TPM to be the active device
> rther than having spidev in /dev
>

Just remember that there are 2 drivers, one for the SPI controller and one
for the TPM.


>                 target = <&spi0>;
>
>                 __overlay__
>                 {
>                         pinctrl-names = "default";
>                         pinctrl-0     = <&pb_spi0_pins>;
>                         status        = "okay";
>
>                         #address-cells = <1>;
>                         #size-cells    = <0>;
>
>                         channel@0
>                         {
>                                 compatible = "spidev";
>                                 reg = <0x0>;
>                                 status = "disabled";
>
>                                 spi-max-frequency = <32000000>;
>                         };
>
>                         channel@1
>                         {
>                                 compatible = "spidev";
>                                 reg = <0x1>;
>                                 status = "disabled";
>
>                                 spi-max-frequency = <32000000>;
>                         };
>

disabling the spidev drivers shouldn't need any of the other arguments.
Also, I think you'd want to be targeting the spidev symbols to overwrite
those values. Can you confirm the spidev drivers aren't being loaded?


>                 };
>         };
>
>         fragment@5               // The main fragment. Configuring the
> TPM. I did it as per the example given by those who wrote the SPI kernel
> modules.
>         {                        // That's how I managed to get the dtbo
> to load the actual modules. All my previous versions of this fragment
> failed to do that.
>                target = <&spi0>; // I did try wtihout the gpio interupt
> stuf but it didn't work either.
>
>                 __overlay__
>                 {
>                         #address-cells = <1>;
>                         #size-cells    = <0>;
>
>                         tpm_tis@0
>                         {
>                                 compatible = "tcg,tpm_tis-spi"; //
> tcg,tpm_spi_tis,infineon,slb9670
>                                 status     = "okay";
>
>                                 #gpio-cells = <2>;
>                                 #interrupt-cells = <2>;
>

why?


>
>                                 reg = <0x0>;
>                                 spi-max-frequency = <32000000>;
>                                 num-cs = <1>;
>

Is this needed?


>                                 interrupt-parent = <&gpio1>;
>                                 interrupts = < 16 2>;
>

I don't see this in the bindings:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/security/tpm/tpm_tis_spi.txt


>                                 gpios = <&gpio1 16 GPIO_ACTIVE_LOW>,
> <&gpio0 31 GPIO_ACTIVE_LOW>;
>

I don't see this in the bindings either. Where are you pulling the
instructions from?


>                         };
>                 };
>         };
> };
>
> dmesg gives no relevant information.
>

are you sure?


>
> Thanks in advance and sorsy for long post :)
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/f26111dd-7119-47a2-9205-2658acd90a47%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/f26111dd-7119-47a2-9205-2658acd90a47%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
https://beagleboard.org/about - a 501c3 non-profit educating around open
hardware computing

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnRMgMra%2B76uPkG_PNznBBtoCzv0b3rwC2nzY1QwVPoKQ%40mail.gmail.com.

Reply via email to