[GSoC] UEFI framebuffer task

[Sebastian Sumpf]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 


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