NanoPI 4MV2


Recommended Posts

Hi,

I have a problem with my NanoPi M4V2 (with Raspberry Pi 4 power supply) and the new Armbian release 19.11.3 (Buster). I can boot the image from SD, eMMC. But when I connect any USB storage (USB-Stick or SSD with USB to SATA) then I have packet lost on the Ethernet connection. Any idea where the problem is?
On the interface I can't see problems.

 

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.xx.36  netmask 255.255.255.0  broadcast 192.168.42.255

        inet6 fd58:xxxx:xxxx:1::1006  prefixlen 64  scopeid 0x0<global>

        inet6 fe80::94ad:f6ff:fe0d:757b  prefixlen 64  scopeid 0x20<link>

        ether 96:ad:f6:0d:75:7b  txqueuelen 1000  (Ethernet)

        RX packets 1475  bytes 231894 (226.4 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1088  bytes 129189 (126.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 24

 

Thanks for your support and kind regards

 

Norbert

Link to post
Share on other sites
Donate and support the project!

17 hours ago, Nobby42 said:

Hi,

I have a problem with my NanoPi M4V2 (with Raspberry Pi 4 power supply) and the new Armbian release 19.11.3 (Buster). I can boot the image from SD, eMMC. But when I connect any USB storage (USB-Stick or SSD with USB to SATA) then I have packet lost on the Ethernet connection. Any idea where the problem is?
On the interface I can't see problems.

 

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.xx.36  netmask 255.255.255.0  broadcast 192.168.42.255

        inet6 fd58:xxxx:xxxx:1::1006  prefixlen 64  scopeid 0x0<global>

        inet6 fe80::94ad:f6ff:fe0d:757b  prefixlen 64  scopeid 0x20<link>

        ether 96:ad:f6:0d:75:7b  txqueuelen 1000  (Ethernet)

        RX packets 1475  bytes 231894 (226.4 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1088  bytes 129189 (126.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 24

 

Thanks for your support and kind regards

 

Norbert

Hi I have one of these boards and haven't noticed any degradation in signal ( but unless it was dropping the connection I wouldn't check ) do you have WiFi working on this Buster release?

Link to post
Share on other sites

Hello,

 

'openpvn' is still waiting and does not make new network interface. I suppose that a reason is missed TUN kernel module.


but manually I can make a TAP device
 

ip tuntap add mode tap dev tap0
root@nanopim4v2:/etc/openvpn/client# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether fe:0f:8e:36:d4:22 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 96:ad:f6:0d:75:7b brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.105/24 brd 192.168.100.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a0d5:e8e8:9ecf:42b3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether c0:84:7d:18:b0:6a brd ff:ff:ff:ff:ff:ff
6: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 3e:61:c0:43:ae:4a brd ff:ff:ff:ff:ff:ff
root@nanopim4v2:/etc/openvpn/client# openvpn --config client.conf

Jarek

 

PS: Armbian_19.11.3_Nanopim4v2_buster_legacy_4.4.192 has a very slow network (it is not usable)

Edited by SpringPeace Endy
Add next details
Link to post
Share on other sites

Some further observations of mine in case it helps identifying the problems using ethernet: After noticing that the throughput using the native ethernet connection (eth0) of the M4V2 is low, I checked it using iperf3. I tested the legacy kernel, the current kernel and the dev kernel. The results are quite interesting:

 

Legacy kernel: Can receive data via TCP  from anoter host with high speed (~940MBit/s) but the other way around is quite slow (<1MBit/s).

Current/dev kernel: Can send data via TCP to another host with high speed (~950MBit/s) but the other way around is quite slow (~3MBit/s).

 

Further information:

  • If I set the link speed to 10MBit half duplex there seems to be almost no packet loss that slows down the connection.
  • Using a USB3-ethernet adapter speed is good in both directions.
  • I did not care about WiFi. It's not connected.
  • There is a SATA hat attached to my NanoPi M4V2. Only power supply is used, no hdds are connected.
  • Of course I only have one device at hand, so I cannot guarantee that the behavior is representative.

Generally: If there is somebody working on further bringup of NanoPi M4V2 and needs somebody for testing, I'm happy to assist.

Link to post
Share on other sites
47 minutes ago, Matthias said:

Legacy kernel: Can receive data via TCP  from anoter host with high speed (~940MBit/s) but the other way around is quite slow (<1MBit/s).

Current/dev kernel: Can send data via TCP to another host with high speed (~950MBit/s) but the other way around is quite slow (~3MBit/s).

Thanks for verifying and sharing this valuable insights.

 

I never noticed / verified that for mainline kernels the issue exists but is opposite in direction.

Link to post
Share on other sites
On 12/12/2019 at 9:53 AM, SpringPeace Endy said:

Hello,

 

'openpvn' is still waiting and does not make new network interface. I suppose that a reason is missed TUN kernel module.


but manually I can make a TAP device

My apologies, openvpn client is working correctly, but this new version requires to add an option 'tls-version-min 1.0'.

BTW: It is strange that there was not any output

Link to post
Share on other sites

@Nobby42 @Matthias I hopefully fixed ethernet issues on legacy kernel in Armbian master. It works well on my unit.

The issue with USB drives borking ethernet are also gone.

Downloadable images were recreated.

 

I also verified current (5.4.6) kernel and it does not exhibit the problems with network bandwidth in either direction - it's a strong 930-940mbps in both directions.

Link to post
Share on other sites
13 hours ago, piter75 said:

@Nobby42 @Matthias I hopefully fixed ethernet issues on legacy kernel in Armbian master. It works well on my unit.

The issue with USB drives borking ethernet are also gone.

Downloadable images were recreated.

 

I also verified current (5.4.6) kernel and it does not exhibit the problems with network bandwidth in either direction - it's a strong 930-940mbps in both directions.

I can confirm your patched legacy-kernel can receive and transmit at about 930mbps. Good job, @piter75!

 

Unfortunately I cannot confirm high rates for receiving data using kernel 5.4.6 on my hardware. I used this image to test the current kernel: Armbian_19.11.4_Nanopim4v2_buster_current_5.4.6.img (downloaded from server, no local compilation)

Link to post
Share on other sites
10 hours ago, Matthias said:

I cannot confirm high rates for receiving data using kernel 5.4.6 on my hardware

@Matthias thanks for verifying that. Could you try to fiddle a bit with `rx_delay` setting on your M4V2 with current kernel?

 

The easiest and fastest way IMHO would be to add the following line to "/boot/boot.cmd" after "fdt resize 65536" line:

fdt set /ethernet@fe300000 rx_delay <0x0E>

rebuilding the boot script with:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and rebooting.

 

You could try "0x0E", "0x14" and then maybe "0x0C" and "0x16" and see if it helps to move your receiving rates into expected levels.

Link to post
Share on other sites
2 hours ago, piter75 said:

The easiest and fastest way IMHO would be to add the following line to "/boot/boot.cmd" after "fdt resize 65536" line:


fdt set /ethernet@fe300000 rx_delay <0x0E>

rebuilding the boot script with:


mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and rebooting.

 

You could try "0x0E", "0x14" and then maybe "0x0C" and "0x16" and see if it helps to move your receiving rates into expected levels.

 

Sure, I can do that. Thanks for the manual, looks quite straight forward. I was afraid I need to much "heavier" steps of the build process to check the different options. Just give me a day or two.

Link to post
Share on other sites

@piter75 I just tested the values for rx_delay you provided with kernel 5.4.6-rockchip64.

 

0x16 seems to be the best value for me, 0x14 offers a similar quality. You can find the details in the table below.

 

rx_delay Observation
0x0E No connection to device via SSH possible. Problems receiving data?
0x14 Receives data at ~ 930mbit/s, but on very rare occasions drops down to ~200mbit/s but then normalizes again
0x0C No connection to device via SSH possible. Problems receiving data?
0x16 Receives data at ~ 930mbit/s, seems to be more stable than 0x14
Link to post
Share on other sites
1 hour ago, piter75 said:

Thanks for verifying @Matthias!

I also verified that 0x18 still works well with my unit and then settled with 0x1

there's a tool to test this:

 

https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test

 

@tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind :P

https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3

https://github.com/armbian/build/issues/546

 

 

Link to post
Share on other sites

let me fix that...

4 hours ago, piter75 said:

Thanks for pointing that out. I did not know about it. Sometimes I feel like I know nothing  not everything

 

spotting this one (https://github.com/TinkerBoard/debian_kernel/commit/30a8401c2f3851f4e9b46c9d3e8e1138ce8d5b51) to fix camera support for the tinkerboard took me over a year... :ph34r:

it happens and when it happens it's IMO not something you should feel ashamed for. iperf3 (combined with a computer/sbc with known good settings) is a great tool to test this. But it's interesting that the settings work well on the legacy drivers but not on mainline.

Link to post
Share on other sites
56 minutes ago, martinayotte said:

Isn't that available since more than a year, at least in DEV ?

It is available in DEV indeed. I thought about bringing it into current kernel where it is missing.

 

16 minutes ago, chwe said:

it happens and when it happens it's IMO not something you should feel ashamed for

I am not. Sometimes I am just amazed at how much there is still to discover / learn ;-)

Link to post
Share on other sites

@piter75 Thanks. Now the ethernet workes and I can test the legacy kernel. With the 5.4.6 kernel I have a lot of problems. Sometimes the Pi crashes. I cannot verify the reason. I boot the Pi from emmc and rootfs on a SSD.
Looks like a problem with the USB SSD adapter but I am not shure. I use USB adapters with JM567 and ASM1153 chipset.

Link to post
Share on other sites
5 hours ago, martinayotte said:

Did you check the /sys/kernel/config/device-tree/overlays directory presence ?

It was not there on rockchip64-current.

I prepared a PR that adds it: https://github.com/armbian/build/pull/1699

 

1 hour ago, Nobby42 said:

Sometimes the Pi crashes. I cannot verify the reason. I boot the Pi from emmc and rootfs on a SSD.
Looks like a problem with the USB SSD adapter but I am not shure.

I am using similar setup but with NVMe hat and I would call it very stable.

One thing to mention is that I am using it as a server and not a desktop.

Link to post
Share on other sites
1 hour ago, piter75 said:

It was not there on rockchip64-current.

I prepared a PR that adds it: https://github.com/armbian/build/pull/1699

I've look about rockchip64-dev history from about 1 year ago, and apparently I've only added overlays, but not CONFIGFS like I did for meson64 around the same time. Simply that I've forgot.

Since you did a PR, it would be good to have the same patch also in rockchip64-dev ...

 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...