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
