Hi Philipp,
On 03/16/2017 09:03 PM, Philipp Kerling wrote:
Hi,
I'm interested in participating in the Genode project as GSoC student, specifically the UEFI framebuffer task, so I am writing to you to briefly introduce myself and discuss the project idea. I am currently a student of Computer Engineering (MSc) at Ilmenau University of Technology in Germany in my second master semester. I've chosen computer engineering over computer science out of interest for low- level topics, which I think fits nicely with Genode. I worked on a toy x86 operating system with a friend some years ago, which was a good learning experience. It naturally did not go very far, but it did at least have basic multitasking and virtual memory :-)
Thanks for your introduction!
So, about the UEFI framebuffer proposal: Is the overall goal to have Genode/Nova running as bare UEFI application (without any OS Loader) or to have it loaded by GRUB (or similar) but not rely on outdated BIOS features (such as VBE) any more? Or support both like e.g. the Linux kernel does?
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).
This heavily influences the options available for framebuffer output, since the UEFI GOP (Graphics Output Protocol) that I assume you are referring to as one of the alternative/modern ways to access the framebuffer is only available as UEFI boot service. When being booted from an OS loader, usually only UEFI run-time services are available. In that case, the OS loader has to convey some information (mainly memory address, width/stride, height, depth) about the linear GOP framebuffer that the loader (or the firmware, for that matter) initialized to the kernel. multiboot2 does this for example with the framebuffer boot info tag. So to use this it would be sufficient to write a generic framebuffer driver operating on that information that is not specific to UEFI at all. It could probably also use the VBE framebuffer provided the OS loader initialized it. The "problem" with this is that it is probably not enough work to justify a 3-month GSoC proposal.
Sounds very good. VBE is not necessary as Genode already offers a VESA driver. Additionally, multiboot2 support should be added to the SeL4, base-hw, and Fiasco.OC kernels. Some experiments with Genode and coreboot are also welcome. 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.
Cheers,
Sebastian
I hope that the questions at least touch the right topics but do feel free to say so if you had something different in mind altogether.
Best regards, Philipp
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main