ioncube

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.
 
 

@Fajar Muttaqin Can you share your compiled kernel & headers `.debs`
 
In default kernel support for filesystems `cifs` & `nfs` were not included. I compiled with these support as well
https://github.com/defencedog/orangepi4A/tree/main/kernels