NanoPi R4S-RK3399 is a great new OpenWrt device

Two questions I have:

  1. Have somebody looked into the HW watchdog device? According to datasheet RK3399 has one but I can't find much more info.
  2. Have somebody looked into the hardware sensors? I see a few devices on i2c bus (1B, 40, 41 @ bus 0 and 51 @ bus 1) but I have no idea what are they.

Hi,

I have problem when booting the last snapshot build:

  • ssh to NanoPI R4S is not working (over LAN interface)
  • LAN LED is powered off (it looks like something with eth1 card is wrong)

I saw recently some Realtek driver commits, but I am not sure what is causing problems.
Last successful build is with kernel 5.15.107, r22599-1416b9bbe9, from 2023-04-19.

This commit has fixed this issue

1 Like

Hi @xiaobo,
Thanks for information.
It is working OK with the latest snapshot build r22651-8f427f1a05.

Just to report that I had a weird update to 22.03.4. I've compiled the new build as usual, then I upgraded the R4S, all the leds were okay but the device was offline, I tried to reboot it, nothing. So I flashed again the microSD with the "stock to OpenWrt squashfs", then I updgraded it with my custom 22.03.4 build, and it worked, I re-imported the backup and now all is perfect.

I don't understand why a straight upgrade from .3 to .4 didn't worked, but just in case if the same happens also to somebody else, there's the workaround/fix.

1 Like

Hi, I'm thinking about buying one of theese for OpenWRT use. Are there speed tests with NAT and pppoe? I suppose it is very much able to handle gigabit routing.

in youtube, this video:

OpenWRT - NanoPi R4S Overview & Performance Test (NAT, OpenVPN,Wireguard, iPerf)

You suppose correctly. There are few OpenWrt supported low power usage 1 Gb ARM options faster than the R4S.

A Raspberry PI 4B may be faster if an application can actually make use of all four of its A72 cores (versus "only" two A72 cores on the R4S along with its four A53 cores), but even assuming you can find and afford one, you'll still need to add a case and USB to serial dongle to the PI4B, just to have what already comes with the R4S.

The NanoPi R5S and R6S are not supported by OpenWrt yet, but may be in future. However the R5S CPU is actually slower than the R4S despite its 2.5G ports. And while the R6S CPU is faster, the R6S is so expensive that a fanless Intel N5105 router box with more ports, or cobbling together a custom build with a used x86 thin client start to look like better options for > 1Gb ports.

4 Likes

Agreed. The R6S is way to expensive and the R4S is fast but getting old.
The R5S would have been sweet if it had the processors from the R4S.

Just to report that I had to do the same to upgrade from .4 to .5 yesterday! I have no idea of why... I suspect is something related to the custom size of the root image (from 100Mb to 30Gb).

If someone have an idea it would be great, reset all and re-write the minisd every time I need to upgrade is a bit annoying.

I really don't consider the R6S expensive given its capability. Issue is really that it's not officially supported by OpenWrt that's the red flag for me. I've heard there is some upstream issues with support, hopefully it happens. The R4S remains a great option though.

FriendlyWRT is not bad, and you could always fork it and customize it.

There have been some security issues mentioned concerning FriendlyWrt that may or may not matter to you.

Aside from the R6S the R6C is the budget version and the newly NanoPc T6 look very interesting too. OpenWrt can run on these devices if you fork @mj82 repo NanoPi R6S & Linux 6.3 ARM SoC Updates - #15 by mj82 or grab the the patches and apply them on the top, I did a build for my R6C last night and everything is working.

1 Like

FriendlyElec has a newer kernel already, but I agree that having official upstream support should be the best way to go. While I saw from kernel git that NanoPi R6S RK3588 already has more usable features in 6.3, so I am expecting something official might come out next year.

Those NanoPi are selling over priced when you buy them from overseas channel.
Since I speaks Chinese so I was able to order R2S/R4S/R6S at much lower price (e.g. R6S at 40% off when compared with Amazon) from their China selling channel directly (I don't live in greater China region, but they can ship me). I am looking forward to the R6C because I can get it with USD80, given the power consumption and the size I really like them (and I plan to use R2S + USB WiFi to form a travel router combination)

1 Like

The problem isn't the upgrade, is a bug in the nics initialization. sometimes at reboot the nics don't show up

see https://github.com/MichaIng/DietPi/issues/6342

so you need to unplug/plug the nanopi several times until the nanopi gets right the nics, you don't need to rewrite the sdcard the first upgrade is good, the problem belongs with the nics

Gabrielo

1 Like

Hi, I think this is a different unrelated topic. One is losing the partitioning after a sysupgrade and the other you linked is about sporadic ethernet device naming issue after reboots. The latter seems to be related to 5.15 kernel. I have not experienced it with 5.10 yet which is in the standard release.

Yes usually (I mean with some other releases) it was like you said: plug-in the power cable 1-2 times and the R4S started to work again but not after the 22.03.3.

I tried 2-4 times to do a power cycle but it didn’t worked.

The curious thing is that the router is up and running after the upgrade, I was able to ping it, but no GUI or SSH access. Then if you do a power cycle it stops responding also to a ping.

I suspect is something related to the custom size but I can’t debug it because the R4S looks like is bricked after the upgrade, until I flash the SD with a new/stock image.

yeah maybe is different issue, my experience is with building snapshots, one every week, but lately every month, from master with a 350Mb image, in that time the sysupgrade never failed, yes sometimes, if not always, I have to reboot the nanopi several times to get it to start in service after the sysupgrade, but never needed to take the sdcard out to rewrite it

so my nanopi run snapshots, not releases, so many variables are different to get a common cause