[GSoC] UEFI framebuffer task

[Sebastian Sumpf]

Hey Philipp,

On 03/17/2017 11:02 PM, Philipp Kerling wrote:
> Hi Sebastian,
> 
> Thanks for looking through my findings.
> 
> Am Freitag, den 17.03.2017, 11:01 +0100 schrieb Sebastian Sumpf:
>> Loading Genode with GRUB2 is sufficient. The main goal is, as you
>> said,
>> to not rely on outdated BIOS features. There is already a work in
>> progress on the NOVA hypervisor
>> (https://github.com/genodelabs/genode/issues/2242), which now
>> supports
>> legacy boot (mutliboot) and UEFI boot (multiboot2).
> Yes, I had taken a look at that. I've investigated a bit, but apart
> from VBE and getting rid of the BDA for communicating the serial port
> address there doesn't seem to be that much left driver-wise to do at
> first glance since Genode didn't use many of the AT BIOS features in
> the first place. RTC driver using EFI runtime services could be added,
> though.
> 
>> Sounds very good. VBE is not necessary as Genode already offers a
>> VESA
>> driver.
> Yep, that was just to illustrate that it's not specifically an UEFI
> issue.
> 
>> I have to admit that this challenge is meant for students with little
>> systems programming knowledge an, so feel free to look into more
>> challenging topics here (http://genode.org/about/challenges). Also,
>> these are just suggestions and you are welcome to propose topics. We
>> also have topics not on the challenges list, if you let us know your
>> interests (like kernel hacking, device drivers, porting ...), we may
>> be
>> able to suggest something more fitting for you.
> I'd like to try my hand at device drivers, which was why I looked into
> the UEFI thing in the first place. Do you have any suggestions there
> that are not on the list? Isochronous USB is an option, but it looks
> like it is more about hooking up/passing through the Linux driver code
> correctly than the actual USB driver stuff.

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

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.

@staff: Do you have any additional suggestions?

Regards,

Sebastian

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