Device drivers and board support files

Paul Boddie paul at
Tue Jan 26 14:34:19 CET 2016

Hello again,

Emboldened by my recent modest success, and taking a look at the previously-
mentioned MIP32 port of Fiasco.OC and L4Re [*], which doesn't really seem to 
have any community involved with it, I wondered whether there might be some 
general documentation about adding board support files to Fiasco.OC as well as 
writing drivers for L4Re.


I've browsed around the L4Re site and have even looked at the TU Dresden 
teaching resources, but there appears to be a lot of slideshows and not so 
much in the way of concise guidance on such topics. Are there any documents 
out there that cover writing the actual code involved?

With regard to board support, I get the feeling that I could possibly get away 
with something rather similar to other MIPS-based boards, and if I'm launching 
Fiasco.OC from U-Boot, I might not even need to do the basic board setup tasks 
(which include things like setting up the DRAM on the SoC concerned). However, 
I suspect that I would have to look into things like interrupt controllers for 
the various timers that I suppose must be needed by the kernel.

As for driver support, I noticed a previous message that gives an outline of 
what should be done:

Here, to be more specific, I imagine that the following things would be 

1. src/l4/pkg/io/config/<board>.devs would need populating with Device 
definitions employing those Mmio declarations

2. src/l4/pkg/io/config/vbus-config.vbus might need changing, perhaps to allow 
devices to match some bus identifier or other, although I don't completely 
follow this (I'm guessing that my driver should obtain a device reference via 
the vbus mechanism)

3. looking at the src/l4/pkg/drivers/lcd/src/lcd-omap3.c driver, which 
probably references devices in src/l4/pkg/io/io/config/plat-
beagleboard/, I see that the driver actually obtains a reference 
to the "dss" device using l4io_lookup_device, whereas the GPIO and I2C devices 
are obtained using l4vbus_get_device_by_hid, but I'm guessing that there is a 
distinction between specific and generic devices here

4. in src/l4/pkg/drivers/.../<device>.c the l4io_request_iomem call would 
employ the same physical addresses as those mentioned in (1) to access the 
device memory regions

I did start looking at the existing LCD drivers, this being something that 
I've managed to get to work with bare-metal code on the board concerned, and I 
noticed that drivers/lcd seems to mention "arm" a lot, but would I be right in 
assuming that none of that code is actually ARM-specific?

Thanks once again for any help you can offer!


More information about the l4-hackers mailing list