Some tentative L4Re investigations

[Paul Boddie]

Hello again,

I mentioned earlier that I was attempting to gain some experience with 
existing L4-related frameworks. Obviously, one way of doing this is to run 
such software on supported hardware. Another is to use a kernel that runs on 
existing systems (like Fiasco.OC-UX).

Because I wanted to repurpose some old hardware, build on other things I had 
done, and also look at L4, I set about getting Fiasco.OC to work on various 
MIPS devices that were not completely supported (MIPS Creator CI20) or not 
supported at all (Ben NanoNote, Letux 400/Trendtac EPC 700/Skytone Alpha-400). 
More on this here:

http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html

This also entailed writing user space driver code for the L4 Runtime 
Environment (L4Re), and it became apparent after a while that this code would 
be better off in a separate repository. I haven't really written any really 
sophisticated drivers, but it has given me some experience with how they might 
be designed and configured. More on this here:

http://www.boddie.org.uk/paul/Landfall.html

Unlike the CI20, the Ben and Letux do not conveniently provide a serial 
console, and so it is essential to get the screen that they each have to work. 
This is addressed by one of the drivers and was fundamental to achieving 
anything. To configure the hardware in a way that supports the screen, other 
peripherals need to have driver code written for them: these are mundane 
things like clock management, GPIO support (and pin management), PWM support 
and so on.

Other things are then built on top, such as support for adjusting the display 
backlight, which may require signalling a controller using SPI or use of PWM 
to control the intensity directly. I also felt that the keyboard on the Ben 
and Letux should be supported, although I haven't yet fully integrated the 
drivers into the existing L4Re mechanisms.

L4Re doesn't really have a coherent driver framework, as I understand it, and 
I imagine that the architectural choices being considered here intersect 
substantially with those made by Linux and other operating system kernels, 
with things like device tree being adopted to describe hardware and to 
parameterise the software accessing it. Here, I plug device servers together 
using capabilities in the init program, Ned, and the capabilities employed 
together with the server interfaces constitute my own driver framework as it 
stands.

Of course, this has little to say about broader architectural concerns such as 
how Hurd-like components can be implemented on L4 systems, but it has provided 
some insight into the mechanisms available when writing components: things 
like interprocess communication, capabilities, interrupt support, and so on. I 
hope to implement more drivers and to consider more general components in 
future.

For those who feel that this is of some interest to them, I have also put the 
repository for my experiments online here:

http://hgweb.boddie.org.uk/Landfall/

I hope it gives some idea of what code for L4Re currently looks like.

Paul