Quiet honestly, I have no idea.
I don't have a USB-C power draw tester
but, just in case you want one, 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 
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 
, 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 
Steps I took:
- Booted from sdcard
- Downloaded file:
wget https://github.com/mj22226/openwrt/releases/download/linux-6.4/openwrt-rockchip-armv8-friendlyelec_nanopi-r6c-squashfs-sysupgrade.img.gz
- Wrote file to internal flash storage
pv openwrt-rockchip-armv8-friendlyelec_nanopi-r6c-squashfs-sysupgrade.img.gz | zcat | dd of=/dev/mmcblk1
- 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
I disabled the CPU frequency scaling on rk3588 because it causes issues with rk3568 devices, it can be enable editing the rockchip config in
target/linux/rockchip/armv8/config-6.1/6.4
# CONFIG_ARM_ROCKCHIP_CPUFREQ is not set
change to
CONFIG_ARM_ROCKCHIP_CPUFREQ=y
1 Like
Ohh yeah, disabling frequency scaling is a bummer... but CPUidle should not be affected by this change I guess? so at least some power saving should still work, right?