ct100

Update: I reported this bug to OpenMediaVault and it was fixed in OpenMediaVault Version 6.8.0. https://github.com/openmediavault/openmediavault/commit/82c74b07fb7f57a6c55832f6e3aa17ba6b67b55d (Issue #1589: Fix a problem in the netplan.io configuration for ethernet network interfaces with non-permanent MAC addresses.) For stock Armbian with Network-Manager you still have to make sure that the Realtek RTL8125 2.5GbE NIC is correctly configured.

@Dantes Sorry but that image doesn't really help. Yes it boots but there is a lot of stuff not working with that edge kernel. There is definitely something wrong with the hardware itself or the driver of the GMAC and Realtek Transceiver combo on the 1G WAN. Its possible to increase the RX performance by deactivating energy efficient ethernet with "ethtool --set-eee eth0 eee off" but the performance is still worse than the Realtek RTL8125BG NIC on 2.5G LAN port. Also deactivating eee leads to ~0,25W increased idle power consumption. Running iperf3 tests everything looks ok but when there is the slightest I/O at the same time esp. on the NVME drive the NIC stalls. When reducing the Kernel write cache from 20% to 1% with "echo 1 > /proc/sys/vm/dirty_ratio" its very easy to see the difference:

I found the reason this happens. Its not the eMMC itself, the boot from eMMC or booting from FAT vs EXT4. It's the much faster system boot speed from eMMC and the network configuration that leads to this bug. The device that consumes the additional idle power is the Realtek RTL8125 2.5GbE NIC when left in an bugged unmanaged/unconfigured/off state. When using stock Armbian with Network-Manager it seems to depend on the image, software distribution and the system boot speed with how often the Realtek NIC gets into this bugged state. Properly configuring the NIC in Network-Manager prevents this from happening. When using Armbian Bullseye with OpenMediaVault installed with the OMVExtras InstallScript this can be reproduced 100%. The InstallScript (without using the option -n to skip network configuration) removes Network-Manager and lets systemd-networkd and OpenMediaVault/Netplan manage the network. Since the MAC of the Realtek RTL8125 2.5GbE NIC is not fixed and changes every boot systemd-networkd with the policy "MACAddressPolicy=persistent" (default in /usr/lib/systemd/network/99-default.link) automatically adds a persistent MAC address to the Adapter. At the same time OpenMediaVault creates netplan files that assign network configuration based on this added MAC address. This leads to a race condition in systemd-networkd. If systemd-networkd adds the persistent MAC to the adapter before it tries to assign the configuration matched to this persistent MAC everything works as expected. When the system boots faster systemd-networkd tries to match the configuration to a MAC that is not added yet to the adapter and that leaves the adapter off, unmanaged and bugged. (In these code parts eth0 = GMAC & Realtek RTL8211F 1GbE and Realtek RTL8125 2.5GbE NIC = enP3p49s0) Random MAC adresses: Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00 Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Random ether addr 4e:54:94:b5:ad:c7 OMV Netplan file (matching with mac!): root@nanopi-r6s:~# cat /etc/netplan/20-openmediavault-enP3p49s0.yaml network: ethernets: enP3p49s0: match: macaddress: de:d1:aa:55:c9:bf accept-ra: true dhcp4: yes dhcp4-overrides: use-dns: true use-domains: true dhcp6: yes dhcp6-overrides: use-dns: true use-domains: true Netplan auto generated systemd-networkd .network: root@nanopi-r6s:~# cat /run/systemd/network/10-netplan-enP3p49s0.network [Match] MACAddress=de:d1:aa:55:c9:bf [Network] DHCP=yes LinkLocalAddressing=ipv6 IPv6AcceptRA=yes [DHCP] RouteMetric=100 UseMTU=true UseDomains=true When booting from slow microSD status of enP3p49s0 is ok: root@nanopi-r6s:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether routable configured 3 enP3p49s0 ether no-carrier configuring 3 links listed. root@nanopi-r6s:~# networkctl status enP3p49s0 ● 3: enP3p49s0 Link File: /usr/lib/systemd/network/99-default.link Network File: /run/systemd/network/10-netplan-enP3p49s0.network Type: ether State: no-carrier (configuring) Path: platform-fe180000.pcie-pci-0003:31:00.0 Driver: r8125 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8125 2.5GbE Controller HW Address: de:d1:aa:55:c9:bf HW Permanent Address: 4e:54:94:b5:ad:c7 MTU: 1500 (min: 68, max: 9194) QDisc: mq IPv6 Address Generation Mode: eui64 Queue Length (Tx/Rx): 4/4 Auto negotiation: yes Speed: n/a Port: tp DHCP6 Client DUID: DUID-EN/Vendor:0000ab1166a0671791d79f890000 When booting from much faster eMMC enP3p49s0 is left in a bugged state: root@nanopi-r6s:~# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether routable configured 3 enP3p49s0 ether off unmanaged 3 links listed. root@nanopi-r6s:~# networkctl status enP3p49s0 ● 3: enP3p49s0 Link File: /usr/lib/systemd/network/99-default.link Network File: n/a Type: ether State: off (unmanaged) Path: platform-fe180000.pcie-pci-0003:31:00.0 Driver: r8125 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8125 2.5GbE Controller HW Address: de:d1:aa:55:c9:bf HW Permanent Address: 92:f6:18:f3:59:af MTU: 1500 (min: 68, max: 9194) QDisc: noop IPv6 Address Generation Mode: eui64 Queue Length (Tx/Rx): 4/4 Auto negotiation: yes Speed: n/a Port: tp The fix is to install OpenMediaVault without re configuring the network with InstallScript option -n. That keeps Network-Manger and doesn't add the ethernet adapters to the OMV database. Another option is to remove Network-Manager and also remove the matching by MAC address from OMV netplan files by editing "/srv/salt/omv/deploy/systemd-networkd/netplan/files/ethernet.j2" and deleting: match: macaddress: {{ mac_address }} After saving and applying the new network configuration in OMV webgui the MAC address matching is gone and adapters get only matched by name.

I have the newest Armbian 28.08.0-trunk image running on a NanoPi R6C with a 4TB NVMe SSD. The NanoPi is only connected to power and 1G ethernet via the 1G WAN port. When using the machine as NAS with Samba and a Windows client connected there is a strange problem when receiving large files. The files are stored on the NVMe SSD with ~450MB/s read/write via PCIe 2.1x1. When transmitting files from the NanoPi to a SMB client the 1G ethernet is maxed out but when receiving files the connection drops down to ~60 MB/s every few seconds. This instantly gets fixed when using the 2.5G LAN port instead of the 1G WAN port. On that port the RX looks exactly the same as the TX. Both with 112MB/s maxed out speed. I noticed that the 1G WAN port is a combination of GMAC in RK3588s SoC and a Realtek RTL8211F Transceiver while the 2.5G LAN port is a dedicated Realtek RTL8125BG. So i suspect there is something wrong with that combination of GMAC and Realtek Transceiver on the 1G WAN port. I already tried changing the rgmii rx settings with an overlay, but that didn't have any effect. Driver problem?!

I have Armbian running on a NanoPi R6C 8GB with 32GB eMMC. I made a new Armbian image with the build framework that uses newest linux-u-boot-nanopi-r6s-legacy 23.8.0-trunk linux-dtb-legacy-rk35xx 23.8.0-trunk linux-image-legacy-rk35xx 23.8.0-trunk Booted from microSD this system has an idle power consumption of 0,92w. I can access both the eMMC and microSD storage. When i transfer this system from microSD to eMMC with "nand-sata-install" to boot & OS on eMMC and cold boot without the microSD, the idle power consumption increases to 1,21w. After a shutdown and booting from the microSD again the idle power consumption is back at 0,92w. So far i have not been able to find a reason for this. The only things i noticed was: (microSD) Device Start End Sectors Size Type /dev/mmcblk1p1 32768 557055 524288 256M Linux extended boot /dev/mmcblk1p2 557056 61702144 61145089 29.2G Linux filesystem (eMMC) Device Start End Sectors Size Type /dev/mmcblk0p1 32768 59998207 59965440 28.6G Linux filesystem While microSD uses a vfat partition for /boot and an EXT4 partition for the OS the eMMC has a single EXT4 partition for everything. Does that change how the system is booting? https://github.com/radxa/u-boot/commit/bf47e8171f44804c7f2004f53d3f05801f8dbbb8 Different drive strength settings in u-boot for when eMMC is boot drive or not? Can that really increase the power usage of the eMMC by 0,3w?

Ok i found the cause of the first bug. It was the USB3 in OTG-Mode! I took a kernel image where the bug is present (linux-image-legacy-rockchip-rk3588/now 23.05.1--5.10.160-S03c9-Db165-P0000-C5e28Hfe66-HK01ba-Vc222-B9c18 arm64) and added an user overlay: /dts-v1/; /plugin/; / { fragment@0 { target = <&usbdrd_dwc3_0>; __overlay__ { dr_mode = "host"; }; }; }; That fixed the increased idle power consumption. The kernel images on the nightly branch beta.armbian.com (linux-image-legacy-rk35xx_23.8.0-trunk*) all have the fix and work fine. I'll mark this post as the solution and make a new thread for the 2nd bug.

I don't care what power supply you are using. You can use a totally oversized power supply with ancient technology i don't care. I just want other people to know that your idle power numbers are not representative of what can be achieved with the nanopc t6 and other rk3588(s) boards when used with a high efficiency power supply. He is overvolting the RPi in this article. And yes that will potentially reduce the life time of the soc. But does it matter if you reduce it from 30 years to 15 years when you replace the system after 5-10 years anyway? I will repeat it again. Temperatures of 50-60°C are absolutely not critical for any cpu, gpu or soc. There is also no need to overclock or overvolt the nanopc t6. A fan is ___NOT___ needed for the nanopc t6 in the metal cnc case. This is not a power limitation for the drive. The drive can move freely between these states. The drive decides this automatically based on the time it is in idle. Here is a table where you can see what time it takes to switch to a different state (values again for Lexar NM790 4TB): > nvme get-feature /dev/nvme0n1 -f 0x0c -H get-feature:0xc (Autonomous Power State Transition), Current value:0x000001 Autonomous Power State Transition Enable (APSTE): Enabled Auto PST Entries ................. Entry[ 0] ................. Idle Time Prior to Transition (ITPT): 750 ms Idle Transition Power State (ITPS): 3 ................. Entry[ 1] ................. Idle Time Prior to Transition (ITPT): 750 ms Idle Transition Power State (ITPS): 3 ................. Entry[ 2] ................. Idle Time Prior to Transition (ITPT): 750 ms Idle Transition Power State (ITPS): 3 ................. Entry[ 3] ................. Idle Time Prior to Transition (ITPT): 2450 ms Idle Transition Power State (ITPS): 4 ................. Entry[ 4] ................. Idle Time Prior to Transition (ITPT): 0 ms Idle Transition Power State (ITPS): 0 When copying a large file to the drive it automatically transitions to power state 0: > nvme get-feature /dev/nvme0n1 -f 2 -H get-feature:0x2 (Power Management), Current value:00000000 Workload Hint (WH): 0 - No Workload Power State (PS): 0

I read a lot about u-boot and checked the source code that writes the bootloader to virtual sd (in build scripts) and to the mmc (with platform_install.sh). They are identical files and written like: dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc (If you don't use any seek= to skip blocks you are reading and overwriting the partition table too.) What i didn't understand at the start was that its not just the kernel. This is a system of u-boot + dtb files + kernel. I now also realize that im dealing with 2 bugs here. 1. Bug with different kernels / dtb files between armbian-versions that increases idle power consumption. 2. Bug with booting from mmc instead of sd-card that increases idle power consumption. For the first bug that is is fixed in 28.08.0-trunk i noticed the difference in dtb files. Inside the dtb-file compared to older file there is: USB3 fix: dr_mode = "otg" -> dr_mode "host" Enable CEC: cec-enable = true Cursor fix that adds "disable-win-move", "cursor-win-id" stuff and "rockchip, plane" stuff. I think one of these fixed the bug (or a change in the kernel?!). From the datasheet of RK3588s: Is it possible that this bug is resulting from the DP1.4 lanes that are combined with USB3? And that using USB3 in OTG mode somehow activates them? Some RK3588s boards have these "USB 3.0 OTG Type-C port with DisplayPort Alt mode" combo ports, while the NanoPi R6C just has a normal USB3 A port. Why does the USB3 port not work in OTG mode at all? Activating the HDMI port on the NanoPi R6C results in ~0,30-0,35W more power consumption and that bug is suspiciously in the same power range. For the second bug i have no idea how it is possible to explain the difference when using identical bootloader, dtb-files and kernel. I can see some difference in the bootloader code when booted with mmc as boot drive, like adjusting mmc "drive strength", but i don't think that can explain 0,3W more power consumption.

Check out this picture from meanwell. Below 10% load (5W) LRS-50 efficiency is <70%. With efficiency rating VI 12v 2a wall psu you could have 85%+ at idle. The nanopc t6 in its metal case does not need a fan. Friendlyelec tests the system from 0-70°C AMBIENT!!! Your temperatures are absolutely normal and not critical in any way. If your NVMe-drive gets hot at idle or at low load make sure it has power saving mode enabled (values in this example are for Lexar NM790 4TB): (list all available Power States for the nvme drive) > smartctl -a /dev/nvme0n1 Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 6.50W - - 0 0 0 0 0 0 1 + 5.80W - - 1 1 1 1 0 0 2 + 3.60W - - 2 2 2 2 0 0 3 - 0.0500W - - 3 3 3 3 5000 10000 4 - 0.0025W - - 4 4 4 4 8000 41000 (check that the nvme drive is in lowest power state at idle) > nvme get-feature /dev/nvme0n1 -f 2 -H get-feature:0x2 (Power Management), Current value:0x000004 Workload Hint (WH): 0 - No Workload Power State (PS): 4 (check if ASPM power saving is enabled) > lspci -vvv | grep LnkCtl: LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ (if ASPM power saving is not enabled) (only for current session) > echo powersave > /sys/module/pcie_aspm/parameters/policy (for permanent activation add this line to "/boot/armbianEnv.txt") extraargs=pcie_aspm.policy=powersave My Lexar NM790 4TB stays at just 7°C above ambient temperature even in the closed case without any ventilation. Under light load ~10°C above ambient. And btw. there really should be a new thread just for nanopc t6...

It seems the armbian images i was testing with had both kernel (armbian/linux-rockchip) and u-boot (radxa/u-boot) from april or may 2023. I made a completely new Armbian 23.08.0-trunk image with the armbian build script that included kernel 5.10.160 and u-boot 2017.09 with the latest commits (2023-08-08). With the new image booted from sd card i can reboot the system as many times as i want and install all the updates without permanently increasing the idle power consumption. It always returns to 0,92W. So my NanoPi R6C 4GB without emmc are fine now with the new image But sadly the problem is still there when booting from emmc for the NanoPi R6C 8GB model. After copying the system from sd to emmc with nand-sata-install and booting from emmc the idle power consumption is back at 1,21W. And this is not due to increased power usage from emmc vs sd. When the same NanoPi with the same armbian system is booted from sd with both sd and emmc active the idle power consumption returns to 0,92W.

I did check that. I also spend some time analyzing CPU frequencies and CPU core idle times with cpufrequtils and powertop. There is no difference that would explain such higher idle power consumption. Whats interesting is that i managed to reproduce the same problem on kernel 5.10.110 by moving a system from micro-sd to emmc with armbian-config. The system running from micro-sd: 0,92W idle Same system copied and started from eMMC: 1,21W idle (and this effect is not because the eMMC uses more power) Is there a different boot loader or a different boot loader configuration for booting from emmc? Is it possible that the boot loader permanently activates an unused device? Does armbian-config directly copy u-boot from micro-sd to emmc or is that downloaded from a repo? Is there a difference between a cold start and a reboot with u-boot and how it configures the system? I will try that after i read more about u-boot. It would be nice to have a newer u-boot directly from armbian. Btw. does any1 know if its possible to read out the negotiated USB PD modes with the NanoPi R6x like some Rock 5 Models can? I want to rule out any USB PD quirks.

I don't think its the USB port. I did more tests today and what i noticed was... Fresh install of "Armbian_23.5.1_Nanopi-r6s_bookworm_legacy_5.10.160_minimal" with just .dtb change started cold: 0,92W idle (same as Kernel 5.10.110) Restarting the system instead of cold booting: 1,21W idle But if i install all the updates with apt even a cold boot cannot get the system back to 0,92W idle, it stays permanently on 1,21W idle. Is it possible that this is caused by the bootloader? I wonder why there is a difference between restart and cold boot with a fresh install. All single-sided drives without a heat sink fit inside the NanoPi and you can close the bottom. The Lexar fits. Only double-sided drives are a problem. Easy to see if you take a look at this Picture.

@Jiff The question was about the power usage of the NanoPC T6. Why are you even talking about power factors, reactive or apparent power numbers? An end user only cares and gets billed for real power usage. Most low wattage power supplys dont have power factor correction because it is not needed and would only decrease efficiency. You should stick to reporting real power numbers so people dont get confused. What i have written in my last post still stands. 22,2VA apparent power * 0,42 power factor = 9,324W real power. Thats a very high idle power number for a rk3588 system even with an USB-Hub attached. Do you realise that your power supply does not have 86% efficiency from 0-50W? Below 10W it is more likely something like 60% or even lower. For NanoPC T6 its better to buy a simple 12V 2A wall power adapter with efficiency rating "VI". If you need more power buy a 30+W USB-C GaN charger that supports 12V output and add an USB-C to DC 12V PD Adapter.

Jiff it seems the Mean Well power supplys you are using have very bad power efficiency at low load... far away from the stated 83/86% at typical load the manufacturer writes in their datasheet. Or else it would not be possible to have such high idle power numbers. Does your transcent ssd have deep sleep states and is APST active? I think you also have PCIe ASPM L1 off in your T6 so the PCIe link never goes into power saving mode. Most RK3588 systems can easily beat Raspberry Pi 4 idle power consumption when used with an efficient power supply and power saving modes enabled.

M.2 NVMe flash drives are only power hogs when you buy a drive with a controller manufactured in an old process node, lots of dram cache, many inefficient flash chips with low layer count and then run them without power saving modes enabled. A modern M.2 NVMe flash drive with power saving modes active (APST, ASPM L1 + L1 substates) uses less than 0,05W in idle. NanoPi R6C 4GB + 32GB SanDisk mSD + Lexar NM790 2TB + Ugreen CD122 70273 18W = 0,85W idle (1G connection via WAN-port, no HDMI/USB, SSD APST active, PCIe ASPM L1 active) For 4TB drives Lexar NM790 is prob most efficient drive too and it is single sided so it can fit inside the NanoPi. Btw. i am still wondering where the increased power consumption in kernel 5.10.160 comes from... doesnt seem to be cpu. Could it be RAM or a device that isnt used but still is active?!