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