Jump to content

MMGen

Members
  • Posts

    53
  • Joined

  • Last visited

Other groups

Long-term editor

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Results of my testing of prebuilt images with the Nano Pi M6: Armbian vendor kernel image (Gnome/resolute): no HW acceleration, even with Chromium. HDMI sound works but headphone output doesn’t. HDMI sound incorrectly identified as “Analog Output”. Armbian mainline kernel image (Gnome/resolute): HW acceleration works with Chromium but not with mpv. No sound, period. An audio device is identified and VU meter is active in the mixer, but both HDMI and headphones are silent. Official Friendlyelec image (Gnome/trixie): HW accel works with every media player I tested. Sound works perfectly, with devices correctly identified. System appears to be stable, with no crashes so far. Results of my testing of prebuilt images with the Rock Pi 5B: Armbian vendor kernel image (Gnome/resolute): no HW acceleration, even with Chromium. HDMI and headphone sound both work. HDMI sound incorrectly identified as “Analog Output”. Armbian mainline kernel image (Gnome/noble): HW acceleration works with Chromium. No sound. Clicking on the sound icon on the taskbar crashed the system and corrupted the filesystem, making the image unbootable. Official Radxa image (KDE/bookworm): HW accel and sound work for all media players I tested. There are issues with the ethernet driver and occasional video crashes when switching to fullscreen mode. Otherwise, the system appears to be stable. Verdict: if you want a usable RK3588-based workstation, use the images provided by the manufacturers. Armbian still has a long way to go.
  2. @robertoj: Yes, it truly is the vanilla mpv. All packages are from debian.org, not Friendlyelec. $ apt list mpv mpv/stable,now 0.40.0-3+deb13u1 arm64 [installed] $ apt list ffmpeg ffmpeg/stable,now 7:7.1.5-0+deb13u1 arm64 [installed,automatic] $ mpv --version mpp[949]: mpp_platform: client 18 driver is not ready! mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects libplacebo version: v7.349.0 FFmpeg version: 7.1.2-0+deb13u1 (runtime 7.1.3-3rockchip) FFmpeg library versions: libavcodec 61.19.101 libavdevice 61.3.100 libavfilter 10.4.100 libavformat 61.7.100 (runtime 61.7.103) libavutil 59.39.100 libswresample 5.3.100 libswscale 8.3.100 $ cat /etc/issue Debian GNU/Linux 13 \n \l $ uname -a Linux NanoPi-M6 6.1.141 #16 SMP Thu Dec 4 14:51:28 CST 2025 aarch64 GNU/Linux $ apt-cache show mpv Package: mpv Version: 0.40.0-3+deb13u1 Maintainer: Debian Multimedia Maintainers <debian-multimedia@lists.debian.org> Architecture: arm64 ... Filename: pool/main/m/mpv/mpv_0.40.0-3+deb13u1_arm64.deb Size: 1270108 SHA256: ab039661c5016d96161fb9649b99cdde34ec4dfc83248ed9e42abb30318ac901
  3. 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.
  4. @bedna: Actually, my previous answer was incorrect. That area is not empty: it contains the Protective MBR, GPT partition header and GPT partition table, and we don’t want to copy those for the following reasons: a) There’s no reason to do so, since we create the partitions later; b) If we did, we’d end up with a corrupted partition table anyway unless we copied the backup header and tables too. That’s why we skip this area and begin writing at 0x8000 (32k), which is where the Armbian bootloader begins. If you’re just making backups, there’s no reason not to copy all the data, however. Different goals, different methods.
  5. @bedna: Sixty-four 512-byte blocks is the same as eight 4k blocks from dd's perspective. In the GPT partition scheme, the first eight 4k blocks are blank.
  6. @Werner, @Igor: Is the Raspberry Pi 500 supported by Armbian? It’s the successor to the RPi 400, for which support is mentioned. Internally, it looks similar to the RPi 5, except that it seems to lack wifi.
  7. @quaSimba: Fantastic work! Will put a link at the top of the tutorial for visibility.
  8. @quaSimba: Thanks for your remarks and the link to the guide on Github. Hopefully I'll one day have a RPi to work with so I can support it in my script and tutorial. @fxkl47BF: The completion packages were removed because they can be horribly laggy on low-powered SoCs and I find them annoying in general. They can be easily reinstalled if desired.
  9. The automated script has been updated to support the Nano Pi M6 (Noble mainline kernel IOT/minimal image and Noble Gnome desktop vendor kernel image both tested). Use the -m option to include all loaded modules in the initrd. The boot partition size has also been increased to 400MB, which should fix out-of-space errors when upgrading via apt. The tutorial has been updated accordingly.
  10. Successfully tested on the Orange Pi 5 with Ubuntu Noble minimal mainline image. Note that this image kernel panics every now and then on bootup (something to do with power management and interrupts). Disabling networking seems to solve the issue The automated script now supports configuring the network interface on the target using ifupdown. This is primarily useful for statically configured setups
  11. Tutorial has been updated to include support for GPT-partitioned images
  12. Automated script has been successfully tested on the Orange Pi 5, with the Debian bookworm minimal (kernel v6.12) image (also GPT-partitioned) Note that there are some missing modules in the initrd in this image, resulting in a blank screen at startup. This can be fixed by booting via serial or network console, adding the modules listed by lsmod to /etc/initramfs-tools/modules and rebuilding the initrd
  13. The automated script has been updated to support GUID partition table (GPT) images Tested on the Radxa Rock 5B, with the Debian trixie minimal (rolling release) image The tutorial will be updated shortly with instructions for GPT
  14. The tutorial and automated script have been updated for images that use extlinux.conf to configure the bootloader. In addition, some logic has been added to select the correct network device name (eth0 on some systems, end0 on others). The script has been successfully tested on the Banana Pi F3 with the Ubuntu Noble legacy minimal image.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines