NanoPI R6S with OpenWRT

Do you use eMMC or SD card to boot?

Much appreciated I fixed my error.

2 Likes

Just wanted to say thank you. I used your settings for the R4S as well and it improved cake SQM from 630 Mbps to about 795 Mbps!

nano /etc/hotplug.d/net/40-net-smp-affinity
friendlyarm,nanopi-r4s|\
friendlyelec,nanopi-r4s)
	set_interface_core 4 "eth0"
	set_interface_core 8 "eth1"
	echo -n 10 > /sys/class/net/eth0/queues/rx-0/rps_cpus
	echo -n 20 > /sys/class/net/eth1/queues/rx-0/rps_cpus
	;;
1 Like

I used eMMC.
When using eMMC it is not easy to flash back to an initial state.
I need to use an USB A to A cable and the RKflasher tool.
Once configured to boot from eMMC you can not easily boot from SD Card again.
I haven't tried the option to erase the initial portion of the boot section, this may also work instead of USB recovery. Hence I am familiar with USB recovery I just use it.

I tried to wipe eMMC boot section to force SD card booting, it works, however if it's hard bricked then you don't have any means to wipe it, so you still need USB recovery. I just want to know how DietPi/Armbian able to boot SD card, there must be something missing during the SD card build.

I think the Openwrt builds use kmod-8169 driver, Frendilywrt use kmod-r8125.

try the below aswell, im using these builds until offical released, they use kmod-r8125

https://firmware-selector.immortalwrt.org/?version=SNAPSHOT&target=rockchip%2Farmv8&id=friendlyarm_nanopi-r6s

just add luci to requested packages and request build

Thanks for the suggestion.
Probably I would stay on Friendlywrt as I would have to incorporate 500+ Packages
(without localization)
image

And other than expected Friendlywrt uses

image

the 8169 driver.

Thank you either way.

2 Likes

For testing purpose, I put DietPi (a stripped version of Debian) on my R6S, and found that the 2.5GbE can't be used with r8169 driver, I have to use r8125 as well.

1 Like

@mj82

Hey I got the 6.8 build running on nanopi R6S, but I'm getting a kernel panic with docker running homebridge. It's not happening super-consistently but when I stop and start the homebridge container a few times (current issue is that homebridge-ui-x in the same container is trying to bind to the host IP but cannot, so it keeps restarting homebridge-ui-x).

Could it be an issue with the hardware support that you've built? I honestly have no idea.

Thank you so much for the amazing work!

EDIT: It seems to happen as well when I type docker container ls

EDIT: I'd like to also add that I am using your raspberry 5 build and did not get this issue at all with the homebridge docker container (I bought a R6S since USB nics were just crapping out on the RPI 5 because of realtek), so I'm thinking it's kernel-related.

[  343.411872] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148
[  343.412642] Mem abort info:
[  343.412886]   ESR = 0x0000000096000006
[  343.413213]   EC = 0x25: DABT (current EL), IL = 32 bits
[  343.413676]   SET = 0, FnV = 0
[  343.413943]   EA = 0, S1PTW = 0
[  343.414216]   FSC = 0x06: level 2 translation fault
[  343.414641] Data abort info:
[  343.414893]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[  343.415378]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  343.415829]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  343.416292] user pgtable: 4k pages, 48-bit VAs, pgdp=000000010088c000
[  343.416853] [0000000000000148] pgd=0800000109092003, p4d=0800000109092003, pud=080000010a7b4003, pmd=0000000000000000
[  343.417782] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
[  343.418327] Modules linked in: nft_fib_inet nf_flow_table_inet nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_compat nft_chain_nat nf_tables nf_conntrack_netlink ipt_REJECT zstd xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_cgroup xt_addrtype xt_TCPMSS xt_REDIRECT xt_MASQUERADE xt_LOG xt_HL xt_DSCP xt_CLASSIFY sch_cake r8169 ppp_async nfnetlink nf_reject_ipv4 nf_flow_table lzo_rle lzo iptable_nat iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt br_netfilter sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact ip6table_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_NPT ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT
[  343.418439]  x_tables nf_reject_ipv6 ifb veth uas gpio_button_hotplug(O) btrfs xor zstd_decompress zstd_compress zstd_common xor_neon raid6_pq lzo_decompress lzo_compress
[  343.427503] CPU: 7 PID: 11533 Comm: dockerd Tainted: G           O       6.8-rc1 #0
[  343.428170] Hardware name: FriendlyElec NanoPi R6S (DT)
[  343.428625] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  343.429231] pc : Ύe\xc0\xae+0x14/0x5c
[  343.429519] lr : \xbct\x1b\xe0i\xa3\xb6\xeefy+0xa8/0x2c4
[  343.429849] sp : ffff8000839fb4c0
[  343.430138] x29: ffff8000839fb4c0 x28: 0000000000000003 x27: 0000000000000000
[  343.430761] x26: ffff800081183410 x25: ffff0001021b2110 x24: ffff00010262ee00
[  343.431382] x23: ffff8000811832f8 x22: ffff0001021b2000 x21: ffff00010a360600
[  343.432004] x20: ffff00010a360678 x19: ffff00010a360600 x18: 0000000000000000
[  343.432627] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[  343.433249] x14: ffffffffffffffff x13: 0000000000000020 x12: 0101010101010101
[  343.433871] x11: 7f7f7f7f7f7f7f7f x10: 00000000081ae590 x9 : 0000000000000020
[  343.434493] x8 : 0101010101010101 x7 : 0000000080808080 x6 : 0000000080808080
[  343.435115] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[  343.435738] x2 : ffff000101a2e740 x1 : 0000000000000000 x0 : 0000000000000000
[  343.436359] Call trace:
[  343.436573]  Ύe\xc0\xae+0x14/0x5c
[  343.436828]  \xbct\x1b\xe0i\xa3\xb6\xeefy+0xa8/0x2c4
[  343.437127]  \x9f\x18\xb6\xee\xc5\xfa\xf7\xe7l~a\xfb+0x50/0x6c
[  343.437436]  \xe7Ƽt+0x54/0x9c
[  343.437683]  ~\xe2\x8bna\xcf+0x150/0x2b4
[  343.437960]  o\x8c\xbdk+0xba8/0xf04
[  343.438223]  tnl\x8c\xbdk+0xf0/0x188
[  343.438492]  t\xbct\x1frcv_\x1ag+0x118/0x370
[  343.438800]  \xbct\x1frcv\xffkb+0x58/0x120
[  343.439093]  t\xbct\x1frcv+0x14/0x1c
[  343.439362]  \xbct\x1f\xdb\xc1a\xe9+0x1fc/0x2fc
[  343.439647]  \xbct\xbdk\xe6nd\x1ag+0x15c/0x358
[  343.439946]  \xaas\xe6nd\xd5+0xd8/0x138
[  343.440214]  \x15
                    \xaas\xe6nd\xd5+0x24/0x30
[  343.440489]  \xfbvo\x06\xaasc\xe7l.\x9a\xe9]p\xa2+0x4c/0xdc
[  343.440818]  \x85_el0\xffvc+0x3c/0xb8
[  343.441094]  l0\xffvc+0x34/0xf8
[  343.441347]  el0\xfd
                       \xaan\xe3h
l\xfa+0xf8/0x124
[  343.441660]  l0\xfd
                      \xaanc+0x160/0x164
[  343.441945] Code: 910003fd f9000bf3 aa0003f3 f9404c00 (f940a401)
[  343.442475] ---[ end trace 0000000000000000 ]---

Okay still happening after I switched from squashfs to ext4.

All interfaces in the baseline config had static mac addresses set, but eth0 and eth2 had the SAME one assigned.

Yeahhhhh ethtool says only eth0 has a permanent mac address assigned, and other two say Permanent address: not set with ethtool -P ethX.

Rebooting is a crapshoot and its inconsistent with the interfaces coming up as assigned.

Also the port 2 light on the nano r6s always lights up for some reason, but maybe my r6s is broken?

Ive been testing the firmware for FriendlyElec -

21.02 uses kmod 8169 drivers
23.05 has both installed 8125 and 8169

Im assuming your using 21.02?

Have tested both, dont notice any really difference in performance TBH

I have an embarrassingly n00bish question: how would I install security updates were I to use https://github.com/mj22226/openwrt/releases? I’m wondering if the process differs from official images since this is a fork. But to be honest I’ve never used OpenWRT and don’t have experience doing this with an official image. Ideally I’d be able to do this via the gui (and setup notifications through something like email). Thanks!

I love OpenWRT and enjoyed using it. However, one glaring downside of OpenWRT is how excruciatingly difficult it is to properly update OpenWRT versions on devices with larger storage that one wants to utilize as well as on devices on which you run additional packages. The inability to simply push the update button and have the system updated like it happens say in pfSense is a high bar to jump over multiple times per year to keep the OpenWRT device up to date with the latest releases. Personally, I had to compile my images from source for the device I ran OpenWRT on in order to have it updated with a new image. I would preload an SD flash card with a new image (compiled with the same exact set of packages and for the size of the flash storage) and then swap out the SD card in the device and upload the most recent config. That worked, but it took hours. It got old within a couple years and I started skipping the releases and dreading having to update OpenWRT. This caused me to start looking for alternatives.

Because most of my network was on Ubiquiti UniFi devices (except for the firewall), I jumped on the new UniFi UXG-Lite as soon as it was released last December. Even though the UXG-Lite device is not as powerful as the ARM device I originally used to run OpenWRT on (Raspberry Pi 4B) or especially the R6S that I replaced the Raspberry Pi with, I decided to go with a less powerful ARM device but a device that can be easily updated with a new software release by simply pushing the update button and having all the settings survive the update.

Before switching to OpenWRT, I used pfSense for a long time, and updating software was an absolute non-issue with pfSense regardless of which additional packages I ran. It never had to jump through hoops to update pfSense like I had to do with OpenWRT. The only reason I switched away from pfSense was the fact that pfSense couldn’t (and still can’t) run on ARM based devices.

In my opinion, unless you use one of the consumer Wi-Fi routers with limited storage and run one of the standard compiled images with minimum services (the only case when the update is painless), this glaring lack of a simple update procedure drives people away from OpenWRT.

1 Like

Well....this is not really true (at least it broke twice at my home, and quite a lot of people got issue from time to time), however I also understand and really want to have better solution on the partitioning thing (not sure if there can be scripts that making the expansion automated during first startup)

The NanoPi R6S is not supported by OpenWrt. Nothing exists for the R6S to drive people away from.

If and when the NanoPi R6S is supported by OpenWrt - and it seems likely it eventually will be - OpenWrt does provide some relatively simple update mechanisms via attended sysupgrade and the firmware selector (the latter also offers a "Customize installed packages and/or first boot script" drop down to add any desired packages to the image).

Granted, these update mechanisms work smoother with the native squashfs OpenWrt file system. However, even building, downloading and flashing an updated ext4 image takes just minutes with the firmware selector.

I agree with you though that it can get quite cumbersome to maintain OpenWrt on an ext4 file system due to needing to restore customized expanded partition sizes, configurations from backup files, etc. Other operating systems can be better options for applications beyond what OpenWrt is designed to support.

Ironically, the R6S update mechanism is much more streamlined if one were to go with FriendlyWRT, as their image is tailored for R6S. So, I had much better experience with the R6S in this respect by running FriendlyWRT because at least the software updates were relatively painless compared to what I had to do with the Raspberry Pi 4B.

This is a tinkerer’s heaven, but this is not for the people who specialize in fields other than compiling Linux code.

From this perspective, pfSense is a much more reasonable platform to maintain.

I should hope so! FriendlyWrt supports the R6S, OpenWrt currently does not.

There is certainly nothing wrong with "compiling Linux code" yourself for your Pi 4B, but if you find that too cumbersome there are alternatives. The Pi 4B is supported by OpenWrt. Compiled firmware images can be easily downloaded for the Pi 4B in minutes from the firmware selector. Specialized linux code compiling skills are not required.

Not for larger SD card sizes. Additionally, if you have a dozen packages installed, you have to redownload them once you load the new image you downloaded. This is not a software upgrade. This is a fresh install. The only shortcut you can use is try and use your saved configuration backup, but the settings for the packages that don’t come with the standard image don’t get saved in the backup configuration. Then, you have to run custom scripts to have those package settings backed up and restored. It’s a pain in the rear. This is one serous downside that needs to be addressed. I’m a little surprised that after 20 years of this project, this glaring issue hasn’t been addressed.

If one runs OpenWrt as a squash partition image on an underpowered consumer device, software updates work fine, but this is not the kind of device that can be used in advanced setups.

Having said that, the R6S is a superb device. I have two of them. It’s just I don’t have time to have to tinker with the software updates several times per year. I want an update button that does everything once I push it. This is the way it works for me now in a much less powerful UniFi UXG-Lite. I push the update button, it downloads the update and flashes itself with a new update within a minute or two. Everything survives the update. No drama no stress.

At the end of the day, my internet connection is just as good with the UXG-Lite, I have immediate access to the packages that I never got around to installing under OpenWRT because I didn’t want to have to spend multiple hours on restoring the functionality of all those packages after every software update.

These are my experiences. I’m not bashing OpenWRT. I’m pointing out what drove me away from it, and I’m not a newbie with Linux. I’m way better with Linux than the average user who comes across OpenWrt and attempts to use it.

No. You don't.

The firmware selector customize drop down menu is not automatic like attended sysupgrade, but it lets you paste a list of packages you would like included with your firmware (most add luci at a minimum) so that you do not need to download them separately. If you use attended sysupgrade, it takes care of including your previously installed packages automatically.

That's not the case. Backups include everything in /etc/config/, which includes installed package config files.

1 Like

Thank you very much for the insight! This is the exact scenario I'm hoping to avoid.

I read about attended sysupgrade and was hoping to (but doubting that I could) use this to streamline updates.

I'm debating between waiting until the R6S might be supported by OpenWRT or just using FriendlyWRT. It seems like FriendlyWRT is overall less likely to require my cycles to keep the device working and secure. That said, I'm nervous running an image obtained from google drive; I really have no idea what I'd actually be running and am concerned from a security perspective. I see a GitHub repo for FriendlyWRT, but it has no releases. How would one know that the image hosted on google drive was actually built from the code on GitHub?

Thanks again, all!