[GSoC] UEFI framebuffer task

Sebastian Sumpf Sebastian.Sumpf at ...1...
Tue Mar 21 10:49:10 CET 2017

Hi Philipp,

On 03/18/2017 07:36 PM, Philipp Kerling wrote:
> Hi,
> 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
>> controller)
>> through our USB session interface. For isochronous USB this sessions
>> the
>> 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
> interface?


>> As for additional driver stuff I can think of iMX6 USB and NIC
>> support.
>> AHCI is slowly replaced by NVMe so a NVMHCI implementation would be
>> very
>> 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
>> things
>> 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? 

Read/write with native command queuing support would suffice.

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

If the above is working, it would be interesting to investigate if there
are features Genode could benefit from and maybe implement some.
Additionally power management is always a topic.



Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list