Hi domillo, If the green light has started flashing, it may indicate that the system has been started, but at this point, we cannot determine the IP address of the Cubie a5e. Once you have a UART adapter, please try to capture the DRAM parameters of the Cubie a5e according to this document: radxa-cubie-a5e-u-boot/README.md Guation

WOL might work on a newer 6.18 release of the kernel. Btw do I have it right that you're using Armbian without OMV?

Thank you for the information mmgen, One thing you missed is the ffmpeg compilation information. Run: $ ffmpeg It will print out the ffmpeg version and all the libraries that were enabled, and all the libav* libraries it has compiled along with ffmpeg (libav* are parts of the ffmpeg project). The interesting information is whether it uses the "v4l2-request" library, which lets ffmpeg control a part of the kernel that controls the hardware decoder. When you run mpv -v yourvideo.mp4 you could also see v4l2request, or some other message about the hardware acceleration (at this point I doubt that v4l2request is used, because it works better in newer kernels)

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.

Uhm... What repository is that commit hash for? I tried armbian/build and armbian/linux and a couple of others but it doesn't seem to belong there. I don't expect this to be a single-day task. I'm OK to invest the time in finding out what happened and run a bunch of bisections, even if that needs to include both Armbian tool repos and the Linux kernel repo. I just need some pointers to what the right approach is here and what kind of scripts/setup I should be running for each iteration. I would expect having this procedure documented can help other people too, so I'd be happy to do some write up for it. I can think that: Maybe there's a way to provide a kernel repo commit to check out to the build infrastructure and get kernel packages built from that. I should be able to just sync the build scripts to whatever was current when 6.19 was released. Maybe there's some way to just "compile and install the kernel the old way" and ignore the packages part of it. But I'm not familiar with the uboot specific formats for images and initial ram disks and I fear the result of doing that might be missing patches or some other things and not be comparable to the package-based experience. And, yes, 6.19 might be some time ago, but AFAIU -current is still based on 6.18... next time that gets bumped up breakage will stop being "optional" for me.