bickns

Thanks Valdik - I won't get a chance to test this until next week though but sounds promising!

@AurealNix - I realised I meant to say "NVMe is recognised now" so was getting a little ahead of myself so felt i should at least give the SSD a bit more exercise. cue: f3write/f3read on the entire 256GB + rinse/repeat a few times worked ok with nothing appearing in the dmesg to indicate it trips up etc. Regarding running rootfs on I'll see if I can squeeze that in (maybe Tuesda) as i will need to dd my sd and then image onto the NVMe and tweak /boot/boot.cmd /boot/orangepiEnv.txt accordingly - I can't just use your image on the NVMe as it starts at 2GB and then stretches out at first boot. If this is what you are looking to do/get-tested or maybe something else ? Also (low priority request), if you could add/install iproute2 onto the minimal image that would be handy! Cheers

@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 - 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:~$

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

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

Thanks @AurealNix - that's good intel. Only 20 of those patches of the 109 failed - I had a quick look through them and I can see you are looking to prioritise the GPU (all those GOOGLE_ flags to make youtube stream better etc) amongst other things. For my project I only needed to run headless so I could install your image and uninstall KDE if it didn't work out with my current prototype for this outdoor noise cancelling thing (I was attracted to the opi 4a because it had a bit more all round grunt) I figured I'd stick with armbian as it would have a better chance of the PR for changes to dtb etc being accepted into "stable".. I think I might go with your .dts and manually apply the changes to the other files and then build from there - used to have the stomach for this back in the day when I used to hack stuff before the internet, but I really need to get onto the noise cancelling project as my wife complains about the noise of the road when we have a BBQ outdoors and I reckon i could go some way to disturb that with some software. Your retro gaming image sounds top notch! I'm still to Master Halo 4 on the X-Box one given all these other distractions. The board is now in the bottom drawer for now as the DJI Mic Mini 2 just turned up today and the other board recognises it ok and its on to stage 2 of this prototype. Enjoy the football .. Cheers

@AurealNix - great effort and thanks for putting me in touch with Claude 5, I was just using Gemini and it was struggling a fair bit!! In fact I had just put this board on ebay as it was causing too much distraction so your last two posts looked hopeful. Sorry my spanish isn't that great so I'll stick with English. I was hoping to just put these 106 patch files directly into the userpatches/kernel/archive/sunxi-6.18 folder and then run compile.sh with USER_PATCHES=yes, but that didn't work as patch files in that location seem to be tempremental and it couldn't find a lot of the targets. I tried removing the ones with errors which didn't work either, so went down the route of adding running compile.sh with kernel-patch parameter then copying your sun55i-t527-orangepi-4a.dts into ./cache/sources/linux-kernel-worktree/6.18__sunxi64__arm64/arch/arm64/boot/dts/allwinner/sun55i-t527-orangepi-4a.dts to get a new patch file, but this failed to compile likely because it doesn't have the changes you made to the .dtsi and other files . It would be good to know how you and Claude were building the kernel - I can see in your README that you are doing it directly into linux 6.18.38 tree, whereas I was working out of a clone of armbian in github. I would like to spend more time on this but need to get onto the real reason I bought the board (an outdoor noise cancelling project) so I'm going to use another board in the meantime. Cheers

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

Title: [Working Image + Patch] Orange Pi 4A (T527) - Fast Ethernet Fixed on Mainline 7.0 Edge Hi everyone, Since the Orange Pi 4A (Allwinner T527) is currently an unmaintained community target on the bleeding-edge Mainline 7.0 Edge branch, the default images boot up completely blind with cannot attach to PHY (error: -ENODEV) errors. After a lot of debugging, I (with assistance from Gemini - who wrote this post) managed to successfully compile a full, functional Debian Trixie image where Ethernet works perfectly (capped at 100M) and the green status LED pulses a native heartbeat. The secret sauce is that the board uses a Motorcomm YT8531 transceiver, but the kernel falls back to a Generic PHY driver which fails to calibrate the high-frequency RGMII clock skews required for Gigabit speeds. Dropping the link frequency down to 100 Mbps Full Duplex bypasses the timing sensitivity completely, allowing NetworkManager to instantly pull a stable IPv4 DHCP lease! (Note: Mainline 7.0 does not yet have internal C drivers for the T527 audio codec or the SDIO mmc1 bus clocks, so internal audio and onboard Wi-Fi remain offline. Use a USB sound/Wi-Fi dongle if needed). I can't vouch whether HDMI is working or not as I was debugging it using a serial cable. 📦 Download the Image https://drive.google.com/drive/folders/1ieu3TBn2nSP0BaJvJMIhLeLM6kt-x8bX?usp=sharing 🛠️ The Device Tree Patch File I managed to diff the radxa-cubie-5e.dts file and patch it to get it to kind of work with the opi 4a. The patchfile is also in the google drive folder and supplied as an attach here. To include this in your own Armbian build environment, delete any old patches and save this file exactly as: build/userpatches/kernel/archive/sunxi-7.0/zzzz-working-opi4a.patch It wipes out the broken default configurations and replaces them with clean, compiling mainline mappings. You can then build the image using this: ./compile.sh build BOARD=orangepi-4a BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_CONFIGURE=no RELEASE=trixie USERPATCHES_ALLOWED=yes SYSTEM_VERBOSE=yes FORCE_REBUILD=yes 📝 Step-by-Step Instructions to Lock Down the 100M Connection Because the Generic PHY driver cannot process 1Gbps packets correctly, the interface will sit in an unconfigured DOWN loop upon initial boot. Run these steps via your serial terminal loop to bring it online and automate it: Force the hardware down to 100M to clear the packet queue: sudo ethtool -s end0 speed 100 duplex full autoneg off Tell NetworkManager to explicitly negotiate the port: sudo nmcli device connect end0 Make the 100M setting permanent so it survives a reboot: sudo nmcli connection add type ethernet con-name eth-100m ifname end0 802-3-ethernet.auto-negotiate no 802-3-ethernet.speed 100 802-3-ethernet.duplex full ipv4.method auto ipv6.method disabled Automate the green status heartbeat LED: Open /etc/rc.local and add this line right above exit 0 echo heartbeat > /sys/class/leds/green:status/trigger Reboot, and you should have a 100% automated, maintenance-free, fully operational network target - with some tweaking will hopefully get you to the next stage as apt will be working. Hope this helps anyone else struggling to get this community board running on modern releases! zzzz-radxa-to-orangepi4a-fix.patch

Greetings ### [Follow-up Update] Boot Deep-Dive via Cubie-A5E DTB Masking Following up on my previous boot freeze post, I (with some assistance from Gemini - who formatted this post) managed to force the Armbian kernel to initialize by masking the sister chip profile (`sun55i-a523-cubie-a5e.dtb`) over the broken `sun55i-t527-orangepi-4a.dtb` target and injecting `clk_ignore_unused` / `irqpoll` parameters. This got us past the initial handoff hang and successfully spawned the 8-core CPU array initialization and initramfs launch (`Run /init as init process`), but the system eventually hit a permanent deadlock during the device probe phase. I don't think I can get this to go any further without some many hours spent looking at how these things work and its currently 35 degrees C here in the UK so time for a beer methinks! #### Full Boot Log Paste Link: - this is the log before using irqpoll parameter (which eventually caused a deadlock) - I can post the irqpoll logs although i wouldn't have thought irqpolling is the way to go ? https://pastebin.com/TvxTxdbp ### Either way - having just read that this post refers to irqpoll then this is the boot logfile with irqpoll added an an extraparm https://pastebin.com/TNS3DDTC #### Key Technical Takeaways from the Log Dump: 1. **PMIC / I2C Communication Failures:** The kernel initializes the AXP717 and AXP323 power chips but encounters standard timeout errors right away: ```text axp20x-i2c 0-0034: AXP20x variant AXP717 found axp20x-i2c 0-0034: Failed to set masks in 0x40: -6 axp20x-i2c 0-0034: failed to add irq chip: -6 ``` 2. **MMC / Storage Controller Deadlock:** Because the AXP717 framework drops out and the Cubie pin definitions do not line up with the Orange Pi 4A's physical board wiring, the kernel enters an endless loop waiting for internal voltage rails (`cldo3` and `bldo1`) to power up the storage controller: ```text platform 4020000.mmc: deferred probe pending: platform: wait for supplier /soc/i2c@7081400/pmic@34/regulators/cldo3 platform 4021000.mmc: deferred probe pending: platform: wait for supplier /soc/i2c@7081400/pmic@34/regulators/bldo1 ``` This prevents the storage device slot from spinning up, trapping the system right as it attempts to mount the root filesystem. Hopefully this helps isolate the unaligned power configuration loops and clock tables in the current `armbian-imager` source profile for the OPi 4A!

Greetings - just investigating an issue with the opi-4a Armbian 26.8.0 minimal (edge 7.0.12) build - not getting past starting kernel. The board has a T527 - Hopefully this information is useful ? ### [Bug Report] Orange Pi 4A - Silent Hang at 'Starting kernel ...' (Trixie Minimal) **Board:** Orange Pi 4A (Allwinner A523/T527) **Image used:** Debian Trixie Minimal (Built via armbian-imager) **Installation Media:** SD Card (Class 10) **Log Type:** UART Serial Console Output (115200 baud) --- #### Description of Issue The recent community build of Debian Trixie Minimal for the Orange Pi 4A successfully clears the U-Boot / SPL stages, loads the Ramdisk and DTB from the SD card, but hangs completely silently immediately after hitting `Starting kernel ...`. The onboard status LED remains solid red with no flashing activity. #### The Technical Root Cause Looking closely at the UART initialization text, there appears to be a mismatch between the SoC detected by the low-level firmware and the Device Tree Blob (DTB) loaded by the Armbian boot script: 1. **Firmware/U-Boot Chip Detection:** TF-A and U-Boot explicitly identify the SoC as an **Allwinner A523**: ```text NOTICE: BL31: Detected Allwinner A523 SoC (1890) CPU: Allwinner A523 (SUN55I) ``` 2. **Script DTB Selection:** Immediately afterward, the automated script loads a **T527 DTB** profile: ```text Load fdt: /dtb/allwinner/sun55i-t527-orangepi-4a.dtb ``` Because the kernel tries to initialize the primary power rails and clock gates using a T527 map on an A523 layout, the CPU locks up silently at the execution handoff. --- #### Complete Boot Log (Up to the Hang) ```text U-Boot SPL 2026.01_armbian-2026.01-S127a-P60fe-Hc6a9-Vf757-Bd0d2-R448a (May 30 2026 - 05:53:33 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.13.0(debug):armbian NOTICE: BL31: Built : 05:52:43, May 30 2026 NOTICE: BL31: Detected Allwinner A523 SoC (1890) NOTICE: BL31: Found U-Boot DTB at 0xa0b8ac0, model: OrangePi 4A INFO: Configuring SPC Controller INFO: BL31: Platform setup done INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 287 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a55: CPU workaround for erratum 1530923 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2026.01_armbian-2026.01-S127a-P60fe-Hc6a9-Vf757-Bd0d2-R448a (May 30 2026 - 05:53:33 +0000) Allwinner Technology CPU: Allwinner A523 (SUN55I) Model: OrangePi 4A DRAM: 2 GiB sunxi_set_gate: (CLK#35) unhandled Core: 94 devices, 24 uclasses, devicetree: separate WDT: Not starting watchdog@2050000 MMC: mmc@4020000: 0, mmc@4021000: 2, mmc@4022000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial@2500000 Out: serial@2500000 Err: serial@2500000 Net: No ethernet found. starting USB... USB EHCI 1.00 USB OHCI 1.0 USB EHCI 1.00 USB OHCI 1.0 Bus usb@4101000: 1 USB Device(s) found Bus usb@4101400: 1 USB Device(s) found Bus usb@4200000: 2 USB Device(s) found Bus usb@4200400: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 PCIe: Acquiring resources... PCIe: Failed to get switch-sel GPIO: -2 PCIe: Hardware init failed with error -2 Device 0: unknown device switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 4641 bytes read in 2 ms (2.2 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 249 bytes read in 2 ms (121.1 KiB/s) Load fdt: /dtb/allwinner/sun55i-t527-orangepi-4a.dtb 33383 bytes read in 7 ms (4.5 MiB/s) Working FDT set to 4fa00000 Failed to load '/dtb/allwinner/overlay/sun55i-t527-fixup.scr' 16748327 bytes read in 814 ms (19.6 MiB/s) 41171456 bytes read in 1707 ms (23 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=0x42a30000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 16748263 Bytes = 16 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 49007000, end 49fffee7 ... OK Loading Device Tree to 0000000048f96000, end 0000000049006fff ... OK Working FDT set to 48f96000 Starting kernel ... ```