Hi Paul, On 07/04/2017 11:11 PM, Paul Boddie wrote: > Hello, > > I've been trying to write some drivers in L4Re, starting out with a GPIO > driver for a currently-unsupported board, and I think I have mostly > understood > the concepts involved. Fortunately, there are already a couple of drivers to > borrow ideas from... > > pkg/io/io/server/src/drivers/gpio/bcm2835.cc > pkg/io/io/server/src/drivers/gpio/omap.cc > > And if I am not mistaken, such drivers can be accessed from other components > by just doing something like this (testing for validity as we go): > > vbus = l4re_env_get_cap("vbus"); > l4vbus_get_device_by_hid(vbus, 0, &gpio_handle, gpio_hid, 0, 0); > l4vbus_gpio_set(vbus, gpio_handle, gpio_reg, value); > > It appears that if I just declare the device appropriately in my board's > hw_devices.io file, I should be able to get a handle for it using code like > the above. And all access can apparently be done via the l4vbus_gpio > functions > with this handle.
That's not the whole story. Devices declared in e.g. hw_devices.io describe physical (real) devices and their resources. The device handle that you obtain via the Vbus API points to a virtual device and only virtual devices can be assigned to a client's virtual bus. A virtual device can wrap a physical one but e.g. in the case of GPIOs it can be composed of individual (or ranges) of physical GPIO resources (= pins). > (I was also wondering if it was possible to actually instantiate or obtain a > device directly instead of obtaining a handle, for code written in C++, but > the above is easily good enough at the moment.) > > But now I want to make another, non-GPIO, driver abstraction, instead of > directly accessing the mapped memory regions concerned (which I see that some > of the drivers do). It seems like I should be able to... The first question that should be answered is, whether the driver (abstraction) has to be implemented inside io. Maybe a standalone driver with an appropriate API is better suited for your use case, because the Vbus API has its limitations and most likely you need to extend it anyways. Also from a security standpoint it is maybe worthwile to implement the driver in its own component. Currently L4Re is lacking a proper device driver framework and we are still learning and exploring different directions. Maybe you would like to discuss your use case further so that we can guide you through that process? Regards, Matthias. > * define a class for the abstraction inheriting from Hw::Device > * declare the device in hw_devices.io using this class > * provide various properties in the hw_devices.io declaration > (for configuration purposes) > * read the properties in the actual class implementation > * access registers in memory just as the GPIO drivers do > > I think I can muddle through all this. But how should another component > access > methods provided by this driver? Do I have to implement functionality like > that provided by the following files...? > > pkg/io/libvbus/lib/src/vbus_gpio.cc > pkg/io/libvbus/include/vbus_gpio-ops.h > pkg/io/io/server/src/virt/gpio/vgpio.cc > > Does any of this make any sense? :-) > > I'm just getting started here, but thanks are due in advance for any advice > anyone may have! > > Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers