On Wed, 2020-04-08 at 10:17 +0200, Sebastian Reitenbach wrote: > Hi, > > > Am Dienstag, Februar 04, 2020 23:10 CET, schrieb Kurt Miller > <li...@intricatesoftware.com>: > > > > > On Mon, 2020-02-03 at 00:28 +0100, Sebastian Reitenbach wrote: > > > > > > Hi, > > > > > > I've two rock64 1 with 2GB memory, the other with 1GB memory. > > > Both with NetBSD-evbarm-aarch64-202001141930Z-rock64.img > > > as well as the one with 2GB on OpenBSD -current, have super > > > lousy network performance. Both are Rock64_V2.0 from 2017-0713. > > > It's connected to Gigabit switch. > > > > > > Related to it, I found this threat regarding similar bad > > > networking on Linux: > > > https://forum.pine64.org/showthread.php?tid=5043&page=4 > > > > > > so tried to set MTU to 1492 and also experimented with something > > > even much smaller, but to no avail, I can't successfully download > > > base66.tgz for example, it gets stuck after a few kb, until it eventually > > > gives up. > > > > > > ICMP pinging kind of works, about 5% packet loss. > > > > > > I also tried different media options, forcing to 100MBit full and half > > > duplex, > > > as well as 10MBit full and half duplex. Also tried to force the switch > > > down to > > > 100 MBIT or 10 MBit. The situation improves, for example, I get much more > > > of a base66.tgz downloaded, but it still gives up in the end. > > > > > > ifconfig dwge0 debug doesn't bring nothing new in dmesg. > > > > > > I don't think so but, can I disable rx/tx like they say in the Linux > > > thread using ethtool? > > > > > > Also this threat here talks about network problems with V2.0 board: > > > https://forum.pine64.org/showthread.php?tid=7545 > > > > > > In this threat here: > > > https://forum.pine64.org/showthread.php?tid=5712 > > > they play with values of allwinner,tx-delay-ps, maybe playing with > > > tx-delay in ./linux-4.20/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts > > > might help? > > > > > > Can I set this somewhere before booting, without the need to rebuild the > > > dtb package, > > > and recreate an image for testing? > > > > > > I even found this post: > > > https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ > > > where someone is fixing it by soldering on the board. > > > Before I go down that rabbit hole, anyone with working (gigabit) network > > > on the Rock64, which board version? > > I took a look at the links you posted. A few of them indicate that > > v2.0 board has an electrical issue as the root cause that was later > > fixed in the v3.0 board. You may want to consider adding the resistor > > as described by Sergey Anisimov in the last link. > just to report back: I finally got around to do the soldering, > afterward downloading a install67.iso without issues. > > so, soldering definitely helps.
That's great. Thanks for following up. The current options for Rock64 gen2 networking are to: 1) Downgrade to 100baseTX # ifconfig dwge0 media 100baseTX mediaopt full-duplex 2) Modifying the board as described here: https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ For Rock64 gen3 networking is solid without downgrading or modifying the board, however you will need to use u-boot from -current package v2020.04p0 or higher. Regards, -Kurt > blubb# ifconfig > dwge0 > > > dwge0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500 > lladdr 4e:a3:7d:d8:88:6b > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex) > status: active > inet 10.0.0.220 netmask 0xffffff00 broadcast 10.0.0.255 > blubb# netstat -I dwge0 > Name Mtu Network Address Ipkts Ifail Opkts Ofail > Colls > dwge0 1500 <Link> 4e:a3:7d:d8:88:6b 325652 0 202049 0 > 0 > dwge0 1500 10.0.0/24 10.0.0.220 325652 0 202049 0 > 0 > > cheers, > Sebastian >
