NanoPi R4S-RK3399 is a great new OpenWrt device

I doubt this is related, since the R1 is on a different architecture (sunxi/cortexa7 according to firmware selector). I thing the only chance is to bisect your config, trying to locate the problem … potentially it is a wider issue. Not sure if I have time this weekend to take a look.

I'm building from master since 0612 every two days, and the images always work, but I enabled the testing kernel from make menuconfig and the changes to .config after saving it are:

--- a/dot/.config
+++ b/dot/.config
@@ -58,7 +58,7 @@ CONFIG_TARGET_PROFILE="DEVICE_friendlyarm_nanopi-r4s"
 CONFIG_TARGET_ARCH_PACKAGES="aarch64_generic"
 CONFIG_DEFAULT_TARGET_OPTIMIZATION="-Os -pipe -mcpu=generic"
 CONFIG_CPU_TYPE="generic"
-CONFIG_LINUX_5_10=y
+CONFIG_LINUX_5_15=y
 CONFIG_DEFAULT_base-files=y
 CONFIG_DEFAULT_busybox=y
 CONFIG_DEFAULT_ca-bundle=y
@@ -91,6 +91,7 @@ CONFIG_DEFAULT_uci=y
 CONFIG_DEFAULT_uclient-fetch=y
 CONFIG_DEFAULT_urandom-seed=y
 CONFIG_DEFAULT_urngd=y
+CONFIG_HAS_TESTING_KERNEL=y
 CONFIG_HAS_FPU=y
 CONFIG_AUDIO_SUPPORT=y
 CONFIG_GPIO_SUPPORT=y
@@ -159,6 +160,7 @@ CONFIG_SIGNATURE_CHECK=y
 #
 # General build options
 #
+CONFIG_TESTING_KERNEL=y
 CONFIG_DISPLAY_SUPPORT=y
 # CONFIG_BUILD_PATENTED is not set
 # CONFIG_BUILD_NLS is not set
@@ -2861,7 +2863,7 @@ CONFIG_PACKAGE_kmod-crypto-sha256=y
 #
 # Filesystems
 #
-# CONFIG_PACKAGE_kmod-fs-antfs is not set
+# CONFIG_PACKAGE_kmod-fs-afs is not set
 # CONFIG_PACKAGE_kmod-fs-autofs4 is not set
 # CONFIG_PACKAGE_kmod-fs-btrfs is not set
 # CONFIG_PACKAGE_kmod-fs-cifs is not set
@@ -2871,6 +2873,7 @@ CONFIG_PACKAGE_kmod-crypto-sha256=y
 # CONFIG_PACKAGE_kmod-fs-exportfs is not set
 # CONFIG_PACKAGE_kmod-fs-ext4 is not set
 # CONFIG_PACKAGE_kmod-fs-f2fs is not set
+# CONFIG_PACKAGE_kmod-fs-fscache is not set
 # CONFIG_PACKAGE_kmod-fs-hfs is not set
 # CONFIG_PACKAGE_kmod-fs-hfsplus is not set
 # CONFIG_PACKAGE_kmod-fs-isofs is not set
@@ -2878,6 +2881,7 @@ CONFIG_PACKAGE_kmod-crypto-sha256=y
 # CONFIG_PACKAGE_kmod-fs-ksmbd is not set
 # CONFIG_PACKAGE_kmod-fs-minix is not set
 # CONFIG_PACKAGE_kmod-fs-msdos is not set
+# CONFIG_PACKAGE_kmod-fs-netfs is not set
 # CONFIG_PACKAGE_kmod-fs-nfs is not set
 # CONFIG_PACKAGE_kmod-fs-nfs-common is not set
 # CONFIG_PACKAGE_kmod-fs-nfs-common-rpcsec is not set
@@ -3223,6 +3227,9 @@ CONFIG_PACKAGE_kmod-libphy=y
 # CONFIG_PACKAGE_kmod-macvlan is not set
 CONFIG_PACKAGE_kmod-mdio-devres=y
 # CONFIG_PACKAGE_kmod-mdio-gpio is not set
+# CONFIG_PACKAGE_kmod-mhi-net is not set
+# CONFIG_PACKAGE_kmod-mhi-wwan-ctrl is not set
+# CONFIG_PACKAGE_kmod-mhi-wwan-mbim is not set
 CONFIG_PACKAGE_kmod-mii=y
 # CONFIG_PACKAGE_kmod-mlx4-core is not set
 # CONFIG_PACKAGE_kmod-mlx5-core is not set
@@ -3368,6 +3375,8 @@ CONFIG_PACKAGE_kmod-gpio-button-hotplug=y
 # CONFIG_PACKAGE_kmod-keys-encrypted is not set
 # CONFIG_PACKAGE_kmod-keys-trusted is not set
 # CONFIG_PACKAGE_kmod-lp is not set
+# CONFIG_PACKAGE_kmod-mhi-bus is not set
+# CONFIG_PACKAGE_kmod-mhi-pci-generic is not set
 # CONFIG_PACKAGE_kmod-mmc is not set
 # CONFIG_PACKAGE_kmod-mtd-rw is not set
 # CONFIG_PACKAGE_kmod-mtdoops is not set
@@ -7001,7 +7010,6 @@ CONFIG_PACKAGE_vim-full=y
 #
 # CONFIG_PACKAGE_acl is not set
 # CONFIG_PACKAGE_afuse is not set
-# CONFIG_PACKAGE_antfs-mount is not set
 # CONFIG_PACKAGE_attr is not set
 # CONFIG_PACKAGE_badblocks is not set
 # CONFIG_PACKAGE_btrfs-progs is not set

Yeah, i did not express myself right there tbh :stuck_out_tongue:

What i meant when i said that its related to that issue report, is that there has been other ppl with boot issues recently, i just grabbed the most recent report :smiley:

There is another report here:

Edit:

Reading this second issue above, its does not seem to be related... But ill still leave it here.

Anyway ill try to narrow it down tomorrow :smiley:

1 Like

There is an old comment in the R4S wiki saying that the snaphots images are not booting in the 1GB RAM model (I'm not sure if this information is up-to-date).

I'm wondering if this restriction is still valid and if it could be related to the new boot issues (I'm assuming you're using the 4GB model).

BTW, I am running a custom build of 22.03-rc4 and it is booting ok on a 4GB model (actually I just received mine yesterday and it is already up and running!).

Hi

Just receive the R4S...what's the simple guide to install OpenWRT RC4 with Luci?
Just download the sysupgrade img and flash it to a microSD?
ext4 or squashfs?

thx for the hints

Yep, that's basically it (download sysupgrade image and flash it to a microSD with Rufus, Win32 Disk Imager or similar).

Notice that you have to uncompress the *.img.gz to *.img before flashing. As previously mentioned, for some reason at least 7-Zip is giving a warning in this process, but the file is OK and it is safe to ignore the warning.

I would recommend starting with squashfs (it has a read-only filesystem that allows you to easily restore factory defaults among other things). I recommend reading the topic below for more information about ext4 x squashfs:

1 Like

It may not be up to date. It was put in during early stages of R4S being added. Most people with the R4S had the 4gb version and thus we only discovered the 1gb issue later. People using the 1gb version used alternate builds with the patch in. Someone needs to test it again to see if its fixed. (or someone checks the commits to find the patch)

1 Like

Has someone tested the 1GB version since?

If they have, they haven't posted here. Once we get confirmation I can update the wiki.

I don't think anyone added support for the 1gb into official openwrt, if i am not mistaken it was a uboot thing that no one cared to do the upstream of the changes needed to make the 1gb work so far.

I think that 90% of everybody who bought the r4s, got the 4gb version since the price difference is not that much.

My version is the 4gb one, its not related to that cause with minimal config file it boots with kernel 5.15 but when i go with a "full" config file it does not.

I did not try any new builds since that day, i might do it today.

2 Likes

I open a PR to switch the rockchip target to kernel 5.15 , it also solve the boot and build problems.

2 Likes

Thats nice, thx!

But i have a question, if you are doing the switch to 5.15 instead of using it as a testing kernel, should not 5.10 be removed? like the patchs folder and such?

Everything working flawlessly!

Default values seem to be the other way around on mine:

root@OpenWrt:~# cat /sys/class/net/eth0/queues/rx-0/rps_cpus
00
root@OpenWrt:~# cat /sys/class/net/eth1/queues/rx-0/rps_cpus
00
root@OpenWrt:~# grep eth /proc/interrupts
 35:     580672          0          0          0          0          0     GICv3  44 Level     eth0
 87:          0    1126184          0          0          0          0   ITS-MSI 524288 Edge      eth1
root@OpenWrt:~# cat /proc/irq/35/smp_affinity
3f
root@OpenWrt:~# cat /proc/irq/87/smp_affinity
3f

Is there a PR open to have this done in official release?

You probably did something like packet steering or irqbalance or you downloaded another image from somewhere else(not an official image?) or its related to this:

Cause you can see on openwrt 22.03:

And even on master:

Nothing is changed, in other words, irq will be on cores 4 and 5 and the queues with rps won't spread cause they will be set to 00 after boot.

No it is the standard rc4 version from openwrt downloads…

Ok, but still i gave 3 more reasons to why yours is different right now.

Yeah but I did not touch anything, waited more than 10sec, did not install irqbalance etc
But anyway, my question was more to know if we can hope to have the right settings done in future official release or we will have to either manage it manually or through irqbalance?

I use R4S 4Gb only for 2 docker images (using as managed switch).
What is the best way to divide CPU load in this case?
Do I even need to divide it (I am not using R4S as a router)?

I was thinking something like this:

eth0 IRQ on A53 core - core0 --> I don't use eth0 (deleted wan/wan6)
eth0 queues on A53 core - core1 --> I don't use eth0 (deleted wan/wan6)
eth0 queues on A53 core - core2
eth1 IRQ on A53 core - core3

Docker1 (Unifi Controller) --> cores 0-2 (or 0-3 if I don't need IRQ on separate core)
Docker2 (HomeAssistant) --> cores 4-5

core0 --> docker1 (Unifi), eth0 IRQ (eth0 is not in use)
core1 --> docker1 (Unifi), eth0 queues (eth0 is not in use)
core2 --> docker1 (Unifi), eth1 queues
core3 --> eth1 IRQ (or also with Unifi)
core4 --> docker2 (HA)
core5 --> docker2 (HA)

docker1 (Unifi) - 1.2gb RAM
docker2 (HA) - 2gb RAM

Unifi - 2 AP, 10 devices (6 IoT, 2 phones, 2 notebooks)
HA - 6 IoT devices, 1 integration

My questions:

  1. Does dividing IRQ and queues make sense in my case?
  2. Is CPU dividing ok for these 2 containers (Unifi -> 0-2 or 0-3 and HA 4-5)?
  3. Is RAM dividing ok for these 2 containers (Unifi 1.2gb and HA 2gb)?