It would probably come down to getting enough information about the board and a functional DTS for the entire board (not just the SoC) to be able to port a new target for OpenWrt and then the board for that target. If there is a viable GPL drop for the device that is DTS based that might make it easier. If the device is running a DTB-based kernel, then that information could be read from /proc/device-tree and de-compiled. Depending on how old that kernel was and how many proprietary drivers were in use would impact how useful that information was.
Possible, yes. Easy? Probably not, at least with what my quick search found. Information I may not have found may make it easier.
Upstream support for these AnnapurnaLabs SOCs (taking the AL-514 as an example) doesn't go far beyond serial console support and mainlining has stopped after amazon bought them out. While it's an interesting and very fast SOC, they're only used in very few (high priced-) devices and there'd be a lot of work required to get it working.
Thanks for your help.
How do I find the DTS of this device?
# cat /proc/cpuinfo
processor : 0
model name : Annapurna Labs Alpine AL212 Dual-core ARM Cortex-A15 CPU @ 1.40GHz
Speed : 1.4GHz
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 4
processor : 1
model name : Annapurna Labs Alpine AL212 Dual-core ARM Cortex-A15 CPU @ 1.40GHz
Speed : 1.4GHz
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 4
Hardware : Annapurna Labs Alpine
Revision : 0000
Serial : 0000000000000000
[~] # uname -a
Linux Mac 4.2.8 #2 SMP Thu Apr 25 04:20:11 CST 2019 armv7l unknown
If the vendor firmware is device tree based (instead of using the older approach using device specific mach files, but device tree is more likely on ARM platforms), you can extract it from the running kernel (/sys/firmware/devicetree/base) via dtc (device-tree-compiler). However, this is only partially useful, as the results are both bad quality (using a flat FDT, with all includes being expanded) and because they only apply to the vendor kernel and its drivers, while the interfaces (the device tree bindings and their ABI) might differ to current mainline(ish) or OpenWrt kernels, due to different drivers and driver versions being in use. Furthermore many of the required drivers and driver changes will also be missing from mainline'ish kernels, so having a FDT file on its own is only (a rather small) part of the puzzle.