[ 1.234958] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 1.235032] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 PCI support on this SoC has never been fully stable. Patch that tries to mitigate the issue, exists: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/rk3399-fix-pci-phy.patch Not really much we can do more - use a kernel that it works, try current one with few reboots, ... I know its not perfect but we have nobody that can afford investing few weeks trying to fix this. Imagine the frustration if nothing will be improved - which I highly suspect for this case.

Hm. Well. Im out of ideas. Perhaps openwrt will find something when they're going to work on 6.18. Unmarked the old solution for now since it no longer applies.

I don't know if it's useful, but folks have been attaching external GPUs to low power boards for a while. My personal favorite was sacking and desoldering a USB3 controller to reuse it's PCIE lane: https://mloduchowski.com/raspberry-pi-4-b-pci-express/ Others have run into the same BAR limitation you noted: https://www.jeffgeerling.com/blog/2020/external-gpus-and-raspberry-pi-compute-module-4/ From a practical perspective, I'm not sure how many folks would be interested in discrete GPUs, as I'm not sure these sorts of boards would have the CPU or PCIE lanes to really make use of that extra horsepower. Most would get a dedicated embedded system, or a bespoke NVidia setup. For what it's worth, I ran into an issue where the kernel was too big for u-boot to boot it, and would just throw a synchronous abort and reset. The difference between working and not working was 7 MB.

That is true that there are images that target server vs. desktop. But they share the same kernel. I find what you are working on an interesting idea. Good luck getting it working.

Yes, it is a fair point that I've not demonstrated that it can actually be made to work yet, I'm working on that part,.... and as you say, it's also a fair question to ask how much impact compiling those drivers as modules has on systems not using them. That latter question I /can/ answer. The increase in the kernel in memory is about 5MB, and the increase in the /lib/modules/ is about 26MB I did notice when I went through the build process to make a new kernel/image (That's pretty impressive work BTW, great job!)... that there is a distinction between a server and desktop image... obviously in the server build this wouldn't be a thing, and the desktop image would probably be useless on a machine that couldn't spare 5MB... Point taken tho, I'll post some updates here once it's working.