I was under the impression, that for most (popular) chip families, like RockChip, Allwinner, Amlogic, some assorted Broadcoms, .. the Mainline linux kernel support has mostly been sorted for, and it's only the stragglers like Hisilicon, Huawei, Most Broadcom, Qualmcomm where mainline support is not on their priority list?
If the application fits, choosing one of the BSDs with the more popular chip families can work well. In other words, if the BSD crowd likes an SoC, you'll get a good, stable system running with good kernel support. In my case it's the RockChip family, specifically from PINE64.
Examples:
- PINE64 Rock64 running FreeBSD 14.1 replaced an aging RPi3. I use this for SDR applications. It's a small, low power device with PoE that I can deploy close to my outdoor antennas (e.g. 1090mhz for dump1090-fa ADS-B). It's been really solid with its eMMC, and FreeBSD has good USB support for RTL-SDR devices.
- PINE64 RockPro64 running NetBSD 10. I have a PCIe card with a 500gb SSD M.2 slot. NetBSD has ZFS support and it has been stable. This lets me take snapshots on the SSD zpool. I generate time-lapse videos using the faster cores.
You don't get 100% HW support (e.g. no camera support for RockPro64) but I don't need it. The compromise is worth it in my case because I get a stable and consistent system that I'm familiar with: BSD.
Maybe, but regular distros on x86/x64 thin clients are even more sorted out. GPIOs are better handled through an Arduino clone over USB than with scripts running on inherently laggy desktop OS.
After configuring the vendor uBoot to chainload into a newer uBoot-compile with JustEnoughUEFI compiled in, you can just launch the standard Debian Arm64/UEFI install iso on many/most(?) popular SOCs.
W.r.t. GPIOs, I agree, that delegating that to an e.g. Arduino connected via USB/UART or one of the available internal(often RTC), or external(HDMI/VGA) I2C connections as an I2C slave is the preferred solution.
