So if we want to go with completely open arch, we'd be looking at something like this: https://www.hackster.io/news/a-feather-compatible-fpga-board-running-a-ri

So if we want to go with completely open arch, we'd be looking at something like this: https://www.hackster.io/news/a-feather-compatible-fpga-board-running-a-risc-v-core-with-lorawan-848d6257aa88 https://www.hackster.io/news/a-feather-compatible-fpga-board... https://github.com/mcci-catena/HW-Designs/tree/master/Boards/Catena-4710 https://github.com/mcci-catena/HW-Designs/tree/master/Boards... https://github.com/mcci-catena/catena-riscv32-fpga https://github.com/mcci-catena/catena-riscv32-fpga ie. an FPGA you can put your own OS AND radio firmware on. Something like https://www.bunniestudios.com/blog/?p=5921 https://www.bunniestudios.com/blog/?p=5921 (and see the updates https://www.crowdsupply.com/sutajio-kosagi/precursor/updates https://www.crowdsupply.com/sutajio-kosagi/precursor/updates) doesn't cut it fully as the wifi has a firmware blob, and in addition I'm not sure how open the xilinx toolchain is (might be, I know some xilinx chips are supported by open source toolchains). As an OS for the feather board, you could use DASH7 for the radio portion (https://en.wikipedia.org/wiki/DASH7 https://en.wikipedia.org/wiki/DASH7), and Oberon as a general OS. (https://blog.gadgetfactory.net/2016/02/how-to-implement-the-old-oberon-system-on-a-modern-fpga/ https://blog.gadgetfactory.net/2016/02/how-to-implement-the-...) Obviously several problems exist there - only Linux has an available FPGA toolchain, so you need a linux computer to bootstrap Oberon onto the FPGA, and DASH7 won't run on the same device (it runs on STM32 boards mainly). So, to get a completely open design, you'd need to port DASH7 stack and the FPGA tools to Oberon to allow self-hosting and fully open radio. Add to that the fact that this board doesn't supply any video output so your development is over ssh/terminal and you have a way to go to get a fully open system. Other pain points are that Oberon is a systems language that uses GC, so for deterministic/realtime (radio) operation it is not usable - you'd need to use it's cousin Composita to have a deterministic memory managed OS. Lastly, Oberon doesn't have any formal verification tools which would be ideal for verifying the entire self-hosted stack. I suspect you'd need to use a LISP of some sort to be able to verify things from the ground up. Of course most LISPs have GC so you'd need to migrate the Composita+Oberon (A2) architecture to LISP to be able to build higher-level verifiable constructs. However... this is almost possible. There are a few key things to work out here, but it's closer than at any point previously :)