bickns

The current image is broken due to incorrect GPT header.
https://github.com/armbian/build/issues/10647
 
I had the same issue and somehow when I flashed the image the first attempt, the bootloader detected *something* and tried to boot *something*, but the console never appeared.
The subsequent writes, after wiping the start and the end of MicroSD, failed at the bootloader (the bootloader did not see the partition table, just as Linux both times).
 
So my guess is that even if the bootloader uses backup partition table somehow, the Linux kernel does not and fails to mount rootfs.
 
The fix is to set Number of partition entries in array = 16. See the ticket. The image successfully boots after that.

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.

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";        };    }; };