Hi,
I bought a Rock Pi 4B+ a few days ago (Version 1.72)
When using ethernet (with DietPi), the speeds are soooo slow.
I could connect the board using wifi, to get all the apt packages updated, but when I try to do this on ethernet: Timeouts, disconnects, all sorts of problems… (I couldn’t get APT updated, which is why I switched over to using Wifi)
When I try to to a speedtest with the ethernet, I get a download speed of 0.09 Mbps
Any idea what could be wrong?
The ethernet phy is changed from RTL8211E to RTL8211F, I believe the tx/rx delay change will cause the mainline kernel ethernet issue. We will check this.
I have tried:
Ubuntu Server (Radxa image mentioned on Rock Pi 4 page) --> Not working
Armbian (Radxa image mentioned on Rock Pi 4 page) --> Not working
DietPi (with latest kernel) --> Not working
TwisterOS (Downloaded from TwisterOS website) --> Not working
Right now I’m using Manjaro (5.15.11.1-MANJARO-ARM) --> Not working
I tried iperf3, and the speed is fine there (~ 900 Mbps) - But no luck when trying to upgrade packages/APT/pacman/… (Timeouts, etc.)
Not sure what could be the cause (Wifi works fine, it’s the only way I can install additional packages)
Could it be a hardware issue with the board?
@igorp - I understand your frustration, and appreciate what you guys are doing at armbian. I also read your post there, and I understand that the manufacturers for hardware don’t update their drivers in linux kernels. -> Kudos to you for trying to support all that “old” stuff.
But: I’m looking to get my board up and running. (Since this board is still being sold (I bought it a week ago) - I assume there must be some kind of (older) image version that I can use that does simply just work and that is stable - I assume Radxa tested their board with some kernel/image)
This is my first SBC, and I don’t feel like paying someone to fix the bugs in the “latest” kernel versions. I feel like getting my board up and running (with an older kernel, if need be)
If there is no way to get it running (on an older kernel/image) I will just send the board back and switch to one that is more “openly” supported (You know which one).
At this point, I’m not sure if it’s a kernel problem - or a hardware problem. That’s what I’m trying to figure out here. (By trying an “old” kernel and go from there)
I am. And I know exactly what is wrong and what choices you have.
No, you can’t find old image that will just work stable since chip is new and there is no (proper) support for it in the kernel.
Well, I’ll be sure to make my choice then. Thanks for the help! 
That’s strange, I also bought the 4B+ v1.72 a couple of weeks ago and had no problem with the eth port, iperf gave me over 200Mb/s.
On the other hand wifi is pretty bad, i’m looking to buy an external antenna.
I’m using the official Debian Buster from radxa by the way.
Yeah, in the official builds from Radxa it works fine it seems.
@ccarneiro - Did you succeed in booting from the NVME? (What happens when you try a ‘reboot’ / warm boot)
Any news on this issue?
I think I’m running into the same problem with a Rock Pi 4B+ 1.73 with mainline uboot (v2023.01)/kernel (v5.15.88) and Debian Bullseye.
Does anybody have a clue what’s different in the old radxa images that makes ethernet work?
Did some more digging: I flashed an old (known-working) image that uses U-Boot 2017.09-00022-gf18abd08ab-dirty (Aug 29 2022 - 14:20:35 +0200) and simply replaced both boot and root partitions with my own Kernel (v5.15.88) / Bullseye rootfs. In this configuration ethernet works as expected.
So this seems to be an U-Boot issue and not a mainline kernel issue.
That’s the cause for the issue. I set rx_delay = <0x20> in arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi (taken from [1]). With this change applied the Ethernet issues are gone.
Since upstream U-Boot uses almost the same rk3399-rock-pi-4.dtsi I think the patch could also have been applied there. My theory is that in the old Radxa-Images the U-Boot dts got patched. During the boot process U-Boot writes the correct delays to the MAC registers and thus correctly initializes the MAC. So even with an incorrect Kernel dts the problem is gone. I didn’t do any further testing in this regard, so this might not be the correct explanation for my observations I made earlier.
@jack @igorp I’m wondering where this particular value of 0x20 for the RX delay comes from. I was not able to get my hands on any datasheet/documentation that further describes this value. Furthermore I’m curious if this change can be upstreamed in a way that works for all rock-4b boards.
Usually from experimenting.
In case this is useful for someone: if the dtc binary is present (e.g. on armbian), then this is fixable without compiling code. The following converts the device tree blob to source, applies the correction, then converts it back to blob:
dtc -I dtb -o rk3399-rock-pi-4b-plus.dts rk3399-rock-pi-4b-plus.dtb
nano rk3399-rock-pi-4b-plus.dts
Now find the line with rx_delay and correct its value to 0x20, then save. Convert back:
dtc rk3399-rock-pi-4b-plus.dts -O dtb -o rk3399-rock-pi-4b-plus.dtb
Ensure /boot/armbianEnv.txt references the correct dtb file. The dtb file should be in /boot/dtb/rockchip/.
Linking from this similar topic:
Recommended values are 0x2a 0x21 as per Realtek specs, and there is a PR on Github. Once merged this should be fixed for all of us.
Thanks for providing the fix. For those who can’t use the dtb trick you can have a cronjob @reboot as a workaround:
@reboot echo 0x2a 0x21 > /sys/class/net/eth0/device/driver/fe300000.ethernet/rgmii_delayline