Nick_Sl

Hi all,
 
Quick update for anyone following the Orange Pi 4A (Allwinner T527, A523
family / sun55iw3) mainline work: I've just pushed AurealNix v0.4, now on a
vanilla Linux 6.18.44 kernel (up from 6.18.38). Three ready-to-flash images,
all validated on real hardware:
 
- CLI / headless — 197 MB. Working analog audio out of the box, HDMI console.
- GNOME (Wayland) — 717 MB. Autologin, ArcMenu, hardware video decode.
- Kubuntu 26.04 / KDE Plasma (Wayland) — 1.1 GB. New this release.
 
Same disclaimer as always: I'm not a kernel developer by trade — a lot of this
was done with AI coding agents and a lot of testing on my own board. It's shared
in case it's useful and to get feedback, not as something perfect. Reviews of the
patches are very welcome.
 
What's new in v0.4
 
WireGuard + nftables/iptables NAT (requested by a user who wanted a small router/VPN box). All as modules. Both iptables-nft and iptables-legacy paths work. Kubuntu 26.04 (Plasma 6.6.6) as a third image — pure Wayland (KWin), and it's genuinely fast on this board: glmark2 880 at 800x600 (a touch above GNOME's 847), boots to the desktop in ~26 s. GTK apps run fine under Plasma too. 52 kernel patches since the last drop — mostly hardening: PCIe/NVMe resume fixes, clock/CCU robustness, a couple of memory-safety fixes in the video engine and the combo-PHY, plus DTS work (696 MHz GPU OPP for this SID bin, a voltage range for the little cluster so a future DSU driver can coordinate the shared rail). Images now ship fully up to date (dist-upgrade at build time), and the kernel has the lockup detectors enabled.  
One honest known issue
 
Under sustained WireGuard saturation (~880 Mbps, `iperf3`) the board can hang and reboot. It's intermittent and so far *only* `iperf3` has reproduced it — moving the same data with `netcat` (22 GB) or copying real files over `scp` went through fine, and it's rock-solid at 100–300 Mbps. It's not thermal, not power, and not the network on its own (unencrypted iperf3 sustains 925 Mbps). With every lockup detector on and a serial console recording, the kernel dies without printing a thing. Still chasing the root cause — if anyone has seen this pattern with WireGuard on an ARM SoC, I'm all ears.
 
Still on the list: hardware VPU is in (cedar + gst-omx, H.264/HEVC), NVMe with a real drive and eMMC boot are the next hardware items. 
 
Downloads & patches:
https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.4
 
The repo has the patch series, defconfig and board DTS if you'd rather build your own. If this saved you some time and you want to chuck a coffee my way, there's a Ko-fi link on the repo — entirely optional, the images are free and always will be.
 
Thanks, and feedback very welcome.
 

Massive thanks to everyone in here — this thread has basically become a live bring-up lab. Catching up with each of you:
@bickns — the whole 256 GB written and verified with zero dmesg noise is a much harder test than I asked for; passing it clean means the PCIe link and the Innosilicon combo PHY are genuinely solid under sustained I/O, not just "it enumerates." Thank you. Two follow-ups on your requests:
iproute2 is in now — I re-rolled the v0.3 CLI with just that one package added (ip / ss), same kernel and everything else; only the SHA-256 changed (updated in the release notes).
rootfs on NVMe: don't burn your Tuesday on it just yet — it won't boot with the current image. In this kernel nvme is a module and the images have no initramfs, so pointing root= at the NVMe just gives an "unable to mount root fs" panic. I'm baking NVMe built-in (NVME=y) plus a short "move rootfs to the NVMe" recipe into the next release — I'd love to have you confirm it then.
 
@JamesCL — two milestones from you:
Booting v0.3 from the eMMC (root on mmcblk2p1, auto-resize working, and no SD enumerating in your dmesg) is something I genuinely can't test myself — my board has the eMMC socket but I don't have a module for it, so I run from SD. So this is your discovery, not mine, and it's why the FAQ still says nothing about eMMC install: I won't document steps I can't verify. Could you share the exact steps you used (and confirm no SD card was inserted on that boot)? Another tester's board stops early in the boot ROM stage doing the same thing, so your method is the missing piece — with it I'll write a proper "install to eMMC" guide, with your name on it.
The f3 run on your Intel NVMe — 50 GB, 0 corrupted / 0 changed / 0 overwritten, ~276 MB/s read — is exactly the result I hoped for, and now it's confirmed on two different drives/vendors (bickns' KIOXIA and your Intel). NVMe as storage is closed with confidence. 🙌
@flintduval — on the U-Boot question: the released images boot with the stock Orange Pi BSP U-Boot (2018.07-orangepi, boot0/eGON SPL) — I reuse the vendor blob as-is in the first 20 MiB rather than building my own. If you get mainline U-Boot into SPI, I'd love to hear how far it boots.
@ioncube — thanks for helping spread the word. 🙌
Roadmap, for everyone following: my plan is to refresh the kernel roughly every 5-10 stable point releases, starting with the 6.18.40/.41 bump. 6.18 is longterm, so the stable stream keeps landing fixes — and I've already spotted some genuinely interesting A523-specific improvements queued up there. So expect worthwhile updates over the coming weeks, not just version bumps. No firm dates, as always.

Update: the ready-to-flash Debian 13 + KDE Plasma image is now available: https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.1
Boots straight to an accelerated Plasma desktop. Feedback welcome!

Just managed to distract myself some more in this outrageous heat here in the UK and can confirm that the RELEASE=stable (6.18) build (from compile.sh) boots ok after some tweaking.  It got stuck on "Starting Kernel" but when I added these lines to /boot/armbianEnv.txt to see why it failed, then it booted ok - dunno why.  I think keep_bootcon was the important bit.

 
extraargs=earlycon=uart8250,mmio32,0x02500000 keep_bootcon ignore_loglevel loglevel=8  
The other problem then was getting the ethernet to work which I did by creating a device tree overlay file - much the same as other here is it only seems be working at 100M unlike the 1000M in the 5.15 kernel.  The extra problem seemed to be that the wifi driver would periodically crash and cause a kernel-panic.  The following DTS file pulls the ethernet down  to 100M and disables the wifi to stop it crashing.  You then compile this into a .dtbo file, copy it to /boot/overlay-user and reference it in armbianEnv.txt with this line 
 
user_overlays=opi4a-network-fix
 
The opi4a-network-fix.dts syntax to create it is as follows ... apart from that I can't get it to do much more, so will go down the 5.15 bookworm route until things change
 
/dts-v1/; /plugin/; / {    compatible = "xunlong,orangepi-4a", "allwinner,sun55i-t527";    /* Maintain working Ethernet at 100M address 1 */    fragment@0 {        target-path = "/soc/ethernet@4510000";        __overlay__ {            phy-mode = "rgmii-id";            phy-handle = <&ext_rgmii_phy>;            status = "okay";            mdio {                #address-cells = <1>;                #size-cells = <0>;                ext_rgmii_phy: ethernet-phy@1 {                    compatible = "ethernet-phy-ieee802.3-c22";                    reg = <1>;                    max-speed = <100>;                };            };        };    };    /* Hard disable the unstable wireless MMC controller block */    fragment@1 {        target-path = "/soc/mmc@4021000";        __overlay__ {            status = "disabled";        };    }; };

 

After upgrade to 7.0.0-rc6-edge-sunxi64 wlan is shown in interfaces. Gigabit Ethernet does not work yet. 

hello i try  image "Armbian-unofficial_26.05.0-trunk_Orangepi-4a_trixie_edge_7.0.0-rc5.img"
not detected emmc and wifi. ethernet crushed periodically