Active threads

You are completely right - at least 50MB one is there /dev/zram1 on /var/log type ext4 (rw,nosuid,nodev,noexec,relatime,discard) But big 987MB /dev/zram0 isn't at all - so it looks like it's useless and could be removed from zram config, right? Both mystic /dev/mmcblk2bootX are still in question

Yes I'm aware that I can only rely on the community for any help or tip. I'm now considering to revert back to a bullseye setup with a 5.10 Radxa kernel, but I was kind of reluctant to keep an old version of Debian as my Rockpi is accessible from ouside my network... The Rockpi is powered by a PoE hat, it never had any issue so far but maybe the PoE management is the culprit. I'll try an use the Rockpi with a traditional power supply, but in any case if this is the issue it won't be a sustainable solution for my target setup.

Thanks @eselarm for the input that this should work. So I tested it. And it does! I leave a few hints for anyone who wants to replicate. When creating a new image layout working directly with the image files was the fastest for me. So you need to download one original Armbian image. I used a minimal cli image. Image preparations Create a new image file (e.g. with dd) that will be partitioned like described above. Copy all the first sectors until the first partition starts from the original image to the new image. This will copy the original partition table but more importantly also the uboot bootloader into the new image (32768 sectors = 16MB). Partitioning Partition the new image as described above (e.g. with fdisk/sfdisk) and format the new partitions. One smaller boot partition (e.g. 512MB, ext4) and two bigger root partitions (e.g. 3GB, ext4). I will use the terms rootA and rootB for the two new root partitions in the new image from here on. Get the UUIDs of the newly created boot and rootA partition of the new image (e.g. lsblk/blkid). Most likely instead of using two separate ext4 rootA and rootB partitions one bigger btrfs partition and the usage of subvolumes could be possible. But I did not test this. Copy boot and adjust Mount the new boot partition and create directories bootA and bootB and a relative symlink boot pointing to bootA. Place all files from the original image’s /boot directory into bootA of the new image. Adjust the UUID line in armbianEnv.txt that still points to the original image’s root partition to the rootA UUID from the new image. Copy root and adjust Mount rootA and copy all the files from the original image into it. Remove all files from the /boot directory in rootA as we will mount the boot partition into this directory anyway and do not want to get mixed up. Create a new directory /rawBoot in rootA. Edit the fstab of rootA and change the UUID that still points to the original image’s root partition to the rootA UUID. Add a line to fstab to mount the boot partition of the new image into /rawBoot. Add a line to fstab to bind mount the directory /boot of /rawBoot into /boot of rootA. Add an empty file /root/.no_rootfs_resize in rootA to avoid the partitions being changed if the original image was never booted before. I did all of the above also with an archived older Armbian image and put that into rootB (and bootB). With this setup we now have two separated OS versions. They can be switched by simply changing the boot symlink to bootA or bootB and reboot. Because we used bind mount we can also do kernel upgrades which end up in the correct directory. As all of the steps are easily automatable by a shell script we can now download a new earlier prepared update package place its content into the other boot directory and partition adjust their UUIDs (and maybe copy SSH keys and machine-id if we want to keep system identity) and change a symlink. If we need to go back to the older image just the symlink needs to changed back. Either from within a running system or if that is not possible by taking the card out and doing this externally. As I said earlier this A+B update scheme is not as robust as other tools. But we can stay with prebuilt images from Armbian that can be locally configured the way we want it. After this an update package can be created and distributed which could also contain a new uboot. If this is tested well before distribution I guess most errors that make the other tools so robust can be avoided.

I Did It! I Got It Working!! ES8388 Analog Audio Output Here's How (this is very easy to do): It just involves making one simple modification to the devicetree. Note: I did this with the Edge kernel. My guess is that it will also work with the Current kernel. You can also try the Vendor kernel if its devicetree has the same code. I manually applied this patch: https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/ If you scroll to the bottom where it gives the patch, the GPIO_ACTIVE_LOW needs to be changed to GPIO_ACTIVE_HIGH in the given section of the devicetree. Here's the simple / quick way to fix it, without having to go through any lengthy (re)builds. Modify the already installed devicetree file (/boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb). 1. Install the package: device-tree-compiler 2. Backup the original, and convert to .dts format as follows: # Go to your devicetree directory cd /boot/dtb/rockchip/ # Make a backup of your original devicetree: sudo cp rk3588-orangepi-5-plus.dtb rk3588-orangepi-5-plus.dtb.bak # Use device-tree-compiler to convert the file from the binary .dtb format to textual .dts format (ignore the warnings) sudo dtc -I dtb -O dts -o rk3588-orangepi-5-plus.dts rk3588-orangepi-5-plus.dtb # Safety-Check Part 1: Convert right back to .dtb format (another filename), ignore the warnings. sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dts # Safety-Check Part 2: Compare the newly converted file with the original. They should be identical (this command should produce no output) cmp -l rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dtb 3. Using a text editor in sudo mode, edit the text file: rk3588-orangepi-5-plus.dts Search for this phrase: simple-audio-card,hp-det-gpios I should appear exactly once in the file. # Here is what that line looks like (for me): simple-audio-card,hp-det-gpios = <0x133 0x1b 0x01>; # This is that same line before original compilation simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; 4. Notice between the brackets, there are 3 values, separated by spaces. The third value is the value to modify from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH, or for us, from 0x01 to 0x00. 5. Convert your modified .dts file to a .dtb file (ignore the warnings): sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dts # Optional: Quick Comparison Check (this should output exactly 1 line with 3 numbers: [big number] 0 1) cmp -l rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 6. Copy the new fixed file to (overwriting) your original: sudo cp rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb 7. Reboot (and have ES8388 analog audio out). Note: Whenever you do a kernel change or update, you will need to repeat this process until the Armbian kernel updates catch up with this patch. Here's the lengthier explanation (this is repeatable if you want to check it out yourself) 1. I downloaded the source code for version 25.8.1: https://github.com/armbian/build/releases/tag/v25.8.1 2. I extracted the archive and started the building process (./compile.sh) with the edge kernel (and a desktop image). It would not build because it rejected two of the kernel patches, but it did download everything into the cache. 3. I then found the file described in the patch: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts 4. In that file, I searched for the line indicated in the patch, just prior to the line to modify: simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; ...and found the appropriate section. I confirmed the line that followed matched the original (incorrect) version mentioned in the patch entry. 5. I then scrolled to the top of the .dts file and looked at the files #included, to find where the GPIO_ACTIVE_LOW macro was defined. I figured dt-bindings/gpio/gpio.h was a reasonable place to look first. I found it here: ./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/include/dt-bindings/gpio/gpio.h Near the top of the file were these #defines: /* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1 6. See the simple fix above for the rest. Tags: @Werner, @Igor, @laibsch @dimaxus, @EricaLina, @ricardo_brz, @eselarm

@Nick A sorry, i haven't got any information about the axp chip, i will do the reseacrch

I had the precise information about data-offset from "--examine" mdadm command, and also I was in raid1, that's far less sensitive to error than raid5 or raid0 for example. I would not have been surprised that the resync, if taken to the end, would have worked... But I will never know. As far as I know, I get the data back and I'm very lucky and happy. Thank you

For anyone looking for simple instructions to install the official Armbian image for "H96 Max V56" (as of August 30th, 2025) using a Linux PC (e.g. Ubuntu Desktop 24.04): 1. Install the "rkdeveloptool" tool first, as instructed in: https://docs.radxa.com/en/zero/zero3/low-level-dev/rkdeveloptool?host-os=debian sudo apt-get update sudo apt-get install -y libudev-dev libusb-1.0-0-dev dh-autoreconf pkg-config libusb-1.0 build-essential git wget git clone https://github.com/rockchip-linux/rkdeveloptool cd rkdeveloptool autoreconf -i ./configure make -j $(nproc) sudo cp rkdeveloptool /usr/local/sbin/ At the time of writing, this installed version 1.32. If you installed "rkdeveloptool" from Ubuntu's repos, it would install version 1.0 which may work, but let's be on the safe side here... 2. Connect and boot the device to loader/maskrom mode 2.1 While pressing the reset button (back/right) with a pin, connect the USB 2.0 port (back/left) and the power cable. Gotta be careful here not to miss the reset button pressing while connecting the cables. 2.2 Use the rkdeveloptool tool to identify the device and the mode it is on ("loader" or "maskrom"). $ rkdeveloptool ld ...should show the connected device if point 2.1 was successful - e.g. on my 8GB RAM device it printed this: DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=304 Loader Or after I had already flashed Armbian, it would show: DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=304 Maskrom (If you installed "rkdeveloptool" from Ubuntu's repo, the command is "rkdeveloptool list" if I recall correctly - every other "rkdeveloptool" command following though is the same) Now grab the latest release of Armbian for this device. At the time of writing it was: https://github.com/armbian/community/releases/download/25.11.0-trunk.106/Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img.xz (the name of the device is on the filename) Extract the included .img file with (sudo apt install xz-tools): $ unxz Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img.xz 2.2.1 If in "loader" mode (see the last part of the command's output above), simply flash Armbian directly. E.g. $ sudo rkdeveloptool wl 0x0 Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img (if you attempt to flash the attached bootloaders, you'll get a "device not supported" error - Armbian already contains a bootloader) 2.2.2 If in "maskrom" mode (e.g. if you are re-flashing Armbian), flash the bootloader first: # For the 8GB RAM device use the attached (in this post) H96-MAX-8gb-MiniLoaderAll.bin file $ sudo rkdeveloptool db H96-MAX-8gb-MiniLoaderAll.bin # For the 4GB RAM device use the attached (in this post) H96-MAX-4gb-MiniLoaderAll.bin file $ sudo rkdeveloptool db H96-MAX-4gb-MiniLoaderAll.bin ...and then re-flash Armbian as you did the first time: $ sudo rkdeveloptool wl 0x0 Armbian_community_25.11.0-trunk.106_H96-tvbox-3566_bookworm_current_6.12.44_minimal.img 2.3 Reboot the device with: $ sudo rkdeveloptool rd Done! If all goes well, once you reboot the device you will be asked to set a root password and optionally a sudo user. Rebooting afterwards you should now be greeted with: _ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.11 rolling for h96-tvbox-3566 running Armbian Linux 6.12.44-current-rockchip64 Packages: Debian stable (bookworm), possible distro upgrade (trixie) Updates: Kernel upgrade enabled and 2 packages available for upgrade Support: for advanced users (rolling release) IPv4: (LAN) 192.168.1.10 (WAN) 1.2.3.4 Performance: Load: 3% Uptime: 2 min Memory usage: 2% of 7.50G CPU temp: 40°C Usage of /: 3% of 57G Commands: Configuration : armbian-config Upgrade : armbian-upgrade Monitoring : htop Last login: Sat Aug 30 12:47:54 2025 Key points: - If you do this the first time, it's obviously a matter of just flashing the latest Armbian image directly. - You don't need to open the device or compile Armbian. - It's simpler than 2 years ago when I bought the device thanks to people like @Hqnicolas (muito obrigado Nicolas!) H96-MAX-4gb-MiniLoaderAll.bin H96-MAX-8gb-MiniLoaderAll.bin

please be more specific, what happened exactly? where did you get that statement that netplan or networkmanager are not supposed to touch firewall settings? when you bring a network interface up or down that can obviously affect firewall rules.

@dale you need a display overlay that is compatible with tm16xx. OpenVFD overlays are NOT supported. You can read README.md and dt-bindings documentation at https://github.com/jefflessard/tm16xx-display But note that there has been many changes recently to the code base since the driver is currently in review process to be upstreamed into mainline kernel (targeting v6.18). So double check which bindings version format has been integrated into Armbian rockchip64. The GitHub repo also contains a vfd-convert utility to automatically convert OpenVFD configuration files to expected tm16xx DTSO. But : 1. It requires OpenVFD conf file, not dtso. 2. You may need to go through file history to get the version matching of what has been integrated into Armbian rockchip64.

To replace an image on the eMMC, the MASKROM mode is not necessary. It is only required when the firmware is so damaged that it no longer works, but the signature is still intact and the MASKROM code still executes it. To replace an image, it is sufficient to boot from a rootfs that is not on the eMMC and replace it from there. And the good thing about it is that no device-specific hacks are necessary, just a properly configured bootflow. Furthermore, it is also self-contained, as no external devices with special software or other dependencies are necessary. It can also be automated in such a way that it runs unattended and the user only has to start the process initially.

Customizing image and customizing kernel are different tasks. For latter use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } kernel-config command and then copy over the created config file from output to userpatches. The framework will look for custom kernel configuration files and uses them if they're detected. More details here: https://zuckerbude.org/armbian-using-kernel-config/

That seems to have gone away. ? SNILMERG... Now using very small but 1920x1080 screen, xfce terminal text is about 7 microns tall, way too small for my ancient eyes, Simplified keyboard. ctrl&shift&+ magnify's text but when big enough to read, bottom of xfce4 terminal is offscreen below bottom of screen, so cannot see command line. Is there a keycode combo that expands text independently from terminal window size? Thank you.

Armbian kernel and BSP Debian/Ubuntu userland

You are still using an old Linux. You need Linux 6.13 or newer. You need to build your own Armbian OS. Also, don't forget the cma=256M kernel argument

removed

reopening after moving to "Software / Applications / Userspace"

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

Anyone an idea?

Yup, I opened a bug report about this on his github, I have yet to receive an answer. I'm having trouble figuring out if it's a hardware issue or a software issue, since I don't have a second bug to test at the same time. When I try the Makerbase OS on this same board, I don't have connectivity either, but at least, the link led turns on and off with the cable connect/disconnect.

Did you try to build the image with compile.sh and this following setting? INCLUDE_HOME_DIR=yes See https://docs.armbian.com/Developer-Guide_Build-Switches/#advanced

Yeah, also on my laptop (Arch with upstream 6.16 kernel) this problem does not happen, so it shouldn't be because of specific patches to the rtw88 kernel in the RPi kernel repo. It only happens when I use the kernel built with Armbian build system. I am completely clueless about what could be causing this 🤷‍♂️

Sorry that was resolved 2 days ago, but I don't see and never seen this long list. Only 3 options vendor 6.1, 6.12 and edge (6.16), This morning I also seen the u-boot wasn't the good one. I downloaded for rock5-itx, but had linux-u-boot-cyber-aib-rk3588-edge instead of linux-u-boot-rock-5-itx-edge, changed it, rebooted (on 6.16) worked, tried again 6.12, still no display. I needed to arch-chroot on the armbian to take a screenshot (but I've the same dispay on armbian itself): I seen 6.16.4 is now available and work, after /boot/config-6.16.4-edge-rockchip64, gcc 13.3.0 is now again used instead of old 11.x :). Debian Trixie has GCC 14.2.0 CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0" And after changelog on kernel.org, patch for AV1 acceleration had been applied on this version: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.16.4 Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588") Sorry I maybe mix too much subjects in the same post, but: I also seen a minimal IoT version of Trixie for Rock5-itx. Can I made safely a debian os upgrade from apt? Or is it better to wait release for desktop version ? Another point. On armbian, only LLVMpipe is used, I compiled last mesa git on arch, will try to do this for debian too. and some application that need to use EGL+dri (wings3D, blender, obs) report broken DRI2 access. I'm not sure if it's due to some kernel patchs (I reuse the armbian 6.16 kernel on arch), or to the current state of mesa-git. They all works with llvmpipe. Othere applications like PPSSPPSDL work fine without it. Ex, with wings3d + forced zink: MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink wings3d WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance libEGL warning: egl: failed to create dri2 screen WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance

You can either experiment with the CLEAN_LEVEL switch or use kernel-patch or uboot-patch (depending on what you want to modify) to create proper patch files from the diff.

Did you download stretch already, before I remove it to put up Bionic?

Hello, everyone. I'm using Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal on 4GB OpiZero3. When booting from sd, the bluetooth controller is initialized correctly. I made a boot from usb-ssd via armbian-config: everything works fine, but the bluetooth controller is not initialized. /sys/class/bluetooth is empty. Switch back to sd - it works again. Boot from ssd - no. I compared whether it transferred the distribution correctly from sd to ssd - all files are the same. What could be the problem?