All Activity

If you are using the friendlyelec image, can you really say "mpv is vanilla from Debian"? I am really asking, because I haven't used friendlyelec in a long time, and I don't remember if they have their own DEB repository. Can you identify the ffmpeg version and compilation options? Same with mpv. Run $ ffmpeg with no options, and it will print out the version and the libraries that were activated. $ apt list ffmpeg $ apt list mpv $ mpv --version $ cat /etc/issue $ uname -a I do remember that friendlyelec has some extra video abilities, because they maintain their own patches with bleeding edge code, while the official ffmpeg and mpv maintainers are still checking whether to accept the pull requests. Is it even possible to run "armbianmonitor -u" in friendlyelec? Do you see "v4l2-request" or "va-api" anywhere in the mpv log? is your gnome desktop running under X11 or Wayland?

@Nick_Sl @bickns — the headless build is up (146 MB, pure Debian 13, mainline 6.18.38, SSH from first boot): https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.2 If either of you gives it a spin, I'd love a short report — what works, what doesn't. No rush and no obligation; even "booted, nothing broke" is useful. @Nick_Sl — you offered to test, so I'm taking you up on it 🙂. Most useful gaps right now: NVMe / M.2 SSD, suspend, and the GPIO header (eMMC and the 4 GB variant were just confirmed by another tester). @bickns — if the board ever leaves the drawer: the analog codec driver works, but mic capture is the one bit I couldn't bench-test (no onboard mic here). With your outdoor-audio project, you'd be the only one who could close that gap. Zero pressure either way. And if you don't mind, I'll add you to the thanks in the repo — testers get named there (JamesCL is already in for confirming the eMMC and the 4 GB variant). Also, early days and no promises: the VPU (hardware video decode) is something I've now started digging into. Thanks both.

That sounds good. I'm not using the jack for mic or output but should be able to check the DSP when things are more tied down with this outdoor-audio project. Will let you know and thanks again on a great job with this board!!

Software complexity is extreme ... And only x86 I would assume, so there is very little of interests for us. It is enough that packages are assembled at different time, so they will have different (bugs &) fixes. Either Ubuntu will get this bug or xtradebs will be fixed. Soon both wil be fixed or both broken .... unless bug is down to the OS level. Where snap will win with its, presumbly, stabilized OS container.

On prebuild images we test video acceeleration within Chromium and it works. Both kernels, Ubuntu Noble / Resolute Gnome, same good or bad on all boards. Others userspace combo might not work and other/all video players we don't even try to cover. Our job is done, when at least one method works OOB. It was integrated. This is not needed anymore. For overlay, I don't know. I think its still needed and it that case, its certanly present. On kernel, where this is needed.

With the official friendlyelec image for Nano Pi M6 (trixie, gnome, 6.1 kernel), I'm getting hardware acceleration with the plain vanilla mpv from Debian: mpv --vo=gpu my.mp4 mpp[2968]: mpp_platform: client 18 driver is not ready! ● Video --vid=1 (h264 1080x1920 59.9998 fps) [default] ● Audio --aid=1 (aac 2ch 44100 Hz 128 kbps) [default] arm_release_ver: g24p0-00eac0, rk_so_ver: 10-616430-r0 mpp[2968]: mpp_info: mpp version: 958803d7 author: Herman Chen 2026-02-26 fix[h265d_rkv]: Fix rkv ref and poc setup overflow Using hardware decoding (rkmpp). AO: [pipewire] 44100Hz stereo 2ch floatp VO: [gpu] 1080x1920 drm_prime[nv12] Everything works wonderfully, and CPU usage is about 25%, compared to 500% for Armbian. Why can't rkmpp be enabled on Armbian to give us harware accel out of the box? @Igor: The overlay link you provided above (mesa-vpu) is broken. And no such overlay exists in the prebuilt images for the Nano Pi M6. Result: still no hardware acceleration for my M6 with Armbian.

@JamesCL This is a fantastic report — thank you, James. 🙏 You've actually confirmed two things I couldn't test on my own hardware… 1) eMMC works (detection + HS200 + read/write)… booting from eMMC is a separate step I haven't wired up yet. 2) 4GB variant confirmed (free -m shows 3830 MB)… The two warnings — you read it right, secure SRAM for OP-TEE/BL31, harmless, cosmetic DTS cleanup I'll tidy up. …that's the most useful kind of report there is. Thanks again! 🙌

I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.

Hi, I'm testing your Linux image on an Orange Pi 4B/4A with an eMMC installed and wanted to share the results. The image correctly detects the eMMC. The kernel recognizes the device as: mmcblk2: mmc2:0001 ISOCOM 58.3 GiB Operating mode: HS200 image : aurealnix-opi4a-debian13-cli-v0.2.img.xz @AurealNix Thank you for your work. Update: During boot, the kernel reports two reserved-memory warnings: OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram1@42350000' OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram2@43000000' The system remains fully functional. OP-TEE and BL31 reserved-memory nodes are present in the device tree, and eMMC HS200 operation has been tested successfully. root@orangepi-4a:~# uname -a Linux orangepi-4a 6.18.38-g59eb61929e89 #49 SMP PREEMPT Thu Jul 16 00:46:12 CEST 2026 aarch64 GNU/Linux root@orangepi-4a:~# free -m total used free shared buff/cache available Mem: 3830 330 95 9 3592 3500 Swap: 0 0 0 root@orangepi-4a:~# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.6 ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@orangepi-4a:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 7.4G 0 disk └─mmcblk0p1 179:1 0 7.4G 0 part / mmcblk2 179:32 0 58.3G 0 disk ├─mmcblk2p1 179:33 0 1.2G 0 part └─mmcblk2p2 179:34 0 57.1G 0 part /mnt/emmc-test mmcblk2boot0 179:64 0 4M 1 disk mmcblk2boot1 179:96 0 4M 1 disk root@orangepi-4a:~# fastfetch _,met$$$$$gg. root@orangepi-4a ,g$$$$$$$$$$$$$$$P. ---------------- ,g$$P"" """Y$$.". OS: Debian GNU/Linux 13 (trixie) aarch64 ,$$P' `$$$. Host: OrangePi 4A ',$$P ,ggs. `$$b: Kernel: Linux 6.18.38-g59eb61929e89 `d$$' ,$P"' . $$$ Uptime: 38 mins $$P d$' , $$P Packages: 299 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.37 $$; Y$b._ _,d$P' Terminal: /dev/pts/2 Y$$. `.`"Y$$$$P"' CPU: sun55i-t527 (8) @ 1.80 GHz `$$b "-.__ GPU: Allwinner sun55i-a523-mali [Integrated] `Y$$b Memory: 331.41 MiB / 3.74 GiB (9%) `Y$$. Swap: Disabled `$$b. Disk (/): 744.36 MiB / 7.19 GiB (10%) - ext4 `Y$$b. Disk (/mnt/emmc-test): 24.49 GiB / 55.91 GiB (44%) - ext4 `"Y$b._ Local IP (eth0): 192.168.7.12/27 `"""" Locale: en_US.UTF-8 root@orangepi-4a:~#

Hi xaja34, The patches and all code modifications used to build the 1 GB Cubie A5E images are already present in my repository. I pushed the complete Git commits alongside the prebuilt images that I published in the Releases section. You can find the changes here: radxa-cubie-a5e-armbian-build@202f1bf Best regards, Guation

@L. Jorge Soares Thanks a lot for testing both — genuinely, this is the most useful thing anyone can do for the project. 🙏 CLI: great to hear it boots and HDMI works on your setup — that's the first confirmation from hardware other than mine, so it means a lot. If you get time, I'd love to hear how it holds up (networking, USB, and the 4 GB variant if that's what you have). Root password: that's by design, not a bug. Root login is locked on purpose — the image ships with a default user / user account and SSH enabled, so an open root account would be a security hole. Use the user account with sudo: root shell: sudo -i (or sudo su) to set a root password if you really want one: sudo passwd root KDE image + Etcher error: let's pin it down. Full disclosure — I flash with dd myself, so I haven't actually run these images through BalenaEtcher; I'll test the Etcher path on my end to try to reproduce it. In the meantime, two quick checks: Verify the download — a truncated/corrupt download is the #1 cause of Etcher errors. The desktop image sha256 is: 63b0019423d2a320aaa5fe58df97db68823b353a30510ffa863fec475904e0ba Check yours: sha256sum on Linux/Mac, or certutil -hashfile <file> SHA256 on Windows. If it doesn't match, re-download. And thanks for the heads up — I'll also double-check on my end that the file on the release didn't get corrupted during upload. Card size — the desktop image is ~5.3 GB when written (bigger than the CLI one), so it needs an 8 GB or larger card. A smaller/oddly-sized card makes Etcher fail. If the checksum matches and the card is 8 GB+ but it still errors, it's most likely Etcher choking on the .xz — try Raspberry Pi Imager (Use custom → pick the .img.xz), Rufus (it writes in DD Image mode and takes the .xz directly), or on Linux just dd: xz -dc aurealnix-opi4a-debian13-v0.2.img.xz | sudo dd of=/dev/sdX bs=4M status=progress And if you can, paste the exact Etcher error text — that tells me straight away whether it's a size, decompression, or validation issue. Thanks again for digging in! 🙌

Mint packages its own Chromium as a deb package, whereas Ubuntu's Chromium is a snap (even `apt install` just installs a snap by default). So, all x64 packages work (and I confirmed by testing xtradeb PPA's x64 package, which works). However, it's also not ARM64 related, as the Chromium ARM64 Snap from Ubuntu 24.04 (I just tested that too) works perfectly fine. It's just the ARM64 deb package from xtradeb that seems broken, which is bizarre.

I had quick look at both new version 0.2 version. The CLI version boots up no issue, hdmi output works. Well test further. The KDE version, I get an error using BalenaEtcher writing the image to the SD. Also can you provide the root password? ( just notice Root is locked )

Meanwhile I did replace systemd-resolved on Trixie with resolvconf. Unfortunately, although the configuration now is (to my knowledge) mostly identical to the working Bookworm AP, it still does not work. When I connect a Debian system to both APs, the output of "ip r" is identical. Also the output of "dig <some server>". But "ping" works only partially for the Trixie AP: I get only a ping answer for the AP address. Same for traceroute. What I did observe using tcpdump: ssh communication with the Bookworm system gives "ack/seq pairs": 23:56:26.276869 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [.], ack 18029, win 537, options [nop,nop,TS val 1656092742 ecr 742514735], length 0 23:56:26.278437 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 18029:18105, ack 8352, win 344, options [nop,nop,TS val 742514737 ecr 1656092742], length 76 Whereas the same with the Trixie system gives (apparently much longer) sequences of only "seq" entries: 23:56:26.962828 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9612:9648, ack 19365, win 537, options [nop,nop,TS val 1656093428 ecr 742515405], length 36 23:56:26.964613 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19365:19401, ack 9648, win 344, options [nop,nop,TS val 742515423 ecr 1656093428], length 36 23:56:26.982677 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9648:9684, ack 19401, win 537, options [nop,nop,TS val 1656093447 ecr 742515423], length 36 23:56:26.984461 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19401:19437, ack 9684, win 344, options [nop,nop,TS val 742515443 ecr 1656093447], length 36 23:56:27.001390 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9684:9720, ack 19437, win 537, options [nop,nop,TS val 1656093466 ecr 742515443], length 36 I guess I get some SD cards now and install different clean images to start from ...

@Nick_Sl @bickns — no more waiting, the headless build is up. 🙂 It's a CLI / headless image for the Orange Pi 4A: pure Debian 13 (a debootstrap minbase — bare on purpose, add the rest with apt), the full mainline 6.18.38 kernel, SSH on from first boot. 146 MB compressed, idles at ~180 MB of RAM. Same kernel as the desktop image (HDMI, WiFi/BT, gigabit ethernet, USB, thermal + CPU/GPU frequency scaling) — just no desktop. It's the ...-cli-v0.2.img.xz asset here (the desktop image is on the same page): https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.2 Whoever gives it a spin: I'd really appreciate the feedback — especially if something doesn't work quite right. A lot of this only shakes out once other people run it on their own boards, so bug reports are genuinely welcome (here or on the GitHub issues). @bickns — "no special requests, apt adds the rest later" was exactly the design goal, so we're on the same page: it's a minimal base and nothing more. If you're still doing your own build for the Armbian-stable PR, the tip stands — for a headless target you can drop the whole display/GPU series (drm/sun4i + iommu + clk), which is where most of your ~20 rejects were coming from; you only need the dts + the ethernet/wifi/usb/thermal/cpufreq bits. One thing that's right up your alley given your outdoor-audio project: the A523 analog codec now has a working driver (ported from the BSP). Headphone output and jack-detect are validated on hardware; mic capture is wired in the driver but I couldn't bench-test it (no onboard mic here). You'd be the ideal person to confirm whether capture works — if it does, that's the last gap on this codec closed. @Nick_Sl — you said you could wait; turns out you don't have to. 🙂 If you're still up for testing, I'd genuinely love your results — flash it, SSH in, and tell me what breaks (especially on the 4 GB variant if that's what you have). Glad the board's out of the eBay pile.

i can wait

Weston 16 expands HDR and color management support, improves Perfetto debugging and DRM backend performance, and adds new protocol and renderer capabilities for more efficient and flexible Wayland compositor development. View the full article

Use framework and DIY. That's what it is made for

that looks like a very ambitious undertaking

@xaja34 hi images appear here: https://github.com/armbian/community/releases orangepi 4 pro seems have debian image now (sadly dont have resolute image): Armbian_community_26.8.0-trunk.359_Orangepi4pro_trixie_vendor_6.6.98_minimal.img.xz @jshkol anyone knows if have gpu acceleration? thanks

@Nick_Sl @bickns — CLI/headless image is coming. It's the same debootstrap base and the same kernel, just without Plasma/Mesa/Discover, so it's mostly "subtracting", not extra work — a small ~300–500 MB image. Nick, I'll ping you when there's something to test. 🙂 Before I build it: is there anything you'd want baked in by default? Thinking headless/server use — things like NetworkManager vs systemd-networkd, docker/podman, python3, build tools, an ssh-only footprint, zram on by default, etc. If you tell me your use case I'll pick sane defaults rather than guessing. Good news on audio in the meantime: both HDMI and the analog 3.5 mm jack are working now (with jack-detect hotplug), so that's no longer a blocker for either image.

sudo ip link set dev wlp1s0 down sudo ip link set dev wlp1s0 address 02:00:00:00:00:01 sudo ip link set dev wlp1s0 up sudo systemctl restart NetworkManager

Same problem here. There are two other (older) threads without a real solution. Has anyone found a fix?

Hello @BipBip1981, with Kernel 6.18.35 / Armbian 26.5.1, are you using @iav's new DTP patch or the old DTP file? I'm not sure if it makes any difference, so I was curious what you're using.