TCB13

Do you have any hint on what to look at to try to fix that issue ?
I might invest some time on it (and hopefully also get some more knowledge about these things)

Doing what is explained in this post make it to work but spidev isn't anymore controlled through /boot/armbianEnv.conf file but the DT.
 
I used the "quick and dirty" fix for now by using "rohm,dh2228fv" which is already in the spidev_dt_ids[] list and avoid me creating a new build with a patch to modify drivers/spi/spidev.c
 
So basically, I used armian-config to edit the Device Tree (System => Dtc),
Browse the DT over soc => spi@1c68000
And I added these lines :
spi@1c68000 { ... spidev@0x00 { compatible = "rohm,dh2228fv"; spi-max-frequency = <100000000>; reg = <0x00>; }; }  
And the same for the second SPI controller :
 
spi@1c69000 { ... spidev@0x00 { compatible = "rohm,dh2228fv"; spi-max-frequency = <100000000>; reg = <0x00>; }; }  
I also had to remove the spidev stuff from /boot/armbianEnv.conf (No spi-spidev overlay)

This way, I get two SPI devices and the SBC is working again with 5.15 kernel :
 
# ls /dev/ | grep spi spidev0.0 spidev1.0  

@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

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.

So the M4V2 is a supported board. that the SPI isn't working is probably worth a post by itself in the Rockchip 3399 Subforum.
 
At a glance, I tried turning on the SPI on my M4V2 and didn't see any spidev devices pop up, but might need to pull out the serial console to see if u-boot is throwing any warnings about the overlay.
 
Taking a look at the overlay, I'm not sure it looks correct, as it looks like even if it applies the SPI channel is disabled.
 
fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };  
 

Well - not similar from assembly, but similar in use case
I have Sata Tower from radxa. I have 4 ssd attached, but I didn't run any benchmarks. I love the small form factor, and its going to be useful after I ported driver from radxa.

Looks like a neat setup. I was not aware that M.2 to 5x SATA device existed.
 
But before you reinvent the wheel, have you considered that you basically made a Helios64 without the nice enclosure?

Moved to Common issues / peer to peer technical support since this is not a valid bug report

received my nvme board and ssd this week, here is my iozone results.
FriendlyArm Nanopi M4v1 4GB board NVME board Armbian Buster Desktop Kernel 5.4.28 Adata XPG SX8200 Pro 1TB Tom's hardware favorite
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
                                                                                                 random    random                                 
                  kB   reclen       write     rewrite        read      reread        read       write
          102400          4     97170    133733   155927   156368     61290   133851                                                          
          102400        16    254791   325694   337906   339478   134043   323214                                                          
          102400      512    669920   744732   662990   674603   558387   670433                                                          
          102400    1024    658770   710258   677015   705205   627108   776480                                                          
          102400   16384   820732   824027   727671   731739   722866   821623
Power consumption is up from 5.5-6.5watts for 2 and with 1024 and 16384 for 3 watts up to 9.5watts.
Not bad for a lame SBC. I use with Postgres, Timescaledb and Grafana in Docker containers.

Try bigger files. This test does files of 64k. Try files of 100MB 100times.
dd if=/dev/zero of=test bs=100MB count=100 conv=fdatasync I use the gnome-disks utility to benchmark. It shows the performance with big files, but also the latency what is important for small files. That way you get numbers that can be understood.

My results with a NanoPi M4v2 + 8A custom power supply + Samsung NVMe 250 GB EVO 960 PRO:
 
$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.72603 s, 394 MB/s
 
Kernel 4.4.213-rk3399
 
Slow isn't it ? I wonder what can be done to improve this.
 

I like to further add regarding Sabrent 256GB Rocket NVMe i have tested this write speed and read speed same time.
Read 390mb give or take few mb and around 380 write.
 
So i would assume this is the upper limit on the pci2.1 on the m4 of around 780 something considering the NVMe is rated 1050mb write 3100 read. Still alot faster then the ssd i tested through usb3.

It seems, that there is no driver for fan in armbian. So I wrote a little program in C to control fan on the hat. This nice program adjust the fan speed on cpu temperature accordingly. It starts the fan as 60 °C with 30% power. At 70 °C up to 60% and at 80 °C to 90%. You can adjust it within the code easily.
Compile it with "gcc fancontrol.c -o fancontrol". I configured the program as service. If you want it too, do the following steps:
Create a file fancontrol.service with the following content:
[Unit] Description=Fan control [Service] Type=simple User=root Group=root WorkingDirectory=/usr/bin ExecStart=/usr/bin/fancontrol [Install] WantedBy=multi-user.target do the following steps
sudo cp fancontrol /usr/bin sudo cp fancontrol.service /etc/systemd/system sudo systemctl enable fancontrol sudo systemctl start fancontrol  and that's it.
It works perfekt for me.
Have fun.

Linux m4-2 5.4.13-rockchip64 #19.11.8 SMP PREEMPT Wed Jan 22 22:53:38 AEDT 2020 aarch64 aarch64 aarch64 GNU/Linux
 
this is a home built image with X
 

Now I have get the next crash processes (see the log).
Kernel 5.4.13
CPU 1,42/1,8Ghz governor is set to "conservative"
What I doing. I open the webgui from a nextcloud (docker) installation.
 
 
log_crash-20200191.txt

Hi,
First, I use a mean well S-100F-12 (12 Volt 8.5 A) 
https://www.meanwell-web.com/nl-nl/ac-dc-enclosed-power-supply-output-12vdc-at-8-5a-s--100f--12
This one I had some time and I wasn't using it.
I power the NanoPi true the 4-pin connector on the sata hat with a connector used from an old PC power supply.  (All 4 wires connected)
 
 
I had some spare time this week-end and did some test with my NanoPi.  
The problem seems to be more noticeable when I use midnight commander and copy files from usb to the sata hat.
It also shows up when copying files from network to sata true a samba share on the NanoPi.
 
Slowing down the CPU to 1800 ,1600 and 1400 did not make a difference.
 
Temperature found with htop was approx. 42-40°C at max CPU and at 1600 - 1400 about 36°C
I have a large slow turning fan on the NanoPi and a 50mm direct above the sata hat.
 
What I found strange is, that when I started from a cooled down NanoPi the NanoPi worked longer before failing than when is just rebooted and started again. (Or it is my imagination :-))
 
After another tip on https://forum.openmediavault.org/index.php/Thread/30512-Nanopi-crashes-on-file-transfers/ I restarted and used kernel 4.4.
The CPU is now running at 1800 with a temp of 30 a 35°C and I don’t seem to have this problem anymore.
 
At this point I'm not sure it's a power problem or a temperature problem but I'm planning to spend some more time on it this weekend.
There is also still a possibility that I received a faulty NanoPi or hat . . .
 
Any further input about this is always welcome.
 
 

Since I set the CPU frequency to 1.4/1.8Ghz I have no problems.
Look at this topic
 
 

Erueka! Now the wifi is working perfectly.
 
Did fallow part of this instructions https://askubuntu.com/questions/621452/something-keeps-changing-my-wireless-regulatory-domain
 
 

It was the same with me, too. CPU message on the console and nothing works. I use the 5.4.8 kernel.
Currently I use a power supply with 5.3V/4A on pin4/6
https://www.amazon.de/gp/product/B01HRR9GY4/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
But I'm not entirely satisfied with that either.
I am currently preparing a rack mounting of the NanoPi and will then use this power supply.
https://www.meanwell.com/webapp/product/search.aspx?prod=RS-25
That's stable at 5A.

I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
But of course, that's not a prove against crashes...

@Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.

Could you possibly test it with 4.x on M4v2?

Interesting, I also had problems copying files using the 5.4 kernel on my NanoPi M4V2. I compiled it myself and copies files from the sd-card to and external hard drive connected via the SATA-hat. I used file systems on the hard drive that were able to detect corrupted data on the drive (ZFS and BTRFS) and every time I did a scrub after copying the files, failed CRC-checks within the data were reported, some of them even at the same position on two redundant drives (mirror).
 
I'll try again with the legacy kernel (4.x). Would be greate if it works in this configuration. @piter75: Did you apply your fixes for ethernet also to the legacy kernel? Then it would be much easier to get the data onto the device in the first place.

for the LEDs you can try the following:

ls -l /sys/class/leds
(here as example from a NanoPi Neo2):
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr
 
then echo none to the trigger of the led-name: 
 
echo 'none' > /sys/class/leds/[name_of_the_led]/trigger
 
so it should look like this:
 
echo 'none' > /sys/class/leds/nanopi:green:status/trigger
 
You only have to check the led-names of your board and add the commands in /etc/rc.local before "exit 0"

Thank you once again!