All Activity

Well the only thing armbian-config does, is calling "armbian-install" which has been there for ages

i find it is very convenient now, not only able to choose boot from nvme or sata ssd. but can also install the image from armbian-config. last time im installing armbian i need to dd the image manualy into nvme. very nice work for armbian team

What firmware are you using?

correct

never heard of that one before so probably no.

@xiboliyadongtu Your log seems normal. The problem is that the game is ~100Gb. I don't have that much free disk space to try. It looks like the game is running, but it's just not using the proper GPU renderer. By default, it will use the WineD3D renderer on top of OpenGL (panfrost). 1) You can try Zink by setting those vars: 2) Try Dxvk-stripped: Download Dxvk-stripped here: https://github.com/khanh-it/dxvk/releases/download/releases/dxvk-v1.6.1-stripped-msvc-output.zip and copy the files x64/d3d11.dll, x64/dxgi.dll to the game's folder (/media/xiboliyadongtu/固态/BlackDesert/) setting those vars: Start the game, and see how it goes?!

Find a board similar to yours and make the necessary adaptations. and on Linux Rockchip: So we can do an shutuo-v8-rk3288 compatible: many times in mainline you can do some tricks like disabling all usb

so today im finally reinstall my opi5, and when choose mtd to flash i got two option, i guess the sata version is if im using sata ssd instead of nvme ssd?

Thanks for your reply. Sorry for the bad identification of my SBC, (i have many ). The board is this one : https://www.armbian.com/orange-pi-5-plus/ Therefore, it seems that my bug report is relevant

This 8TOPS AI computing SBC has two official o.s : ubuntu 22.04 aarch64 and OpenEuler 22.03 aarch64 Is there any Armbian .img available for this SBC ?

https://www.mediafire.com/file/f2iaay5gccs163l/TV_STICK_R3_TRB.rar/file

As I had read, the maximum amount of RAM the H618 handles is 4GB, so, this 8GB TV Box should be a false information.

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:~#