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:
- 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.
- 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.
- 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.
- 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.