OPI 4A - Allwinner T527

[AurealNix]

@L. Jorge Soares  Thanks a lot for testing both — genuinely, this is the most useful thing anyone can do for the project. 🙏

CLI: great to hear it boots and HDMI works on your setup — that's the first confirmation from hardware other than mine, so it means a lot. If you get time, I'd love to hear how it holds up (networking, USB, and the 4 GB variant if that's what you have).

Root password: that's by design, not a bug. Root login is locked on purpose — the image ships with a default user / user account and SSH enabled, so an open root account would be a security hole. Use the user account with sudo:

• root shell: sudo -i (or sudo su)
• to set a root password if you really want one: sudo passwd root

KDE image + Etcher error: let's pin it down. Full disclosure — I flash with dd myself, so I haven't actually run these images through BalenaEtcher; I'll test the Etcher path on my end to try to reproduce it. In the meantime, two quick checks:

• Verify the download — a truncated/corrupt download is the #1 cause of Etcher errors. The desktop image sha256 is: 63b0019423d2a320aaa5fe58df97db68823b353a30510ffa863fec475904e0ba Check yours: sha256sum on Linux/Mac, or certutil -hashfile <file> SHA256 on Windows. If it doesn't match, re-download. And thanks for the heads up — I'll also double-check on my end that the file on the release didn't get corrupted during upload.
• Card size — the desktop image is ~5.3 GB when written (bigger than the CLI one), so it needs an 8 GB or larger card. A smaller/oddly-sized card makes Etcher fail.

If the checksum matches and the card is 8 GB+ but it still errors, it's most likely Etcher choking on the .xz — try Raspberry Pi Imager (Use custom → pick the .img.xz), Rufus (it writes in DD Image mode and takes the .xz directly), or on Linux just dd: xz -dc aurealnix-opi4a-debian13-v0.2.img.xz | sudo dd of=/dev/sdX bs=4M status=progress

And if you can, paste the exact Etcher error text — that tells me straight away whether it's a size, decompression, or validation issue. Thanks again for digging in! 🙌

[JamesCL]

Hi, I'm testing your Linux image on an Orange Pi 4B/4A with an eMMC installed and wanted to share the results.

The image correctly detects the eMMC. The kernel recognizes the device as:

mmcblk2: mmc2:0001 ISOCOM 58.3 GiB
Operating mode: HS200

 

image : aurealnix-opi4a-debian13-cli-v0.2.img.xz 

@AurealNix Thank you for your work.

 

Update:

During boot, the kernel reports two reserved-memory warnings:

OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram1@42350000'
OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram2@43000000'

The system remains fully functional. OP-TEE and BL31 reserved-memory nodes are present in the device tree, and eMMC HS200 operation has been tested successfully.

 

root@orangepi-4a:~# uname -a
Linux orangepi-4a 6.18.38-g59eb61929e89 #49 SMP PREEMPT Thu Jul 16 00:46:12 CEST 2026 aarch64 GNU/Linux
root@orangepi-4a:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            3830         330          95           9        3592        3500
Swap:              0           0           0
root@orangepi-4a:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.6
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@orangepi-4a:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk0      179:0    0  7.4G  0 disk
└─mmcblk0p1  179:1    0  7.4G  0 part /
mmcblk2      179:32   0 58.3G  0 disk
├─mmcblk2p1  179:33   0  1.2G  0 part
└─mmcblk2p2  179:34   0 57.1G  0 part /mnt/emmc-test
mmcblk2boot0 179:64   0    4M  1 disk
mmcblk2boot1 179:96   0    4M  1 disk
root@orangepi-4a:~# fastfetch
        _,met$$$$$gg.          root@orangepi-4a
     ,g$$$$$$$$$$$$$$$P.       ----------------
   ,g$$P""       """Y$$.".     OS: Debian GNU/Linux 13 (trixie) aarch64
  ,$$P'              `$$$.     Host: OrangePi 4A
',$$P       ,ggs.     `$$b:    Kernel: Linux 6.18.38-g59eb61929e89
`d$$'     ,$P"'   .    $$$     Uptime: 38 mins
 $$P      d$'     ,    $$P     Packages: 299 (dpkg)
 $$:      $$.   -    ,d$$'     Shell: bash 5.2.37
 $$;      Y$b._   _,d$P'       Terminal: /dev/pts/2
 Y$$.    `.`"Y$$$$P"'          CPU: sun55i-t527 (8) @ 1.80 GHz
 `$$b      "-.__               GPU: Allwinner sun55i-a523-mali [Integrated]
  `Y$$b                        Memory: 331.41 MiB / 3.74 GiB (9%)
   `Y$$.                       Swap: Disabled
     `$$b.                     Disk (/): 744.36 MiB / 7.19 GiB (10%) - ext4
       `Y$$b.                  Disk (/mnt/emmc-test): 24.49 GiB / 55.91 GiB (44%) - ext4
         `"Y$b._               Local IP (eth0): 192.168.7.12/27
             `""""             Locale: en_US.UTF-8



root@orangepi-4a:~#

 

Edited July 17 by JamesCL
update

[AurealNix]

@JamesCL This is a fantastic report — thank you, James. 🙏 You've actually confirmed two things I couldn't test on my own hardware…

 

1) eMMC works (detection + HS200 + read/write)… booting from eMMC is a separate step I haven't wired up yet.

2) 4GB variant confirmed (free -m shows 3830 MB)…

 

The two warnings — you read it right, secure SRAM for OP-TEE/BL31, harmless, cosmetic DTS cleanup I'll tidy up. …that's the most useful kind of report there is. Thanks again! 🙌

Edited July 17 by AurealNix

[bickns]

15 hours ago, AurealNix said:

One thing that's right up your alley given your outdoor-audio project: the A523 analog codec now has a working driver (ported from the BSP). Headphone output and jack-detect are validated on hardware; mic capture is wired in the driver but I couldn't bench-test it (no onboard mic here). You'd be the ideal person to confirm whether capture works

That sounds good.  I'm not using the jack for mic or output but should be able to check the DSP when things are more tied down with this outdoor-audio project.  Will let you know and thanks again on a great job with this board!!

 

[AurealNix]

@Nick_Sl @bickns — the headless build is up (146 MB, pure Debian 13, mainline 6.18.38, SSH from first boot): https://github.com/ut-slayer/orangepi-4a-mainline/releases/tag/v0.2

If either of you gives it a spin, I'd love a short report — what works, what doesn't. No rush and no obligation; even "booted, nothing broke" is useful.

@Nick_Sl — you offered to test, so I'm taking you up on it 🙂. Most useful gaps right now: NVMe / M.2 SSD, suspend, and the GPIO header (eMMC and the 4 GB variant were just confirmed by another tester).

@bickns — if the board ever leaves the drawer: the analog codec driver works, but mic capture is the one bit I couldn't bench-test (no onboard mic here). With your outdoor-audio project, you'd be the only one who could close that gap. Zero pressure either way.

And if you don't mind, I'll add you to the thanks in the repo — testers get named there (JamesCL is already in for confirming the eMMC and the 4 GB variant).

Also, early days and no promises: the VPU (hardware video decode) is something I've now started digging into.

Thanks both.

[L. Jorge Soares]

@AurealNix download the KDE v0.2 again and I was able to write it to SD card . No issues.

 

I am impressed, KDE loads just fine. Took a bit to load the first time.  Wifi works just fine, loaded Chromium and launched Youtube. Playback is good, at the moment full screen drops frames.

 

Audio through HDMI just worked, no issue.

 

I also loaded the KDE image on eMMC, it did not boot. I will check what is going on use serial and report back if I see anything.

 

 

[JamesCL]

@AurealNixThank you, excellent work... boot from eMMC

All that's missing is adding support for NVMe

 

Edited July 17 by JamesCL
update

[L. Jorge Soares]

Using the KDE image on eMMC storage, this is how far the boot process get. The results or from the serial port.

 

 

[217]HELLO! BOOT0 is starting!
[220]BOOT0 commit : 595900dccf
[224]periph0 has been enabled
[227]set pll end
[229]PL gpio voltage : 3.3V
[233][pmu]: bus read error
[236]PMU: AXP2202
[241]PMU: AXP1530
[245]power mode:33, sys_vol:920
[249]vaild para:1  select dram para0
[253]dram_para[0]:0x4b0
[255]dram_para[1]:0x8
[258]dram_para[2]:0x7070707
[261]dram_para[3]:0xd0d0d0d
[264]dram_para[4]:0xe0e
[266]dram_para[5]:0x84848484
[269]dram_para[6]:0x310a
[272]dram_para[7]:0x8000000
[275]dram_para[8]:0x0
[277]dram_para[9]:0x34
[280]dram_para[10]:0x1b
[282]dram_para[11]:0x33
[285]dram_para[12]:0x3
[287]dram_para[13]:0x0
[290]dram_para[14]:0x0
[292]dram_para[15]:0x4
[295]dram_para[16]:0x72
[297]dram_para[17]:0x0
[300]dram_para[18]:0x8
[302]dram_para[19]:0x0
[305]dram_para[20]:0x0
[307]dram_para[21]:0x26
[310]dram_para[22]:0x80808080
[313]dram_para[23]:0x6060606
[316]dram_para[24]:0x0
[318]dram_para[25]:0x74000000
[322]dram_para[26]:0x38000000
[325]dram_para[27]:0x802f3333
[328]dram_para[28]:0xc7c5c4c2
[331]dram_para[29]:0x3533302f
[335]dram_para[30]:0xc60
[337]dram_para[31]:0x48484848
[340]board init ok
[363]enable_jtag
[365]card no is 0
[367]sdcard 0 line count 4
[370][mmc]: mmc driver ver 2023-03-24 16:23
[380][mmc]: Wrong media type 0x0
[383][mmc]: ***Try SD card 0***
[405][mmc]: HSSDR52/SDR25 4 bit
[408][mmc]: 50000000 Hz
[411][mmc]: 30436 MB
[413][mmc]: ***SD/MMC 0 init OK!!!***
[425]boot param - magic error
[428]DRAM BOOT DRIVE INFO: V0.67
[432]DRAM_VCC set to 1160 mv
[559]DRAM retraining ten
[577][AUTO DEBUG]32bit,2 ranks training success!
[606]Soft Training Version: T2.0
[7410][SOFT TRAINING] CLK=1200M Stable memtest pass
[7415]DRAM CLK =1200 MHZ
[7418]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
[7428]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, tpr13 = 6461
[7459]DRAM simple test OK.
[7462]dram size =4096
[7469]nsi init 2023-2-23
[7605]Loading boot-pkg Succeed(index=0).
[7609]Entry_name        = u-boot
[7619]Entry_name        = monitor
[7623]Entry_name        = scp
[7626]Entry_name        = dtb
[7631]mmc not para
[7632]Jump to second Boot.
NOTICE:  BL31: v2.5(debug):20a8ac62a
NOTICE:  BL31: Built : 17:17:28, Jan 22 2024
NOTICE:  BL31: No DTB found.
nsi init ok 2022-11-08
ERROR:   Error initializing runtime service opteed_fast
 

[Nick_Sl]

On 7/17/2026 at 5:26 PM, AurealNix said:

you offered to test, so I'm taking you up on it 🙂. Most useful gaps right now: NVMe / M.2 SSD, suspend, and the GPIO header (eMMC and the 4 GB variant were just confirmed by another tester).

thanks. The image has been launched. I will try to test  gpio and  mipi camera.

 

mipi csi camera not vorking ( need drivers

Edited Monday at 05:36 PM by Nick_Sl

[AurealNix]

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.

 

 

[ioncube]

a very exciting development on mainline with VPU_GPU acceleration enabled

 

https://github.com/ut-slayer/orangepi-4a-mainline/issues/2#issuecomment-5030458197

[bickns]

@AurealNix - Firstly massive kudos to where you've got this board there will be lots of people here quite happy they can get onto a 6.18 kernel .. Well done sir.  You 'll be pleased to hear I pulled my ebay listing as a result of what you and Claude achieved.  I also signed up to a Claude subscription to save me being so abusive to Gemini when it doesn't meet the standard - thank you! 

So I just downloaded the headless image and imaged to an M.2 NVMe ... Connected the Serial cable powered on and nothing on the screen I'm afraid.   So I armbian-imaged it onto an SD and everything booted fine, lots of text - I logged in and "fdisk -l" only showed my SD card.  so I guess that's a negative with the NVMe ... one thing I haven't done is imaged the orangepi-4a 5.x kernel onto the NVMe to see if it boots as it might be that the boot protocol only looks on the SD - will post if I can image the 5.x onto the M.2 and get it to boot later.

 

I've just tried to find a headset cable to test the audio port but only got a headphone cable so can't test yet - and I've seen in your git repo that you have already confirmed the audio port is good so no pressure for me unless you are still in need of testing ?

Great stuff and cheers!

[AurealNix]

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!

[bickns]

@AurealNix - great news on v0.3 and great work !!

 

So having established that the v0.2 image could neither boot from nor recognise NVME SSD (double negative there, apologies .. hope that translates ok into espanol!) I just flashed the vendor 5.x image to the NVME and it failed to boot as well.    However the NVME is recognised correctly from 'fdisk -l' when I boot from the 5.x SD so it might be that more tweaking is needed on the NVME once flashed to maybe get it to boot - but that is for another day ....  

 

Hope this helps - cheers.

 

[AurealNix]

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! 🙌

[bickns]

@AurealNix - I just saw your v0.3 went up so I downloaded it to test the NVME once again and still the same result.  I looked in dmesg -T and see these messages which might be of use ?  It seems to find the nvme0n1:p1 partition but nothing more beyond that

user@orangepi-4a:~$ sudo dmesg -T | grep -iE "pcie|nvme"  
[Sun Jul 26 09:58:55 2026] /soc/pcie@4800000: Fixed dependency cycle(s) with /soc/pcie@4800000/legacy-interrupt-controller
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: host bridge /soc/pcie@4800000 ranges:
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie:      err 0x0020000000..0x0020ffffff -> 0x0020000000
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie:       IO 0x0021000000..0x0021ffffff -> 0x0021000000
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie:      MEM 0x0022000000..0x002fffffff -> 0x0022000000
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: pcie link up success
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: PCIe speed of Gen2
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: Current speed Gen0 < target Gen2. Retraining link...
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: PCIe speed of Gen2
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: PCI host bridge to bus 0000:00
[Sun Jul 26 09:58:55 2026] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 PCIe Root Port
[Sun Jul 26 09:58:55 2026] pci 0000:01:00.0: [1e0f:0001] type 00 class 0x010802 PCIe Endpoint
[Sun Jul 26 09:58:55 2026] pci 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 li
nk)
[Sun Jul 26 09:58:55 2026] pcieport 0000:00:00.0: PME: Signaling with IRQ 465
[Sun Jul 26 09:58:55 2026] pcieport 0000:00:00.0: AER: enabled with IRQ 465
[Sun Jul 26 09:58:55 2026] sunxi-pcie 4800000.pcie: driver version: 1.2.4
[Sun Jul 26 09:58:59 2026] nvme nvme0: pci function 0000:01:00.0
[Sun Jul 26 09:58:59 2026] nvme 0000:01:00.0: enabling device (0000 -> 0002)
[Sun Jul 26 09:58:59 2026] nvme nvme0: allocated 61 MiB host memory buffer (16 segments).
[Sun Jul 26 09:58:59 2026] nvme nvme0: 8/0/0 default/read/poll queues
[Sun Jul 26 09:58:59 2026]  nvme0n1: p1
user@orangepi-4a:~$
user@orangepi-4a:~$ sudo fdisk nvme0n1

Welcome to fdisk (util-linux 2.41).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

fdisk: cannot open nvme0n1: No such file or directory

user@orangepi-4a:~$


 

[bickns]

@AurealNix - TLDR: NVMe is working now !!

I posted that last message before you posted your last message !  I thought I might try a bit of diagnostics because lsblk shows the device and then Claude pointed out my fdisk needed a dev prefix (doh!) - my bad as I had been just typing fdisk -l but didn't for some reason on the v0.3 

user@orangepi-4a:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0  29.7G  0 disk  
└─mmcblk0p1 179:1    0  29.7G  0 part /
zram0       254:0    0     1G  0 disk [SWAP]
nvme0n1     259:0    0 238.5G  0 disk  
└─nvme0n1p1 259:1    0   2.1G  0 part  
user@orangepi-4a:~$ sudo fdisk /dev/nvme0n1

Welcome to fdisk (util-linux 2.41).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): q

user@orangepi-4a:~$ sudo fdisk -l
Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc96adb09

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1      40960 62333918 62292959 29.7G 83 Linux


Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: KBG40ZNV256G KIOXIA                      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4efc7e9e

Device         Boot Start     End Sectors  Size Id Type
/dev/nvme0n1p1      40960 4464639 4423680  2.1G 83 Linux


Disk /dev/zram0: 1 GiB, 1073741824 bytes, 262144 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


 

[AurealNix]

Oh yes!! 🎉 We fixed a few bugs along the way, but honestly I didn't think it was fully ready yet — so "NVMe is working now!!" genuinely made my day. And glad it came down to just the /dev/ prefix in the end 😄

 

This one matters a lot: it's the first time the PCIe/NVMe bring-up has been confirmed with a real drive instead of an empty slot — and it even came up at Gen2, better than the Gen1 I saw with nothing plugged in. So the controller and the Innosilicon combo PHY are solid. I'll note it in the docs (and credit you + the KIOXIA).

 

Next step, if you're keen: running the rootfs on the NVMe (still booting the boot chain from SD/eMMC) — a big jump over the microSD, and it sidesteps the fact that this board can't do UHS on SD anyway. It's not on by default yet because the NVMe driver is a module with no initramfs, so it isn't loaded when root gets mounted. No need for a special build right now, though: I'll just bake NVMe built into the kernel in the next release and add a short "move rootfs to NVMe" recipe then. A one-off build today would only make sense to fix an actual bug, and there isn't one — as storage it already works. And it shouldn't be a long wait: I want the next release to fold in the 6.18.40/.41 stable improvements — there's a fair few worth having, some of them A523-specific — and the NVMe-built-in change will ride along with that refresh.

[flintduval]

1 час назад, AurealNix сказал:

on this SoC the boot ROM only loads the bootloader from microSD or eMMC

... or SPI Flash.

This board has 16 MB of SPI Flash, so we can try writing the bootloader there.

[AurealNix]

@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.