[Invalid] - NanoPi M4V2: SPI Not Working

[TCB13]

Hello,

 

I'm trying to use the NanoPi M4v2 SPI however it doesn't seem to work. I used armbian-config to enable the gpio overlay:

 

[ ] dwc3-0-host
[ ] i2c7
[ ] i2c8
[*] pcie-gen2
[ ] rk3328-opp-1.4ghz
[ ] rk3328-opp-1.5ghz
[ ] rk3399-opp-2ghz
[ ] spi-jedec-nor
[*] spi-spidev
[ ] uart4
[ ] w1-gpio

 

And the SPI isn't showing up on /dev:

 

ls /dev/spi*
ls: cannot access '/dev/spi*': No such file or directory

 

Wasn't this enough to be able to use the SPI1 on this board?

 

SBC: NanoPi M4V2

System: 5.10.35-rockchip64 #21.05.1 SMP PREEMPT Fri May 7 13:53:11 UTC 2021 aarch64 GNU/Linux

 

Thank you.

[Werner]

Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):

 

• it is for an unsupported board or image (CSC/EOS/WIP/edge)
• it is for software that is not supported (such as userspace modules installed on top of the core operating system)
• it has been logged in the wrong forum (for example requests for help that are not actual bug reports)
• it lacks requested data (armbianmonitor output)
• it could have been easily solved by a quick search and/or reading documentation

 

Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as Common issues / peer to peer technical support or General chit chat)

[TCB13]

I'm sorry but...

• it is for an unsupported board or image (CSC/EOS/WIP/edge) > It's a supported board
• it is for software that is not supported (such as userspace modules installed on top of the core operating system) > NO
• it has been logged in the wrong forum (for example requests for help that are not actual bug reports) > NO, its a bug.
• it lacks requested data (armbianmonitor output) > Not relevant in this case.
• it could have been easily solved by a quick search and/or reading documentation > ??

[Werner]

[TCB13]

1 minute ago, Werner said:

 

Okay, you win I'll provide the file ASAP.

[Igor]

14 minutes ago, TCB13 said:

I'll provide the file ASAP

@Werner this image might send a wrong message. There is still absolutely no warranty that any support will be provided even board is declared as supported.

 

27 minutes ago, TCB13 said:

I'll provide the file ASAP.

If a few days will be needed to solve this problem, what you will do?

[TCB13]

46 minutes ago, Igor said:

If a few days will be needed to solve this problem, what you will do?

 

I'll wait patiently for some news. It's not a life or death situation

[Igor]

 
I'll wait patiently for some news. It's not a life or death situation

FYI. A few days of debugging costs few thousand eur. We have 0 eur budget per year for that. Patiently waiting for donation that will cover the time dealing with this problem so we can hire someone to fix this for you.

If this is not life and death, this will not be a problem.

I can afford only a few minutes per bug or per "client". Usually less then 1m. For debugging help - my first available pro bono days are not this year ...

Wrote on mobile

[TCB13]

2 hours ago, Igor said:

FYI. A few days of debugging costs few thousand eur. We have 0 eur budget per year for that. Patiently waiting for donation that will cover the time dealing with this problem so we can hire someone to fix this for you.

If this is not life and death, this will not be a problem.

I can afford only a few minutes per bug or per "client". Usually less then 1m. For debugging help - my first available pro bono days are not this year ...

Wrote on mobile
 

 

I think there is a misunderstanding here, I never requested support in "record time" and I certainly didn't said that it needs to happen fast. I just said I would upload my log file as soon as I can.

 

I'm happy with the "few minutes" whenever you guys have some spare time!

[Igor]

33 minutes ago, TCB13 said:

I think there is a misunderstanding here

 

Agree.

 

41 minutes ago, TCB13 said:

I never requested support in "record time"

 

All support requests are denied by default. There is no support the way you imagine. Check your contract terms:
https://github.com/armbian/build#support

[tparys]

As entertaining as this thread is so far, I suggested to @TCB13 to post here to get more eyes on the problem.

 

I can confirm that enabling the overlay in question didn't do the expected thing. And "armbianmonitor -u" is here: http://ix.io/3nS8

 

Interestingly, the overlay seems to be disabling the spidev?

 

        fragment@4 {
                target = <0xffffffff>;

                __overlay__ {
                        #address-cells = <0x01>;
                        #size-cells = <0x00>;

                        spidev {
                                compatible = "spidev";
                                status = "disabled";
                                reg = <0x00>;
                                spi-max-frequency = <0x989680>;
                        };
                };
        };

 

Offhand, I'm not sure what's required to switch between multi-function pins, but figured there would be far more eyes on the problem here rather than Peer to Peer Support.

[piter75]

@TCB13 I am a bit late to the party but I figured it may still be needed ;-)

 

spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.

 

For configuration options have a look here:

https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126

You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays

[TCB13]

2 hours ago, piter75 said:

@TCB13 I am a bit late to the party but I figured it may still be needed ;-)

 

spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.

 

For configuration options have a look here:

https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126

You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays

 

Never late to the party! Thank you for your tips.

 

Btw, for future reference fro anyone going about the same path, page 11 of the NanoPi M4v2 schematic contains a definition of the SPI1 that can be easily between the overlay and physical pins.

 

Schematic: http://wiki.friendlyarm.com/wiki/images/c/cc/NanoPi-M4V2_1908_Schematic.pdf

Physical pin assignment: https://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4V2#Diagram.2C_Layout_and_Dimension

 

 

[TCB13]

On 6/6/2021 at 9:21 AM, piter75 said:

@TCB13 I am a bit late to the party but I figured it may still be needed ;-)

 

spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.

 

For configuration options have a look here:

https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126

You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays

 

Your comment was crucial to fix my "issue". I enabled the overlay and then as described on the file edited `/boot/armbianEnv.txt` in order to include:

 

param_spidev_spi_bus=1
param_spidev_max_freq=100000000

 

Now the SPI shows up:

~# ls -la /dev/spi*
crw------- 1 root root 153, 0 Sep 16 18:51 /dev/spidev1.0

 

Also passes the spidev_test (https://raw.githubusercontent.com/torvalds/linux/master/tools/spi/spidev_test.c)

~# ./spidev_test
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)

 

(Had to adjust the path)

 

Thank you for the tip!

 

[TCB13]

Now unfortunately luma-oled seems to be yet another problem. I wired up my LCD as:

MOSI > GPIO1_A7 > SPI1_RXD > M4 Pin 21   > LCD DIN Pin (blue)
SCK > GPIO1_B1 > SPI1_CLK > M4 Pin 23     > LCD CLK Pin (yellow)
CS > GPIO1_B2  > SPI1_CSn0 > M4 Pin 24    > LCD CS Pin (orange)

 

DC > GPIO1_A0(3V) > M4 Pin 7        >   LCD DC Pin (green)

RST > GPIO1_A1(3V) > M4 Pin 11    >   LCD RST Pin (white)

 

From my understanding I had to get GPIO1_A0 and GPIO1_A1 in the system so the lib could use them.

According to this https://hev.cc/2927.html GPIO mapping I tried:

 

ls -la /dev/spi*
crw------- 1 root root 153, 0 Sep 16 18:51 /dev/spidev1.0

echo 32 > /sys/class/gpio/export
echo 33 > /sys/class/gpio/export

ls -la /sys/class/gpio/
total 0
drwxr-xr-x  2 root root       0 Jan 18  2013 .
drwxr-xr-x 76 root root       0 Jan 18  2013 ..
--w--w----  1 root dialout 4096 Sep 16 20:51 export
lrwxrwxrwx  1 root root       0 Sep 16 20:50 gpio32 -> ../../devices/platform/pinctrl/gpiochip1/gpio/gpio32
lrwxrwxrwx  1 root root       0 Sep 16 20:50 gpio33 -> ../../devices/platform/pinctrl/gpiochip1/gpio/gpio33
lrwxrwxrwx  1 root root       0 Jan 18  2013 gpiochip0 -> ../../devices/platform/pinctrl/gpio/gpiochip0
lrwxrwxrwx  1 root root       0 Jan 18  2013 gpiochip128 -> ../../devices/platform/pinctrl/gpio/gpiochip128
lrwxrwxrwx  1 root root       0 Jan 18  2013 gpiochip32 -> ../../devices/platform/pinctrl/gpio/gpiochip32
lrwxrwxrwx  1 root root       0 Jan 18  2013 gpiochip64 -> ../../devices/platform/pinctrl/gpio/gpiochip64
lrwxrwxrwx  1 root root       0 Jan 18  2013 gpiochip96 -> ../../devices/platform/pinctrl/gpio/gpiochip96
--w--w----  1 root dialout 4096 Sep 16 19:19 unexport

 

Now I tried the luma-oled examples (running as root):

 

python3 3d_box.py --display ssd1351 --interface spi --spi-port 0 --spi-device 1 --gpio-reset 33 --gpio-data-command 32 --width 128 --height 128
usage: 3d_box.py >(....)
3d_box.py: error: GPIO access not available

 

I'm not even sure if this part "--gpio-reset 33 --gpio-data-command 32" is correct. I've tried both the virtual pin number and the hardware number without luck.

 

Also tried to install https://github.com/friendlyarm/RPi.GPIO_NP without much luck:

 

apt-get update
apt-get install python-dev
git clone https://github.com/friendlyarm/RPi.GPIO_NP
cd RPi.GPIO_NP
python3 setup.py install
python3 setup.py install

python3 luma.examples/examples/3d_box.py --display=ssd1351 --interface=spi --width=128 --height=128 --spi-bus-speed=16000000 --bgr --spi-device=1 --spi-port=0 --gpio-reset=33 --gpio-data-command=32 --gpio RPi.GPIO

Traceback (most recent call last):
(...)
RuntimeError: It is not NanoPi based board.