During the last two years, I have collected ARM and RISC-V gadgets and development boards. What I realized is that many of them run systems far off mainline Linux, and quite often do the vendors not publish the sources. However, when able to get serial output, I can fix that. And that is where many engineers start with regular development, so we are in the same boat.
Now how do the original drivers work? Applications in existing products often
have userspace or hybrid drivers, which opens up a door. We can emulate the app,
e.g., in QEMU, and monitor I/O accesses. Then we can write our own driver. But
that is a tedious and time consuming process, the most inconvenient step being
testing. Given storage media, we need to physically move things. Over network,
we could scp and ssh over to the target machine, then run our code. What if
that could be done in one single step?
The solution is cpu, a concept originating
from the Plan 9 research operating system that came out of Bell Labs:
Transparently run a program on another machine in the network as if it was
local. In this talk, I show cpu in practice and what I have done myself with
it.