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?
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
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/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
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!
Paul