Edmilson Santos

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.

This device is currently an outcast here, and until someone with understanding sets out to fix at least the main problems, welcome to the official image on the 5.15 kernel.

guess it kernel/driver issue

The driver does not request the stmmaceth (emac1-25M) clock during probe. Without this clock the MDIO bus does not function on cold boot - PHY ID reads as 0x00000000 and kernel falls back to Generic PHY instead of YT8531. Ethernet does not work until warm reboot.

Issues for the actual image (no UI): no HDMI; Ethernet got address with DHCP, but cannot connect with SSH, even ping (ICMP) is not stable. Wifi works fine. The board is OK - tested with official debian image.

Ethernet should be working (after rebooting), but wifi doesnt work out of the box.

https://drive.google.com/drive/folders/1dx0TApPAEjFDz24Rm22J4jgtIbJrYYHC?usp=drive_link
 
build log: url
for test...
 
https://github.com/armbian/build/pull/9185

@JuanEsf sunxi-edge is now on 6.18. You can add your patches for t527 there.

You're in luck. Major work has been done. https://github.com/armbian/build/pull/9049 Still needs testing
Once this is merged 4A and other more recent Allwinner Soc related work can be rebased on top of that.