Active threads

Thanks, @WINEDS. I see you guy's are all over it, have at least the Ethernet sorted, and hints on the path to WiFi. I found an AllWinner CPU board from Radxa, that uses the same network peripherals as the newer H96 Max V56. The Radxa Cubie A5E is reported to feature WiFi6 and Bluetooth 5.4 using it's BLink BL-M8800DS2, which would be a step-up for me. https://docs.radxa.com/en/cubie/a5e/other-system/tina-os/build-system <- bsp, etc. Wish me luck. GBEM 👽

In the meantime, I spotted the pending MR from https://github.com/tmshlvck for this in the Pull Request Backlog. There are a number of issues with that, besides that it's very similar. Adding *.deb from xunlong without review is (mmm), better stay away from this. I'm not sure if the camera *.json is required. Not anything from the xunlong tree needs to be copied probably. I cleaned out my version (see https://github.com/sven-ola/armbian-build/tree/orangepi-rv2), but while this is open since October, I postpone to trigger another MR on that issue. My goal is: boot from upper 2230 SSD and use lower M.2 for Wifi (there are cheap Mediatek 3-band Wifi cards with 2280 adapter). If anyone wants similar setup, just checkout my branch from the link above and: ./compile.sh BOARD=orangepirv2 BRANCH=current RELEASE=trixie KERNEL_CONFIGURE=no BUILD_MINIMAL=yes KERNEL_GIT=shallow Write output/images/*.img to SD and boot with that. Use armbian-install to copy boot cfg on MTD. Again copy that *.img to /dev/nvme0n1. Remove SD card, reboot board. While investigating, there are a number of hints that the Ky X1 is in fact a SpacemiT K1 variant. Maybe stripped down, since the RCPU firmware (esos.elf) is much smaller. I have noticed, that Xunlong is not exactly welcome here. Chinese difficulties with the words upstream and donation probably. I think the hard work is to maintain / port the kernel and u-boot code drops with future versions. On the other hand: this board is cheap, offers a way to practice with a new CPU arch, and has the expected minimum number of M.2 slots. I'm currently compiling a kernel on that board. ETA 3 hours or so, board is not very fast. Anyhow, temp stays below 80°C if operated upright (above foto). No unusual hotspots, board and RAM seems stable, wifi and ethernet works. HTH and LG // Sven-Ola

What is booted also depends on boot scripts (and what is in armbianEnv.txt). This might have changed. And also the U-Boot code on the SD-card (sits invisible between partition table and 1st partition, usually sector 34-32767) might be newer and assume other defaults, I don't know. You need serial console cable and loglevel set to 7 so you can see what is happening after power-on. But maybe something else is wrong, at least make sure you post relevant info here on the forum. You can look in /usr/lib/u-boot/platform_install.sh to see where U-Boot is written. Also if you look there you can find some version string, likely in your mtd0/SPI is older than on the SD-card.

I failed to run DaveTheDiver using these settings: PanVk-mesa 26.0 + wine-Proton-10.0.3 + Dxvk 2.7.1(stripped) the log shows: Unsupported ioctl 74080 Faking StorageDeviceProperty data Is FEX or DXVK 1.7.1 is a must ?

lsinitramfs -l boot/initrd.img-6.1.115-vendor-rk35xx | grep dm-mod -rw-r--r-- 1 root root 249464 Nov 25 15:18 usr/lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/md/dm-mod.ko Looks like it is. Interestingly, when I update-initramfs -u, I do get warning about mdadm (failing to scan array) but I thought that the two issues were unrelated. Could it have an effect on the mapper availability? update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.1.115-vendor-rk35xx W: mkconf: MD subsystem is not loaded, thus I cannot scan for arrays. W: mdadm: failed to auto-generate temporary mdadm.conf file.

Duplicate

Could anyone advise the simple example on how to play media files using hardware decoding on VPU? I use actual version of Armbian with Edge kernel user@h96-tvbox-3566:~$ uname -a Linux h96-tvbox-3566 6.18.0-rc7-edge-rockchip64 #1 SMP PREEMPT Sun Nov 23 22:53:16 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux and seems that rkvdec is available user@h96-tvbox-3566:~$ v4l2-ctl --list-devices rockchip,rk3328-vpu-dec (platform:fdea0000.video-codec): /dev/video2 /dev/media1 rockchip,rk3568-vepu-enc (platform:fdee0000.video-codec): /dev/video3 /dev/media2 rockchip-rga (platform:rga): /dev/video1 rkvdec (platform:rkvdec): /dev/video0 /dev/media0 then I've installed MPV player from Armbian repository using apt command, but it seems that it doesn't support hardware decoding. I tried to use different hwdec options (rkvdec, rga, rkmpp, hantro....) but got "Unsupported hwdec" each time. user@h96-tvbox-3566:~$ mpv -hwdec=rkvdec --vo=gpu big_buck_bunny_1080p_h264.mov (+) Video --vid=1 (*) (h264 1920x1080 24.000fps) (+) Audio --aid=1 --alang=eng (*) (aac 6ch 48000Hz) Unsupported hwdec: rkvdec AO: [pulse] 48000Hz 5.1 6ch float VO: [gpu] 1920x1080 yuv420p Exiting... (Quit)

I think I've found it here.

moved. Has nothing to do with opi4a. Remove heatsink to get an idea which SoC hides beneath

That's great. Thanks for sharing.

@PH Ph bootloader -> /dev/block/mmcblk0p1 Maybe this is the boot.bin we are looking for? Try extracting it with Android_boot_image_editor.

Thank you ill go look

yeah, this is quite helpful, although the best solution is to wait at least until 6.19. But now I can see that the board was not abandoned, which I was a bit worried about. It seems to be a nice entry-level option and compatibility of both boards with rpi5 HATs due to the exposed PCIe is a great feature. I found the A53 cores quite speedy on Rock 2F and also not to produce much heat. That's why I might have been a bit impatient (I want to be able to use the pcie with mainline fixes).

Hi, Board: Radxa ROCK 5T SoC: RK3588 Armbian image: Armbian 25.11.2 for Rock 5T Kernel: 6.1.115-vendor-rk35xx Userspace: Debian stable (trixie) U-Boot package: linux-u-boot-rock-5t-vendor 25.11.2 (arm64) u-boot-tools: 2025.01-3 Boot device: NVMe (/dev/nvme0n1), Armbian 25.11.2 for Rock 5T https://paste.armbian.com/opokufetux Summary On ROCK 5T, a normal reboot performs a clean shutdown (all services stopped, filesystems unmounted) but the board does not restart. After reaching Reached target reboot.target - System Reboot., the system hangs for some time and then repeatedly prints an interrupt/IRQ table (GICv3/ITS) on the console. A hardware power cycle is required to recover. Reboot is therefore unreliable / effectively broken. Poweroff hangs in the same way as reboot (clean shutdown, then IRQ table on screen, board does not actually power down). Configuration details Relevant /boot/armbianEnv.txt (current state): verbosity=1 bootlogo=false console=both extraargs=cma=256M reboot=warm sysrq_always_enabled=1 overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588-rock-5t.dtb rootdev=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac rootfstype=ext4 overlays= usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u /proc/cmdline confirms the kernel parameters are applied: root=UUID=fbf76c4c-167a-49b2-81a4-e1b0220e8cac rootwait rootfstype=ext4 splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cma=256M reboot=warm sysrq_always_enabled=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory androidboot.fwver=ddr-v1.18-9fa84341ce,bl31-v1.48,uboot-rmbian-201-09/01/2025 Observed behavior Run sudo reboot. Systemd performs an orderly shutdown: services are stopped, all filesystems (including NVMe root) are unmounted or remounted ro, shutdown target is reached: Reached target reboot.target - System Reboot Instead of resetting and returning to U‑Boot, the board hangs. After some time, the HDMI console repeatedly prints a tall table of interrupts (GICv3/ITS entries, many zeros, some counters for PCIe/NVMe, USB, etc.), and never actually reboots. Only cutting power recovers the board. The system otherwise runs stably under load; NVMe, PCIe, network, and filesystem are all healthy. Workaround As a workaround, the reboot target was overridden to trigger a SysRq hard reset after a brief delay, so that services can shut down cleanly first: /etc/systemd/system/systemd-reboot.service.d/override.conf: [Service] ExecStart= ExecStart=/bin/sh -c 'sleep 5; echo 1 > /proc/sys/kernel/sysrq; echo b > /proc/sysrq-trigger' TimeoutStartSec=0 With this override in place: sudo reboot now: does a normal orderly shutdown, waits ~5 seconds at the end, then does SysRq + b to force a full reset, the board reliably returns to U‑Boot and boots again. This confirms that: clean shutdown works, a forced hardware reset works, but the normal reboot path used by the vendor RK3588 stack on ROCK 5T leaves the SoC in a bad state (seen as GIC/interrupt dump on screen) instead of performing a full reset. What I think is wrong It looks like the firmware/bootloader + vendor kernel combination on ROCK 5T does not properly implement the reboot sequence (PSCIs / PMIC / reset controller), so after Linux hands control over, the hardware stays in some half‑reset state and keeps generating spurious interrupts instead of resetting GIC/PCIe/etc. completely. The fact that SysRq + b from a fully running system does give a clean hardware reset suggests there is a working reset path, but the normal reboot path used by systemd / kernel is not using it correctly. Could you: Confirm whether this is a known issue for: Rock 5T specifically, or the 6.1.115-vendor-rk35xx kernel / current U‑Boot/BL31 bundle for rk3588 on Armbian? Advise whether there is: a newer U‑Boot / ATF / device‑tree combination that fixes reboot on Rock 5T, or a recommended kernel parameter / DT change (e.g. different PSCI reset mode, watchdog reset, etc.) to get a reliable soft reboot without the hard SysRq fallback? If needed, provide debug instructions (extra bootargs, specific logs around PSCI/reset) so the issue can be characterized better. I can provide: full dmesg from a normal boot, photos or serial logs of the IRQ table that appears after reboot hangs (GICv3/ITS dump on HDMI), U‑Boot version / environment if required. Thanks in advance for looking into this.

In fact, image boot very well with minimal change. (dtb change and something about virtual console) It' s after 🥲

They are not empty. You need to go one level deeper: https://armbian.nardol.ovh/dl/tinkerboard/archive/ BTW, try https://github.com/armbian/imager It will be much easier.

Well, I finally used some disk drives to move the btrfs data live, repartition with GPT using a vFAT and btrfs partition with 16MB offset of u-boot before the first partition, so with this boots automatically, and I guess more mainline. Thanks @eselarm for your comments, I'll these variables later.

This is NOT a support request, more of a brag. Needing a backup system, I was enamored of the low power requirements to run the bpi-m5. But they have no sata ports to drive bigger SSD's. But I bought a 5 stack of 4Tb TMSC built SSD drives at $200/copy, figuring on using a USB3.2 hub and startech's usb3.2 to sata adaptors, a big drive cage and a 50 watt 5 volt psu. More than 3 drives plugged in was too much current for the hub, itgot hot & shut down, so I bought another hub & glued it to the otherside of the drive cage. Problem solved. Printed the shelves to hold the drives and a BPI-m5. I configured the 5 SSD's into a software raid6 of 11TB. A friend that is really good at shell scripts knocked up an rsync based thing that could go thru the user trees of all my machines, currently itself, this box, and all my cnc stuff in the garage, several 3d printers, a total of 8 machines, soon to be 9, making a backup of /home/gene or /home/cnc since cnc is first user on the pi running my big but old Sheldon lathe. This draws around 15 watts idling, up to 19 watts running, and does it all in 28 or 29 minutes. So that is something else these pi clones can do, and do very well. I've run it 7 or 8 times in two weeks, adding another 3d printer to the $systems list each time. Its used 4% of the 11TB so far. Using rsync the only expansion in storage is the backup copy of any file thats been changed since the last run. I love doing odd stuff like this just to see if it can be done. And it has succeeded beyond my expectations. That rpi4b running that lathe was another such "project". Started with an rpi3b which wasn't quite fast enough but its been running for over a decade, almost a decade since I switched it to a rpi4b. There, when the lathe is off, linuxcnc controls that too, the pi and monitor show as a 23 watt load. Whats not to like?

I had an error when installing armbian on my M96H androidtv S950L3. Anyone any idea to resolve this?

The holes are visible in the 4. Image of fedes_gl's first message. The holes are right to the display. The pins are connected to the AIP1628. This images are from the first layout version. I now have a second Board with V1.4 marked in the Layout. The holes are no longer present in this version. It has also has a different Wi-Fi chip, therefore Wi-Fi doesn't work in my current Armbian release with this v 1.4. box.

Hello! I've built my own sbc using the Allwinner H3 chip, and I'm looking to get a custom armbian image running on it. I've already successfully compiled an image by adding a new config to u-boot and armbian-build, and a device tree to the linux kernel. Now I'm looking to get the WiFi working, but I can't seem to find where I can change its pin definitions. I'm using the AP6212: the SDIO pins are connected to SDC1 (aka mmc1) like every other board, but the WL_REG_ON (aka WL-PMU-EN) and WL_HOST_WAKE (aka WL-WAKE-AP) pins are connected to GPIO pins different from all other boards, so I'll need to change their pin assignments in the kernel manually. But I can't find where are these pins defined! Do I need to change it via u-boot, the kernel, a module or some config file? Any pointers would be appreciated! Thanks in advance

bringing up a BIG 3d printer from square one on a bpi--m5 with a fairly new image. The pager requires 10 or more mouse clicks, starting with the _ . . . . . at the upper left corner of what I think is the default xfce4 screen. All the eye candy and mouse clicks to actually switch workspaces are very distracting when one is trying to configure klipper. Can all this be reduced to a single click on the dot representing that workspace in the micro-pager? The eye candy is impressive to visiting frogs, until its a PITA when actually doing work. We buy these things in 6 pack qty's to do work, and give you a small monthly support, but impressing the frogs is maybe .0000002% of the time spent as I don't invite the frogs in to see my printer farm very often.

I see the next specific inline comments in the Armbian patches for NenoPi Neo at https://github.com/armbian/build/blob/69e8482426c7da4482dae06edb838dfe8bfd9920/patch/kernel/archive/sunxi-6.12/patches.armbian/arm-dts-h3-nanopi-neo-Add-regulator-leds-mmc2.patch. + /* Warning: sunxi-5.18: + * The leds node is present in the sun8i-h3-nanopi.dtsi file + * You will have to fix this situation yourself + */ + leds { + compatible = "gpio-leds"; + Looks like Linux Kernel source itself has its own `/led/led-0` and `/led/led-1` now in https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/allwinner/sun8i-h3-nanopi.dtsi and it seems preventing patched `/led/pwr` and `/led/status` work. Now I added following Device Tree Overlay and both PWR and STAT leds works again as expected. /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/leds/led-0"; __overlay__ { status = "disabled"; }; }; fragment@1 { target-path = "/leds/led-1"; __overlay__ { status = "disabled"; }; }; }; Create this file as like `fix-leds.dts` then run `sudo armbian-add-overlay fix-leds.dts` by following https://docs.armbian.com/User-Guide_Armbian_overlays/ then reboot the device now PWR LED on and STAT LED blinks.

@Nick A Nice, thanks a lot for the information. I 'll cherry pick the commit in your link and build a new image. I'll let you know if i'm sucessfull or not.

Well, I can't complain about the up-to-dateness of my natively installed browser. Damn, everything is out of date again- It's urgently time for the latest updates for my distribution to become available.