All Activity

I have an Orange Pi 5 Plus 16GB board, revision "1.3.1". I've been using it for about a year with official Armbian, Vendor kernel 6.1. The only issues I noticed were a non-working Type-C port and FAN connector. I thought it was an OS or DTS (Device Tree) bug... But it turned out to be a hardware problem. It started when I got another Orange Pi 5 Plus 8GB board for repair (needed to resolder the Type-C power connector). Same revision "1.3.1". (left is my 16GB board, right is the 8GB board for repair; the PCB solder mask is slightly different in shade of blue — probably different manufacturers or production batches) I inspected it under a microscope and found that both boards have floating (unconnected) vias — the ones that should control the FAN transistor, and also the EN-pin for the Type-C (USB3.1) power. So these are defective boards from some unknown revision where these vias are simply missing. On top of that, even if you force-enable the Type-C (USB3.1) EN pin — it still won't work. The reason is that the data lines are connected to TYPEC1 pins on the SoC, not TYPEC0 as shown in the OPI 5 PLUS_V1_3_1_Schematic.pdf So you need a DTS fix to enable the port via the correct node. The HUSB311 chip is also useless in this case. I don't know what exactly this revision is or why these errors exist. Fix: enabling power on the Type-C port To get the front Type-C (USB3.1) port working, I soldered the EN pin from the Power Switch — which was going TYPEC5V_PWREN_H Nowhere — to the nearest 3V3 Ethernet power rail. Now the Type-C port gets power after boot. The second step is to create a DTS overlay to make the port actually work: File: rk3588-orangepi-5-plus-TypeC-fix-hardware.dts /dts-v1/; /plugin/; / { model = "Orange Pi 5 Plus"; compatible = "rockchip,rk3588-orangepi-5-plus", "rockchip,rk3588"; fragment@0 { target = <&usbdrd_dwc3_1>; __overlay__ { dr_mode = "host"; maximum-speed = "super-speed"; snps,xhci-trb-ent-quirk; }; }; }; To apply the overlay, copy the file to your board and run: cd <path to file> sudo armbian-add-overlay rk3588-orangepi-5-plus-TypeC-fix-hardware.dts Also worth noting: since HUSB311 is missing on this revision, the CC1/CC2 orientation detection doesn't work properly. In practice this means: plug in a USB-C cable one way — the device shows up as USB2.0 (HighSpeed). Flip the cable 180° and replug — it shows up as USB3.0 (SuperSpeed). This happens because only CC1 or CC2 is connected (not both). If you need a PWM fan The PWM signal via for the FAN transistor is also floating on this revision — it goes FAN_CTL_H Nowhere. You can solder to it (either to the end of the nearby SMD resistor or scrape the VIA pad directly) and connect it to any free pin on the 40-pin header. Then update the DTS to assign that pin for fan control instead of the original one. P.S. Sorry for the low quality photos. Source: 4PDA

That is interesting, I would expect the other way around. I use 'btop' to watch clocks and load. On some systems, it also show GPU load and power consumption. Anyway, there is also the edge kernel (7.1.0-edge-rockchip64😞 linux-image-edge-rockchip64/trixie,now 26.5.1 arm64 [installed]

@Caleb Gilmour are you trying to flash using Rockchip Loader mode or Maskrom mode? Regarding wifi I will need to to do some performance testing when I have some time, I did not test it widely. Thanks for your feedback!

Well, I will wait until it works, no worry's. I wil not go back to the 115 kernel because the sbc is getting 10 degrees warmer than the latest gnome version, 47 degrees in the 6.1.115 and 36 in 6.18.28. Both with Firefox in YouTube with the same content... Te dongle works fine... Ernst

a very exciting development on mainline with VPU_GPU acceleration enabled https://github.com/ut-slayer/orangepi-4a-mainline/issues/2#issuecomment-5030458197

Apologies this seems to have posted twice could admin please delete one of them Hi all, I built an image for my new Odroid M2 16 GB board using the parameters in my config-odroid.conf BOARD=odroidm2 RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no Issued compile.sh odroid It built and booted first time I configured it using armbian-install to boot from the emmc and use a 1tb Samsung nvme as the system disk Rebooted after removing the sdcard Everything seemed to work until I tried to flash another image to the sdcard with dd The flash immediately stalled and killed my windows Putty session Some of the errors from dmesg mmc1: Card stuck being busy! __mmc_poll_for_busy dwmmc_rockchip fe2c0000.mmc: Busy; trying anyway mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80200000) GPT PMBR size mismatch (7675903 != 62333951) The primary GPT table is corrupt, but the backup appears OK. I have no idea what to do My intention was to try different images to ascertain which worked best which I can still do but i have to flash the card on another box I hope this makes sense Kind regards Pete Kane

Hi all, I built an image for my new Odroid M2 16 GB board using the parameters in my config-odroid.conf ``` BOARD=odroidm2 RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no ``` And issued compile.sh odroid It built and booted first time I configured it using armbian-install to boot from the emmc and use the 1tb Samsung nvme as the system disk Rebooted after removing the sdcard Everything seemed to work until I tried to flash an image to the sdcard with dd The flash immediately stalled and killed my Putty session Some of the errors from dmesg ``` mmc1: Card stuck being busy! __mmc_poll_for_busy dwmmc_rockchip fe2c0000.mmc: Busy; trying anyway mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80200000) ```

Feel free to test and send a pr with a patch backporting this to 6.18

Actually spoke to soon, seeing this issue on the 6.18 kernel but happens randomly, its a known upstream issue that has been fixed in 7.1, but you guys should back port this fix here: Upstream fixed this exact Radxa/RTL8852BE problem by retrying the eFuse operation five times. The fix is https://chatgpt.com/g/g-p-69619e56d4d48191866d830f3ebddfc0/c/6a5ee909-da2c-83ea-981e-de8591585c8c, with the Wi‑Fi/BT contention confirmed by the Realtek maintainer in the patch discussion https://patchew.org/linux/20260301042422.195491-1-christianshewitt%40gmail.com/?utm_source=chatgpt.com. The fix: Is absent from 6.18.28 kernel. Is still absent from vanilla 6.18.39. First shipped upstream in Linux 7.1. A matching ROCK 5B+ Armbian trace shows the PCIe device and firmware loading successfully, followed by the eFuse failure and error -16. Matching Armbian report.

i got the same problem my ethernet is gone. how does one downgrade i cant figurer it out at all

More likely: friendlyelec is maintaining a separate patch (source code additions to the official ffmpeg), that allows it to do it. The code should be available in the friendlyelec github, to be shared with the public. "No v4l2request"... that means that they implemented another protocol and/or another kernel module to work with the video decoder.

Thank you for your reply. My H96 Max M9 is running Android 14 with the original stock firmware. I have not installed Armbian or any Linux-based operating system. Therefore, I don't think I can run sudo armbianmonitor -u on the TV box. Is there an equivalent way to collect and share the Android system logs, for example using ADB and adb logcat or dmesg? The problem appears when Android's system file picker/Storage Access Framework is used by applications such as PPSSPP and Dolphin Emulator.

6.18.10 or 6.18.35? Gnome build? I look for kernels in armbianconfig... Ernst

Hi Armbuilder, I tried them all but only 6.1.115 made the internal WiFi work. Are there different versions of the board maybe? Ernst

@robertoj: $ ffmpeg ffmpeg: symbol lookup error: ffmpeg: undefined symbol: av_buffersrc_get_status, version LIBAVFILTER_10 Looks like Friendlyelec deleted some functions in their version of the library, or based it on an outdated version. ffmpeg is version 7:7.1.5-0+deb13u1 Filename: pool/main/f/ffmpeg/ffmpeg_7.1.5-0+deb13u1_arm64.deb MD5sum: 18e560e3b4c4b992d74d2bf3020d9a53 No v4l2request info with `mpv -v`

@eselarm: Thanks enormously for this information. I'm not a hardware expert, so much of this is over my head, but you clarified a number of things for me right away and raised a new bunch of questions. Will research things further. One correction: the Friendlyelec libav* libraries are under /usr/local and take preference to those under /usr, so they won't be affected by a Debian update.

That's the advantage when you use a device that doesn't have a PMIC and only goes into deep sleep mode for Off Mode. This is only supported by the proprietary, closed-source manufacturer firmware, for which of course no publicly available API description exists. Mainline support will therefore most likely not become available. So it basically just leaves reverse engineering and an out-of-tree implementation. Good luck.

moved to tvboxes

The board should have RT8821CU as wifi chip. Since Linux 6.17 there is no out of tree driver necessary anymore, mainline i used. So perhaps this is a an issue or regression upstream. You can try to switch to edge kernel, perhaps this has been addressed but not back-ported.

I compiled Linux from hardkernel–it works with the devicetree from petitboot firmware. There's a emmc-data-4b node (not in their source code) which does: &emmc_conf_pull_up { mux { drive-strength = <3>; groups = "emmc_nand_d0", "emmc_nand_d1", "emmc_nand_d2", "emmc_nand_d3"; function = "emmc"; input-enable; bias-pull-up; }; }; Trying this with mainline e.g. overlay=g12b-odroid-n2-spi isn't enough here. No option to wakeup (ir, lan, keyboard) is another reason to stick with 4.9.

Subject: Bluetooth: Unknown BR/EDR signaling command 0x16 / Wrong link type (-22) on meson-gx / Banana Pi M2 Pro Description: When connecting modern Android (POCO F7) and Windows/Linux devices (Lenovo Legion) via Bluetooth to Banana Pi M2 Pro, the dmesg log gets flooded with BR/EDR signaling errors during connection/disconnection phases. Steps taken: - Forced 'ControllerMode = bredr' in /etc/bluetooth/main.conf - Disabled USB autosuspend for the BT controller (set to -1) Logs: [ 345.122975] Bluetooth: Unknown BR/EDR signaling command 0x16 [ 345.123005] Bluetooth: Wrong link type (-22) Environment: - Board: Banana Pi M2 Pro (Amlogic S905X3) - Kernel version: 6.18.34-current-meson64 nano armbianEnv.txt extraargs=usbcore.autosuspend=-1 The problem with Bluetooth on bananapim2pro is that I constantly have trouble connecting. My tweaks to the settings fixed it somewhat, but not 100%... Finally, if all else fails, I use this method: sudo rmmod btusb sudo modprobe btusb sudo systemctl restart bluetooth sudo systemctl restart bluealsa But I have a question: are there any kernel/driver fixes or updates for this Bluetooth model?

Hello guys, i got 2 old fullbox rikomagic mk802 stick android mini pc. Variant Allwinner A10,Ram 512Mb. I tested armbian 26.05 via 4 config : limea1000 boot ok pcduino1 ok cubieboard ok olimex a10 lime stuck at boot os stage, same with official debian 3.4 kernel images of olimex enabled video output for desktop environment. It boot but will take a lot of time to finish

Hello, I believe @m1zfs's work on the DKMS modules is available here: https://github.com/vitalijborissow/rk3568-npu-ODROID-M1 I have spent many hours trying to get the NPU working on my ODROID-M1 (8 GB) running Armbian 26.5.1 with current kernel 6.18.x as well as edge kernels 6.19 and 7.1. I also tried building the latest Armbian image from source (July 19 build including U-Boot 2026.07), but so far I have not been able to get the device tree / overlay and DKMS modules from the repository working on any of these combinations. The system always fails to boot. Fortunately, I can capture the boot process through the serial console and see where it fails. The log shows a kernel exception related to enabling the RK3568 NPU power domain: rockchip-pm-domain fdd90000.power-management:power-controller: failed to get ack on domain 'npu', val=0x1ee platform fde40000.npu: Adding to iommu group 3 Internal error: synchronous external abort ... Workqueue: pm genpd_power_off_work_fn ... rockchip_pd_power From the log it appears that the crash occurs before rknpu.ko is loaded. This makes me believe the issue is more likely related to the device tree, overlay, power-domain, regulator, or clock configuration rather than to the DKMS module itself. Has anyone seen a similar issue on recent Armbian kernels, or can suggest a direction for further troubleshooting? I am still willing to spend some time investigating this and would appreciate any ideas or hints.

OK great that you got it working now! 2GB RAM works fine for HA, at least when running Supervised. I am not sure if Armbian can improve more when Supervised, as this is not supported anymore from the providers/developers of Home Assistant. I think a reason people go from SBC to Intel NUC is because there are things like VMware that IT pros might know from their profession/company. And RPL very long by default had/advised to use 32-bit also on more capable devices like RPi4 with 2GB RAM or even more. And also running from SD-card, and those wear out under high load and many writes. The whole problem with 'traditional RPi' is that it is unusual 32-bit ARMv6 build and not the standard 32-bit ARMv7 which is the minimum for support from Debian and most other distros. And in addition, 32-bit builds do not support the standard Linux Kernel Virtual Machine HW, standard in all 64-bit capable CPU's. Intel/AMD CPU's have support for HW virtualization also for 32-bit and much more known and commercial (also closed-source) hypervisors like VMware are pushed a lot more then the standard Linux build-in QEMU/libvirtd/KVM. So with 64-bit Linux, especially also on ARM, you get it by 'apt install virt-manager' and then you can run other OSses/images at full HW speed and is separated from the host OS, e.g. Armbian. Because images, many files or bigger databases are a burden for simple SD-card. Also because multiple OSses at the same time, it easily needs more RAM than the usual 1GB on SBC's like RPI3. Via virt-manager GUI and also CLI tool virsh, you can then run the generic UEFI bootable HAOS. For long-term and decent 24/7 operation, you will need SSD for storage. RPi's don't have that, you need adapters and HATs etc. But many other SBC's do have, so if you have an unused NVME for example, it fits perfectly in RK388 boards like ROCK5B for example. It is 4-lane PCI-E v3, so similar speed as Intel miniPC's. And most important, lower power consumption for similar total system price, at least before the RAM+storage prices went sky high. I measured my NanoPi-R6C with Samsung 970 NVME and Armbian Trixie (6.1.115 kernel) and is about 1.5 Watt when idle or doing some light tasks like running simple initial HAOS as Virtual Machine. See also:

You are not the 1st to do this: Let me explain the problem first. The CPU itself, without any storage attached, has a built-in U-Boot. However, this U-Boot does not initialize video output, so you won't be able to see it on an HDMI screen. (The good news is that it usually initializes the serial port.) This U-Boot reads environmental data from a data blob on the MMC (usually within the first 10 MB of the disk). This environmental data tells the U-Boot the sequence of commands needed for the MMC/USB U-Boot to boot. Once the MMC/USB U-Boot boots, you get video output. The problem is that you deleted the data blob containing the environmental data from the MMC, so the CPU's U-Boot does nothing. It just loops, saying that it found no device to boot. If you have a serial adapter, it is possible to interact with this CPU U-Boot. Pressing Ctrl+C (in a terminal that does not intercept Ctrl+C—my advice is to use PuTTY, even on Linux) should stop whatever it is doing. By interacting with this CPU U-Boot, you can instruct it how to boot your MMC or USB U-Boot. However, you will have to do this manually every time you boot. To fix the issue, you need to restore that data blob containing the properties to its specific location on the MMC. I don't know where it starts or what format it uses, so I was unable to recreate one from scratch. My way of fixing this was to find a backup of the original MMC and restore the first GB. So, did you make a backup? If yes, you can restore it with some serial magic. If you did not make a backup, you can search for one or ask someone who has one. (check that this thread for the other guy's solution)