I agree with Michael but from a different perspective, people may feel reluctant to support it.
NanoPi r5s comes without UART pins soldered, and I am too lazy to get my hands dirty.
Although HDMI is there, I don’t see the startup information from HDMI until it hits kernel.
The ATF is not opensourced yet, although their(rockchip) bin compiles fine with u-boot 2.7, there is no HDMI ouput yet. And because lack of UART pins, I cannot be bothered to spend time on it.
It’s probably my fault of being lazy, but if I have other choises why bother?
thanks for your brief introduction and insights to IPFire.
After reading your reply I realized I misunderstood/misexpressed ‘driver’ & ‘patch’ & ‘kernel module’ & ‘integration’:
It looks like there are two main techniques to make an ARM system/board running under Debian/IPFire/.ux/.ix:
Integration of patches into the kernel, that have resource addresses hard-coded
Providing hardware description files *.dts, respectively its serialized pendant *.dtb
The first approach is the one you addressed?
I was aiming on the latter The SBC I mentioned is reflected in arch/arm64/boot/dts/ti branch of kernel.org in means of *.dts files:
The question is how to make IPFire read the *.dts/ *.dtb files. As I understood the second approach solves the shortcomings of patching/building the kernel every time a new board / CPU / hardware revision has emerged. DTS’s/DTB’s shift the work for hardware integration from kernel developers back to system vendors who just provide a standardized data structure every linux distribution understands.
So, in my understanding, IPFire (or any ohter distribution) shall easily support the latest hardware, as long as the system vendor provides such files? Does IPFire kernel hardening requirements allow this approach, and if, how is this done?