Have anyone experience with 3rd party module connection with SPI to Opi5?
I'm running Linux orangepi5 5.10.110-rockchip-rk3588 #23.02.2 SMP.

I add spidev device using armbian-config (opi-spi4-m0-cs1-spidev)

verbosity=1
bootlogo=false
overlay_prefix=rockchip-rk3588
fdtfile=rockchip/rk3588s-orangepi-5.dtb
rootdev=UUID=6fc3824e-c6c2-4781-8807-20e5a4bfc432
rootfstype=ext4
overlays=opi5-spi4-m0-cs1-spidev

Two devices appears - 

crwxrw-rw- 1 root root 153, 0 Apr 17 10:55 /dev/spidev4.0
crwxrw-rw- 1 root root 153, 1 Apr 17 10:55 /dev/spidev4.1

Internal loopback test with spidev_test works w/o problem if I put wire MOSI <-> MISO.

But when I plug 3rd party module (Qorvo DWM1000) there and run test program I see something strange at CLOCK. And CS and MISO always high. Seems CS problem. Any ideas?

Spoiler

 

Edited April 17, 20233 yr by gLush

@gLush I don't have experience with spi on this device, but shouldn't you connect miso to miso and mosi to mosi?

https://www.circuitbasics.com/how-to-set-up-spi-communication-for-arduino/

Sorry I didn't read it correctly, this was for the internal loop which did work.

 

Not sure if it's helpful but firefly has some documentation about how to use the spi:

https://wiki.t-firefly.com/en/ROC-RK3588-PC/usage_spi.html#drive-coding

Edited April 18, 20233 yr by royk

Seems to me something wrong with device tree overlay. Here is part of UART boot log:

reading /dtb/rockchip/rk3588s-orangepi-5.dtb
234767 bytes read in 2 ms (111.9 MiB/s)
reading /dtb/rockchip/overlay/rockchip-rk3588-opi5-spi4-m0-cs1-spidev.dtbo
598 bytes read in 2 ms (292 KiB/s)
Applying kernel provided DT overlay rockchip-rk3588-opi5-spi4-m0-cs1-spidev.dtbo
** Unable to read file /dtb/rockchip/overlay/rockchip-rk3588-fixup.scr **
 

@gLush  The fixup.scr seems like it's deprecated.

At least in the repo of orange pi all lines are comment out:

https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-5.10-rk3588/arch/arm64/boot/dts/rockchip/overlay/rk3588-fixup.scr-cmd

 

The CS should be pulled low the moment it sends data, does it get pulled down during the internal loop test?

Did you follow the test from the manual? and did you receive the same as the output?

sudo spidev_test -v -D /dev/spidev4.1
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF F0 0D | ......@....▒..................▒.
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF F0 0D | ......@....▒..................▒. 

 

 

Yes. Seems it's pulled down during loopback test.

 

root@orangepi5:~/dev/spidev_test# sudo ./spidev_test -v -D /dev/spidev4.1
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....�..................�.
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....�..................�.
root@orangepi5:~/dev/spidev_test# sudo ./spidev_test -v -D /dev/spidev4.0
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....�..................�.
RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....�....

Here is rockchip-rk3588-opi5-spi4-m0-cs1-spidev.dtbo decompiled. And seems it use fixup.

 

/dts-v1/;

/ {

        fragment@0 {
                target = <0xffffffff>;

                __overlay__ {
                        status = "okay";
                        #address-cells = <0x01>;
                        #size-cells = <0x00>;
                        pinctrl-names = "default";
                        pinctrl-0 = <0xffffffff 0xffffffff>;

                        spidev@0 {
                                compatible = "rockchip,spidev";
                                status = "okay";
                                reg = <0x00>;
                                spi-max-frequency = <0x2faf080>;
                        };
                };
        };

        __fixups__ {
                spi4 = "/fragment@0:target:0";
                spi4m0_cs1 = "/fragment@0/__overlay__:pinctrl-0:0";
                spi4m0_pins = "/fragment@0/__overlay__:pinctrl-0:4";
        };
};

If you receive the same as you've sent and the cs pin is pulled down I would say there is nothing wrong with the overlay. You probably need to check the wiring/config to your Qorvo DWM1000.

 

So the fixup is implemented in the overlay.

It's sad, but same DWM1000 sensor works at two other platforms (ESP8266 and STM) with same wiring. Will try to make wires shorter today.

Those are microcontrollers. You probably would need to find the right way to communicate with it.

 

I've seen there is some python code to communicate with the module but those are made for the RPI so'll need some adjustments.

https://github.com/pedestrian0423/DW1000_Raspi_Python_library/tree/master

 

Python gpio libraries for the Orange Pi 5:

 

RPI.GPIO replacement: https://github.com/jer021/OPi.GPIO

 

WiringPi: https://github.com/orangepi-xunlong/wiringOP-Python/tree/next

 

For branch next and recursive:

git clone --recursive https://github.com/orangepi-xunlong/wiringOP-Python.git --branch next

 

I can't help you further, maybe someone else who has the module.

I'm communicating with this module at ESP8266 dev board, STM dev board and just our own PCB under Android JNI/Linux. 
Anyway thanks for help.

BTW wiringOP-Python has OPi5 support also at "next" branch.