This is what you get with 99% of the arm SBC trash. They will generally boot the one hacked up kernel the vendor ships, which are overwhelmingly about 5 years out of date because its the kernel they hacked up for the original high margin customer, and by the time the SoC is publicly available its basically abandonware.
Outside of rpi's which have boatloads of community support, about the only boards that aren't this way are the systemready ES/SR certified ones. There is a IR level too, but its still using DT, meaning that the linux kernel devs will break the machine at random times requiring firmware/DT updates when newer kernels are loaded. The ES/SR bands use UEFI+ACPI and provide a standardized platform that is the same as what one expects of a random pc.
Agreed. In this case, the vendor doesn't ship a working kernel at all. Their view is that the community will handle that. Massive props to ayufan, without whom most of the Pine SBC's would likely have no bootable image.
I experimented with a RockPro64 a few years ago before learning this lesson. The hardware sounded wonderful. Unfortunately, there was some kind of conflict between the PCIe slot and the GPU. It was possible to get hardware-accelerated video, or use the PCIe slot for additional SATA slots, but not both at the same time. I spent a fair amount of time trying to dig into it, but never did establish whether the problem was in hardware, the device tree, or the drivers.
Outside of rpi's which have boatloads of community support, about the only boards that aren't this way are the systemready ES/SR certified ones. There is a IR level too, but its still using DT, meaning that the linux kernel devs will break the machine at random times requiring firmware/DT updates when newer kernels are loaded. The ES/SR bands use UEFI+ACPI and provide a standardized platform that is the same as what one expects of a random pc.