Active threads

If any of you have experienced skipping and popping when seeking with vlc, you can try setting the audio sink to ALSA and one of the rockchip-es8316 options. That will smooth out the audio playback BUT you will quickly discover that anything pulseaudio related is locked out of using the soundcard while vlc is up. Instead, try this. Set vlc audio back to pulseaudio (or automatic, seems to map to the same thing) and then change these two lines in /etc/pulse/daemon.conf: -; default-sample-rate = 44100 -; alternate-sample-rate = 48000 +default-sample-rate = 48000 +alternate-sample-rate = 44100 Restart pulseaudio with systemctl --user restart pulseaudio and see if vlc plays nice with everything else as well as supporting smooth playback after seeking. It does for me. It seems that forcing pulseaudio to resample causes all sorts of hilarity (vlc seems to like putting everything out at 48000). I'm sure there's a reason why. I'm also sure if I know, I'll be sorry I do. I wonder, how hard is it to get the Vulkan video hardware decoding working? Has anyone gotten it to work?

@usual userWell, this was also my feeling that there might be something wrong with the device tree. The Hardkernel section for HDMI looks a little bit different compared to the HDMI section in the device tree I have used. I thought it would be kind of okay, because the kernel is a different one. But maybe this assumption was wrong... So what could I do if I'd like to try the Hardkernel DTB? Is there a chance that it just works? Or would it be the better way to create an device tree overlay? I don't know anything at all about that, sry... EDIT: Could there be other reasons? Like an deactivated video output option somewhere? Or maybe it need to be actively activated? Please let me know if I can provide further information, file contents or so...

After many days spent wondering why is my OPI Zero2w 1.5GB not booting some Armbian images (xfce desktop version for example), I have found there is a "bug" or difference in uboot models 1.5GB + 4GB vs 1GB+2GB. Fix that might work for Zero2w is here https://forum.armbian.com/topic/31654-orange-pi-zero-2w/ (planning to test it soon) Can somebody confirm Opi Zero2W 1.5GB has still this issue with some Armbian images ? Armbian minimal boots without aby issues. Not sure why it works and desktop doesnt.

@KhanhDTP Amazing, thanks!! I'll give it a go. Just to check - how did you launch Portal ... from within Steam? ... or direct from the Portal folder? Did you use any special arguments when launching it? Thanks.

Only that its a known issue. In open source world it is normal to see magnitude more issues then its resolving capacity. I'll look into when possible - its high on 2do list. No need.

Yes for sure, thank you. > lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 2b89:8761 Realtek Bluetooth Radio Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 004: ID 0583:2060 Padix Co., Ltd (Rockfire) 2-axis 8-button gamepad > sudo dmesg | grep -i bluetooth [ 1.706048] usb 6-1: Product: Bluetooth Radio [ 4.360426] Bluetooth: Core ver 2.22 [ 4.360457] NET: Registered PF_BLUETOOTH protocol family [ 4.360460] Bluetooth: HCI device and connection manager initialized [ 4.360466] Bluetooth: HCI socket layer initialized [ 4.360469] Bluetooth: L2CAP socket layer initialized [ 4.360480] Bluetooth: SCO socket layer initialized [ 4.415023] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 4.417020] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 4.417027] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 4.417442] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 6.328832] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 6.328847] Bluetooth: BNEP filters: protocol multicast [ 6.328859] Bluetooth: BNEP socket layer initialized [ 870.557589] usb 6-1: Product: Bluetooth Radio [ 870.569776] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 870.571601] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 870.571614] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 870.571686] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 1246.745679] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 1246.747602] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 1246.747629] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 1246.747756] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 3667.259558] Bluetooth: RFCOMM TTY layer initialized [ 3667.259580] Bluetooth: RFCOMM socket layer initialized [ 3667.259595] Bluetooth: RFCOMM ver 1.11 [65689.757539] usb 4-1: Product: Bluetooth Radio [65689.769644] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [65689.771604] Bluetooth: hci0: RTL: rom_version status=0 version=1 [65689.771649] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [65689.771913] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin And here's a pastebin of the full dmesg output. https://pastebin.com/wMuX0bVW I got the driver files from here, https://github.com/Elif-dot/RTL8761BU uname Linux opi5 6.16.4-edge-rockchip64 #1 SMP PREEMPT Thu Aug 28 14:34:51 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux thanks

Now it seems that the package is missing for version 25.8.2 and arm64 target. There are packages depending on it (and specifically asking for version >=25.8.2), so this prevents upgrades.

This kernel is available only when you change repository to beta.armbian.com , which provides daily builds. EDGE kernels comes as is - glad to hear it works, but beware it might also break down as kernel is changing rapidly.

Hello, everyone! I have this same exact model, however, when I tried to boot it from the SD card it does nothing, I tried to hold the reset button and it seems to be stuck on boot. I used etcher to image the file shared by sicxnull, do I need to edit anything else? Am I míssing something? Thanks in advance for the help.

@lowscore I'did uploading for you! https://drive.google.com/file/d/1kgyjLl0JXTwFfWfplOKuQY3vLv_KtYlr/view?usp=sharing

Also step 1A & 1B are kind of weird... Like updating won't recognize the gpg key. I still could bypass the error by adding [trusted=true] on step 1B between deb and the link (or use sudo nano /etc/apt/sources.list.d/panfork-mesa.list if the file was already created).

Hi is there a way to enable the old USB port without re-installing Armbian? I have done to much setup work to start all over again.

Yes, or at least there should be less chances to hit some corner case that reduces the compatibility. LibreELEC is using the mainline kernel only for years though, so it is really strange you have issues with both armbian and multitool. I may wonder there is something odd in the device tree, but it would be odd that a misconfiguration in the device tree causes a kernel fault in the DRM code and in particular in the wait for vblank function 🙄

Hi Guys, I just did a new custom Armbian build ./compile.sh BOARD=orangepi5-plus BRANCH=vendor RELEASE=noble KERNEL_ONLY=yes KERNEL_CONFIGURE=no. The image is Armbian-unofficial_25.11.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop and when I installed it on orangepi I see it is not supporting Panfrost/Mail: glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: llvmpipe (LLVM 20.1.2, 128 bits) OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.0.7-0ubuntu0.24.04.2 but for older image Old_Armbian-unofficial_25.08.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop All was well glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: Mali-G610 (Panfrost) OpenGL version string: 3.1 Mesa 25.0.7-0ubuntu0.24.04.2 I did need to enable "ARM Mail Display Processor" under Device Drivers -> Graphics support -> ARM devices before I perform custom build. And I did this for both OS version 25.11.0 and 25.08.0. But newer version is not able to use it. Thanks Manish

Delete the cache and output folder. Try again.

Hmm. That came across as a bit passive-aggressive, but alright — the question really was poorly phrased and in the wrong place. My intention was to find people from here who had already taken the test... because if documentation were enough, online forums wouldn’t exist 8^)

> ... straightforward and smooth. Same in 25.8.2

@Unrealchex try the x98h image. Or you’ll need to take the wifi node from x98h and add it to your dts. Not sure why your build stops in the middle of the kernel patches without any errors. Are you sure that's the full log?

Ecco una risposta adeguata per il forum in inglese, considerando il tuo aggiornamento: Hello everyone, I’ve reviewed all the connections carefully using the reference manual to ensure everything is correctly wired. Unfortunately, while the display powers on and stays brightly lit, I still don’t see any output on the screen. Here are a few thoughts and tests I’ve tried: Initialization Problem? I’m unsure if the issue is related to the initialization sequence. I don’t know how to create one tailored to this display. Perhaps this could be due to the fact that it’s an ST7735S, while the driver is designed for the ST7735R? Could this be causing incompatibility issues with the current driver? GPIO Changes: I’ve also experimented with changing the GPIO configurations, specifically: dc-gpios = <&pio 2 6 1>; /* changed the 1 to 0 */ r eset-gpios = <&pio 2 9 1>; /* changed the 1 to 0 */ However, this had no effect. Kernel Compatibility: When I use a kernel version 5.x, the display works correctly. But with the current configuration and the newer kernel, I can’t seem to get it to work. This might be a kernel-level issue, or perhaps something changed in how the driver is initialized. Temporary Workaround: I’ve ordered another display to rule out any potential hardware issues, but it will take a while to arrive. At this point, I’m unsure of how to proceed. If anyone has advice on adapting the driver for ST7735S or creating a compatible initialization sequence, I’d greatly appreciate it. Thanks in advance for your help!

Some manufactures change the wifi and lan controllers to keep prices down on new BOM of materials: @WINEDS got experience with thos problems https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/page/16/#comment-210825 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-217289 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-216154

Please share your .desktop file... with sensitive information redacted.

Hello. Sorry to be late. I succeed, I find the image to be installed. I think it was debian-12.11.0-arm64-netinst.iso.

A known issue with the Odroid XU4, HC1, and HC2 is that it (uboot?) does not properly park the hard disk heads before/during shutdown or power cycle/off. So, the disk drive is forced to emergency hard retract the heads when power is shutdown/cycled. This is of course a violent action for the HDD and should be avoided. Use this odroid.shutdown script and install into /lib/systemd/system-shutdown/. https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script Recommend adding to armbian for XU4 distros.

Just a note the download of latest release Armbian_25.8.1_Odroidxu4_noble_current_6.6.102.img works fine, so something in the build system.

Hi again Werner. Please excuse the long waiting time. It's taken me a long time to place back the device at its intended location. Here's the requested output. https://paste.armbian.com/alefaladep At the moment I've got it running on a realtek usb-ethernet dongle at full speed (confirmed throughput up to about 300Mbit). Last year when I created the thread we were using the Nanopi Neo4's onboard realtek ethernet port. No matter what we did it wouldn't run at speeds over 10Mbit. And no, the port isn't faulty. It's happening on ALL armbian devices (official and unofficial) on current distributions still to this day. Bookworm/Trixie/Noble/Jammy, with kernels 6.12, 6.6, 6.1 and 5.15 tested. On x86 debian it works right out of the box at full speed and we're talking much weaker hardware (Intel z8350). Thanks for your work. Armbian is definitely the future IMO.