All Activity

v25.11.2 for Orange Pi 5 Plus running Armbian Linux 6.1.115-vendor-rk35xx on mine. Just saying. You should use a spoiler for the slop. tl;dr: vendor kernel has exactly nothing in common with mainline besides the fact that it is supposed to run in the same hw.

Many thanks for your reply. I tried FEX, but it appears that within bash, only CPU-emulated GPUs can be invoked. Consequently, I proceeded to test box64 combined with umu and protonge. After entering `export=proton_use_wined3d=1`, the launcher managed to open a black window. How should I proceed with debugging next? Much appreciated! log.txt

I have Orange Pi 5 Plus 32GB RAM version (no longer being sold). Known good kernel is 6.1.75-vendor-rk35xx I just ran sudo apt update and apt upgrade, and I knew this kernel 6.12.xx wouldn't work but I rebooted to try it anyway. Broken, dead, thought it may be DTB. I kept good notes from the prior problem. This board has been rock solid stable with 6.1.75 and I'm running with NPU for AI inference (requires rknn2, not the regular rknn, current version I was working on upgrading to tonight is rknn 2.30 as loadable module (.so). I have serial connected so I can recover via U-Boot and get the kernel back to 6.1.75. Here are the fixes Claude provided based on my prior notes. I hope this helps someone. Find me on X @iDare --- Claude Opus 4.6: This is a confirmed, well-documented upstream kernel bug. Here's the full picture: Confirmed: Known RK3588 GPU Power Domain Bug The Bug (Exact Match) Sebastian Reichel from Collabora reported that the Linux kernel crashes on Rock 5B when the panthor driver is loaded. The crash involves the rockchip power management domain failing to enable the GPU domain, followed by an SError Interrupt causing a kernel panic. Patchwork The Armbian forum thread from a Rock 5B user shows the identical crash signature to yours: The crash trace shows rockchip-pm-domain fd8d8000.power-management:power-controller: failed to get ack on domain 'gpu' followed by SError Interrupt on CPU5, code 0x00000000be000411 with the panic originating from panthor_init calling through rockchip_pd_power_on. Armbian Community Forums That user confirmed downgrading to kernel 6.12 fixed it for the edge branch. Root Cause The GPU power domain requires the GPU voltage regulator to be enabled before the power domain can be turned on. The regulator is enabled at boot time but automatically gets disabled when there are no users. If the GPU driver probes late, the system tries to enable the power domain without the regulator, causing an SError. Patchwork Your boot log confirms this exactly: rockchip-pm-domain: Looking up gpu-supply property in node /power-management@fd8d8000/power-controller failed No gpu-supply in the DT = panthor tries to power on GPU domain = bus fault = SError = kernel panic. The Fix (Upstream, Merged) The patch series adds GPU power domain regulator dependency for RK3588, including a specific DTS change for the Orange Pi 5 Plus (rk3588-orangepi-5-plus.dts). Linaro The v6 patchset was merged (commit f94500eb7328) into Heiko Stübner's tree. It landed in the regulator tree for-next and was applied to the Rockchip DTS tree. Patchew However, this fix is in kernel 6.15+ (merge window). Your vendor kernel 6.1.75 doesn't have it, and the panthor DT overlay is apparently being applied without the matching power domain fix. What Happened on Your Board Your apt upgrade likely updated the panthor DT overlay (rockchip-rk3588-panthor-gpu.dtbo) to a newer version that activates the mainline panthor driver path, but the vendor kernel 6.1.75's rockchip-pm-domain driver lacks the regulator handling code. The overlay enables the GPU node for panthor but doesn't add the gpu-supply property to the power domain controller node. Other Users Hit This Too Multiple Armbian forum threads report the OPi5 with kernel 6.12 failing to boot with kernel panic, and the 6.12.58 minimal image also has non-boot reports. Armbian Community Forums Another user reported their OPi5 Plus stayed stuck on kernel 6.1.75 even after apt upgrade to Armbian 25.2.2, suggesting the kernel package wasn't being updated through normal channels. Armbian Community Forums Recovery Plan Step 1: Boot via U-Boot serial (known-good commands) setenv initrd_addr_r 0x0a000000 ext4load nvme 0:4 ${kernel_addr_r} /boot/vmlinuz-6.1.75-vendor-rk35xx ext4load nvme 0:4 0x0a000000 /boot/uInitrd-6.1.75-vendor-rk35xx ext4load nvme 0:4 ${fdt_addr_r} /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb setenv bootargs console=ttyS2,1500000 root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 booti ${kernel_addr_r} ${initrd_addr_r}:${filesize} ${fdt_addr_r} This bypasses the panthor overlay entirely (loads base DTB directly). Step 2: Once booted, disable the overlay and pin the kernel bash # Comment out panthor overlay sudo sed -i 's/^overlays=panthor-gpu/#overlays=panthor-gpu/' /boot/armbianEnv.txt # Pin ALL kernel packages sudo apt-mark hold linux-image-vendor-rk35xx linux-dtb-vendor-rk35xx \ linux-headers-vendor-rk35xx linux-u-boot-orangepi5-plus-vendor # Verify apt-mark showhold cat /boot/armbianEnv.txt Step 3: Check what actually changed bash # See if a new kernel was installed dpkg -l | grep linux-image ls -lt /boot/vmlinuz* ls -lt /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb # Check overlay timestamp ls -lt /boot/dtb/rockchip/overlay/rockchip-rk3588-panthor-gpu.dtbo # Check apt history cat /var/log/apt/history.log | tail -50 Step 4 (Future): Proper Fix Options Once stable, you have two paths to properly restore GPU acceleration: A) Stay on 6.1.75 vendor + add gpu-supply to a custom overlay: dts // Custom overlay that adds gpu-supply to power-controller // This is the DTS fix from the upstream patchset &power_controller { gpu-supply = <&vdd_gpu_s0>; }; B) Wait for Armbian to ship a vendor kernel with the fix backported, or move to a mainline kernel (6.15+) once the full patchset is in a stable release. Are you at the serial console now? Let's get you booted.

Meson 8B is codename of s805 means its not 4k at all bro mine is also 8B i checked it with adb

Actually no. While 6.12.y may be an LTS kernel, support for rk3588 was barely there so very few boards actually work with this. I suggest to download/build an image with either "vendor" kernel 6.1.115 or "edge" with >=6.18.y. This should work better.

Armbian 26.2.1 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 4474ac0f1 (https://ryanfortner.github.io/box64-debs/) + ge-proton10-32 (https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-32) + DXVK-stripped v1.7.3 ~40fps@720p (mixed settings) Metal Gear Solid V - The Phantom Pain - v.1.01 (denuvoless version) (Tpp_steam_mst_en_0803_2200)

Other question ? When looking to previous boot log, it is strange to view u-boot date ? U-Boot SPL board init U-Boot SPL 2017.09-orangepi (Nov 15 2023 - 16:53:25) Trying to boot from MMC1

After reinstalling one fresh SDCARD based on Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img then behavior is the same, noting after following message.... Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking u-boot 0x00a00000 ... sha256(e17d8b540a...) + OK ## Checking fdt-1 0x00ad1370 ... sha256(5411c775cf...) + OK ## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK ## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK Jumping to U-Boot(0x00a00000) via ARM Trusted Firmware(0x00040000) Total: 715.486 ms

Sorry for the bad identification of my SBC. My model is one Orangepi5 plus, therefore it seems that Armbian_25.11.1_Orangepi5-plus_trixie_current_6.12.58_minimal.img.xz is the good choice ?

According to the datasheet (https://de.scribd.com/document/948890791/MT7988A-Datasheet) the supported baudrate seems to be between 300baud and 3Mbaud. However cannot tell anything about support status. Neither do I have this hw, nor did I ever dig into this soc. Starting with device tree overlays might be a good start or check the whole device tree in general for the uart nodes if present.

There is no such board. There is either Orangepi5 plus or Orangepi5b. Check your hw what you actually have. If there is indeed a "Orangepi5b plus" then it must be fairly new and is totally unsupported.

logs? versions??

I managed to boot armbian from SD card without eMMC. The way achived this is by create a bootable insomwrt with venodr u boot, using my script `./run.sh custom` then replace the ROOTFS with armbian's ROOTFS from there I could boot armbian and fix the fstab. So far it's working fine root@aml-s9xx-box:~# lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS mmcblk1 ├─mmcblk1p1 vfat FAT16 BOOT 1C34-0D25 200.9M 18% /boot └─mmcblk1p2 ext4 1.0 ROOTFS 6f2edfb1-adb2-4f1b-8087-46d189763c9b 5.2G 20% /var/log.hdd / zram0 root@aml-s9xx-box:~# uname -a Linux aml-s9xx-box 6.1.66-DBAI #1 SMP PREEMPT Fri Nov 29 09:52:27 +07 2024 aarch64 GNU/Linux root@aml-s9xx-box:~# uptime 01:44:24 up 19 min, 1 user, load average: 0.00, 0.00, 0.00 root@aml-s9xx-box:~# cat /etc/os-release PRETTY_NAME="Armbian 26.2.0-trunk.563 trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.3 ID=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 26.2.0-trunk.563 trixie" root@aml-s9xx-box:~#

Looks like only one HDMI port and one NVMe drive bays work on the edge kernels. Not sure whats wrong with HDMI port but two SSDs installed cause issues PCIE addressing. Probably overlay issue with the newer kernel images?

Howdy hey. What do you guys think of this Android TV Box Q19 Android16 Allwinner H618 https://www.aliexpress.com/item/1005011785087357.html it does claim 8GB ram and price is ~40 euro ? or 95 TV Box Android14 Allwinner H616 https://www.aliexpress.com/item/1005009496923463.html which one is a better bet?

I tried the nightly build, and I'm happy with the result. Vulkan and OpenGL are still running on the CPU, but I'll try newer images in the future. I did a quick test with Yamagi Quake 2. OpenGL 1.4 doesn't even get 60fps at 640x480, but it looks playable. Should run a lot faster once we can run Vulkan on the GPU. https://github.com/yquake2/yquake2/blob/master/doc/020_installation.md This the make command I used: make WITH_GLES1=yes WITH_SDL3=no -j4 I also tested Stable Diffusion XL Turbo with OnnxStream. Image generated in 7m27s. Looks like the CPU performance is as expected. You do need gcc-14 and g++-14. They are available in the repository. https://github.com/vitoplantamura/OnnxStream You need to change the architecture string in CMakeLists.txt. -march=rv64gcv

@Nick A Apologies for going a bit off topic but I've been searching for the SWT6621S driver source for my open source project, and your post is approximately the only reference to it I'm finding. is there any chance you could share? I've attempted to contact the same person you were successful with but as of yet no response.

Found the "no Wayland on current kernel" (see new PR https://github.com/armbian/build/pull/9515). glmark2-es2-wayland still reports a 462 score on 800x600. Thus I updated and renamed the image mentioned in previous post with a current 6.18 kernel. You need to switch from 6.6 with /boot/switch-6.18.16-current script, anything else described in the post still is valid. @maxsub Alternatively install a M2(m)-to-M2(e) adapter in the larger bottom M.2 slot and use a NGFF Wifi card, for example RTL8822CE should run

Thanks Werner. Could you please point to me where is best last download file reference for Orangepi5b plus ?

In the meantime I brought up an access point server using the nightly armbian build. So far it is running solidly. The WiFi is underpowered, while the rest of the system seems stable.

Hello, all, I am trying to confirm the actual status of UART support on the Banana Pi BPI-R4. Does the hardware UART work reliably and appear as a character device (e.g., /dev/uart*) under Armbian Linux? Also, what is the maximum baud rate supported by this port? And one more question: Does Armbian support the Quectel EP06 modem (LTE, mini PCIe)? Thank you in advance, SY, Serge

Hello I am using: Linux nanopineo 6.12.74-current-sunxi #10 SMP Thu Feb 19 15:29:56 UTC 2026 armv7l GNU/Linux PRETTY_NAME="Armbian_community 26.2.0-trunk.464 trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.3 ARMBIAN_PRETTY_NAME="Armbian_community 26.2.0-trunk.464 trixie" i am tring to bind spi1 to fbdev. Here are the configurations: /boot/armbianEnv.txt: /boot/overlay-user/spi1-st7789.dts: SPI1 is not generating any CLK or MOSI signals on the physical pins. Looking forward for any help Best regards, Genadi

Hi everyone, I'm very new to Armbian Linux. I'm about to acquire Orange Pi Zero 2W for my audio project. I have read some of the forum posts related to the SOC's native I2S, and I'd like to know if those problems mentioned in the posts have been resolved in the new kernel? Meaning that users don't have to write and compile their own device tree overlay and kernel mode driver? My project require a full duplex I2S with the CODEC as the master. Nothing fancy, just 2 channels in and 2 channels out. Hope someone can help clear the doubts so that I know for sure I will not be buying what I can not use. Thanks

I have dtb files used by manufacturers for compiling on the Android 5.1 system (OEM versions 2.17 and 2.19). It differs from boards like the firefly, for example: using a 100 Mbps network port, USB GPIO uses <0x50 0x0c 0x00>. Can anyone help with adapting this board? I want to compile it for armbian. 2.17.dtb 2.19.dtb

@xiboliyadongtu Did you try Hangover (which is Fex-emu)? https://github.com/AndreRH/hangover I saw someone had a problem with a similar online game with Box64 before. https://github.com/ptitSeb/box64/issues/3073#issuecomment-3689810679