Device drivers and board support files

[Matthias Lange]

Hi,

On 01/26/2016 02:34 PM, Paul Boddie wrote:
> 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.
> 
> [*] https://github.com/MIPS/fiasco-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?

If you are thinking of something like the "Linux Device Drivers" book
there is no such document. Have you had a look into the L4Re
documentation [1], specifically into io's overview? Maybe this clarifies
some of the concepts involved.

[1] http://l4re.org/doc/io.html

> 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:
> 
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2015/007475.html
> 
> Here, to be more specific, I imagine that the following things would be 
> affected:
> 
> 1. src/l4/pkg/io/config/<board>.devs would need populating with Device 
> definitions employing those Mmio declarations

The device definition doesn't necessarily has to live there. You can
spread device definitions into multiple files and pass the files via
io's cmdline to io.

> 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)

Please refer to [1] to understand the concepts of a vbus.

> 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/hw_devices.io, 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

The code isn't as clean as it should be. The problem is, that you have
to match a device with a device driver. So the driver probes certain
properties of the device i.e. the HID. The HID is a very specific
property and as a rule of thumb a device driver should start probing
from generic to more specific properties. In the device definition you
can add multiple compatible ids and by using l4vbus_is_compatible() you
can check whether your device driver matches a particular device.

> 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

Yes, it maps the MMIO region into the device drivers address space. You
access the MMIO registers via the mapped (virtual) address in your driver.

> 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?

That's because of historical reasons. You know, names are just ... names.

Best,
Matthias.