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.

Lear Zhou

On Thu, May 28, 2020 at 11:58 AM Kurt Miller <k...@intricatesoftware.com>
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 <
> 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
> >
>
>

Reply via email to