NanoPi R6S & Linux 6.3 ARM SoC Updates

I have gotten CPU scaling working on R6S with kernel 6.1

root@OpenWrt:/proc/irq/89# cat /sys/devices/system/cpu/cpu5/cpufreq/stats/time_in_state 
408000 0
600000 0
816000 273115
1008000 3300
1200000 3338
1416000 962
1608000 281
1800000 13
2016000 10
2208000 438
root@OpenWrt:/proc/irq/89# cat /sys/devices/system/cpu/cpu2/cpufreq/stats/time_in_state 
408000 0
600000 0
816000 0
1008000 256242
1200000 1269
1416000 1951
1608000 17709
1800000 4854
root@OpenWrt:/proc/irq/89# 

Also can now distribute the IRQs for the 2.5GbE ports across the BIG cores (se below ... cores 0-3 little, cores 4-7 BIG)

root@OpenWrt:/proc/irq/89# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
 19:     743213     662452     685228     242939    1030936     351579     604673     667857     GICv3  26 Level     arch_timer
 30:          1          0          0          0          0          0          0          0     GICv3 425 Level     rockchip_usb2phy
 31:          2          0          0          0          0          0          0          0     GICv3 423 Level     rockchip_usb2phy
 32:          0          0          0          0          0          0          0          0     GICv3 118 Level     fea10000.dma-controller
 33:          0          0          0          0          0          0          0          0     GICv3 119 Level     fea10000.dma-controller
 34:          0          0          0          0          0          0          0          0     GICv3 120 Level     fea30000.dma-controller
 35:          0          0          0          0          0          0          0          0     GICv3 121 Level     fea30000.dma-controller
 36:          0          0          0          0          0          0          0          0     GICv3 122 Level     fed10000.dma-controller
 37:          0          0          0          0          0          0          0          0     GICv3 123 Level     fed10000.dma-controller
 38:       2139          0          0          0          0          0          0          0     GICv3 365 Level     ttyS2
 39:      21523          0          0          0          0          0          0          0     GICv3 360 Level     feb20000.spi
 40:          1          0          0          0          0          0          0          0  rockchip_gpio_irq   7 Level     rk806
 41:          0          0          0          0          0          0          0          0     rk806   0 Edge      rk805_pwrkey_fall
 42:          0          0          0          0          0          0          0          0     rk806   1 Edge      rk805_pwrkey_rise
 57:      84769          0          0          0          0          0          0          0     GICv3 266 Level     eth0
 58:          0          0          0          0          0          0          0          0     GICv3 265 Level     eth0
 59:          0          0          0          0          0          0          0          0     GICv3 252 Level     xhci-hcd:usb1
 60:          0          0          0          0          0          0          0          0     GICv3 247 Level     ehci_hcd:usb4
 61:          0          0          0          0          0          0          0          0     GICv3 248 Level     ohci_hcd:usb2
 62:      79791          0          0          0          0          0          0          0     GICv3 349 Level     fd880000.i2c
 63:       1871          0          0          0          0          0          0          0     GICv3 429 Level     rockchip_thermal
 64:         57          0          0          0          0          0          0          0     GICv3 237 Level     mmc0
 65:       3681          0          0          0          0          0          0          0     GICv3 235 Level     dw-mci
 76:          0          0          0          0          0          0          0          0   ITS-MSI 427819016 Edge      PCIe PME
 77:     435100    3781927    4547759          0          0     352686          0       4322   ITS-MSI 428343296 Edge      eth1
 88:          0          0          0          0          0          0          0          0   ITS-MSI 570425352 Edge      PCIe PME
 89:    4227196          0          0    1731679          0          0        134          0   ITS-MSI 570949632 Edge      eth2
IPI0:      2566       2971       4124       3196        837        545        772        649       Rescheduling interrupts
IPI1:    443568     464955     364510     193128     537689     332212     535751     533602       Function call interrupts
IPI2:         0          0          0          0          0          0          0          0       CPU stop interrupts
IPI3:         0          0          0          0          0          0          0          0       CPU stop (for crash dump) interrupts
IPI4:      6369       6108       7569       7739       5121       7137      10705       9160       Timer broadcast interrupts
IPI5:     18250      14285      12750      11255       8764      10066      12360       8702       IRQ work interrupts
IPI6:         0          0          0          0          0          0          0          0       CPU wake-up interrupts
4 Likes

How does that impact the power usage?

Quiet honestly, I have no idea.

I don't have a USB-C power draw tester

Too bad :upside_down_face: but, just in case you want one, aliexpress

I’ve been using one of these USB-C to USB-C cables with a power meter for my R5C and while not super accurate it’s pretty neat: USB C to USB C, Mcdodo...

I tested the power consumption on the R6C, setting SQM at 1Gbps and there's not much difference that when is idle.

Idle

at 1Gbps download

3 Likes

Idle= 3.53w
Load = 4.59w
~ 30% increase

I suspect that if you are running a VPN it will increase a bit more, but this is great for my energy bill :heart_eyes:

Yay!

2 Likes

With the current build USB3 works fine:

lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

to a M.2 adapter with a 970 EVO

dd if=/dev/zero of=/dev/sda bs=4M count=1000
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 11.6502 s, 360 MB/s

I noticed /proc/cpuinfo does not show the serial number which is different from Armbian. Might you have any idea what passes this information to /proc/cpuinfo ? and how to disable it, so I can pass this to along to Armbian?

Thank you

I think you ought to use:

dd if=/dev/zero of=/dev/sda bs=4M count=1000 conv=sync

It might still be syncing which gives an unrealistic outcome :slightly_smiling_face:, so you could add the conv=sync.

Doesn't change anything, always around 350-370 MB/s

@DooMMasteR
I really thought he had a point there. How weird, maybe that's for desktop os's.

@mj82
Tested out your build and it runs really fine afaict. I think I'm going to install it to the internal storage. I'll report back in this thread.

True, yeah, but it seems either the buffers are too small or something else is weird, but sync on/off makes no measurable difference.
Or maybe busybox dd is just weird...

My bad, that should have been 'conv=fsync'

conv=sync  Pad blocks with zeros
conv=fsync Physically write data out before finishing

Seems to work fine from internal storage :+1:

Steps I took:

  1. Booted from sdcard
  2. Downloaded file:
wget https://github.com/mj22226/openwrt/releases/download/linux-6.4/openwrt-rockchip-armv8-friendlyelec_nanopi-r6c-squashfs-sysupgrade.img.gz
  1. Wrote file to internal flash storage
pv openwrt-rockchip-armv8-friendlyelec_nanopi-r6c-squashfs-sysupgrade.img.gz | zcat | dd of=/dev/mmcblk1
  1. Rebooted without sdcard into OpenWRT
root@OpenWrt:~# cat /proc/partitions
major minor  #blocks  name

   1        0       4096 ram0
   1        1       4096 ram1
   1        2       4096 ram2
   1        3       4096 ram3
   1        4       4096 ram4
   1        5       4096 ram5
   1        6       4096 ram6
   1        7       4096 ram7
   1        8       4096 ram8
   1        9       4096 ram9
   1       10       4096 ram10
   1       11       4096 ram11
   1       12       4096 ram12
   1       13       4096 ram13
   1       14       4096 ram14
   1       15       4096 ram15
   7        0     432576 loop0
 179        0   30310400 mmcblk1
 179        1      16384 mmcblk1p1
 179        2     524288 mmcblk1p2
 179       32       4096 mmcblk1boot0
 179       64       4096 mmcblk1boot1
root@OpenWrt:~# 

3 Likes

thank you so much for your brilliant work! finally unadulterated OpenWRT for my R5S and R6C.
In the hopes to annoy nobody here I must ask one slightly off topic question:
How do you deal with the little space that's left, when using these squashfs images?

This is obviously a noob question, so at least it's honest, but I just have no clue how to manage an install that allows for just an additional 400 MB of data.

I tried compiling my own images, so that I could set the second partition a bit bigger, but I never built anything else before, so there's a lot of room for improvement there right now lol (somehow forgot luci packages, and more).

how do you solve this? is there some way to add drive space to an image that I'm completely oblivious to for weeks? Chances sure are good

1 Like

I have not done it yet myself but I have seen several posts pointing to an easy solution in the image builder config file(s). Here is a link to one such forum topic: Image builder filesize "out of space"

I and others have posted info on expanding the writable filesystems after installation on SD cards for the R4S and devices with similar storage layout. They may not apply if there are additional filesystems for wifi data or another storage layout etc.

Here is a link to instruction for f2fs filesystem type: https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds/blob/main/docs/resize-f2fs.md

Here is a link to my forum topic if the writable filesystem is ext4: Resizing the hidden overlay filesystem when it is ext4 and not f2fs

Keep in mind that typically for devices with the simple filesystem layout I'm familiar with, the installer and upgrade process both overwrite the partition table and file systems so the extra space and all data get wiped out every time. You need to backup any data you want to restore after each upgrade being mindful not to overwrite upgraded files.

It may be useful to always add new packages by building a new custom image with the additional items and disk sizes, install it and restore your configs etc.

1 Like

funnily enough, all sites you linked I visited today each probably a dozen times, but for whatever reason I am not able to resize the f2fs/ext4 part of an overlayfs, and the whole exroot thing also isn't working for me. For whatever reason I just can't manage to get it right

too bad really, because overlayfs seems pretty useful

Sorry to hear that. If you want help, it may be good to start your own topic asking for it.

Good luck!

1 Like

What steps did you have to take to get frequency scaling and IRQ adjustments to work?

I've tried compiling 6.1 and 6.4 from @mj82's repo, but my cpufreq dir stays empty, and just like you earlier, I'm unable to move the IRQs to the faster cores