All Activity

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)

wifi works fine on our rock 5B+ board with the 6.18 Gnome build...

Yes. commit 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 Author: EvilOlaf <werner@armbian.com> Date: Thu Feb 26 18:09:38 2026 +0000 rockchip64: 7.0: Rebase on top of main diff --git a/patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml b/patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml rename to patch/kernel/archive/rockchip64-7.0/0000.patching_config.yaml diff --git a/patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch b/patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch similarity index 100% rename from patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch rename to patch/kernel/archive/rockchip64-7.0/add-board-helios64.patch :

Hi domillo, If the green light has started flashing, it may indicate that the system has been started, but at this point, we cannot determine the IP address of the Cubie a5e. Once you have a UART adapter, please try to capture the DRAM parameters of the Cubie a5e according to this document: radxa-cubie-a5e-u-boot/README.md Guation

WOL might work on a newer 6.18 release of the kernel. Btw do I have it right that you're using Armbian without OMV?

Thank you for the information mmgen, One thing you missed is the ffmpeg compilation information. Run: $ ffmpeg It will print out the ffmpeg version and all the libraries that were enabled, and all the libav* libraries it has compiled along with ffmpeg (libav* are parts of the ffmpeg project). The interesting information is whether it uses the "v4l2-request" library, which lets ffmpeg control a part of the kernel that controls the hardware decoder. When you run mpv -v yourvideo.mp4 you could also see v4l2request, or some other message about the hardware acceleration (at this point I doubt that v4l2request is used, because it works better in newer kernels)

Small update: the patch series on GitHub is now up to date with what I actually run on the board. It went from 106 to 129 patches, all on vanilla 6.18.38. https://github.com/ut-slayer/orangepi-4a-mainline What's new since the last drop: The GPU was running at the wrong frequencies (and now it isn't). This is the interesting one. The A523 GPU clock is not a linear divider — it's a cycle-masking one: rate = source * (16 - M) / 16. Everyone modelled it as linear, including the vendor BSP. The practical effect: what the kernel labelled "150/200/300/400/600 MHz" was really running at 487/648/560/750/599 MHz. So the GPU was faster than advertised, and thermal throttling to "400 MHz" actually raised the clock to 750. To be clear: nothing was ever unsafe. It ran like that for weeks, stable, at 920 mV, with temperatures in the normal range — the chip simply tolerates it. But the labels were wrong, throttling did the opposite of what it should, and you cannot tune power/performance on numbers that aren't real. Now the five operating points measure 149/199/300/399/597 MHz with the Mali cycle counter, from the intended parents. Credit where it's due: Chen-Yu Tsai spotted the fractional divider while reviewing a patch I sent upstream. That review also produced a Reviewed-by for the generic clk fix, which is now on the lists. PCIe / M.2. The controller and the Innosilicon combo PHY now probe, link training runs and the root port enumerates. I want to be honest about the limit of that statement: I don't own an NVMe drive, so I have only tested it with an empty slot. The bus comes up and behaves; whether a real drive negotiates, enumerates and performs is something I genuinely cannot confirm. If anyone here has an M.2 NVMe in this board, that report would be very welcome — including a failure report, which is just as useful. (Kernel side comes from Marvin Wewer's Armbian series, authorship preserved, plus a 1-lane fix from the BSP and the device-tree wiring for this board.) Hardware video decode works for H.264/H.265. With the cedar-ve shim in this tree plus the Allwinner userspace (libcedarc + gstreamer1.0-omx), YouTube plays smoothly in a WebKit browser (I use Cog). VP8/VP9 do not — that engine never raises its interrupt — so those codecs are capped and YouTube negotiates H.264 instead. Note the userspace half is not in the patch series and not in the published images yet. Also in: a display fix for a frame that could get stuck after direct-scanout transitions, and JOYDEV/UINPUT enabled (analog sticks were dead in software that opens /dev/input/jsN first). Images: the published v0.2 images are now well behind this. Refreshed Debian images (Desktop and CLI) built on this kernel are in preparation. No date promised — they go up when they're tested. Thanks again to everyone testing and reporting here; the eMMC and 4 GB confirmations came from this thread, and the PCIe work started because someone took the trouble to diagnose why NVMe didn't show up.

Uhm... What repository is that commit hash for? I tried armbian/build and armbian/linux and a couple of others but it doesn't seem to belong there. I don't expect this to be a single-day task. I'm OK to invest the time in finding out what happened and run a bunch of bisections, even if that needs to include both Armbian tool repos and the Linux kernel repo. I just need some pointers to what the right approach is here and what kind of scripts/setup I should be running for each iteration. I would expect having this procedure documented can help other people too, so I'd be happy to do some write up for it. I can think that: Maybe there's a way to provide a kernel repo commit to check out to the build infrastructure and get kernel packages built from that. I should be able to just sync the build scripts to whatever was current when 6.19 was released. Maybe there's some way to just "compile and install the kernel the old way" and ignore the packages part of it. But I'm not familiar with the uboot specific formats for images and initial ram disks and I fear the result of doing that might be missing patches or some other things and not be comparable to the package-based experience. And, yes, 6.19 might be some time ago, but AFAIU -current is still based on 6.18... next time that gets bumped up breakage will stop being "optional" for me.

It'll have kernel 6.18 on edge soon with working fans.

Good Morning together, I tried installing the image from here radxa-cubie-a5e-armbian-build@202f1bf. Unfortunately for me booting my 1gb Cubie a5e failed. The green flashlight is blinking (first a bit slower than a bit faster) which seems an improvement to the version before (static green light, no blinking) As soon as I'm getting a UART Adapter, I'll hopefully get some more insights about whats going wrong cheers.

It should be / it was reported fixed a week ago, but you need to make image on your own or use nightly automated builds.