What do you mean by /dev/bone/spi.?
I run custom image with busybox rfs, compiled in buildroot.
I can see that tis-spi driver for tpm2.0 is loaded under /sys/bus/spi/drivers (I compiled it with kernel).
There is also SPI1.1 device visible under /sys/bus/spi/devices
In short, SPI1 is working because I use it for ENC28J60 ethernet PHY with CS0.
For SLB9670 I use P9_42 pin in mode 2 as CS1, but without any luck to establish connection with SLB.
Ok so you don’t mention which pin CS1 is on.
So as you have SPI working on CS0 there could be several reasons why it isn’t working.
Are you sure the mux is MODE 2 ?
Having a quick look through the datasheet, and as far as I can see SPI1_CS1 should be either MODE 1 or MODE 4 depending on pin. Can’t see anywhere it comes as MODE 2. This is most likely your problem.
Ok obviously search wan’t working well. There is a pin where it is MODE 2.
So you are connecting to P9.42 ?
If using P9.42 then the mux address of 0x164 is probably correct assuming 0x800 is added as an offset in there somewhere.
Looking at the schematic P9.42 is connected to 2 pins. There are a couple of 0 ohm resistors so I don’t know if both are fitted. If both resistors are fitted then make sure the other pin is setup as an input. I can only find R51 on my board which is fitted, Can’t locate R50. Numbering might have changed as the board I has is quite old. R50 is the SPI1_CS1 pin so it is important.
I would also check the CS1 pin with a scope and see if it is actually toggling.
Yes, there are two shared pins connected to P9.42, the one I use as SPI1 CS1 in mode 2 with the offset of 0x164 from the base address 0x800, and the second one is with the offset of 0x1A0.
You can find offsets on page 1461 here:
Both resistors R50 and R51 are on board, but I already tried to put another pin as an input, but nothing changed. Seems that another pin in default configuration does not affect CS1 functionality.
Pin mux is functioning, checked pins in /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins
That should be some other issue related to this specific error. Can you try to load this overlay and see if you get the same?
This is what I have included and compiled in my kernel image:
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_SPI=y
So assuming the pin muxing is all ok, you are left with either kernel driver issues or hardware problems.
Have you checked the signals with a scope ? Are they clean ?
You could try reducing the SPI clk frequency.
It can also be useful in debugging hardware to just enable the SPI dev driver and try using that to do some basic communications with the chip to make sure your hardware is working.
Less likely it is a hardware issue because I have multiple same setups. Checked wiring, everything seems correct.
Reduced clock already but no changes at all.
I really start to think it is kernel driver issue but unfortunately there is no workaround for me in that case, or it is somerhing with SPI CS1 pin. I use kernel 6.1.33 and thinking if reverting to older version can change something.
I don’t have scope next to me at the moment
Hi,
Does anyone has any other suggestions?
I reverted back to kernel version 5.4.106 and now there is no any dmesg that shows spi1.1 or tpm
I checked multiple times, hardware connections are ok, pinmuxes are ok, kernel configuration is ok.
It is like I am missing something in my dto but not sure what?
I checked driver to check if compatible property is bad, but it is ok as well:
On some forum i found that issue with SPI1 bus on BBB was due to something inside the minimum image.
Since I lost any options to check, starting to think if the issue lies in fact that I use busybox minimal rfs build with Buildroot?!
I doubt that a minimal bustbox buildroot image is the cause of your problems.
I had a chance at the weekend to fire up a BBB and tested both SPI1 chip selects on a scope and both were working as expected (including P9.42).
If you have access to a scope you really need to check that the SPI pins are working as expected. I suggest for testing just enable SPIDEV as it is easier to use from userspace. If you have the kernel source, look at tools/spi/spidev_test.c for some code to test the port.
Assuming the signals are all ok, then you can rule out in issues with pin muxing or something else in the devicetree causing an issue.
Have you checked the source for the driver to see just where -110 is being returned ?
That might give you some clues also as to why it is not working.
What this output is telling me? Is there any other specific spidev_test command that can tell me something more?
When I execute it once more I get only zeroes in the output.
Really was not able to find nothing specific to -110 on the internet and in my source code, only that is spi timeout related issue. Tried to change frequency to multiple values, lower or higher and Still dthere is an error:
tpm_tis_spi: probe of spi1.1 failed with error -110
You need to put a scope on the CS line and trigger on falling edge. Make sure it is actually going low.
If you can, check with nothing connected and with your hardware connected.
If you are not seeing a CS signal then there is either an issue with the hardware or something in the devicetree with pin muxing.
If you have the signal then the issue is with the driver, or the configuration of it in the devicetree, maybe the SPI mode not being set correctly. As far as I can see the driver does not set the mode when doing a transfer.
Hi,
It is constantly pulled low in mode 2, whichever configuration I use.
By defualt I tried 0x164 0x32, but tried different combinations like 0x12 0x02 and if it is in mode 2 it stays low always.
Regards
If it is permanently low that would probably explain why it isn’t working.
Any SPI activity on the other CS would also have been accepted by the TPM module.
Are you sure there are no pinctl messages in the kernel boot log ?
Hi @benedict.hewson , sorry for the late response, I was waiting for the scope probes
No pinctrl related messages in the kernel boot log.
CS1 goes permanently low only when SLB9670 is connected. When CS1 goes low, I can see something is happening on SCK and MOSI lines during boot, but nothing on MISO line. After that SPI lines stay idle, and CS1 stays permanently low.
Reset line is high, that is OK, and interrupt line does not go low, it is constantly high as well.
When I look CS1 line without hardware connected (only BBB) is stays high, as expected, and I can not see tpm_tis_spi: probe of spi1.1 failed with error -110. message. This is indicative, so SPI can recognize the TPM but communication is not sucessfull, or timed-out.
CS1 should not stay permanently low. It should only got low when clocking data.
I would say you have a problem with the slb9670 chip.
The error code you are seeing comes from tpm_tis_spi_main.c. There is a function tpm_tis_spi_flow_control()
The driver code keeps trying to read from the chip until MISO goes high, or it times out with error -110
Looks like the driver reads a max of 50 bytes before giving up.
With no hardware connected you should still see CS1 go low while the driver looks for the chip, but you will need to trigger on the falling edge of CS1 and do a single shot or you will likely not see it.
It is easier to test SPI using spidev from userspace as you can force as many writes as you need to check.
Hi @benedict.hewson , it is not hardware issue.
I found an image where BBB and SLB8670 are used just to check if it works, and it works. I mounted the image and found .dtbo file which I recompiled to .dts just to see overlay and I get this:
It works, I see normal logs from TPM. When I try to use it with my image, this overlay is not working, even when using the same kernel image.
This is very very strange, especially because compatible is define as for RPI but works on BBB
HW checked, SPI bus is working, tried with multiple kernel versions, removed restitor R51 and my issue still persists.
Am struggling with this some time now, pretty usnure what can try else.
It is strange that the working overlay does not work with your kernel.
Is u-boot applying it - is there a u-boot load error when using it with your kernel ?
The working kernel and overlay might have differences in the root devicetree, that you are missing.
The working overlay is not setting any pin muxing as far as I understand it, so that must be setup somewhere else. Just then using the overlay with your kernel/root device tree wouldn’t work.
Do you mean you are using the same kernel version ? Not the same actual image.
Check the kernel options for the one that works against your kernel and see if there are any differences.
But the fact that the driver is attempting to probe for the chip at least indicates that the driver is loaded.
As you are building your own kernel, why not create a devicetee for it and not bother with overlays.
