[GSoC] UEFI framebuffer task
pkerling at ...483...
Sat Mar 18 19:36:38 CET 2017
Am Samstag, den 18.03.2017, 07:44 +0100 schrieb Sebastian Sumpf:
> Genode has two approaches with regard to drivers: First, we write our
> own (e.g., AHCI, SD, or ACPI) and second, we port them if we think
> writing one exceeds our available resources. That being said, the USB
> driver is ported from Linux and supports UHCI/EHCI/XHCI on x86 and
> diverse ARM platforms (omap4, exynos5, rpi). USB device driver vise
> there is hid/nic/storage support. We also have our own storage driver
> (usb_block) that connects to the USB driver (i.e., the host
> through our USB session interface. For isochronous USB this sessions
> USB host controller drivers would have be to extended to support
> isochronous transfers.
OK, that confirms my understanding of the task.
> A USB device driver (e.g, audio or video) should
> be written or ported. In the future we want to have all USB device
> drivers outside of the current USB implementation.
I'm not quite sure how to interpret the last sentence. Does this mean
that you want to separate e.g. the HID driver that is currently inside
the Linux kernel and have it attach to the Genode USB session
> As for additional driver stuff I can think of iMX6 USB and NIC
> AHCI is slowly replaced by NVMe so a NVMHCI implementation would be
> welcome and if you are up for a really though one: We are currently
> implementing our own Intel GPU multiplexer on Broadwell while also
> having a running port with 3D support enabled. Additionally we are
> looking into GPU virtualization. In this area there are a lot of
> to do or investigate.
The GPU stuff does seem interesting (and challenging), but it also
sounds quite hard to quickly get into well enough for writing a solid
project proposal if you don't have any prior exposure (like me).
NVMHCI sounds like it could be what I was looking for though. I guess
the expectation is to have a driver that implements the Block interface
similar to the current AHCI driver? Do you have any specific feature
requests besides simple read/write? NVMe supports a lot of enhanced
stuff (like atomic compare/write and priorities) that cannot be exposed
over the current Block interface - question is if there's a need for
More information about the users