All Activity

The blue revision is not different in this case. I have it running here too. My recommendation would be to flash the u-boot spi bin inside the u-boot deb generated by armbian build. `dpkg -x xyz.deb ./output` and rkdeveloptool are the things to use here

Hello @mBesar, while I can build images with additional kernel modules, the next "apt-get upgrade" may install a newer kernel that discards such additions. Why not build this on your own? There is already a working DKMS build system on the board for the bcmdhd wifi module. On the next kernel update, DKMS will recompile bcmdhd.ko for the new kernel automatically. Sadly, when I tried this for b2c2-flexcop-usb, it was not too easy to do. Armbian does not provide kernel sources with "apt-source", and the mentioned module itself uses an additional "-i include-dir" during build. So as an example, try to do this on your board: As root: # Change two times "Types: deb deb-src" nano /etc/apt/sources.list.d/debian.sources # Check for avail linux image packages, this time 6.18.5-deb13-parisc apt-get update grep linux-image /var/lib/apt/lists/*Sources|grep 6\\.18|less -S # We are not interested in this image, we just need some source code cd /usr/src apt-get source linux-image-6.18.5+deb13-parisc # Add a new DKMS module (dkms already here b/c bcmdhd wifi driver) mkdir /usr/src/b2c2-flexcop-usb-6.18 cd /usr/src/b2c2-flexcop-usb-6.18 cat > dkms.conf << "EOF" PACKAGE_NAME="b2c2-flexcop-usb" PACKAGE_VERSION="6.18" BUILT_MODULE_NAME[0]="b2c2-flexcop-usb" DEST_MODULE_LOCATION[0]="/updates/dkms" AUTOINSTALL="yes" MAKE="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build CONFIG_DVB_B2C2_FLEXCOP_USB=m" EOF # What subsys do we need? Says: drivers/media/usb/b2c2, then grab that dir grep DVB_B2C2_FLEXCOP_USB $(find /usr/src/linux-6.18.5 -name Kconfig*) cp -av /usr/src/linux-6.18.5/drivers/media/usb/b2c2/. . # The module Makefile uses an additional include dir. We simply copy them here cp -av /usr/src/linux-6.18.5/drivers/media/common/b2c2/*.h . # Register, build, and install dkms add -m b2c2-flexcop-usb -v 6.18 dkms build -m b2c2-flexcop-usb -v 6.18 dkms install -m b2c2-flexcop-usb -v 6.18 HTH // Sven-Ola

@sr4armbian I need more information. Boot logs, error codes, anything you think might be useful.

All moved.

@Nick A Apologies for overlooking the model number. As you suggested, I tried the x98h image from here, and the image worked fine. With this image, both USB ports, Ethernet, and WiFi work without any modification or tweak. Thanks a lot for directing me towards the right image. 🙏 Now, I am trying to get the VFD working. So far, I have tried OpenVFD and the alternative method mentioned here without success. Do you have any suggestions for getting it to work?

Rock-5c vendor builds are good. Current is good except for audio: Armbian_26.5.1_Rock-5c_resolute_vendor_6.1.115_gnome_desktop Boot from SD card - okay Connect via ssh - okay Ethernet iperf3 - okay USB2 ports - okay USB3 ports - okay Reboot - okay Shutdown - okay HDMI video - okay HDMI audio - okay Headphone jack audio - okay Armbian_26.5.1_Rock-5c_resolute_vendor_6.1.115_minimal Boot from SD card - okay Connect via ssh - okay Ethernet iperf3 - okay USB2 ports - okay USB3 ports - okay Reboot - okay Shutdown - okay HDMI video - okay Armbian_26.5.1_Rock-5c_resolute_current_6.18.33_gnome_desktop Boot from SD card - okay Connect via ssh - okay Ethernet iperf3 - okay USB2 ports - okay USB3 ports - okay Reboot - okay Shutdown - okay HDMI video - okay HDMI audio - FAILED Headphone jack audio - FAILED Bluetooth audio - FAILED

Orange Pi 5B subforum has recurring threads about eMMC boot loops, WiFi/Bluetooth regressions on mainline kernels, and the general "what image actually works on this thing" question. Joshua-Riek's ubuntu-rockchip was a common answer to that for a long time, but it was archived recently. This is a personal continuation fork in case it's useful to anyone working through those same issues. What this is: - Fork of Joshua-Riek/ubuntu-rockchip (archived) — same vendor 6.1 kernel base, not mainline - Therefore: onboard WiFi/BT works (no mainline driver regressions), eMMC boots reliably - Scope: Orange Pi 5B + Ubuntu 24.04 (Noble) only. jammy/oracular/plucky suite configs removed. - Single-maintainer hobby project. Best-effort, no SLA. v1.0.0 contents: - Kernel ABI bumped to 6.1.0-1027.27 - Backported CVE-2026-46333 (ssh-keysign-pwn) — upstream commit 31e62c2ebbfd cherry-picked onto noble-security branch - Build-kernel.sh patched for GCC 14+ host compatibility (the 6.1 vendor tree's -Werror defaults conflict with stricter warning-to-error promotion introduced in GCC 14 and inherited by GCC 15)"— the 6.1 vendor tree fails to compile on Ubuntu 24.04+ / Debian Trixie+ hosts due to -Werror promotion. Fix is KCFLAGS=-Wno-error for the kernel proper plus sed-stripping hardcoded -Werror from libbpf, libsubcmd, objtool, and libperf tool Makefiles. Without this, you can't rebuild Joshua's kernel from source on a modern host. - Tested as a daily driver on OPi 5B hardware with reboot loop test, cpu burn. running 4k screensaver. Known limitations (carried over from upstream): - Mali GPU PPA (panfork-mesa) and jjriek/rockchip userspace PPAs are no longer maintained. Frozen at the versions Joshua left them. Not a competitor to Armbian — different scope, different kernel approach. If you're getting clean results with Armbian on your 5B, stick with what works. This is for the case where Armbian's mainline kernel breaks onboard hardware or you specifically need the Joshua-Riek tree. Credit: this is a continuation, not original work. Joshua-Riek did the heavy lifting; LICENSE, NOTICE, and README all credit upstream. Repo: https://github.com/defcom5-rockchip/ubuntu-rockchip Kernel: https://github.com/defcom5-rockchip/linux-rockchip-rk3588 Release: https://github.com/defcom5-rockchip/ubuntu-rockchip/releases/tag/defcom5-v1.0.0 (1.86GB .img.xz + sha256) Peace, defcom5

Also a small display with ST7796 and ADS7846 on shared SPI stopped working. Downgraded to 6.12 and all works. When you solve it, if you remember, give me a shout. Thanks

I was curious and looked into your script, I see parted uses sizes like 32MiB instead of sector numbers I tend to do when using gdisk or fdisk It is only the function write_uboot_platform_ufs() in the image that deals with 512/4k and then it is no issue for Btrfs as this is not related to CPU page-size issues I hinted earlier. So also older kernel is no issue and also RK3576 cannot do e.g. 16k page-size.

@sr4armbian not x96q but x98h. It’s similar to transpeed but it has the wifi you are looking for.

this I cannot remember I have experienced on my ROCK5B, it was indeed boot-loop when power 'was not good enough'; with fixed 12V power everything worked, even 3.5mm audio I remember. Now I have EDK2 UEFIv1.1 for the ROCK5B in the SPI-flash and it is like a PC, so even stores boot entries for several OSses (what is on the ESP). My ROCK3A showed similar behavior as your ROCK5B, that went away when fixed 12V power and Armbian legacy U-Boot and 6.1.115 (I use SATA overlay) At sector 64 the binary u-boot.bin is written, the terminology I am not sure of. You can look up all addresses the ROM uses at rock-chip.com or so. You might want to build/compile an as pure as possible and as latest as possible mainline U-Boot for ROCK5B, I saw kernel 6.17 or later should have fusb302 support, but it might be too late in the power-on process. EDK2 UEFIv1.1 has no fusb302 support.

Sorry I forgot to mention, I have used dts from Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server.img.xz version to make the 2nd USB working.

Thanks for replying. I have tried the images that you have suggested. Below given is the status. Armbian-unofficial_25.05.0-trunk_X96q-lpddr3-v1-3_bookworm_edge_6.12.11_server.img.xz - Not booting Armbian-unofficial_25.05.0-trunk_X96q-ddr3_bookworm_edge_6.12.11_server.img.xz - Not Booting Armbian-unofficial_25.05.0-trunk_X96q-ddr3-v5-1_bookworm_edge_6.12.11_server.img.xz - Boots but hangs at Btrfs step in the beginning itself Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server.img.xz - Boots but hangs at Btrfs step in the beginning itself Meanwhile I have tried to edit the dts file and modified the usb related entries from "disabled" to "okay" which made the 2nd USB working. Since the Ethernet is working fine the WiFI is less priority as of now. However if I can make the VFD working will help me to understand whether the device is up and running or powered off. At present the VFD is black so unable to check the status. Also it will be good to display the current time if possible.

Yeah no problem, heading to GitHub. No forum for Ubuntu and you are not covering the 5b so I tried. They will care about solid performance. defcom5

> My ROCK5B was ordered as a 'blue one' on Aliexpress a year ago Mine has green PCB with some text: Rock 5B v1.42022.08.29 U-boot at sector 64 is SPL or standard U-boot? From what I've read online it looks like if it was a power supply issue I would get a boot loop but my board never reset... It looks like U-boot has support for fusb302. I will build a U-boot with more logs to see if there is any negotiation going on. I've built a Nixos Image. I'm able to go up to U-boot console, start linux via extconfig then get some Linux logs but at some point it just stops without errors on some random log.

Hello, has anyone figured out how to get the ethernet working? I have only gotten the ethernet port to work with 100mbps.

Hi @sven-ola, first of all a huge thank you for maintaining this image — the work you're doing for the Orange Pi RV2 is genuinely appreciated, especially given how early the SpacemiT/K1 ecosystem still is. I'd like to kindly request enabling a few kernel config options in the next build. I'll split them by priority: Request 1 — TechniSat SkyStar USB 2 HD (simple, guaranteed fix) CONFIG_DVB_B2C2_FLEXCOP_USB=m The FlexCop core (CONFIG_DVB_B2C2_FLEXCOP=m) and all its dependencies are already enabled in the current kernel. This is a one-line addition that will make this DVB-S2 USB receiver work out of the box with no further changes needed. Request 2 — TBS DVB cards via out-of-tree media_build (best-effort) CONFIG_DVB_USB=m CONFIG_DVB_USB_V2=m CONFIG_MEDIA_CONTROLLER_DVB=y These are the required kernel-side foundations for the TBS linux_media out-of-tree driver tree to compile and load. All dependencies are already satisfied in the current config (DVB_CORE=y, MEDIA_USB_SUPPORT=y, MEDIA_CONTROLLER=y). I say "best-effort" because the TBS media_build source has compatibility issues with kernel 6.18 APIs that require manual patching regardless of kernel config — so these options are necessary but not the whole story on my end. That part is on me to sort out, not on you. Environment for reference: Board: Orange Pi RV2 (orangepirv2) Kernel: 6.18.33-current-spacemit Armbian: 26.8.0-trunk.61 (BRANCH=current) Thank you again for your time and effort — genuinely appreciated! 🙏

Thanks for the replies. I understand that native UFS boot support is still very new, and that ext4 is currently the safest and expected path. After some more testing, I managed to get a separate ext4 /boot + btrfs / layout working on my NanoPi M5 with the onboard 64GB UFS. This is not a request for official support, and I do not want to imply that this is a recommended or fully tested solution. I am only sharing it as an experimental helper script for users who may want to test a similar layout. ============================================================ WORKING LAYOUT ============== The layout I tested successfully is: * /dev/sda1: ext4, mounted as /boot, LABEL=BOOT * /dev/sda2: btrfs, mounted as /, LABEL=ROOT * btrfs subvolume @ mounted as / * btrfs subvolume @snapshots mounted as /.snapshots The reason this works is that U-Boot only needs to read /boot from ext4. The Linux kernel and initramfs can then mount the root filesystem as btrfs. ============================================================ WHAT THE SCRIPT DOES ==================== The attached script does the following: 1. Checks that it is running as root. 2. Checks that the system is not currently running from UFS. 3. Checks that the expected UFS LUN devices exist. 4. Mounts an official Armbian NanoPi M5 image read-only through a loop device. 5. Creates a minimal safety backup. 6. Wipes and repartitions the UFS General LUN. 7. Creates an ext4 /boot partition starting at 32MiB. 8. Creates a btrfs root partition after /boot. 9. Creates btrfs subvolumes @ and @snapshots. 10. Sets @ as the default btrfs subvolume. 11. Copies the root filesystem from the Armbian image to the btrfs root. 12. Copies /boot from the Armbian image to the ext4 /boot partition. 13. Writes /etc/fstab. 14. Updates /boot/armbianEnv.txt with: rootdev=LABEL=ROOT rootfstype=btrfs 15. Ensures btrfs support is included in the target initramfs. 16. Regenerates /boot/boot.scr. 17. Uses the official write_uboot_platform_ufs() function from the image to write the UFS bootloader. 18. Performs some basic validation before finishing. The script does not patch boot.cmd. Instead, it relies on: * rootdev=LABEL=ROOT * rootfstype=btrfs * btrfs default subvolume set to @ This keeps the boot script closer to the official Armbian files. ============================================================ IMPORTANT NOTES =============== This script is destructive. It wipes the UFS General LUN. It assumes the usual NanoPi M5 UFS mapping: * /dev/sda = UFS General LUN * /dev/sdb = UFS Boot LUN A * /dev/sdc = UFS Boot LUN B * /dev/sdd = vendor/config LUN It was only tested on my NanoPi M5 with onboard 64GB UFS. Please review the script carefully before running it. I am attaching it only as an experimental helper for testing, not as an official solution. ============================================================ BASIC USAGE =========== Boot from an SD card maintenance system first. Make sure the Armbian image is already decompressed to .img. Example: sudo ./flash-nanopi-m5-ufs-btrfs.sh --image /path/to/Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img For a dry run: sudo ./flash-nanopi-m5-ufs-btrfs.sh --image /path/to/Armbian_26.5.1_Nanopi-m5_trixie_vendor_6.1.115_minimal.img --dry-run --yes-i-understand The script requires typing: YES_FLASH_UFS before it performs the destructive flashing operation, unless --yes-i-understand is used. ============================================================ RESULT ====== With this layout, the system boots successfully from UFS on my NanoPi M5 with the BOOT switch set to UFS/SD. After booting, I verified that: * / is btrfs from LABEL=ROOT * /boot is ext4 from LABEL=BOOT * /.snapshots is a btrfs subvolume * the system boots without requiring U-Boot to read btrfs directly I hope this may help other users who want a btrfs root filesystem on UFS while keeping /boot on ext4. flash-nanopi-m5-ufs-btrfs.sh

Radxa-e54c - tested okay please move to dl: Armbian_26.5.1_Radxa-e54c_resolute_vendor_6.1.115_gnome_desktop Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 USB Reboot Shutdown HDMI video HDMI audio Armbian_26.5.1_Radxa-e54c_resolute_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 (needs manual config) USB Reboot Shutdown Armbian_26.5.1_Radxa-e54c_trixie_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan1 ethernet iperf3 Lan2 ethernet iperf3 Lan3 ethernet iperf3 Wan ethernet iperf3 (needs manual config) USB Reboot Shutdown

radxa-e52c - tested okay please move to dl: Armbian_26.5.1_Radxa-e52c_resolute_current_6.18.33_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan ethernet iperf3 Wan ethernet iperf3 USB Reboot Shutdown Armbian_26.5.1_Radxa-e52c_resolute_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan ethernet iperf3 Wan ethernet iperf3 USB Reboot Shutdown Armbian_26.5.1_Radxa-e52c_trixie_vendor_6.1.115_minimal Boot from SD card TTY Terminal 1500000 baud Connect via ssh Lan ethernet iperf3 Wan ethernet iperf3 USB Reboot Shutdown

Neither we do full hardware validation. That is only done in military grade software support and this is community open source development Thank you for your input. We don't have much time so in case we don't find a fix in <1h, broken images will be removed. Which is already a good added value. It is interesting that Gnome works and KDE don't. I did several tests on x86 platform and KDE always worked ... But I think we need to be realistic and happy if one desktop works solid.

root@nanopi-m5:~# grep BTRFS /usr/lib/u-boot/nanopi-m5-rk3576_defconfig # CONFIG_CMD_BTRFS is not set # CONFIG_FS_BTRFS is not set So no direct Btrfs rootfs support. It is image Armbian_26.5.1_Nanopi-m5_trixie_current_6.18.33_minimal.img run as container quick test. # gdisk -l Armbian_26.5.1_Nanopi-m5_trixie_current_6.18.33_minimal.img GPT fdisk (gdisk) version 1.0.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk armbian.img: 3252224 sectors, 1.6 GiB Sector size (logical): 512 bytes Disk identifier (GUID): 1F37D403-5DE7-4F81-AB22-D9825AE1EFEB Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 2048, last usable sector is 3252190 Partitions will be aligned on 2048-sector boundaries Total free space is 32735 sectors (16.0 MiB) Number Start (sector) End (sector) Size Code Name 1 32768 3250175 1.5 GiB 8305 rootfs There is no 4K sector 'awareness', that is the whole reason I ran this testing; If that is an issue with the M5, I don't own and don't know, but I have encountered quite some issues in Linux in general w.r.t. that, so I would for sure scan armbian-install script to see what is done. Risk with 6.1.115 kernel is that is messes up 512/4k things when Btrfs as kernel 6.7 or later is needed to handle it transparently. Check all yourself, as is long time ago I checked it and I use mostly latest Linux, so kernel > 6.18 currently.

1. At this stage you should be extremly happy if it generally works trouble free. 2. Yes.

The first iteration of mainline kernel driver support has just been posted. So a kernel build with this patch set applied should give a playground for initial experiments.