SK-AM62B-P1: Assistance Required for SPI device Issue

Murali Vikash Ganireddy said:

. Are there any modifications required in the device tree to correctly recognize the W25Q64JV device? I

Memory devices like that will show up under /dev/mtd, not as a /dev/spidev device. Those use completely different drivers and SW stacks.

Regards, Andreas

Hi Andreas,

I want to test the SPI interface using a user-space application. I've noticed that there's no MTD device listed under /dev/. Could you guide me on how to open the driver and perform read/write operations? Also, is it necessary to use the compatible string "winbond,w25q64jv," or can I keep it as "rohm,dh2228fv"? Please assist me with this issue.

regards, VIkash

Hi Vikash,

if you are using an external Flash memory device you should use it through the Linux MTD software stack, and not trying to access it byte-by-byte through a userspace application (via spidev) which would require you to model the SPI communication protocol with the memory chip you have in userspace -- something the Kernel driver already does. Plus, such an approach  won't be scalable/portable when you switch to a new device down the road.

1) Look for ls -al /dev/mtd*  (note the asterisk at the end)

2) Check your kernel log for signs of mtd activity, something like this...

root@am62xx-evm:/# dmesg | grep -i mtd
[ 0.000000] Kernel command line: console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 mtdparts=spi-nand0:512k(ospi_nand.tiboot3),2m(ospi_nand.tispl),4m(ospi_nand.u-boot),256k(ospi_nand.env),256k(ospi_nand.env.backup),98048k@32m(ospi_nand.rootfs),256k@130816k(ospi_nand.phypattern) root=PARTUUID=076c4a2a-02 rw rootfstype=ext4 rootwait
[ 1.308904] 7 fixed-partitions partitions found on MTD device fc40000.spi.0
[ 1.315868] Creating 7 MTD partitions on "fc40000.spi.0":

If there aren't any you might be missing partition definitions (add those via device tree).

Also try looking for spi0 activity like this...

root@am62xx-evm:/# dmesg | grep -i spi0
[ 1.303787] spi-nor spi0.0: s28hs512t (65536 Kbytes)

Regards, Andreas

Hi Andreas,

Please have a look on screenshot of dmesg output for spi:

Device tree changes:

+       main_spi0 = &main_spi0; --> in aliases

+    main_spi0_pins_default: main-spi0-pins-default {
+               pinctrl-single,pins = <
+            AM62X_IOPAD(0x01bc, PIN_OUTPUT, 0) /* (A14) SPI0_CLK */
+           AM62X_IOPAD(0x01b4, PIN_OUTPUT_PULLUP, 0) /* (A13) SPI0_CS0 */
+           AM62X_IOPAD(0x01b8, PIN_OUTPUT_PULLUP, 0) /* (C13) SPI0_CS1 */
+           AM62X_IOPAD(0x01d0, PIN_OUTPUT_PULLUP, 1) /* (A15) UART0_CTSn.SPI0_CS2 */
+           AM62X_IOPAD(0x01d4, PIN_OUTPUT_PULLUP, 1) /* (B15) UART0_RTSn.SPI0_CS3 */
+           AM62X_IOPAD(0x01c0, PIN_OUTPUT, 0) /* (B13) SPI0_D0 */
+           AM62X_IOPAD(0x01c4, PIN_INPUT, 0) /* (B14) SPI0_D1 */
+               >;
+        };

+&main_spi0 {
+        status = "okay";
+       #address-cells = <1>;
+       #size-cells = <0>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&main_spi0_pins_default>;
+        ti,pindir-d0-out-d1-in=<0>;
+        ti,spi-num-cs = <4>;
+        flash@0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "winbond,w25q64jv", "jedec,spi-nor";
+        reg = <0>;
+        spi-max-frequency = <40000000>;
+    };
+};

Alright this is good info; you can see from the error how it's reading the device ID bytes as 0xFF 0xFF etc., this usually means there's an issue with the signals for example (but not limited to) the pinmux settings.

Try updating your pinmux definitions like shown in this known-good example here:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am625-sk-mcspi-loopback.dtso?h=ti-linux-6.6.y-cicd

Then, if that alone doesn't work, try the following:

• Experiment with setting ti,pindir-d0-out-d1-in=<1>;  (this will take care of potentially swapped MISO/MOSI lines)
• Experiment with setting spi-max-frequency = <10000000>;  (always a good thing to try to get things working initially)

If this doesn't help you should connect a logic analyzer to your SPI signals and see what you get on the actual bus, this usually is greatly helpful to quickly understand why/where things are breaking down.

Regards, Andreas