I think some of the community builds use different ethernet drivers for one or more of the wired interfaces, at least on the R4S. There might be an unusual interoperability issue with link negotiation on the wired connection between your WAP and port on your R5 running official OpenWrt. It could be more involved if you use a power injector in between.
Check the actual link speed and duplex at both ends and also look at ethernet error counters at both ends to see if there is an indication of issues.
Check that the wifi link quality stays consistent between tests. Is the link mcs index the same? Is the snr staying consistent? Keep the pc in the same position and orientation. Keep the RF environment as constant as possible, like position and usage of potential rf emitters like cell phones, cordless phones, TVs, motors (like air conditioners), etc.
I did notice that friendlywrt uses the r8125 kernel module for the 2.5 GBe NICS, while the community builds use r8169. Are there any differences between the two? The former shows a Realtek copyright notice in dmesg, suggesting that it's some kind of proprietary driver that's being used.
I have already looked at some of the link speed negotiation settings you mentioned, but I'll do some more thorough testing and get back to you.
I think I have tried with/without packet steering and software offloading, but let me double check. Some of the omada access points have ipv6 broken in their firmware, so IPV6 is disabled for everything I do
Both sides of the link to the WAP and the NanoPi are at Full Duplex 1000Mbps.
Flow control was disabled on the switch. Enabling it on both ports shows no difference.
The wifi link speed to the laptop running the test is over 1000Mb/s. 1200 Mb/s is the highest that is supported by the WAP I think (802.11 ax). It varies between 1000 and 1200 depending on the signal I think. I am sitting <5 ft from the router. The WAP is running of PoE off the switch directly. No Injectors.
I might have jumped the gun a bit with my reporting here. I installed immortalwrt 23.05 snapshot that had kmod-r8125 as one of the packages in it and it looks like I'm getting the same speeds as the friendlywrt builds.
This is potentially suggesting that the issue is with the r8169 driver. I'm probably going to stick to this build for a while, but it's concerning that there are almost no other reports with the open source driver.
If anyone has any other hints as to what may be going on, please do let me know.
When I install another non FriendlyElec's Debian OS on my R6S, the r8169 driver didn't work for the 2.5G NICs, I have to use r8125 and blacklist r8169 to make it work in my setup.
i've bought an R5C to use as AP+STA "mixed" mode. It seems to not work in this mixed mode.. once i connect to my hotspot, i try to create the AP network and it stays in disabled mode (in case of 2.4ghz) or it loops on and off in 5ghz mode. I tried to install the Openwrt snapshot (the only one which supports R5C right now) in place of FriendlyWRT, but it does not see wireless at all. I also tried to plug a usb wifi dongle in one of the usb ports, although it sees dual wireless, setting one STA and one AP is no go, just like only one card.
Any ideas?
I'm in the same boat as @aricade And not getting hdmi output and can't figure out how to get it to work when building. If I install friendlywrt, hdmi works fine. I've also tried images from mj as @foggygray posted and hdmi doesn't work there either. I've just been using the webui terminal for things but worried for the day I can't access the webui. This is on release 6.1.61 from mj22226.
dd if=/dev/zero of=/dev/mmcblk2 bs=8M count=1 //Clear the Loader on the eMMC
The Boot order between eMMC and SD card
By default, the system will be booted from the TF card first, but this is not the case under all conditions. This section will explain all situations in detail;
Refer to rockchip official document [1], there are two types of loader program:
U-Boot TPL/SPL (i.e. upsream U-Boot, also called mainline U-Boot)
Rockchip MiniLoader
Things to note:
FriendlyELEC's image uses Rockchip MiniLoader
The third-party image usually uses U-Boot TPL/SPL
The following situations will always start from eMMC:
If the system in the eMMC, or the system in the TF card uses the first Loader type U-Boot TPL/SPL, it will always boot from the eMMC;
If you want to boot from the TF card, there are the following methods:
Method 1: Clear the Loader on the eMMC, the clearing method is as follows, after starting from the eMMC, enter the following command on the command line to clear the Loader on the eMMC:
dd if=/dev/zero of=/dev/mmcblk2 bs=8M count=1
Method 2: Insert the TF card, Press Maskrom Key (or short-circuit the Maskrom contacts) and then power on (need to keep the short-circuit for about 3 seconds), it will start from the TF card
A few days at most based on past cycle time. Plus 6.1 kernel on other rockchip targets.
The R5C and R5S have some interesting features - decently fast CPU, 2.5G ports, M2 slot, WiFi capability, reasonable cost. I'm excited to see them supported.
Snapshots are here! Fantastic news!
Just downloaded and booted an R5S off an SD card and... no screen support. I tried to use imagebuilder to build a new image including kmod-drm (hoping it would add screen support) but the build fails with "cannot find dependency libubox20231128 for mtd". Looks like the packages have not been updated yet. I also tried contacting the device through all ports and got no signs of life. Will try again in a day or two.
Yep - cant' recall where, but I do recall that the OpenWrt support did not include HDMI and video driver support. For a router only O/S....seems like that is not going to be top priority, but maybe someday.
