I don't know if there is even any setting or jumper available to change the boot on power-on behavior but it certainly boots up when powered. I tested this 4 times this week with unexpected power failures while using my laptop so I know it is back up in about a minute.
Edit: The issue with the R4S with the standard OpenWrt builds had been the inability to warm boot (reboot command). I initially tested the reboot command after doing a Luci initiated upgrade from an October snapshot to 22.03-rc1 and it didn't work but it worked today. Back passing traffic in about 24 seconds.
I'm sure further up in the thread there was a OpenWrt commit that fixed the reboot issue. They essentially restrict the UHS controller to 3.3v and thus a reset it will warm reboot. Downside is you lose the 1.8v highspeed mode but once you've booted from the SDCard you barely touch it again.
https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds He and other builds have the reboot patch included. At some point i must try out the bare OpenWrt build and see what patches need adding so we can bring some consistancy to the R4S builds. Part of the issue is FriendlyElec really should be making their patches available upstream (for the uboot stuff and the sdcard issue) and they have been bad about that. The OpenWrt team are right in that it should be properly upstreamed so they dont have to patch every little issue manually. Get your devices supported properly. Then port it in. It was also a similar problem for the 1gb/4gb issue.
The thing is that if you have applications like docker running from the SD card, the patch that was made for oficial openwrt is not ideal, at least according to @walmartshopper...
The guy in this video missed an important fact: he was using IPERF3 server on the WAN side, and client on the LAN side. Since IPERF3 by default send data from client to server, he is in fact testing upload. Client is always the sender by default. This can be reversed if the "-R" option is informed in the IPERF3 client command line.
This mistake does not fully invalidate the overall results, but nevertheless unless I missed something in the video the information he provided is not really accurate.
I've already purchased a NanoPI R4S, and when I receive it I will do a quick performance test with IPERF3 (similar to what I've done with the Redmi AX6S here).
good spot. Be interesting to know just how much this little monster can push. It was one my primary reasons for getting it tbh. When/if they roll fibre out here it would be nice to be able to get 1gb line
i've now finally finished my massive info post above. Sorry i was a terrible poster and ended up editing multiple times but i think i've fixed all the links now and gathered all the info up. Fixed the wiki links too.
Yes. loosing the 1.8v fast mode is a reasonable compromise, unless you are using a bigger card. However they do have a point. Currently they are forced to use that reset in order to have it recover from both a warm reset or a kernel crash. That is a much better situation to recover from rather than have it sat there hung from kernel crash and having higher speed sdcard. Its something that should be upstreamed and properly fixed. Sadly FriendlyElec are quite bad about that. But with the commit flagged there, people can have a choice to re-enable as they see fit. sort of a "you can do this but understand the issue ok?"
If you use either oficial openwrt or anaelorlinski build or immortal wrt, then by default their cpu affinity is throwing everything on cores 4 and 5 that are the 72 cores, since cores 0 to 4 are the a53 ones!
As you can see here:
They are setting up the irq of each eth on cores 4 and 5 with hex 10 and 20 respectively and are not setting up the queues with anything, which makes openwrt use hex 00 by default for the queues of both eth after booting and the result is that openwrt will throw the queues also on cores 4 and 5 together with the IRQ.
Just do:
cat /sys/class/net/eth0/queues/rx-0/rps_cpus
cat /sys/class/net/eth1/queues/rx-0/rps_cpus
And the result will be 00.
And this is not optimal tbh, cause you can easily saturate a dual core system in my opinion!
I have a 500/250 connection and bellow we have a torrent without sqm:
But there are plenty of ways to spread the load to all 6 cores of the NanoPi R4S!
There is the automatic way, that is enabling Package Steering + Irqbalance(package that you install and enable too).
There is the manually way, where you manually spread the load yourself ! I prefer to do it manually, as many others also confirm that manually is always better than using irqbalance.
I am going to the affinity file and doing like the print screen above, in other words, the red arrows are the IRQ and the blue arrows are the queues! In this case the irq of eth0 is using core 4(hex 10) and the irq from eth1 is using core 5(hex 20) and the queues are using all 6 cores with hex 3f.
Now after a reboot, if i do:
cat /sys/class/net/eth0/queues/rx-0/rps_cpus
cat /sys/class/net/eth1/queues/rx-0/rps_cpus
The result will be 3f.
By doing this way using this file, the change is permanently and you dont need to dedicate anything else just to make it like that, like a script that executes at boot or using rc.local and etc.
Now with this setting we have the result for a torrent wihtout SQM:
The beauty of doing it manually is that you can do it the way you want! This above is just an example , you can also try another way like dedicating the a72 cores for the queues and the a53 cores for the IRQ.
You can selected the cores by using different hex, as explained here:
and
Just keep in mind that the queues will spread with the correct hex like 3f = 111111 to as many cores as you like, but the IRQ won't! They stick to one core for each IRQ for each eth, so you cant spread them to more than 2 cores...
I'd prefer it as a separate script you could add in that you copy over as it is a change from the default settings that are provided. That way we know out of the box to expect "x" setting and we can edit/change for our settings. Would you copy yours to the wiki? It was one of the reasons i put wallmarts post into the wiki for others to tinker with.
From the 40-net-smp-affinity and reboot, then everything goes back to default.
So i still think that changing this file is the best way of doing things, cause then you dont have anything extra doing anything or needing to be executed or hogging any resources even if its minimal!
And for testing you can do you on the fly, just need to use the commands:
PS: For kernel 5.15 need to use: echo -n hex > /proc/irq/IRQ-NUMBER/smp_affinity
In shell while running your system and then execute like a speedtest, torrent and etc, that way you will see the immediate results and after the testing you go to the 40-net-smp-affinity and change it to the settings you liked the most.
PS: If changing SQM settings(like enable or disable), then the commands in shell for testing on the fly should be done after setting up SQM and not before! In other words, setup sqm first and then do the commands in shell and after that check the results.
Give me a few. i'm just having a look to re-write it. i think maybe expanding the section to do a general "this is how to set things" and then a "put this here for permanent fix"
Also wondering if to just break it out to else where on wiki as well. as its a more general thing that could be used for other cpus.
(edit) I now have coffee and a quick google shows me the page doesnt exist. I'm going to re-write it all and thus it can be used for any multicore cpu. Question is where to link it. I think initially on the irqbalance page but it should have its own page. and then be cross referanced.
break it into the "how" and "why" and then a permanent "put in this file for persistance" setting.
Yeah it's a tradeoff for sure. You either have to choose slower SD card speed and guaranteed reboot, or faster SD card speed and manual reset after a kernel panic. My use case of running docker applications from the SD card is probably not very common, so it makes sense that the official patch went with slower SD and guaranteed reboot. Most people are only running OpenWrt from the SD card and don't need the extra speed.
On the other hand, I have never seen a kernel panic happen on this or any other OpenWrt devices ever. If I was setting up an R4S at a remote location, I would go with the official patch. But for my home router where I can easily do a manual reboot, it's worth the risk.
Another thing that i forgotten to mention, is that the file 40-net-smp-affinity can be changed before building a new img, in other words, you can setup it the way you like it and make a new build!
The moment you boot that new build the affinity will be working the way you setup it in the file before building
Well, you can check the new patchs that friendlywrt added to their repo, just like i shared above and @Barrakketh said:
They seem to have 2 new patches that are related to the UHS situation and reboot panic, now if they are better or worse than the oficial patch being used in openwrt or the original fix done in immortalwrt, that i honestly dont have a clue about!
Cause i am not an experienced dev yet(maybe in the future xD) so i still cant tell which one is better from these kinda of advanced stuff.
Would be nice if we can make either friendlyelec upstream all the new and better or important patch's for the R2S\R4S to openwrt oficial!
Or if its possible for someone independent who is an experienced dev to make their mission to fix this inconsistency of patch's that exist between friendlywrt and oficial openwrt for the R2S/R4S by making PR's and stuff...
I think this is even more important now, since it seems that there are new and important patches missing in official openwrt for the R2S\R4S.
I'm just a web dev with no experience in kernel / uboot stuff, but as far as I can tell, it looks to me like those two friendlywrt patches just disable UHS mode like the official OpenWrt patch. I think one of the patches adds a new flag that allows disabling high speed mode for any rockchip device, and the other patch adds that flag to the R4S. The official OpenWrt patch just explicitly disables it for the R4S. I guess the friendlywrt solution is a bit cleaner because you could disable high speed mode for other devices just by adding the flag, but for the R4S the end result would be the same.
I could be wrong in how I read the patches, but for now I'm going to continue using the immortalwrt patch that leaves high speed enabled.
I agree we need somebody trying to upstream some of these patches if friendlywrt isn't going to. I would consider doing it but I don't feel qualified. All I would be able to do is cherry pick patches that work well for me and submit them as-is upstream. But I wouldn't be able to actually review them or contribute to any discussion about the quality of the code or fixes needed to get accepted upstream.
I have NanoPi R4S, R2C, and Orange Pi R1 Plus. The R2C and R1 Plus are in a similar situation. They are not officially supported, but it's fairly easy to cherry pick a handful of patches from friendlywrt and do a stock openwrt build. Both devices have a PR open for official support, but they are both stuck open with not enough reviewers to get them merged.
! I prefer to do it manually, as many others also confirm that manually is always better than using irqbalance.