On Thu, 2020-05-28 at 12:52 -0700, Lear Zhou wrote: > It’s weird that I bought 2 batches of Rock64 v2, and have > Ethernet trouble only with the first one, not the second batch. > > The second batch marked as ‘Rock64 V 2.0, 2017 - 0713’, > cannot check the first one which was put in a case.
My V2 board is marked the same as yours but exhibits the networking issues. Seems like the V2 boards should be avoided in favor of the V3. As an aside, I never intended to purchase the V2 board but due to AmeriDroid's poorly described website at the time (since been fixed), I received a V2 board when I was intending on purchasing a V3 board. Their customer service follows a 'customer is always wrong' approach to problems, so buyer beware. > Lear Zhou > > On Thu, May 28, 2020 at 11:58 AM Kurt Miller <[email protected]> > wrote: > > > > > On Wed, 2020-04-08 at 10:17 +0200, Sebastian Reitenbach wrote: > > > > > > Hi, > > > > > > > > > Am Dienstag, Februar 04, 2020 23:10 CET, schrieb Kurt Miller < > > [email protected]>: > > > > > > > > > > > > > > > > > > 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 > > > > >
