AurealNix

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.
 

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.
 

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.

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.

AurealNix v0.3 is out 🎉 — hardware video decode (H.264/H.265 in the browser) plus a GNOME desktop, on mainline 6.18.38: https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.3
 
On booting from an SSD — short answer, you can't boot the board purely from an M.2 SSD. The Allwinner boot ROM only loads the bootloader from microSD or eMMC (it doesn't boot off PCIe), so the boot chain (U-Boot + kernel) has to live on SD or eMMC. If you flash the whole image onto the SSD with nothing on SD/eMMC, there's no bootloader for the ROM to pick up, so it won't start.
 
Thanks @bickns, that's really useful! It fits what I'd expect: on this SoC the boot ROM only loads the bootloader from microSD or eMMC, never from PCIe — so booting purely from an M.2 SSD can't work, however it's flashed. The boot (U-Boot + kernel) always has to live on SD/eMMC.
The good news: your fdisk -l shows the drive and the PCIe link are fine. So the realistic setup is boot from SD/eMMC, rootfs on the NVMe (that needs a small kernel tweak — NVMe built-in or an initramfs). Booting the kernel itself off the SSD would mean adding NVMe support to U-Boot, which is a bigger job for another day.
If you get a chance, boot v0.3 from SD and run lsblk — I'd love to know the mainline 6.18 kernel sees your NVMe too. Cheers! 🙌

@flintduval You're absolutely right — thanks for the correction, and consider me happily corrected. The boot ROM on these SoCs also tries SPI NOR (and finally FEL over USB) after SD/eMMC, and this board does carry SPI flash — 16 MB as you say. So my "only microSD or eMMC" was incomplete.
That would enable the classic setup Armbian uses on other boards: bootloader in SPI, kernel + rootfs on NVMe → a genuinely SD-free board. One heads-up on the second half, though: U-Boot would also need to learn PCIe/NVMe on this board to load the kernel from the SSD — writing U-Boot to SPI alone doesn't get there.
It's not something I'm working on myself right now (my plate is full), but if you feel like experimenting with the SPI, it should be low-risk on this board: the ROM tries the SD slot first, so a bad SPI write is recoverable by just booting from SD. If you do try it, please share what you find here — I'd read that with great interest.

@JamesCL One more thing, only if you're up for it (zero pressure, as always): I'd love to know how both drives hold up under a real data load — sustained writes, and whether anything corrupts. The clean tool for this is f3 (it writes known patterns and verifies them on read-back, so it catches even a single flipped bit).
On the eMMC — keep it small. Your root fills the whole module (57 GB of 58), so there's little free space, and filling the live root filesystem completely would be a bad idea. A 5 GB run is plenty to prove integrity:
 
sudo apt install f3
cd ~ && f3write --end-at=5 . # 5 × 1 GB files, watch the speed it reports
f3read . # re-reads and verifies every bit
sudo dmesg | grep -iE "mmc2|error|fail"
rm ~/*.h2w # cleanup
 
On the Intel NVMe — go big. That's where a long sustained run really tells us something. No need to format — f3 just writes files into whatever's mounted, so we can use the existing partition's free space (non-destructive):
 
lsblk # find the NVMe partition (nvme0n1p1)
sudo mount /dev/nvme0n1p1 /mnt # mount what's already there — no formatting
df -h /mnt # how much free space?
cd /mnt && sudo f3write --end-at=100 . && sudo f3read . # or drop --end-at to just fill the free space
sudo dmesg | grep -iE "nvme|pcie|error|fail" sudo rm /mnt/*.h2w && cd ~ && sudo umount /mnt # cleanup
 
(If there's less than 100 GB free, no problem — f3 fills whatever is available and stops; even 20-30 GB is a solid sustained run.)
The --end-at numbers are just suggestions — check free space with df -h first and dial them down to whatever fits on each drive. A smaller run still proves integrity; it just exercises the drive for less time. The point is 0 corrupted sectors, not the size.
What we're looking for: 0 corrupted sectors and a quiet dmesg on both. The speeds are a nice bonus — the eMMC at HS200 should read 100+ MB/s, and the NVMe is capped by the M.2 slot being PCIe 2.0 ×1, so ~350-400 MB/s is the by-design ceiling; if f3 reports that range with 0 corrupted, the link is running as well as this SoC allows. A clean eMMC run is the last box to tick before I write the "install to eMMC" guide around your method.
 
@bickns you can try too.

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.

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.

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.

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.

Orange Pi 4A (Allwinner T527 / A523, sun55i-a523) — new mainline image coming in a few days
Hi all,
A quick heads-up for anyone following the Orange Pi 4A / Allwinner T527 (A523) mainline effort: a new image, v0.3, is coming in the next few days. It's based on mainline Linux 6.18 (longterm) and it's a decent step up from v0.2, so I wanted to give some advance notice.
What's new in v0.3:
Hardware video decode (VPU): H.264/H.265 decoded on the Cedar VPU — smooth video in the bundled web browser (WebKitGTK), using Allwinner's own cedar + libcedarc stack.
GNOME on Wayland (replaces Plasma), accelerated by Panfrost (Mali-G57). The X11 session is intentionally not used — Wayland is much faster on this GPU for both desktop and video.
Low-RAM fix: compressed in-RAM swap (zram) is on by default, so the 2 GB board stays responsive under a browser + video instead of freezing.
Robustness: the VPU driver now survives a client crashing mid-decode without wedging the board, plus a round of code-audit fixes across the clock, PCIe, DRM, VPU and audio-codec drivers.
Everything from before still works: display/KMS, GPU, HDMI + analog audio (headphones with jack detection), Ethernet, WiFi, USB, PCIe/NVMe (not yet tested with a real drive), thermal and cpufreq/DVFS.
How it's built: on top of mainline Linux and public community work (linux-sunxi, Armbian and others — credited in the tree), with Allwinner's public documentation and vendor BSP as the hardware reference, plus the project's own patches, each one validated on real hardware. Some of this has been posted to the linux-sunxi / upstream lists and picked up by maintainers.
This is a spare-time hobby project, shared as-is (async, no live support). Sources, patches and images are on GitHub — I'll post here again when the release is up:
GitHub: https://github.com/ut-slayer/orangepi-4a-mainline
Testers and feedback are very welcome. Thanks!

Small update: the patch series on GitHub is now up to date with what I actually run on the board. It went from 106 to 129 patches, all on vanilla 6.18.38.
 
https://github.com/ut-slayer/orangepi-4a-mainline
 
What's new since the last drop:
 
The GPU was running at the wrong frequencies (and now it isn't).
 
This is the interesting one. The A523 GPU clock is not a linear divider — it's a cycle-masking one: rate = source * (16 - M) / 16. Everyone modelled it as linear, including the vendor BSP. The practical effect: what the kernel labelled "150/200/300/400/600 MHz" was really running at 487/648/560/750/599 MHz. So the GPU was faster than advertised, and thermal throttling to "400 MHz" actually raised the clock to 750.
 
To be clear: nothing was ever unsafe. It ran like that for weeks, stable, at 920 mV, with temperatures in the normal range — the chip simply tolerates it. But the labels were wrong, throttling did the opposite of what it should, and you cannot tune power/performance on numbers that aren't real. Now the five operating points measure 149/199/300/399/597 MHz with the Mali cycle counter, from the intended parents.
 
Credit where it's due: Chen-Yu Tsai spotted the fractional divider while reviewing a patch I sent upstream. That review also produced a Reviewed-by for the generic clk fix, which is now on the lists.
PCIe / M.2. The controller and the Innosilicon combo PHY now probe, link training runs and the root port enumerates. I want to be honest about the limit of that statement: I don't own an NVMe drive, so I have only tested it with an empty slot. The bus comes up and behaves; whether a real drive negotiates, enumerates and performs is something I genuinely cannot confirm. If anyone here has an M.2 NVMe in this board, that report would be very welcome — including a failure report, which is just as useful.
(Kernel side comes from Marvin Wewer's Armbian series, authorship preserved, plus a 1-lane fix from the BSP and the device-tree wiring for this board.)
 
Hardware video decode works for H.264/H.265. With the cedar-ve shim in this tree plus the Allwinner userspace (libcedarc + gstreamer1.0-omx), YouTube plays smoothly in a WebKit browser (I use Cog). VP8/VP9 do not — that engine never raises its interrupt — so those codecs are capped and YouTube negotiates H.264 instead. Note the userspace half is not in the patch series and not in the published images yet.
 
Also in: a display fix for a frame that could get stuck after direct-scanout transitions, and JOYDEV/UINPUT enabled (analog sticks were dead in software that opens /dev/input/jsN first).
 
Images: the published v0.2 images are now well behind this. Refreshed Debian images (Desktop and CLI) built on this kernel are in preparation. No date promised — they go up when they're tested.
 
Thanks again to everyone testing and reporting here; the eMMC and 4 GB confirmations came from this thread, and the PCIe work started because someone took the trouble to diagnose why NVMe didn't show up.
 
 

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!