But it was merged as testing kernel, so you either need to change it in the make file in target->linux->rochchip or use menuconfig to set your build to use the testing kernel.
There is another PR that is going to switch to kernel 5.15 instead of adding it as a testing kernel for master builds(snapshots):
This "new" PR also fix issues with the original one that was causing boot problems. So its best if you are going to try to use kernel 5.15, to merge these changes of the new PR first to avoid boot issues.
So to you use kernel 5.15, you need to do a custom build + merge the changes of the new PR + change the build to use kernel 5.15.
If you plan on waiting then you will have to wait maybe a long time? Cause like I've shown here, it takes a long time before rockchip changes get merged.
Thanks! Yes I meant not in the test kernel because I don’t want to make a build myself every time there’s a new one, I don’t have hurry, I’m just curious! What are the benefits for the R4S with the 5.15 instead of 5.10?
We’ll it is the new features/enhancements coming with 5.15 plus some R4S patches got upstreamed (= directly implemented in the kernel), thus one could drop some patches. Generally I’d say R4S support improved, although for the general case I would doubt you feel any material difference.
I have been following this post on the forum and I have seen that you have great knowledge in R4S, I would like to ask you for some help.
My R4S with "OpenWrt 21.02.1 r16325-88151b8303" has very high latency compared to other devices. Even performing a ping to localhost the latency is between 0.200 ms and 0.400 ms. Testing on other devices is around 0.050 ms, which I find strange because the R4S is a powerful device.
When I perform a ping to the next hop after the WAN or LAN, the ping is above 1 ms, I believe this should be smaller too, since the network is wired.
For one user running FriendlyWRT, yes. I've had no such issues. If you try it and find the same, a) that would be a very useful data point and b) it is trivial to reverse.
This is not the R4S, it's OpenWrt, when I ping from one RaspberryPI to another I have about 0.2ms, when i ping from RaspberryPI to the R7800 or R4S, latency is about 0.4/0.5ms
192.168.1.2 = R4S
192.168.1.3 = R7800
192.168.1.5 & 6 = other RPis inside the LAN
root@Pi-Hole:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.560 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.471 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.531 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.222 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=0.476 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.483 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=0.479 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.528 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.514 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.473 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=0.475 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=0.467 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=0.505 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=0.512 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=0.491 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=0.459 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=0.470 ms
64 bytes from 192.168.1.2: icmp_seq=18 ttl=64 time=0.463 ms
64 bytes from 192.168.1.2: icmp_seq=19 ttl=64 time=0.513 ms
64 bytes from 192.168.1.2: icmp_seq=20 ttl=64 time=0.533 ms
64 bytes from 192.168.1.2: icmp_seq=21 ttl=64 time=0.480 ms
^C
--- 192.168.1.2 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20466ms
rtt min/avg/max/mdev = 0.222/0.481/0.560/0.063 ms
root@Pi-Hole:~# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.510 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.448 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.405 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.467 ms
64 bytes from 192.168.1.3: icmp_seq=5 ttl=64 time=0.477 ms
64 bytes from 192.168.1.3: icmp_seq=6 ttl=64 time=0.434 ms
64 bytes from 192.168.1.3: icmp_seq=7 ttl=64 time=0.403 ms
64 bytes from 192.168.1.3: icmp_seq=8 ttl=64 time=0.411 ms
64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=0.420 ms
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=0.426 ms
64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=0.455 ms
64 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=0.434 ms
64 bytes from 192.168.1.3: icmp_seq=13 ttl=64 time=0.448 ms
^C
--- 192.168.1.3 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12291ms
rtt min/avg/max/mdev = 0.403/0.441/0.510/0.029 ms
root@Pi-Hole:~# ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=0.268 ms
64 bytes from 192.168.1.5: icmp_seq=4 ttl=64 time=0.212 ms
64 bytes from 192.168.1.5: icmp_seq=5 ttl=64 time=0.258 ms
64 bytes from 192.168.1.5: icmp_seq=6 ttl=64 time=0.206 ms
64 bytes from 192.168.1.5: icmp_seq=7 ttl=64 time=0.240 ms
64 bytes from 192.168.1.5: icmp_seq=8 ttl=64 time=0.252 ms
64 bytes from 192.168.1.5: icmp_seq=9 ttl=64 time=0.220 ms
64 bytes from 192.168.1.5: icmp_seq=10 ttl=64 time=0.256 ms
64 bytes from 192.168.1.5: icmp_seq=11 ttl=64 time=0.281 ms
64 bytes from 192.168.1.5: icmp_seq=12 ttl=64 time=0.235 ms
64 bytes from 192.168.1.5: icmp_seq=13 ttl=64 time=0.234 ms
^C
--- 192.168.1.5 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12279ms
rtt min/avg/max/mdev = 0.206/0.238/0.281/0.022 ms
root@Pi-Hole:~# ping 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_seq=1 ttl=64 time=0.249 ms
64 bytes from 192.168.1.6: icmp_seq=2 ttl=64 time=0.331 ms
64 bytes from 192.168.1.6: icmp_seq=3 ttl=64 time=0.236 ms
64 bytes from 192.168.1.6: icmp_seq=4 ttl=64 time=0.259 ms
64 bytes from 192.168.1.6: icmp_seq=5 ttl=64 time=0.242 ms
64 bytes from 192.168.1.6: icmp_seq=6 ttl=64 time=0.244 ms
64 bytes from 192.168.1.6: icmp_seq=7 ttl=64 time=0.338 ms
64 bytes from 192.168.1.6: icmp_seq=8 ttl=64 time=0.230 ms
64 bytes from 192.168.1.6: icmp_seq=9 ttl=64 time=0.238 ms
64 bytes from 192.168.1.6: icmp_seq=10 ttl=64 time=0.248 ms
^C
--- 192.168.1.6 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9198ms
rtt min/avg/max/mdev = 0.230/0.261/0.338/0.037 ms
root@Pi-Hole:~#
Just remove the lines you added to /etc/rc.local and reboot again.
Or, if you don't want it to be permanent at all, just ssh in and execute the three lines by hand. It'll stick until the next reboot (intentional or otherwise).
I'm running OpenWRT snapshots in a nanopi r4s 4GB, but this week in the recents snapshots, when I reboot the nanopi sometimes the lan port is not recognized, maybe the issue was always present, but this week is more frequent, in the update log from:
I using the nanopi r4s since June 2022, always compiling my own image, once every two weeks or more frequently if the commits show something interesting as new kernel version, from snapshots,
and I'm using the test kernel 5.15,
and always wrote the image from the nanopi, and sometimes failed to boot from the new image, but in this week wrote two images, different snapshots, from the nanopi and the two failed to boot, but I was able to ssh and the lan port didn't come online, so I have to reboot the nanopi many times until the eth1 comes online.
so I found that the issue was resolved, but I'm unable to find the commit to test
I have an R4SE and it works fine with vanilla OpenWRT. I did have to zero the loader on the eMMC, as described in the R4SE documentation, before it would boot the SD card though:
This is good to know as I just ordered an R4SE and expect it in hand tomorrow. When you say "vanilla OpenWRT" are you specifically referring to a vanilla snapshot build?
