ahlCVA

This is on point. I work on small-ish embedded Linux systems and I would really like to use Rust there, but a single Rust binary takes up enough space for 10 C programs, so it's prohibitive. You can dynamically link your libraries (especially since these systems are usually built as full images, so ABI compatibility does not really matter) and it helps a little, but nowhere close to the order of magnitude you need.

Alas, there is little interest in/awareness of the middle ground between the no_std world and the "size doesn't matter" world in the Rust community right now. I've asked a bunch of people for pointers as to where to start working towards supporting those cases but I mainly got shrugs. There were attempts at more lightweight stdlibs and so on, but they all seem to have fizzled out.

I wonder how much of this is inherent in the language design. Rust heavily leans on monomorphization, so as a first approximation, you will always generate more code (before maybe optimizing that away again). Famously, the Swift people went to great lengths to avoid these problems: https://faultlore.com/blah/swift-abi/. But while running Swift on Linux is possible, this is even more niche.

This seems to be the corresponding video (linked in the associated media tab on arXiv): https://sciencecast.org/casts/suc384jly50n

I missed that development, thanks! As I understand it, it's not strictly muxing per se - you're basically siphoning off the interrupts from the M0 core using a hardware mechanism instead of firmware + IPC, so any firmware you might want to run on the M0 core still needs to be careful not to mess this up. But it's still an improvement.

While the BL808 (what the Ox64 uses) can nominally run Linux, it doesn't really work for that in practice because of design issues in the chip (or to put it differently: it was never designed for that purpose - the C906 core was included to be used as a DSP. The MMU etc. is just incidential.). Almost all peripheral interrupts (such as the the SD controller, Ethernet MAC, etc.) are routed to the E907 core (which is more comparable to a Cortex-M "microcontroller" core in the ARM world). Thus, doing anything useful with it with Linux requires ugly IRQ forwarding hacks. The community is working on that, but it's always going to be a Rube Goldberg thing that I'm not sure upstream will ever accept. I really hope the chip manufacturer realizes what they are sitting on and adds the ability to mux the IRQ lines in a later design.

The documentation on the CV1800B is still pretty light, but what I've seen suggests it does not suffer from the same issue, so that alone makes this board much more interesting than the Ox64.