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. > For the time being, I've a USB-Ethernet converter, that does the to get > OpenBSD > installed, but still would be nice if there would be a way to make GigaBit > interface > working, so any ideas to pursue are welcome. > > OpenBSD 6.6-current (GENERIC.MP) #443: Thu Jan 30 21:47:12 MST 2020 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 2080894976 (1984MB) > avail mem = 1986916352 (1894MB) > mainbus0 at root: Pine64 Rock64 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 256KB 64b/line 16-way L2 cache > efi0 at mainbus0: UEFI 2.8 > efi0: Das U-Boot rev 0x20200100 > apm0 at mainbus0 > psci0 at mainbus0: PSCI 1.1, SMCCC 1.1 > syscon0 at mainbus0: "syscon" > "io-domains" at syscon0 not configured > syscon1 at mainbus0: "power-management" > rkclock0 at mainbus0 > rkclock_set_frequency: 0x00000145 > rkclock_set_frequency: 0x00000045 > rkclock_set_frequency: 0x0000003e > rkclock_set_frequency: 0x000000e5 > rkclock_set_frequency: 0x00000092 > rkclock_set_frequency: 0x000000dc > rkclock_set_frequency: 0x00000061 > ampintc0 at mainbus0 nirq 160, ncpu 4 ipi: 0, 1: "interrupt-controller" > rkpinctrl0 at mainbus0: "pinctrl" > rkgpio0 at rkpinctrl0 > rkgpio1 at rkpinctrl0 > rkgpio2 at rkpinctrl0 > rkgpio3 at rkpinctrl0 > "fit-images" at mainbus0 not configured > "opp_table0" at mainbus0 not configured > "arm-pmu" at mainbus0 not configured > agtimer0 at mainbus0: tick rate 24000 KHz > "xin24m" at mainbus0 not configured > com0 at mainbus0: ns16550, no working fifo > com0: console > rkiic0 at mainbus0 > iic0 at rkiic0 > rkpmic0 at iic0 addr 0x18: RK805 > "spi" at mainbus0 not configured > simplebus0 at mainbus0: "amba" > "dmac" at simplebus0 not configured > dwmmc0 at mainbus0: 50 MHz base clock > sdmmc0 at dwmmc0: 4-bit, sd high-speed, mmc high-speed, dma > dwmmc1 at mainbus0: 50 MHz base clock > sdmmc1 at dwmmc1: 8-bit, mmc high-speed, dma > dwge0 at mainbus0: address 7a:ff:31:d6:7e:bb > rgephy0 at dwge0 phy 0: RTL8169S/8110S/8211 PHY, rev. 6 > ehci0 at mainbus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci0 at mainbus0: version 1.0 > "usb" at mainbus0 not configured > "external-gmac-clock" at mainbus0 not configured > "sdmmc-regulator" at mainbus0 not configured > "vcc-host-5v-regulator" at mainbus0 not configured > "vcc-sys" at mainbus0 not configured > "dmc" at mainbus0 not configured > "usb" at mainbus0 not configured > cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 > cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu1: 256KB 64b/line 16-way L2 cache > cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 > cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu2: 256KB 64b/line 16-way L2 cache > cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 > cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu3: 256KB 64b/line 16-way L2 cache > usb1 at ohci0: USB revision 1.0 > uhub1 at usb1 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > sdmmc1: can't enable card > scsibus0 at sdmmc0: 2 targets, initiator 0 > sd0 at scsibus0 targ 1 lun 0: <SD/MMC, EB1QT, 0030> removable > sd0: 30528MB, 512 bytes/sector, 62521344 sectors > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > bootfile: sd0a:/bsd > boot device: sd0 > root on sd0a (bc3b5c1485137e4a.a) swap on sd0b dump on sd0b > WARNING: preposterous clock chip time > WARNING: CHECK AND RESET THE DATE! >
