[GSoC 2022] Introducing myself & seeking for project ideas

[GSoC 2022] Introducing myself & seeking for project ideas

[Théo Jehl]

Hello,
I’m Théo, a French 1st year master’s student, specialized in embedded
systems engineering. I’m interested in joining EDK II development as
part of the Google Summer of Code program.

I’ve learnt operating system structures in uni, I know how to write
C/C++ and I started learning x86 ASM.
 I also worked with uni on a disk driver and virtual memory mapping.

Currently I have little to no experience in firmware/UEFI as I’m only
starting in this field.
I wanted to ask if any important project ideas were available that
would fit my skills. I have checked the task list provided and I feel
like it’s outdated, like the audio output project [1] which was
completed a year ago.

Thanks in advance.
Théo

[1] https://github.com/tianocore/tianocore.github.io/wiki/Tasks#Audio_Output_device_support

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

Hi Théo,

Welcome! Pleasure to meet you!
As a former GSoC student myself, I advise you to look for something you
fancy instead of just looking for something that fits your skill set. It's
way better to find something you like (even if you're not 100% familiar
with it) instead of looking for something that perfectly fits your existing
skill set; remember, you're also here to learn :)
Most tasks in https://github.com/tianocore/tianocore.github.io/wiki/Tasks
are up-to-date. In fact, I'm fairly sure the one you linked wasn't finished
last year (it's not in the GSoC archive and I don't see any patches that
were merged).
Of course, the tasks are just examples and you can diverge from those if
you'd like.

For a brief overview of the project:

- https://github.com/tianocore/edk2 is the main EDK2 repo that contains
lots of support code (that's used throughout most/all platforms) and OVMF
(edk2-on-virtual machines, like QEMU; good for testing your changes). Most
of the development is done here. The build tools also reside here. You can
look at the various packages inside edk2 to see if there's anything you
like.
- https://github.com/tianocore/edk2-platforms is the repo where platform
specific code resides. As an example,
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G
was contributed by a GSoC student last year. edk2-platforms also has
advanced, less commonly used features like my Ext4Pkg, which I maintain
since last year's GSoC.
- https://github.com/tianocore/edk2-libc contains a C standard library that
edk2 has in order to run standard C programs. It also has various ports of
programs like Python to UEFI.
Of course, you also have more repos like edk2-test, edk2-staging, etc :)

So yeah, take a look and see if there's anything you like :) Of course, if
you could tell us more about yourself and your interests inside embedded
programming, it would be easier to help out.

Best regards,
Pedro

On Thu, Mar 31, 2022 at 4:06 AM Théo Jehl <theojehl76@gmail.com> wrote:

> Hello,
> I’m Théo, a French 1st year master’s student, specialized in embedded
> systems engineering. I’m interested in joining EDK II development as
> part of the Google Summer of Code program.
>
> I’ve learnt operating system structures in uni, I know how to write
> C/C++ and I started learning x86 ASM.
>  I also worked with uni on a disk driver and virtual memory mapping.
>
> Currently I have little to no experience in firmware/UEFI as I’m only
> starting in this field.
> I wanted to ask if any important project ideas were available that
> would fit my skills. I have checked the task list provided and I feel
> like it’s outdated, like the audio output project [1] which was
> completed a year ago.
>
> Thanks in advance.
> Théo
>
> [1]
> https://github.com/tianocore/tianocore.github.io/wiki/Tasks#Audio_Output_device_support
>
>
> 
>
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 4129 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Théo Jehl]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hi Pedro,
Thanks a lot for your answer!

My bad then :') After taking a look at the tasks proposal lists I'm interested in the MinPlatform port to QEMU [1], of course, I'm open to other projects ideas that are not on the list.

To talk about myself a little more, I have a bachelor's in computer science and it's my first year as a Master's student, and I took the embedded systems programming branch to learn more about operating systems, booting, and how systems work in general :) I'm only starting in the field but I have a lot of fun making the software interact with the hardware, and understanding how computers work under the hood.

And you are right, larger projects are way better to learn :)

Best regards,
Théo

[1] https://github.com/tianocore/tianocore.github.io/wiki/Tasks-MinPlatform-QemuOpenBoardPkg

[-- Attachment #2: Type: text/html, Size: 902 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

Theo,

Sorry for leaving you on read!

CC'ing Nate as he knows a lot more about MinPlatform than I do!

Meanwhile, you can also take a look at the MinPlatform spec:
https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
Since you're new to UEFI, you may also want to take a brief look (don't
read it front-to-back, that's almost useless) at the UEFI spec:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

Thanks,
Pedro

On Sat, Apr 2, 2022 at 1:01 PM Théo Jehl <theojehl76@gmail.com> wrote:

> Hi Pedro,
> Thanks a lot for your answer!
>
> My bad then :') After taking a look at the tasks proposal lists I'm
> interested in the MinPlatform port to QEMU [1], of course, I'm open to
> other projects ideas that are not on the list.
>
> To talk about myself a little more, I have a bachelor's in computer
> science and it's my first year as a Master's student, and I took the
> embedded systems programming branch to learn more about operating systems,
> booting, and how systems work in general :) I'm only starting in the field
> but I have a lot of fun making the software interact with the hardware, and
> understanding how computers work under the hood.
>
> And you are right, larger projects are way better to learn :)
>
> Best regards,
> Théo
>
> [1]
> https://github.com/tianocore/tianocore.github.io/wiki/Tasks-MinPlatform-QemuOpenBoardPkg
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 2260 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Nate DeSimone]

[-- Attachment #1: Type: text/plain, Size: 4554 bytes --]

Hi Theo,

Great to meet you and welcome to the TianoCore project! Great to hear you are interested! Apologize for the tardiness in my response. Pedro is correct that the audio support task unfortunately did not make it past the finish line last year. My understanding is that the communication protocol for USB audio devices turned out to be much more complex than the student anticipated! It involved implementing several audio codecs as each device was allowed per spec to have a different set of supported codecs, and the transfer protocol was also highly non-trivial. I’m not sure where exactly things left off last year, Leif (cc’d) would have a better understanding there. Overall, I wouldn’t necessarily recommend that project because it seems like there was a lot of pitfalls and unpleasant surprises that were encountered along the way, but if are really interested in tackling a challenging project you are welcome to try taking it on.

The Qemu Minplatform port is something that I can speak with high levels of authority on. I’ve kinda been hoping that someone would pick that project 😊. I provided some background information on the MinPlatform Architecture in the following message on the mailing list: https://edk2.groups.io/g/devel/message/73152 Also, I would recommend that over the next couple months you read “Beyond BIOS” to learn more about the overall UEFI architecture.

The general goal of this project is to create a method of working on full featured UEFI firmware in an emulated environment. While there is some overlap between this and OVMF, over time OVMF has evolved to be used to initialize KVM and Xen virtual machines. The goals of being a developer sandbox vs. bootstrapping VM guest OSes don’t always align, which is where QemuOpenBoardPkg comes in.

For example, OVMF only implements UEFI variable services for DXE, and does not provide UEFI variable services in PEI or SMM. This is largely due to the virtualization focus that OVMF has gained over time. Given the focus on bootstrapping OSes, only implementing UEFI variables in DXE is fine. But for developers who want to test new SMM features without immediately integrating them into a real platform, having SMM variable services would immensely help. The same is true for PEI.

In parallel, MinPlatform Architecture is moving the methodologies for platform firmware development forward, by reducing the amount of platform specific code that needs to be written. But OVMF has not kept up with these new developments. So naturally, it make sense to combine these two together, which results in the QemuOpenBoardPkg project.

If any of this piques your interest I would be happy to answer any questions you have about it!


Hope this helps and welcome to the project!



With Best Regards,

Nate

From: Pedro Falcato <pedro.falcato@gmail.com>
Sent: Monday, April 4, 2022 2:13 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; theojehl76@gmail.com
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Subject: Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

Theo,

Sorry for leaving you on read!

CC'ing Nate as he knows a lot more about MinPlatform than I do!

Meanwhile, you can also take a look at the MinPlatform spec: https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
Since you're new to UEFI, you may also want to take a brief look (don't read it front-to-back, that's almost useless) at the UEFI spec: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

Thanks,
Pedro

On Sat, Apr 2, 2022 at 1:01 PM Théo Jehl <theojehl76@gmail.com<mailto:theojehl76@gmail.com>> wrote:
Hi Pedro,
Thanks a lot for your answer!

My bad then :') After taking a look at the tasks proposal lists I'm interested in the MinPlatform port to QEMU [1], of course, I'm open to other projects ideas that are not on the list.

To talk about myself a little more, I have a bachelor's in computer science and it's my first year as a Master's student, and I took the embedded systems programming branch to learn more about operating systems, booting, and how systems work in general :) I'm only starting in the field but I have a lot of fun making the software interact with the hardware, and understanding how computers work under the hood.

And you are right, larger projects are way better to learn :)

Best regards,
Théo

[1] https://github.com/tianocore/tianocore.github.io/wiki/Tasks-MinPlatform-QemuOpenBoardPkg



--
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 9145 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Théo Jehl]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

Hello Nate,
Thanks a lot for your answer ! I got myself a copy of "Beyond BIOS" to understand how UEFI works.

The project sound very interesting, so if I understand correctly, OVMF only implements some of the services needed for QEMU support, porting what's present to MinPlatform and then improving it with the required services will result in QemuOpenBoardPkg, is that right? So the goal is to allow MinPlatform testing inside QEMU instead of getting a specific board supported by MinPlatform?

I'll use the upcoming months to get up to pace with UEFI with the ressources you gave me 😄
Before starting to write my application I have a few questions, especially on the prerequisites, on the project page the only one listed is C knowledge, is anything else required or recommended ? In case I need to get up to pace with something specific :)

And thanks for welcoming me in the project !

Best regards,
Théo

[-- Attachment #2: Type: text/html, Size: 1006 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Nate DeSimone]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Hi Theo,

Yup you are totally correct. There are a lot of features and services that exist in a real hardware UEFI firmware that do not exist in OVMF. If you are trying to build some new code to run on real hardware UEFI firmware, then having a feature complete qemu version would be super helpful for testing. Otherwise, as you note you have to hope that one of the boards you currently own has a working MinPlatform port, which may or may not be the case.

Nothing else is required for the proposal, the only thing that would be helpful is spending some time reading the code for OVMF and MinPlatform and EDK II in general. EDK II is rather unique compared to most software frameworks these days and having some knowledge of its codebase will help you.

Hope that helps!
Nate

From: Théo Jehl <theojehl76@gmail.com>
Sent: Friday, April 8, 2022 9:06 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

Hello Nate,
Thanks a lot for your answer ! I got myself a copy of "Beyond BIOS" to understand how UEFI works.

The project sound very interesting, so if I understand correctly, OVMF only implements some of the services needed for QEMU support, porting what's present to MinPlatform and then improving it with the required services will result in QemuOpenBoardPkg, is that right? So the goal is to allow MinPlatform testing inside QEMU instead of getting a specific board supported by MinPlatform?

I'll use the upcoming months to get up to pace with UEFI with the ressources you gave me 😄
Before starting to write my application I have a few questions, especially on the prerequisites, on the project page the only one listed is C knowledge, is anything else required or recommended ? In case I need to get up to pace with something specific :)

And thanks for welcoming me in the project !

Best regards,
Théo

[-- Attachment #2: Type: text/html, Size: 4329 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Benjamin Doron]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Hi Theo and Nate,
I took a brief look at this myself, because having an emulated environment would help me with my project. I didn't know then that QemuOpenBoardPkg was an accepted project this year. OvmfPkg is large, I'm unfamiliar with QEMU's codebase and I'm only minimally familiar with Intel's old ICH chipsets (the platform some emulators expose), so I looked at porting QEMU's Q35 + ICH9 support into SimicsOpenBoardPkg. I don't know how you're preparing, but I'd recommend at least a look there: Q35's ICH9 and Simics' ICH10 are fairly similar. There are other QEMU machines, but I can't comment on those.

SimicsOpenBoardPkg can partially boot QEMU with a minimum of changes. It makes it into the DXE phase (where we'd eventually get a shell), but fails to initialise SMM, so it can't load the variable driver in there. Many drivers depend on the variable protocol, including critical UEFI-architecture ones, so the DXE core will assert and hang after printing a bunch of "driver GUID discovered but not loaded" messages. To fix this, the SMM access, maybe SMM control drivers would need to be patched; some register definitions differ between chipsets.

Anyways, I can send you my diff if you'd like, or you're welcome to approach this any way you'd like. SimicsOpenBoardPkg is not a true MinPlatform board because it implements a number of init steps itself rather than using some of MinPlatform's FSP-centric libraries. I'm probably going to skip to the step where I try Frankensteining enough MinPlatform code in to suffice my testing.

Best regards,
Benjamin

[-- Attachment #2: Type: text/html, Size: 1614 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

(CC Gerd, Isaac)

Comments inline.

On Mon, May 23, 2022 at 5:50 PM Benjamin Doron <benjamin.doron00@gmail.com>
wrote:

> Hi Theo and Nate,
> I took a brief look at this myself, because having an emulated environment
> would help me with my project. I didn't know then that QemuOpenBoardPkg was
> an accepted project this year. OvmfPkg is large, I'm unfamiliar with QEMU's
> codebase and I'm only minimally familiar with Intel's old ICH chipsets (the
> platform some emulators expose), so I looked at porting QEMU's Q35 + ICH9
> support into SimicsOpenBoardPkg. I don't know how you're preparing, but I'd
> recommend at least a look there: Q35's ICH9 and Simics' ICH10 are fairly
> similar. There are other QEMU machines, but I can't comment on those.
>
We're still trying to figure everything out and since the GSoC projects
were only announced Friday, we haven't discussed much. My idea was to try
to get something relatively smaller and simpler than current OVMF, as the
end result can be a lot more interesting than just repackaging OVMF or
straight up copying SimicsOpenBoardPkg; we're also mostly aiming for Stage
IV (Booting to an OS), so we can safely discard some of the advanced
features of OVMF for now. Again, I'd like to give you more details but it's
still too early and we're trying to introduce Theo to UEFI; hopefully we'll
get a better idea of the project for the summer this week.

>
> SimicsOpenBoardPkg can partially boot QEMU with a minimum of changes. It
> makes it into the DXE phase (where we'd eventually get a shell), but fails
> to initialise SMM, so it can't load the variable driver in there. Many
> drivers depend on the variable protocol, including critical
> UEFI-architecture ones, so the DXE core will assert and hang after printing
> a bunch of "driver GUID discovered but not loaded" messages. To fix this,
> the SMM access, maybe SMM control drivers would need to be patched; some
> register definitions differ between chipsets.
>
One issue with QEMU is that you currently have 3 machines worth supporting:
the i440fx (i440fx + PIIX), which is the default, the Q35 (Q35 + ICH9), and
the microvm (probably not going to be apart of the scope of this project,
at least for now, even though OVMF supports it). I don't know much about
Simics or SimicsOpenBoardPkg, but I imagine that taking way too much
inspiration from them would possibly negatively impact the capability of
supporting multiple platforms in one OpenBoardPkg.

>
> Anyways, I can send you my diff if you'd like, or you're welcome to
> approach this any way you'd like. SimicsOpenBoardPkg is not a true
> MinPlatform board because it implements a number of init steps itself
> rather than using some of MinPlatform's FSP-centric libraries. I'm probably
> going to skip to the step where I try Frankensteining enough MinPlatform
> code in to suffice my testing.
>
> Best regards,
> Benjamin
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 3746 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Oram, Isaac W]

[-- Attachment #1: Type: text/plain, Size: 4149 bytes --]

Benjamin,

Thanks for sharing, it is interesting that Simics gets that far.  In looking at the QemuPkg, I note that they have QEMU drivers for all the DXE and SMM HW needs that likely explain .  Timer, SMM access, SMM control, FVB services …  I haven’t gotten to the next level of details yet, like what chipsets the QemuPkg supports.  Readme says “The minimum required QEMU machine type is "pc-q35-2.5".”   Also I note that there is a whole section on QEMU SMM and flash options.

It seems promising to make the MinPlatform QEMU board port using the QemuPkg for all the “silicon” support needed.  As Pedro indicated though, we have not yet had a chance to get into project details yet.  As we get through GSoC community bonding period, we should get better understanding.

Regards,
Isaac

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Monday, May 23, 2022 10:34 AM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Benjamin Doron <benjamin.doron00@gmail.com>
Cc: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Oram, Isaac W <isaac.w.oram@intel.com>
Subject: Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

(CC Gerd, Isaac)

Comments inline.

On Mon, May 23, 2022 at 5:50 PM Benjamin Doron <benjamin.doron00@gmail.com<mailto:benjamin.doron00@gmail.com>> wrote:
Hi Theo and Nate,
I took a brief look at this myself, because having an emulated environment would help me with my project. I didn't know then that QemuOpenBoardPkg was an accepted project this year. OvmfPkg is large, I'm unfamiliar with QEMU's codebase and I'm only minimally familiar with Intel's old ICH chipsets (the platform some emulators expose), so I looked at porting QEMU's Q35 + ICH9 support into SimicsOpenBoardPkg. I don't know how you're preparing, but I'd recommend at least a look there: Q35's ICH9 and Simics' ICH10 are fairly similar. There are other QEMU machines, but I can't comment on those.
We're still trying to figure everything out and since the GSoC projects were only announced Friday, we haven't discussed much. My idea was to try to get something relatively smaller and simpler than current OVMF, as the end result can be a lot more interesting than just repackaging OVMF or straight up copying SimicsOpenBoardPkg; we're also mostly aiming for Stage IV (Booting to an OS), so we can safely discard some of the advanced features of OVMF for now. Again, I'd like to give you more details but it's still too early and we're trying to introduce Theo to UEFI; hopefully we'll get a better idea of the project for the summer this week.

SimicsOpenBoardPkg can partially boot QEMU with a minimum of changes. It makes it into the DXE phase (where we'd eventually get a shell), but fails to initialise SMM, so it can't load the variable driver in there. Many drivers depend on the variable protocol, including critical UEFI-architecture ones, so the DXE core will assert and hang after printing a bunch of "driver GUID discovered but not loaded" messages. To fix this, the SMM access, maybe SMM control drivers would need to be patched; some register definitions differ between chipsets.
One issue with QEMU is that you currently have 3 machines worth supporting: the i440fx (i440fx + PIIX), which is the default, the Q35 (Q35 + ICH9), and the microvm (probably not going to be apart of the scope of this project, at least for now, even though OVMF supports it). I don't know much about Simics or SimicsOpenBoardPkg, but I imagine that taking way too much inspiration from them would possibly negatively impact the capability of supporting multiple platforms in one OpenBoardPkg.

Anyways, I can send you my diff if you'd like, or you're welcome to approach this any way you'd like. SimicsOpenBoardPkg is not a true MinPlatform board because it implements a number of init steps itself rather than using some of MinPlatform's FSP-centric libraries. I'm probably going to skip to the step where I try Frankensteining enough MinPlatform code in to suffice my testing.

Best regards,
Benjamin


--
Pedro Falcato


[-- Attachment #2: Type: text/html, Size: 8220 bytes --]

Re: [edk2-devel] [GSoC 2022] Introducing myself & seeking for project ideas

[Gerd Hoffmann]

  Hi,

> > SimicsOpenBoardPkg can partially boot QEMU with a minimum of changes. It
> > makes it into the DXE phase (where we'd eventually get a shell), but fails
> > to initialise SMM, so it can't load the variable driver in there. Many
> > drivers depend on the variable protocol, including critical
> > UEFI-architecture ones, so the DXE core will assert and hang after printing
> > a bunch of "driver GUID discovered but not loaded" messages. To fix this,
> > the SMM access, maybe SMM control drivers would need to be patched; some
> > register definitions differ between chipsets.
> >
> One issue with QEMU is that you currently have 3 machines worth supporting:
> the i440fx (i440fx + PIIX), which is the default, the Q35 (Q35 + ICH9), and
> the microvm (probably not going to be apart of the scope of this project,
> at least for now, even though OVMF supports it).

If you want support for authenticated variables (+ secure boot I guess)
and SMM q35 is pretty much the only option you have.  microvm doesn't
support smm at all, and the i440fx is too old and hasn't enough SMM
memory (no TSEG).

take care,
  Gerd