Jump to content
  • 0

NanoPI 4MV2

Nobby42

Asked by Nobby42,

 Share

Question

Nobby42

Nobby42

Posted
Posted

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 comment
Share on other sites

48 answers to this question

Recommended Posts

Donate your old hardware to community. Start a giveaway Raffle!

  • 0
pkfox

pkfox

Posted
Posted
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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
On 12/10/2019 at 8:09 PM, Nobby42 said:

Can anyone reproduce the problem with the 4.4.192 kernel

I verified and can confirm there are issues with networking on 4.4.192.

LAN is not working well and WLAN cannot connect to AP.

 

I will look into fixing that but no ETA guaranteed ;-)

Link to comment
Share on other sites
  • 0
SpringPeace Endy

SpringPeace Endy

Posted
Posted (edited)

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 comment
Share on other sites
  • 0
Matthias

Matthias

Posted
Posted

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.

1
Link to comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
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 comment
Share on other sites
  • 0
SpringPeace Endy

SpringPeace Endy

Posted
Posted
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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted

@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 comment
Share on other sites
  • 0
Matthias

Matthias

Posted
Posted
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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
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 comment
Share on other sites
  • 0
Matthias

Matthias

Posted
Posted
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 comment
Share on other sites
  • 0
Matthias

Matthias

Posted
Posted

@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 comment
Share on other sites
  • 0
chwe

chwe

Posted
Posted
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

 

 

1
Link to comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
8 hours ago, chwe said:

there's a tool to test this

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

 

Anyway, this reminded me that I need to add a patch with dynamic overlay support for rockchip64 in current target.

Link to comment
Share on other sites
  • 0
chwe

chwe

Posted
Posted

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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
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 comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
6 minutes ago, piter75 said:

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

Looking at kernel configs, it seems to be there ...

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

Link to comment
Share on other sites
  • 0
Nobby42

Nobby42

Posted
  • Author
Posted

@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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
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 comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
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 comment
Share on other sites
  • 0
piter75

piter75

Posted
Posted
22 minutes ago, martinayotte said:

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

The patch is not needed in rockchip64-dev as it is already incorporated in ayufan's kernel sources we use for dev target.

That's why it's being added to current target only with my PR.

Link to comment
Share on other sites
  • 0
martinayotte

martinayotte

Posted
Posted
8 minutes ago, piter75 said:

The patch is not needed in rockchip64-dev as it is already incorporated in ayufan's kernel sources we use for dev target.

That's why it's being added to current target only with my PR.

Right ! I was continuing searching, and figured out that it was even present in his old branches, such as 5.3.0-rc4-1118-ayufan or even very old one 4.20.0-1090-ayufan.

And I've just figured out that "current" is not pointing to an ayufan branch anymore  ...

 

Also, it seems that @ayufan is busy elsewhere since he didn't create a 5.5.y branch yet ... :( (and his last commit was done on Aug 13th)

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept