[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some tentative L4Re investigations
From: |
Paul Boddie |
Subject: |
Some tentative L4Re investigations |
Date: |
Wed, 30 May 2018 17:57:06 +0200 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-6-486; KDE/4.8.4; i686; ; ) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Some tentative L4Re investigations,
Paul Boddie <=