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.