Search the Community

I thought I had read that someone had the T2U working out of the box. Well, it's mostly there. When I tried it, didn't work. Got message in dmesg that firmware file not found. Did a Google search and found that it came down to the mediatek firmware files needing to be in the /lib/firmware/mediatek directory but they are currently in the /lib/firmware directory. FYI, the /lib/firmware/mediatek directory already existed and did not need to be created. Also in the current Jammy Gnome desktop Armbian, the file that was being loaded, mt7610e.bin, was not there and only the backup file, mt7610u.bin, was there in the /lib/firmware directory. What I did was download the mt7610e and mt7610u from: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek I placed them in the /lib/firmware/mediatek directory. This was before I saw that the /lib/firmware directory contained the mt7610u.bin file. Rebooted and then no errors in dmesg but correct loading and recognizing the T2U and my WiFi router/SSID. Don't know if there would be issues with other Mediatek dongles or if Armbian needs to be updated for this or it's an issue elsewhere. Just thought this would be useful for others trying to find a working dongle or trying to make their T2U/Mediatek based dongles work.

I'm trying to use an SPI driven TFT display on the orange pi 5, but I'm stuck on enabling SPI in the first place. Looking at the pinout of the orange pi 5 in its manual, it appears that SPI4...M0 is the only bus broken out to the pins. However, enabling "rk3588-spi4-m0-cs1-spidev" in the armbian-config menu does not seem to do anything, as no /dev/spi device exists after a reboot. Enabling any of the other spi hardware functions seems to work just fine, creating a /dev/spi device as expected, but none of the other spi busses are accessible through the pin header. I'm on Armbian 23.8.1 (image: Armbian_23.8.1_Orangepi5_bookworm_legacy_5.10.160.img). Has anyone used SPI on the Orange Pi 5 before?

Hi everyone, Has anyone been able to get gpu hardware acceleration to do encoding/decoding on Jellyfin on the orange pi 5? Thank you

Since I re-installed 23.8 Jammy with the extra ppa:liujianfeng1994 repo - I haven't been able to play any videos on my OPI5. All players I tried seem to have kernel issues decoding any h264. I've narrowed down the error message to a 4Gb memory limit with the selected version of the drivers but I was wondering if anyone had luck with playback. I had better luck with Jammy 23.4 and I regret upgrading. What is the recommendation? Should I try nightly with 6.6.0-rc1 kernel? I assume this one doesn't need panfork drivers anymore or are there other recommendations for h264 playback?

Dear Armbian ARM64 6.6.x kernel people: Orange Pi 5 delivers incorrect larger SCTP chunks to SCTP. from lower IP stack in kernel. This can be seen from the computed CRC-32 checksum below. The packet length is right. This CRC-32 checksum process works correctly on OpenSuSE x86_64 Tumbleweed with kernel 6.5.4-1. It also works correctly on Armbian ARM64 5.10.110. Hence we believe the IP code is faulty in the 6.6.x kernel "stable rolling release" from Armbian. This SCTP driver is used in Telecom by companies like Nokia and Ericsson instead of Linux kernel SCTP and we would like to get it working on the OrangePi 5. Shorter packets like the SCTP INIT are are unaffected, and in the failing INIT_ACK and COOKIE_ECHO the initial 20 bytes or so are correct. This was tested on the 2023 October 9 release of the 6.6.x rolling release and previous releases.. -------------------------------------------------------------------- SCTP/T Trace showing corrupted packet after successful INIT packet of length 60 bytes received (correctly). NB: INIT is a short packet. INIT_ACK and COOKIE_ECHO are 580 or 560 bytes respectively and both fail the CRC-32 check. The SCTP packet contains a checksum (pkt-csum) and the receiver recalculates the checksum (c-csum) and compares it to the enclosed checksum. They re failing to match on larger >500 byte packets. root@orangepi5:/tmp/sctp# dmesg -T | tail -22 [Mon Oct 9 11:47:49 2023] Adax_STRM_IP: Linux Streams-to-IP driver [Mon Oct 9 11:47:49 2023] Adax_STRM_IP: Copyright (C) 2001-2022 ADAX [Mon Oct 9 11:53:45 2023] sctp: S1 init_rproc: q 0x6ca71c0 state 1 IPv4/6 0x6800a8c0 len 4 src 2001 dst 3001 vtag 0 [Mon Oct 9 11:53:45 2023] sctp: S1 init_rproc: q 0x6ca71c0 state 1 cookie w/ alen 0 num_addrs 0 [Mon Oct 9 11:53:45 2023] : current paddrs 0x0 num_addrs 0 [Mon Oct 9 11:53:45 2023] sctp: S1 sa_sendINIT_ACK: len 20 cookielen 548. [Mon Oct 9 11:53:45 2023] sctp: S1 putIP() 0x6800a8c0 src 3001 dst 2001 SKB_HASH-like k 19498 lower port 2 lwq 0x000000004df10be3 [Mon Oct 9 11:53:45 2023] sctp: S1 putIP() final lwput: 0x6800a8c0 src 3001 dst 2001 lower port 2 lwq 0x000000004df10be3 [Mon Oct 9 11:53:45 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x55cc0838 [Mon Oct 9 11:53:48 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x7f2c8d7a [Mon Oct 9 11:53:51 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x55cc0838 [Mon Oct 9 11:53:52 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 529 len 216 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:53:52 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 534 len 16 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:53:52 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 573 len 4 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:53:54 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x55cc0838 [Mon Oct 9 11:53:57 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x55cc0838 [Mon Oct 9 11:54:00 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x978abd22 [Mon Oct 9 11:54:00 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 529 len 216 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:54:00 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 534 len 16 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:54:00 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 573 len 4 rs 0 ws 0 ts 0 nets 1. [Mon Oct 9 11:54:03 2023] sctp: prep_input: totlen 560 pkt-csum 0x3da864fb c-csum 0x744581f1 [Mon Oct 9 11:54:05 2023] sctpwput: S1 state 1 q ffff000106ca7360 mon 0 IOCTL 538 len 4 rs 0 ws 0 ts 0 nets 1. We are using the Orange PI 5 Ethernet interface. Also TCP, like in large file transfers over scp, works fine.

Hello, I cloned the master branch of WiringOP one month ago, it reported same version 2.46 and it was working except for the option to activate internal pull up/down. Trying it in C code using: pullUpDnControl(n, PUD_DOWN); or by terminal with: gpio mode 1 down same behavior, nothing happen.. by default, unfortunately in my case, it seem active a pull up resistor for all inputs. I searched on the web and found there was a bug, fixed. I checked again the main branch and in effect it is different now, the new code is: *(gpio + GPPUD) = pud & 3 ; delayMicroseconds (5) ; *(gpio + gpioToPUDCLK [pin]) = 1 << (pin & 31) ; delayMicroseconds (5) ; *(gpio + GPPUD) = 0 ; delayMicroseconds (5) ; *(gpio + gpioToPUDCLK [pin]) = 0 ; delayMicroseconds (5) ; but executing it I get "segmentation fault", debugging deeply the reason is that "gpio" address is zero. I tried to clone the "next" branch but it is even worst, it won't compile, many errors, log from terminal attached. What I can do in order to fix.. of simply to setup all inputs with pulldown resistor active? Thanks in advance Andrea log.txt

Hello! Does anyone, and by anyone I probably really mean @balbes150 :D, know what I need to do when building official Mesa for it to be recognized in the experimental 6.x kernel environment? There's a panfrost focused dev/staging branch that the panfrost devs are using that I would love to try and be able to build for OPi5 but when I do it I always just get llvm. balbes, you are managing to get the GPU recognized would you be able to share how that's done in the building? I'm not asking for you to provide a build I would just love to know how you do it so I can as well and test the new versions as they happen. This is the branch and commits btw that I read on 'the internet' that its the bleeding edge for rk3588/Mali g610 mesa. https://gitlab.freedesktop.org/panfrost/mesa/-/commits/panfrost/v10-wip Iv'e successfully built that mesa branch and took the latest commits but the gpu is still not recognized so there must be a trick I'm missing. Does anyone have any suggestions? Cheers!

Hello everyone, I have been searching on the net trying to find a way to activate 3d acceleration since i want to use Jellyfin on my orange pi 5. After searching I found the option for ubuntu but not for bullseye, unfortunately I'm using bullseye due to OMV which won't work on ubuntu to use for my media server. Is there any way to turn on the 3d acceleration on Debian? I mean it should be possible since technically Ubuntu is based on Debian. but i was wondering if there are any steps that I need to follow.

$ neofetch ubuntu@orangepi5 ---------------- █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (23.11.0-trunk.145) aarch64 ███████████████████████ Host: Orange Pi 5 ▄▄██ ██▄▄ Kernel: 6.6.0-rc1-edge-rockchip-rk3588 ▄▄██ ███████████ ██▄▄ Uptime: 4 mins ▄▄██ ██ ██ ██▄▄ Packages: 427 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.2.15 ▄▄██ ██ ██ ██▄▄ Terminal: /dev/pts/0 ▄▄██ █████████████ ██▄▄ CPU: (8) @ 1.800GHz ▄▄██ ██ ██ ██▄▄ Memory: 196MiB / 15718MiB ▄▄██ ██ ██ ██▄▄ ▄▄██ ██ ██ ██▄▄ ▄▄██ ██▄▄ ███████████████████████ █ █ █ █ █ █ █ █ █ █ █ Hello, I'm running the edge kernel on a Orange PI 5. I have moved the root partition to an nvme drive with the commands: mount /dev/nvme0n1p# /mnt rsync -aAXHv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/media/*","/boot/*","/mnt/*","/lost+found"} /mnt I left the boot partition on the SD card. I changed the root UUID in the /boot/armbianEnv.txt and in the /mnt/etc/fstab to point to the nvme drive partition. Rebooted and everything seems to work just fine. Is there anything else I need to do before I start using this SBC as a server? Mainly for docker and qemu testing.

GPU can perform far better than CPU cores for certain applications. Computer vision is one of them. Orange Pi 5 GPU has 64 shading cores. It runs up to 19 times faster than 8 CPU cores combined for computer vision models. Armbian on Orange Pi 5 supports OpenCL driver for compute-intensive GPU programs. To install OpenCL on Orange Pi 5 Armbian, follow the instructions in the following link; Install OpenCL on Orange Pi 5 Armbian

I download the following image and encountered serious problem; Armbian_23.8.1_Orangepi5_bookworm_legacy_5.10.160_cinnamon_desktop.img.xz The problem is that after screen blank out, 8 CPU cores get near full 100% usage and OPi5 gets very hot. They all have the following htop profile. Pri NI VIRT SHR S CPU% Command 20 0 5725M 224M R 96% cinnamon -- replace

I have been using my OPi 5 for several months with Armbian on my NVMe ssd. I decided to shift my SSDs around, and removed the one that was in my OPi5 and put in a new one. I burned the latest Armbian 23.8 Bookworm Cinnamon dated Aug 31, 2023 using BalenaEtcher onto an SD card, put it in the OPi5, and it booted fine. I did apt update and upgrade, no problems. I ran nand-sata-install hoping to transfer the system to the ssd and it failed. My memory is fuzzy due to panic setting in, but I tried the Jameschambers process to copy the system over, and then tried to boot off the ssd card, and it failed. When I tried armbian-config it failed to update the MTD and reported no space (blank MB). Then I tried booting off the SD card and it failed. I connected the USB-tty to read the console and there were errors both on the ssd and the 16 MB MTD. So I removed the ssd, and I still get an error and it will not boot off the SD card. I have attached the console output for the condition with no ssd card, and failing to boot. Can anyone help me correct this boot problem? I think the MTD is somehow corrupted and needs to be reloaded but I don't know how to do it. OPi5BootFail.txt

Hello, I have just installed the Armbian_23.11.0-trunk.114_Orangepi5_jammy_edge_6.6.0-rc1_xfce_desktop.img It boots OK, but does not present any desktop, but I can ssh into it and configure In syslog I find lots of errors where lightdm fails due to: Sep 20 16:10:15 orangepi5 systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 4. Sep 20 16:10:15 orangepi5 lightdm[2103]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Sep 20 16:10:16 orangepi5 systemd[1]: lightdm.service: Main process exited, code=exited, status=1/FAILURE Sep 20 16:10:16 orangepi5 systemd[1]: lightdm.service: Failed with result 'exit-code'. Sep 20 16:10:16 orangepi5 systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 5. I recon this might be the cause, but have never spent any time on how the desktop gets activated and its components. Is this the reason I get no video/HDMI on my PI 5 (that works ok with kernel 5.10) And, is it trying to retrieve a user list from freedesktop.org?? Why?? G

I have attempted to install OMV on my orange pi various times and i have had the same issue weather with the OMV after installation or with the armbian os before the OMV installation. when you start the system, it just won't get it's Ip automatically, at first i thought my orange pi came with a problem from fabric since I'm new to this but after attempting to put an Ip statically seemingly making it work I noticed that it just would not be set automatically. Now surely you might think it's a problem with my router set up, but this won't happen when I try it out with any other equipment in my house or when i just run regular Linux in my laptop, even when i run the OrangePi OS arch version it starts magically working. Even worse so is, if i just go and think " o well let's just put it manually" when you do the OMV installation that is not an option, whenever i attempt to put it manually it works until you reboot the system; once you reboot it just starts attempting to get a Ip automatically again as if it didn't save the previous static Ip. I have attempted everything to make it work and even if i put a USB to ethernet adapter or i just connect it to a regular router, it just won't get the Ip automatically. Please help. PS Sorry for the bad English, not my main language.

We have 6.6.rc1 kernel installed using Armbian_23.11.0-trunk.105_Orangepi5_jammy_edge_6.6.0-rc1_xfce_desktop.img.xz. I've also installed the Armbian Linux edge headers 6.6.0-rc1-edge-rockchip-rk3588 (linux-headers-edge-rockchip-rk3588 23.11.0-trunk.107). I am able to compile externel kernel modules. I would like to get the kernel source for the 6.6.rc1 kernel. I have cloned the main branch using: git clone --branch=main https://github.com/armbian/build And used the menu system by running compile.sh to select orangepi5 and other options. When it started building I could tell right away it was not working towards the 6.6.rc1 kernel. What combination of options do I need to built the 6.6.rc1 kernel based content? /compile.sh BOARD=orangepi5 BRANCH=??? BUILD_ONLY=kernel RELEASE=jammy KERNEL_CONFIGURE=no What value should be used for BRANCH= in the above? I'm not even sure I've got the correct git repo. Do I clone --branch=main or something else? Thanks for reading. ~Mark P.S. Some system details: OS: Armbian (23.11.0-trunk.107) aarch64 Host: Orange Pi 5 Kernel: 6.6.0-rc1-edge-rockchip-rk3588

I have 23.8.1 Jammy installed with kernel 5.10.160 and I'm getting plenty of kernel errors during any video playback, and these also cause the playback to freeze. From my research, these error messages come from librga - which I assume come from the panfork and rockchip repos but I was wondering if anyone has been able to resolve these errors.

Standard install - Armbian Bookworm, full 'firmware install'. I am getting some packet loss over the LAN. A raspberry pi, Synology NAS and Deban x86 install on the same LAN do not seem to exhibit the same loss. Anyone have experience or ideas? Oddly enough this never seems to occur on fresh installs. This is a docker host for pihole and home assistance, no other packages are really installed at all. I've not really tried much, but since this is a standard install, apt-get update & upgrade are about the only modifications outside of docker install that has occurred. 1. This plugs directly in to a Ubiquiti switch 2. I have tried a few different ethernet cables. 3. dmesg does not really show disconnects on the regular

Hello everyone, I recently installed my orangePi 5 to pass workload from my x86 servers over to the orangePi. My main focus is to reduce my overall energy consumption of my homelab. TL;DR Kernel thinks, that while being idle the sweet spot for the frequencies in "ondemand" and "schedutil" is: 1024MHz on the small chips (CPU0-3) 816MHZ on the big chips (CPU4+5, CPU6+7) Reason is an internal cost calculation power vs. frequency gain, which sorts out the lower frequencies. Long story: After getting my first orangePi5 in place, I started to play around with the hardware. I am running: █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (23.11.0-trunk.43) aarch64 ███████████████████████ Host: Orange Pi 5 ▄▄██ ██▄▄ Kernel: 6.5.0-rc5-edge-rockchip-rk3588 ▄▄██ ███████████ ██▄▄ Uptime: 5 days, 17 hours, 24 mins ▄▄██ ██ ██ ██▄▄ Packages: 459 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.2.15 ▄▄██ ██ ██ ██▄▄ CPU: (8) @ 1.800GHz ▄▄██ █████████████ ██▄▄ Memory: 1439MiB / 7688MiB # cpufreq-info (cropped for low and high cores) cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: rockchip-cpufreq CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 72.0 us. hardware limits: 408 MHz - 1.80 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 1.80 GHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 408 MHz:0.00%, 600 MHz:0.00%, 816 MHz:0.00%, 1.01 GHz:99.91%, 1.20 GHz:0.07%, 1.42 GHz:0.01%, 1.61 GHz:0.00%, 1.80 GHz:0.01% (38672) [..] analyzing CPU 7: driver: rockchip-cpufreq CPUs which run at the same hardware frequency: 6 7 CPUs which need to have their frequency coordinated by software: 6 7 maximum transition latency: 356 us. hardware limits: 408 MHz - 2.21 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 408 MHz and 2.21 GHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 408 MHz:0.00%, 600 MHz:0.00%, 816 MHz:99.91%, 1.01 GHz:0.03%, 1.20 GHz:0.01%, 1.42 GHz:0.02%, 1.61 GHz:0.01%, 1.80 GHz:0.00%, 2.02 GHz:0.00%, 2.21 GHz:0.02% (41580) So, why are the lowest frequency not reached? Tests with the "powersave" showed, that the kernel is able to set these frequencies. The "ondemand" scheduler showed no difference. # uptime 15:44:20 up 5 days, 17:26, 2 users, load average: 0.00, 0.00, 0.00 Load average is pretty much like nothing. So, I started to doubt that everything is working correctly: Why does the frequency selection work like this? Why are the lowest frequencies not considered in the evaluation? Are the little/big difference between the cores accounted and used? What are those error messages on system startup? I was not able to find anything useful about any limitations, known errors or open bugs. I wasn't able to find a hint, that explained why "ondemand" and "schedutil" won't hit the lowest possible frequency. And yes! I used Google for several days. So, I started to dig into the following messages from my bootup: [ 1.790851] cpu cpu0: _parse_named_prop: Invalid number of elements in microvolt property (6) with supplies (1) [ 1.790862] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 [ 1.790867] cpu cpu0: OPP table can't be empty [ 1.799837] cpu cpu0: EM: OPP:816000 is inefficient [ 1.799858] cpu cpu0: EM: OPP:600000 is inefficient [ 1.799865] cpu cpu0: EM: OPP:408000 is inefficient [ 1.800170] cpu cpu0: EM: created perf domain [ 1.800981] cpu cpu4: EM: OPP:600000 is inefficient [ 1.800992] cpu cpu4: EM: OPP:408000 is inefficient [ 1.801222] cpu cpu4: EM: created perf domain [ 1.802005] cpu cpu6: EM: OPP:600000 is inefficient [ 1.802014] cpu cpu6: EM: OPP:408000 is inefficient [ 1.802246] cpu cpu6: EM: created perf domain The first two messages are based of the OPP device drive, reading the tuples from the system(/or predefined structures?) containing power information about the given CPU cores. The message "OPP table can't be empty" seem to be emitted by cpufreq-dt, which is working side by side with OPP to organize the internal CPU information. From an earlier research I found we are using the driver "rockchip-cpufreq" on rk35xx/rk3588 for doing OPP handing, which is using the cpufreq-dt functions, too. That driver is needed, because we have to handle more then one OPP table. The next thing was "cpu cpu%d: EM: OPP:%d is inefficient" entry. That message comes from deep inside the kernels common code: "energy management". After some digging, I found out, that armbian is compiled with debugfs enabled (yeah) so we can peek into a lot of counters. The energy management is described in details here: https://docs.kernel.org/power/energy-model.html - I read the code first and found out later that documentation is very accurate. I'm glad, that armbian is build with debugfs enabled, so all counters from energy_management are available under: /sys/kernel/debug/energy_model Basically these are the counter for my orangePi5 chip and how the kernel evaluates the costs for each frequency level (I marked the frequency from above): cpu0/ps:408000/cost 230850 | cpu0/ps:600000/cost 230850 | cpu0/ps:816000/cost 230850 | cpu0/ps:1008000/cost 230850 | <--- cpu0/ps:1200000/cost 246496 cpu0/ps:1416000/cost 279327 cpu0/ps:1608000/cost 314211 cpu0/ps:1800000/cost 370386 cpu4/ps:408000/cost 330669 | cpu4/ps:600000/cost 330670 cpu4/ps:816000/cost 330669 | <--- cpu4/ps:1008000/cost 358800 cpu4/ps:1200000/cost 388078 cpu4/ps:1416000/cost 418503 cpu4/ps:1608000/cost 450077 cpu4/ps:1800000/cost 551690 cpu4/ps:2016000/cost 663635 cpu4/ps:2208000/cost 785915 This is the reason why ondemand, conservative and schedutil choose these frequency as a minimum frequency. The kernel does not seem to have an efficiency gain in terms of power vs energy consumption. The calculation is cost = max_frequency * power_for_frequency / frequency . Where does the "power_for_frequency" come from? These are also delivered and available: cpu0/ps:408000/power 52326 cpu0/ps:600000/power 76950 cpu0/ps:816000/power 104652 cpu0/ps:1008000/power 129276 cpu0/ps:1200000/power 164331 cpu0/ps:1416000/power 219738 cpu0/ps:1608000/power 280696 cpu0/ps:1800000/power 370386 cpu4/ps:408000/power 61102 cpu4/ps:600000/power 89856 cpu4/ps:816000/power 122204 cpu4/ps:1008000/power 163800 cpu4/ps:1200000/power 210912 cpu4/ps:1416000/power 268388 cpu4/ps:1608000/power 327774 cpu4/ps:1800000/power 449748 cpu4/ps:2016000/power 605928 cpu4/ps:2208000/power 785915 This cost value surprised me, that it is the same for the first frequency levels, so I did the math and it is correct. (In fact, I did that to prove my assumption, that I interpreted the cpu-flags correctly, too.) Basically, I found the reason why we are "locked" at these particular frequencies and are not saving more Watt. Unfortunately there is no official way to adjust the cost values to allow the energy_management to do a different decision. What bothered me is, that cpufreq-info shows a complete frequency list and maintains all available frequencies. It took me another hour to figure out, that the energy_management source code (em_cpufreq_update_efficiencies) reports the findings via the function cpufreq_table_set_inefficient to the frequency table inside cpufreq. On that way, the frequency table receives flags for the "inefficient" frequencies, which is taken into account by any sophisticated governor (ondemand, schedutil..). These information is not transported by any cpufreq utility to the user. Bonus question: Does the different power levels of the cores being taken account into the CPU-scheduling? 1. We can see here, that different performance domains are created: [ 1.800170] cpu cpu0: EM: created perf domain [ 1.801222] cpu cpu4: EM: created perf domain [ 1.802246] cpu cpu6: EM: created perf domain 2. Is the energy_aware scheduler active? # sysctl -a | grep sched_energy_aware kernel.sched_energy_aware = 1 It is! Writing this down shortens the path of finding everything out against the real invest into the research 😄 . The Kernel documentation is very helpful, but the debug information need to be found inside the source code (I'm fine with thaT). I recommend reading the https://docs.kernel.org/scheduler/sched-energy.html , which has a very explanation how the energy_management from above works together with the scheduler. According to the documentation, it works the best with the CPU-governor "schedutil" because it works hand in hand with task scheduling information in opposite to "ondemand" which looks at the core-cpu consumption. Further reading https://docs.kernel.org/power/energy-model.html https://docs.kernel.org/scheduler/sched-energy.html https://docs.kernel.org/scheduler/sched-capacity.html Thanks for reading, I hope this will help someone out there. Matthias edit: maybe this is more relevant to the „advanced user/development section“ 🤔

Hi, I would like to use my usb wifi adapter from my old Raspi 3. `lsusb` shows: `Bus 007 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter` `ip a` shows: ``` 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 76:ac:9a:1c:50:76 brd ff:ff:ff:ff:ff:ff inet 192.168.18.213/24 brd 192.168.18.255 scope global dynamic noprefixroute eth0 valid_lft 1953sec preferred_lft 1953sec inet6 fe80::4450:f4d8:e15a:12c/64 scope link noprefixroute valid_lft forever preferred_lft forever ``` and `lsmod` shows: ``` Module Size Used by bnep 24576 2 zstd 16384 8 sch_fq_codel 20480 3 fuse 110592 1 ip_tables 28672 0 ipv6 434176 82 panfrost 57344 0 gpu_sched 28672 1 panfrost ```