GSoC 2021 Qemu OpenBoardPkg Project

GSoC 2021 Qemu OpenBoardPkg Project

[KAAIRA GUPTA]

Hey everyone,

I have been selected as a student developer for the project MinPlatform
Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki. Thankyou
for this opportunity. I have been over the major chapters of Beyond BIOS
as recommended by Nate DeSimone. I want to get familiar with the code
now to help me undersatnd the community practices and get my hands
dirty. Where should I start? What development environment do I need?
How can I use this community bonding period to give me a better start
for the coding phase?

How do the mentors want me to connect with them? Can we have a meet to
discuss this project's plan to add more details? This would be very
helpful for me considering I don't have prior experience with EDK2.

Thank you,
Kaaira

Re: GSoC 2021 Qemu OpenBoardPkg Project

[KAAIRA GUPTA]

On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
> Hey everyone,
> 
> I have been selected as a student developer for the project MinPlatform
> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki. Thankyou
> for this opportunity. I have been over the major chapters of Beyond BIOS
> as recommended by Nate DeSimone. I want to get familiar with the code
> now to help me undersatnd the community practices and get my hands
> dirty. Where should I start? What development environment do I need?
> How can I use this community bonding period to give me a better start
> for the coding phase?
> 
> How do the mentors want me to connect with them? Can we have a meet to
> discuss this project's plan to add more details? This would be very
> helpful for me considering I don't have prior experience with EDK2.

I noticed that the mail-id that I have used of Michael Kubacki doesn't
exist anymore. Please let me know how I can contact him.

> 
> Thank you,
> Kaaira

Thanks,
Kaaira

回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[gaoliming]

Include Michael Kubacki. 

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 KAAIRA
> GUPTA
> 发送时间: 2021年5月18日 22:42
> 收件人: Ray Ni <ray.ni@intel.com>; devel@edk2.groups.io
> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
> > Hey everyone,
> >
> > I have been selected as a student developer for the project MinPlatform
> > Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
> Thankyou
> > for this opportunity. I have been over the major chapters of Beyond BIOS
> > as recommended by Nate DeSimone. I want to get familiar with the code
> > now to help me undersatnd the community practices and get my hands
> > dirty. Where should I start? What development environment do I need?
> > How can I use this community bonding period to give me a better start
> > for the coding phase?
> >
> > How do the mentors want me to connect with them? Can we have a meet
> to
> > discuss this project's plan to add more details? This would be very
> > helpful for me considering I don't have prior experience with EDK2.
> 
> I noticed that the mail-id that I have used of Michael Kubacki doesn't
> exist anymore. Please let me know how I can contact him.
> 
> >
> > Thank you,
> > Kaaira
> 
> Thanks,
> Kaaira
> 
> 
> 
> 

Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Oram, Isaac W]

There is a variety of good basics for edk2 development starting at https://www.tianocore.org/.  There is getting started and training things for basics.  Getting started and how to contribute are key I think.  They should have answers for your questions on development environment and such.  

There is a page for MinPlatform here:  https://github.com/tianocore/tianocore.github.io/wiki/Minimum-Platform-Architecture--MinPlatform, including links to the document.
There was a talk at OSFC 2019 (https://www.youtube.com/watch?v=x3NFbUC3hkA).
There are also talks at OCP Summits.
Navigate to https://www.opencompute.org/summit/global-summit and then Events, Past Events, and find Global Summit 2020 and OCP Tech Week 2020.
For 2020 Virtual Summit, https://www.youtube.com/watch?v=Cg0NavUVT3g 
For Tech Week, look for "Intel Xeon Scalable Processors MinPlatform Porting" event on November 10.  You have to create an account and log in to the hosting platform unfortunately.  I don't believe direct links are possible at this time.

Regards,
Isaac

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Tuesday, May 18, 2021 6:06 PM
To: devel@edk2.groups.io; kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>
Cc: mikuback@linux.microsoft.com
Subject: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

Include Michael Kubacki. 

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 KAAIRA GUPTA
> 发送时间: 2021年5月18日 22:42
> 收件人: Ray Ni <ray.ni@intel.com>; devel@edk2.groups.io
> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
> > Hey everyone,
> >
> > I have been selected as a student developer for the project 
> > MinPlatform Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
> Thankyou
> > for this opportunity. I have been over the major chapters of Beyond 
> > BIOS as recommended by Nate DeSimone. I want to get familiar with 
> > the code now to help me undersatnd the community practices and get 
> > my hands dirty. Where should I start? What development environment do I need?
> > How can I use this community bonding period to give me a better 
> > start for the coding phase?
> >
> > How do the mentors want me to connect with them? Can we have a meet
> to
> > discuss this project's plan to add more details? This would be very 
> > helpful for me considering I don't have prior experience with EDK2.
> 
> I noticed that the mail-id that I have used of Michael Kubacki doesn't 
> exist anymore. Please let me know how I can contact him.
> 
> >
> > Thank you,
> > Kaaira
> 
> Thanks,
> Kaaira
> 
> 
> 
> 

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Michael Kubacki]

Thanks Liming.

Hi Kaaira,

Welcome! You can contact me at mikuback@linux.microsoft.com. You will 
sometimes see my email as michael.kubacki@microsoft.com and that is fine 
to use for communication though I tend to not use it on the mailing list 
due to way the mail server manipulates plaintext email.

GENERIC RESOURCES

I'm sharing some general resources in case you are not already familiar 
with them:

1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki

This one is good for topics like UEFI overview, EDK II concepts, and 
Minimum Platform.

In particular for your project, I recommend looking through the 
MinPlatform training - 
https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf

2. 
https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html

These whitepapers are useful when you need more in depth detail about a 
particular area (like capsule update or work related to the memory map). 
I recommend bookmarking it and keeping it in mind as a reference.

3. https://uefi.org/learning_center/presentationsandvideos/

Scroll through here if you have some time and see if there's anything 
interesting. To help keep on your project schedule I don't think these 
are as important but there is a lot of interesting material there.

Reading through some of the key concepts in Beyond BIOS can be helpful 
and like the UEFI, ACPI, and PI (Platform Initialization) specs at 
https://uefi.org/specifications, I believe they are most useful as 
references when you are solving specific problems.

PROJECT-SPECIFIC RESOURCES

Since your project involves creating QEMU board within the Minimum 
Platform architecture, you can start looking into:

1. QEMU - An open source machine emulator
2. Minimum Platform Architecture - A software architecture to create 
basic platform firmware that can be extended with advanced functionality.
3. Intel FSP - Try to understand the high-level goals and how FSP 
interfaces with firmware.

1. QEMU - https://www.qemu.org/

Please set up the QEMU environment. Your QemuOpenBoardPkg will need to 
run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit 
DXE phase. Most real hardware firmwares also use a 32-bit PEI and a 
64-bit DXE.

I suggest you start with the OvmfPkg README - 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/README

As an initial step you can try to build an OVMF FW with a 32-bit PEI 
(IA32) and 64-bit DXE (X64) and boot to the EFI shell. 
OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these 
target architectures.

Any time you submit patches to edk2, you can check edk2/maintainers.txt 
- https://github.com/tianocore/edk2/blob/master/Maintainers.txt for the 
appropriate maintainers and reviewers to CC on the patch. As you can 
see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a 
reviewer. If there are any questions that require deep expertise in QEMU 
or OVMF, we will reach out to them. The Minimum Platform code is 
maintained in the edk2-platforms repository and it has a similar 
maintainers.txt file for its packages - 
https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt.

I suggest you try sending a very trivial patch for a change in the 
edk2-platforms repository - https://github.com/tianocore/edk2-platforms 
to make sure that your git environment is set up properly to format edk2 
patches and your email service can send patches correctly.

We can discuss the details about how to set up your environment and what 
to change when you are ready. You can use this page to get started - 
https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute.

2. EDK II Minimum Platform Specification - 
https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/

For your project, this spec will be very useful. It describes why 
Minimum Platform was created and how it works at a high-level. Like the 
code, this document is open and available to the community. You might 
contribute content here in addition to your code. You can fix any bugs 
or update content in the spec using git patches and the mailing list 
similar to code.

3. Intel FSP - 
https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

For more information about Intel FSP check out the Intel FSP External 
Architecture Specification in the link above. v2.2 is currently the 
latest version.

There is an open source QEMU FSP available here 
https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64. You will 
find the existing Minimum Platform boards use Intel FSP while OvmfPkg 
does not use FSP.

Firmware is really best learned hands on. Using the links and background 
info above, I suggest:

1. Read the OvmfPkg readme.
2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell 
using QEMU.
3. Reading through the EDK II Minimum Platform Specification to gain a 
high level understanding of Minimum Platform.
4. Connect what you read to the code in 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel. 
Focus on higher level pieces like the board initialization library.
5. Note what each board package is doing. You will find common patterns 
for what a board package needs to implement to make the system boot.
6. As you read through the code, reference the general resources listed 
above to understand anything not Minimum Platform specific. Part of the 
learning process is knowing which spec to use for different interfaces. 
If you're unsure which spec something is in, feel free to reach out.
7. While looking through the code in edk2-platforms, think about a patch 
you can send to edk2-platforms for something very trivial such as a bug 
fix or documentation update.
8. Send the patch and get it reviewed-by the appropriate 
maintainers/reviewers and merged into the master branch.
9. Read through the code in OvmfPkg. Try to map the work it is doing to 
the board code you reviewed in edk2-platforms.
10. At this point, you could start outlining major pieces of 
initialization in OVMF and how they might map to a board package. Try to 
identify where the initialization pieces would reside in the board 
package and try to identify challenges that might arise. We will likely 
spend quite a bit of time here before jumping into too much code.

I know this is a lot of info. Please don't hesitate to reach out if you 
have any questions and I look forward to working with you.

Regards,
Michael

On 5/18/2021 6:05 PM, gaoliming wrote:
> Include Michael Kubacki.
> 
> Thanks
> Liming
>> -----邮件原件-----
>> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 KAAIRA
>> GUPTA
>> 发送时间: 2021年5月18日 22:42
>> 收件人: Ray Ni <ray.ni@intel.com>; devel@edk2.groups.io
>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>
>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>> Hey everyone,
>>>
>>> I have been selected as a student developer for the project MinPlatform
>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>> Thankyou
>>> for this opportunity. I have been over the major chapters of Beyond BIOS
>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>> now to help me undersatnd the community practices and get my hands
>>> dirty. Where should I start? What development environment do I need?
>>> How can I use this community bonding period to give me a better start
>>> for the coding phase?
>>>
>>> How do the mentors want me to connect with them? Can we have a meet
>> to
>>> discuss this project's plan to add more details? This would be very
>>> helpful for me considering I don't have prior experience with EDK2.
>>
>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>> exist anymore. Please let me know how I can contact him.
>>
>>>
>>> Thank you,
>>> Kaaira
>>
>> Thanks,
>> Kaaira
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 
> 

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Michael Kubacki]

I also wanted to add that I will be setting up weekly video calls 
including Ray that we can use to supplement mailing list communication.

I suggest the primary communication mechanism be the mailing list and we 
use those calls for clarification, detailed project planning, and topics 
not directly relevant to the list.

Regards,
Michael

On 5/19/2021 10:29 AM, Michael Kubacki wrote:
> Thanks Liming.
> 
> Hi Kaaira,
> 
> Welcome! You can contact me at mikuback@linux.microsoft.com. You will 
> sometimes see my email as michael.kubacki@microsoft.com and that is fine 
> to use for communication though I tend to not use it on the mailing list 
> due to way the mail server manipulates plaintext email.
> 
> GENERIC RESOURCES
> 
> I'm sharing some general resources in case you are not already familiar 
> with them:
> 
> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
> 
> This one is good for topics like UEFI overview, EDK II concepts, and 
> Minimum Platform.
> 
> In particular for your project, I recommend looking through the 
> MinPlatform training - 
> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf 
> 
> 
> 2. 
> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html 
> 
> 
> These whitepapers are useful when you need more in depth detail about a 
> particular area (like capsule update or work related to the memory map). 
> I recommend bookmarking it and keeping it in mind as a reference.
> 
> 3. https://uefi.org/learning_center/presentationsandvideos/
> 
> Scroll through here if you have some time and see if there's anything 
> interesting. To help keep on your project schedule I don't think these 
> are as important but there is a lot of interesting material there.
> 
> Reading through some of the key concepts in Beyond BIOS can be helpful 
> and like the UEFI, ACPI, and PI (Platform Initialization) specs at 
> https://uefi.org/specifications, I believe they are most useful as 
> references when you are solving specific problems.
> 
> PROJECT-SPECIFIC RESOURCES
> 
> Since your project involves creating QEMU board within the Minimum 
> Platform architecture, you can start looking into:
> 
> 1. QEMU - An open source machine emulator
> 2. Minimum Platform Architecture - A software architecture to create 
> basic platform firmware that can be extended with advanced functionality.
> 3. Intel FSP - Try to understand the high-level goals and how FSP 
> interfaces with firmware.
> 
> 1. QEMU - https://www.qemu.org/
> 
> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to 
> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit 
> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a 
> 64-bit DXE.
> 
> I suggest you start with the OvmfPkg README - 
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> 
> As an initial step you can try to build an OVMF FW with a 32-bit PEI 
> (IA32) and 64-bit DXE (X64) and boot to the EFI shell. 
> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these 
> target architectures.
> 
> Any time you submit patches to edk2, you can check edk2/maintainers.txt 
> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt for the 
> appropriate maintainers and reviewers to CC on the patch. As you can 
> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a 
> reviewer. If there are any questions that require deep expertise in QEMU 
> or OVMF, we will reach out to them. The Minimum Platform code is 
> maintained in the edk2-platforms repository and it has a similar 
> maintainers.txt file for its packages - 
> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt.
> 
> I suggest you try sending a very trivial patch for a change in the 
> edk2-platforms repository - https://github.com/tianocore/edk2-platforms 
> to make sure that your git environment is set up properly to format edk2 
> patches and your email service can send patches correctly.
> 
> We can discuss the details about how to set up your environment and what 
> to change when you are ready. You can use this page to get started - 
> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute.
> 
> 2. EDK II Minimum Platform Specification - 
> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
> 
> For your project, this spec will be very useful. It describes why 
> Minimum Platform was created and how it works at a high-level. Like the 
> code, this document is open and available to the community. You might 
> contribute content here in addition to your code. You can fix any bugs 
> or update content in the spec using git patches and the mailing list 
> similar to code.
> 
> 3. Intel FSP - 
> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html 
> 
> 
> For more information about Intel FSP check out the Intel FSP External 
> Architecture Specification in the link above. v2.2 is currently the 
> latest version.
> 
> There is an open source QEMU FSP available here 
> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64. You will 
> find the existing Minimum Platform boards use Intel FSP while OvmfPkg 
> does not use FSP.
> 
> Firmware is really best learned hands on. Using the links and background 
> info above, I suggest:
> 
> 1. Read the OvmfPkg readme.
> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell 
> using QEMU.
> 3. Reading through the EDK II Minimum Platform Specification to gain a 
> high level understanding of Minimum Platform.
> 4. Connect what you read to the code in 
> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel. 
> Focus on higher level pieces like the board initialization library.
> 5. Note what each board package is doing. You will find common patterns 
> for what a board package needs to implement to make the system boot.
> 6. As you read through the code, reference the general resources listed 
> above to understand anything not Minimum Platform specific. Part of the 
> learning process is knowing which spec to use for different interfaces. 
> If you're unsure which spec something is in, feel free to reach out.
> 7. While looking through the code in edk2-platforms, think about a patch 
> you can send to edk2-platforms for something very trivial such as a bug 
> fix or documentation update.
> 8. Send the patch and get it reviewed-by the appropriate 
> maintainers/reviewers and merged into the master branch.
> 9. Read through the code in OvmfPkg. Try to map the work it is doing to 
> the board code you reviewed in edk2-platforms.
> 10. At this point, you could start outlining major pieces of 
> initialization in OVMF and how they might map to a board package. Try to 
> identify where the initialization pieces would reside in the board 
> package and try to identify challenges that might arise. We will likely 
> spend quite a bit of time here before jumping into too much code.
> 
> I know this is a lot of info. Please don't hesitate to reach out if you 
> have any questions and I look forward to working with you.
> 
> Regards,
> Michael
> 
> On 5/18/2021 6:05 PM, gaoliming wrote:
>> Include Michael Kubacki.
>>
>> Thanks
>> Liming
>>> -----邮件原件-----
>>> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 KAAIRA
>>> GUPTA
>>> 发送时间: 2021年5月18日 22:42
>>> 收件人: Ray Ni <ray.ni@intel.com>; devel@edk2.groups.io
>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>
>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>> Hey everyone,
>>>>
>>>> I have been selected as a student developer for the project MinPlatform
>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>> Thankyou
>>>> for this opportunity. I have been over the major chapters of Beyond 
>>>> BIOS
>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>> now to help me undersatnd the community practices and get my hands
>>>> dirty. Where should I start? What development environment do I need?
>>>> How can I use this community bonding period to give me a better start
>>>> for the coding phase?
>>>>
>>>> How do the mentors want me to connect with them? Can we have a meet
>>> to
>>>> discuss this project's plan to add more details? This would be very
>>>> helpful for me considering I don't have prior experience with EDK2.
>>>
>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>> exist anymore. Please let me know how I can contact him.
>>>
>>>>
>>>> Thank you,
>>>> Kaaira
>>>
>>> Thanks,
>>> Kaaira
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>> 
>>

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Daniel Schaefer]

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

Hi,

that sounds like a great project!

I'm currently trying to create an equivalent of OvmfPkg for the RISCV64 generic QEMU virt machine.
I don't like how much of my DSC and FDF file has modules that pretty much all platforms should have.
MinPlatform would help reduce that, right?
Is MinPlatform flexible enough to account for non-X64 platforms?

If so, then I think Kaaira and I could collaborate.

Cheers,
Daniel
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Michael Kubacki <mikuback@linux.microsoft.com>
Sent: Thursday, May 20, 2021 02:57
To: devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; 'Ray Ni' <ray.ni@intel.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

I also wanted to add that I will be setting up weekly video calls
including Ray that we can use to supplement mailing list communication.

I suggest the primary communication mechanism be the mailing list and we
use those calls for clarification, detailed project planning, and topics
not directly relevant to the list.

Regards,
Michael

On 5/19/2021 10:29 AM, Michael Kubacki wrote:
> Thanks Liming.
>
> Hi Kaaira,
>
> Welcome! You can contact me at mikuback@linux.microsoft.com. You will
> sometimes see my email as michael.kubacki@microsoft.com and that is fine
> to use for communication though I tend to not use it on the mailing list
> due to way the mail server manipulates plaintext email.
>
> GENERIC RESOURCES
>
> I'm sharing some general resources in case you are not already familiar
> with them:
>
> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
>
> This one is good for topics like UEFI overview, EDK II concepts, and
> Minimum Platform.
>
> In particular for your project, I recommend looking through the
> MinPlatform training -
> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
>
>
> 2.
> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
>
>
> These whitepapers are useful when you need more in depth detail about a
> particular area (like capsule update or work related to the memory map).
> I recommend bookmarking it and keeping it in mind as a reference.
>
> 3. https://uefi.org/learning_center/presentationsandvideos/
>
> Scroll through here if you have some time and see if there's anything
> interesting. To help keep on your project schedule I don't think these
> are as important but there is a lot of interesting material there.
>
> Reading through some of the key concepts in Beyond BIOS can be helpful
> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
> https://uefi.org/specifications, I believe they are most useful as
> references when you are solving specific problems.
>
> PROJECT-SPECIFIC RESOURCES
>
> Since your project involves creating QEMU board within the Minimum
> Platform architecture, you can start looking into:
>
> 1. QEMU - An open source machine emulator
> 2. Minimum Platform Architecture - A software architecture to create
> basic platform firmware that can be extended with advanced functionality.
> 3. Intel FSP - Try to understand the high-level goals and how FSP
> interfaces with firmware.
>
> 1. QEMU - https://www.qemu.org/
>
> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
> 64-bit DXE.
>
> I suggest you start with the OvmfPkg README -
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
>
> As an initial step you can try to build an OVMF FW with a 32-bit PEI
> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
> target architectures.
>
> Any time you submit patches to edk2, you can check edk2/maintainers.txt
> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt for the
> appropriate maintainers and reviewers to CC on the patch. As you can
> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
> reviewer. If there are any questions that require deep expertise in QEMU
> or OVMF, we will reach out to them. The Minimum Platform code is
> maintained in the edk2-platforms repository and it has a similar
> maintainers.txt file for its packages -
> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt.
>
> I suggest you try sending a very trivial patch for a change in the
> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> to make sure that your git environment is set up properly to format edk2
> patches and your email service can send patches correctly.
>
> We can discuss the details about how to set up your environment and what
> to change when you are ready. You can use this page to get started -
> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute.
>
> 2. EDK II Minimum Platform Specification -
> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
>
> For your project, this spec will be very useful. It describes why
> Minimum Platform was created and how it works at a high-level. Like the
> code, this document is open and available to the community. You might
> contribute content here in addition to your code. You can fix any bugs
> or update content in the spec using git patches and the mailing list
> similar to code.
>
> 3. Intel FSP -
> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
>
>
> For more information about Intel FSP check out the Intel FSP External
> Architecture Specification in the link above. v2.2 is currently the
> latest version.
>
> There is an open source QEMU FSP available here
> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64. You will
> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
> does not use FSP.
>
> Firmware is really best learned hands on. Using the links and background
> info above, I suggest:
>
> 1. Read the OvmfPkg readme.
> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
> using QEMU.
> 3. Reading through the EDK II Minimum Platform Specification to gain a
> high level understanding of Minimum Platform.
> 4. Connect what you read to the code in
> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel.
> Focus on higher level pieces like the board initialization library.
> 5. Note what each board package is doing. You will find common patterns
> for what a board package needs to implement to make the system boot.
> 6. As you read through the code, reference the general resources listed
> above to understand anything not Minimum Platform specific. Part of the
> learning process is knowing which spec to use for different interfaces.
> If you're unsure which spec something is in, feel free to reach out.
> 7. While looking through the code in edk2-platforms, think about a patch
> you can send to edk2-platforms for something very trivial such as a bug
> fix or documentation update.
> 8. Send the patch and get it reviewed-by the appropriate
> maintainers/reviewers and merged into the master branch.
> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
> the board code you reviewed in edk2-platforms.
> 10. At this point, you could start outlining major pieces of
> initialization in OVMF and how they might map to a board package. Try to
> identify where the initialization pieces would reside in the board
> package and try to identify challenges that might arise. We will likely
> spend quite a bit of time here before jumping into too much code.
>
> I know this is a lot of info. Please don't hesitate to reach out if you
> have any questions and I look forward to working with you.
>
> Regards,
> Michael
>
> On 5/18/2021 6:05 PM, gaoliming wrote:
>> Include Michael Kubacki.
>>
>> Thanks
>> Liming
>>> -----邮件原件-----
>>> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 KAAIRA
>>> GUPTA
>>> 发送时间: 2021年5月18日 22:42
>>> 收件人: Ray Ni <ray.ni@intel.com>; devel@edk2.groups.io
>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>
>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>> Hey everyone,
>>>>
>>>> I have been selected as a student developer for the project MinPlatform
>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>> Thankyou
>>>> for this opportunity. I have been over the major chapters of Beyond
>>>> BIOS
>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>> now to help me undersatnd the community practices and get my hands
>>>> dirty. Where should I start? What development environment do I need?
>>>> How can I use this community bonding period to give me a better start
>>>> for the coding phase?
>>>>
>>>> How do the mentors want me to connect with them? Can we have a meet
>>> to
>>>> discuss this project's plan to add more details? This would be very
>>>> helpful for me considering I don't have prior experience with EDK2.
>>>
>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>> exist anymore. Please let me know how I can contact him.
>>>
>>>>
>>>> Thank you,
>>>> Kaaira
>>>
>>> Thanks,
>>> Kaaira
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>






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

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Oram, Isaac W]

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

Daniel,

The MinPlatform spec was intended to be architecture and product independent for a “mainstream” set of products.  It is intended to constrain some of the nearly unlimited extensibility and flexibility of UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base design should work for 80% of designs, but some will need to leverage full edk2 and UEFI specification flexibility.  I think that a basic QEMU kind of port would fit in 80% target.  I would ultimately like to see a progression of edk2 use that starts with QEMU then moves more seamlessly to open designs and then proprietary product designs.  MinPlatform consistency is hoped to help that developer ramp into system firmware productivity.

We have only seen MinPlatform applied to Intel based products so far.  Which is why we are not rushing to move the spec from a 0.7 “broad feedback” state to a 1.0 “initially complete” state.  Like edk2, MinPlatformPkg and BoardModulePkg content is intended to support multiple silicon and product architectures and we will happily promote content out of “Intel” scope when that is an accurate reflection of use and not just wishful thinking.  While 100% of uses are Intel scope, it makes sense to land in the Intel part of edk2-platforms repo.  Similar logic applies to Features/Intel content, though more there may have ties to Intel specific product features.

The Minimum Platform Arch spec details base requirements for FV layout (thus enabling more common code to publish FV details), base silicon policy configuration flow (thus more common PEIM/drivers to gather config information and reduce board porting to relatively simple libraries), and such things.  By enabling more common PEIM and drivers, we hope to see benefits to ease of use and consistent quality.  Similar approaches for the other elements of the spec should help to improve code sharing.

Anyway, yes, it should be able to help you reduce the copies of “mostly common” code that you encountered and the code and spec are open to welcome the additional use and feedback from additional applications.

Regards,
Isaac

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Daniel Schaefer
Sent: Wednesday, May 19, 2021 8:40 PM
To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

Hi,

that sounds like a great project!

I'm currently trying to create an equivalent of OvmfPkg for the RISCV64 generic QEMU virt machine.
I don't like how much of my DSC and FDF file has modules that pretty much all platforms should have.
MinPlatform would help reduce that, right?
Is MinPlatform flexible enough to account for non-X64 platforms?

If so, then I think Kaaira and I could collaborate.

Cheers,
Daniel
________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki <mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>>
Sent: Thursday, May 20, 2021 02:57
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com> <kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

I also wanted to add that I will be setting up weekly video calls
including Ray that we can use to supplement mailing list communication.

I suggest the primary communication mechanism be the mailing list and we
use those calls for clarification, detailed project planning, and topics
not directly relevant to the list.

Regards,
Michael

On 5/19/2021 10:29 AM, Michael Kubacki wrote:
> Thanks Liming.
>
> Hi Kaaira,
>
> Welcome! You can contact me at mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>. You will
> sometimes see my email as michael.kubacki@microsoft.com<mailto:michael.kubacki@microsoft.com> and that is fine
> to use for communication though I tend to not use it on the mailing list
> due to way the mail server manipulates plaintext email.
>
> GENERIC RESOURCES
>
> I'm sharing some general resources in case you are not already familiar
> with them:
>
> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
>
> This one is good for topics like UEFI overview, EDK II concepts, and
> Minimum Platform.
>
> In particular for your project, I recommend looking through the
> MinPlatform training -
> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
>
>
> 2.
> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
>
>
> These whitepapers are useful when you need more in depth detail about a
> particular area (like capsule update or work related to the memory map).
> I recommend bookmarking it and keeping it in mind as a reference.
>
> 3. https://uefi.org/learning_center/presentationsandvideos/
>
> Scroll through here if you have some time and see if there's anything
> interesting. To help keep on your project schedule I don't think these
> are as important but there is a lot of interesting material there.
>
> Reading through some of the key concepts in Beyond BIOS can be helpful
> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
> https://uefi.org/specifications, I believe they are most useful as
> references when you are solving specific problems.
>
> PROJECT-SPECIFIC RESOURCES
>
> Since your project involves creating QEMU board within the Minimum
> Platform architecture, you can start looking into:
>
> 1. QEMU - An open source machine emulator
> 2. Minimum Platform Architecture - A software architecture to create
> basic platform firmware that can be extended with advanced functionality.
> 3. Intel FSP - Try to understand the high-level goals and how FSP
> interfaces with firmware.
>
> 1. QEMU - https://www.qemu.org/
>
> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
> 64-bit DXE.
>
> I suggest you start with the OvmfPkg README -
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
>
> As an initial step you can try to build an OVMF FW with a 32-bit PEI
> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
> target architectures.
>
> Any time you submit patches to edk2, you can check edk2/maintainers.txt
> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt for the
> appropriate maintainers and reviewers to CC on the patch. As you can
> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
> reviewer. If there are any questions that require deep expertise in QEMU
> or OVMF, we will reach out to them. The Minimum Platform code is
> maintained in the edk2-platforms repository and it has a similar
> maintainers.txt file for its packages -
> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt.
>
> I suggest you try sending a very trivial patch for a change in the
> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> to make sure that your git environment is set up properly to format edk2
> patches and your email service can send patches correctly.
>
> We can discuss the details about how to set up your environment and what
> to change when you are ready. You can use this page to get started -
> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute.
>
> 2. EDK II Minimum Platform Specification -
> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
>
> For your project, this spec will be very useful. It describes why
> Minimum Platform was created and how it works at a high-level. Like the
> code, this document is open and available to the community. You might
> contribute content here in addition to your code. You can fix any bugs
> or update content in the spec using git patches and the mailing list
> similar to code.
>
> 3. Intel FSP -
> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
>
>
> For more information about Intel FSP check out the Intel FSP External
> Architecture Specification in the link above. v2.2 is currently the
> latest version.
>
> There is an open source QEMU FSP available here
> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64. You will
> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
> does not use FSP.
>
> Firmware is really best learned hands on. Using the links and background
> info above, I suggest:
>
> 1. Read the OvmfPkg readme.
> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
> using QEMU.
> 3. Reading through the EDK II Minimum Platform Specification to gain a
> high level understanding of Minimum Platform.
> 4. Connect what you read to the code in
> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel.
> Focus on higher level pieces like the board initialization library.
> 5. Note what each board package is doing. You will find common patterns
> for what a board package needs to implement to make the system boot.
> 6. As you read through the code, reference the general resources listed
> above to understand anything not Minimum Platform specific. Part of the
> learning process is knowing which spec to use for different interfaces.
> If you're unsure which spec something is in, feel free to reach out.
> 7. While looking through the code in edk2-platforms, think about a patch
> you can send to edk2-platforms for something very trivial such as a bug
> fix or documentation update.
> 8. Send the patch and get it reviewed-by the appropriate
> maintainers/reviewers and merged into the master branch.
> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
> the board code you reviewed in edk2-platforms.
> 10. At this point, you could start outlining major pieces of
> initialization in OVMF and how they might map to a board package. Try to
> identify where the initialization pieces would reside in the board
> package and try to identify challenges that might arise. We will likely
> spend quite a bit of time here before jumping into too much code.
>
> I know this is a lot of info. Please don't hesitate to reach out if you
> have any questions and I look forward to working with you.
>
> Regards,
> Michael
>
> On 5/18/2021 6:05 PM, gaoliming wrote:
>> Include Michael Kubacki.
>>
>> Thanks
>> Liming
>>> -----邮件原件-----
>>> 发件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>> GUPTA
>>> 发送时间: 2021年5月18日 22:42
>>> 收件人: Ray Ni <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>
>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>> Hey everyone,
>>>>
>>>> I have been selected as a student developer for the project MinPlatform
>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>> Thankyou
>>>> for this opportunity. I have been over the major chapters of Beyond
>>>> BIOS
>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>> now to help me undersatnd the community practices and get my hands
>>>> dirty. Where should I start? What development environment do I need?
>>>> How can I use this community bonding period to give me a better start
>>>> for the coding phase?
>>>>
>>>> How do the mentors want me to connect with them? Can we have a meet
>>> to
>>>> discuss this project's plan to add more details? This would be very
>>>> helpful for me considering I don't have prior experience with EDK2.
>>>
>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>> exist anymore. Please let me know how I can contact him.
>>>
>>>>
>>>> Thank you,
>>>> Kaaira
>>>
>>> Thanks,
>>> Kaaira
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>






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

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Michael Kubacki]

Daniel,

You will specifically find attempts to consolidate common libraries and 
modules in DSC and FDF files that can be included into a board package 
here - 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include. 
Files are split such that they can be included in the corresponding 
section in the board package DSC/FDF file. Note there are some mixed 
opinions I've encountered in the industry on the complexity trade off 
associated with includes in DSC and FDF files.

But as Isaac mentioned, while MinPlatform is designed to support 
multiple architectures, it has only be enabled on Intel platforms, 
therefore, you should expect to encounter some problems enabling a 
different architecture but identifying and/or resolving those would be 
very valuable.

As you are exploring how to port a platform to MinPlatform I also 
recommend familiarizing yourself the concept of advanced features 
described here - 
https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md. 
You might find your board package is relatively simpler than the 
original platform package after accounting for advanced features being 
separated out.

Thanks,
Michael


On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
> Daniel,
> 
> The MinPlatform spec was intended to be architecture and product 
> independent for a “mainstream” set of products.  It is intended to 
> constrain some of the nearly unlimited extensibility and flexibility of 
> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base 
> design should work for 80% of designs, but some will need to leverage 
> full edk2 and UEFI specification flexibility.  I think that a basic QEMU 
> kind of port would fit in 80% target.  I would ultimately like to see a 
> progression of edk2 use that starts with QEMU then moves more seamlessly 
> to open designs and then proprietary product designs.  MinPlatform 
> consistency is hoped to help that developer ramp into system firmware 
> productivity.
> 
> We have only seen MinPlatform applied to Intel based products so far.
> Which is why we are not rushing to move the spec from a 0.7 “broad 
> feedback” state to a 1.0 “initially complete” state.  Like edk2, 
> MinPlatformPkg and BoardModulePkg content is intended to support 
> multiple silicon and product architectures and we will happily promote 
> content out of “Intel” scope when that is an accurate reflection of use 
> and not just wishful thinking.  While 100% of uses are Intel scope, it 
> makes sense to land in the Intel part of edk2-platforms repo.  Similar 
> logic applies to Features/Intel content, though more there may have ties 
> to Intel specific product features.
> 
> The Minimum Platform Arch spec details base requirements for FV layout 
> (thus enabling more common code to publish FV details), base silicon 
> policy configuration flow (thus more common PEIM/drivers to gather 
> config information and reduce board porting to relatively simple 
> libraries), and such things.  By enabling more common PEIM and drivers, 
> we hope to see benefits to ease of use and consistent quality. Similar 
> approaches for the other elements of the spec should help to improve 
> code sharing.
> 
> Anyway, yes, it should be able to help you reduce the copies of “mostly 
> common” code that you encountered and the code and spec are open to 
> welcome the additional use and feedback from additional applications.
> 
> Regards,
> Isaac
> 
> *From:*devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of *Daniel 
> Schaefer
> *Sent:* Wednesday, May 19, 2021 8:40 PM
> *To:* devel@edk2.groups.io; gaoliming@byosoft.com.cn; 
> kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>; 
> mikuback@linux.microsoft.com
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> Hi,
> 
> that sounds like a great project!
> 
> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64 
> generic QEMU virt machine.
> 
> I don't like how much of my DSC and FDF file has modules that pretty 
> much all platforms should have.
> 
> MinPlatform would help reduce that, right?
> 
> Is MinPlatform flexible enough to account for non-X64 platforms?
> 
> If so, then I think Kaaira and I could collaborate.
> 
> Cheers,
> Daniel
> 
> ------------------------------------------------------------------------
> 
> *From:*devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki 
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Thursday, May 20, 2021 02:57
> *To:* devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com 
> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> I also wanted to add that I will be setting up weekly video calls
> including Ray that we can use to supplement mailing list communication.
> 
> I suggest the primary communication mechanism be the mailing list and we
> use those calls for clarification, detailed project planning, and topics
> not directly relevant to the list.
> 
> Regards,
> Michael
> 
> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>> Thanks Liming.
>> 
>> Hi Kaaira,
>> 
>> Welcome! You can contact me at mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>. You 
> will
>> sometimes see my email as michael.kubacki@microsoft.com <mailto:michael.kubacki@microsoft.com>and 
> that is fine
>> to use for communication though I tend to not use it on the mailing list 
>> due to way the mail server manipulates plaintext email.
>> 
>> GENERIC RESOURCES
>> 
>> I'm sharing some general resources in case you are not already familiar 
>> with them:
>> 
>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki 
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>> 
>> This one is good for topics like UEFI overview, EDK II concepts, and 
>> Minimum Platform.
>> 
>> In particular for your project, I recommend looking through the 
>> MinPlatform training - 
>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf 
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>> 
>> 
>> 2. 
>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html 
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>> 
>> 
>> These whitepapers are useful when you need more in depth detail about a 
>> particular area (like capsule update or work related to the memory map). 
>> I recommend bookmarking it and keeping it in mind as a reference.
>> 
>> 3. https://uefi.org/learning_center/presentationsandvideos/ 
> <https://uefi.org/learning_center/presentationsandvideos/>
>> 
>> Scroll through here if you have some time and see if there's anything 
>> interesting. To help keep on your project schedule I don't think these 
>> are as important but there is a lot of interesting material there.
>> 
>> Reading through some of the key concepts in Beyond BIOS can be helpful 
>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at 
>> https://uefi.org/specifications <https://uefi.org/specifications>, I 
> believe they are most useful as
>> references when you are solving specific problems.
>> 
>> PROJECT-SPECIFIC RESOURCES
>> 
>> Since your project involves creating QEMU board within the Minimum 
>> Platform architecture, you can start looking into:
>> 
>> 1. QEMU - An open source machine emulator
>> 2. Minimum Platform Architecture - A software architecture to create 
>> basic platform firmware that can be extended with advanced functionality.
>> 3. Intel FSP - Try to understand the high-level goals and how FSP 
>> interfaces with firmware.
>> 
>> 1. QEMU - https://www.qemu.org/ <https://www.qemu.org/>
>> 
>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to 
>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit 
>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a 
>> 64-bit DXE.
>> 
>> I suggest you start with the OvmfPkg README - 
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>> 
>> As an initial step you can try to build an OVMF FW with a 32-bit PEI 
>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell. 
>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these 
>> target architectures.
>> 
>> Any time you submit patches to edk2, you can check edk2/maintainers.txt 
>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
>> appropriate maintainers and reviewers to CC on the patch. As you can 
>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a 
>> reviewer. If there are any questions that require deep expertise in QEMU 
>> or OVMF, we will reach out to them. The Minimum Platform code is 
>> maintained in the edk2-platforms repository and it has a similar 
>> maintainers.txt file for its packages - 
>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
>> 
>> I suggest you try sending a very trivial patch for a change in the 
>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms 
> <https://github.com/tianocore/edk2-platforms>
>> to make sure that your git environment is set up properly to format edk2 
>> patches and your email service can send patches correctly.
>> 
>> We can discuss the details about how to set up your environment and what 
>> to change when you are ready. You can use this page to get started - 
>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute 
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
>> 
>> 2. EDK II Minimum Platform Specification - 
>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ 
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
>> 
>> For your project, this spec will be very useful. It describes why 
>> Minimum Platform was created and how it works at a high-level. Like the 
>> code, this document is open and available to the community. You might 
>> contribute content here in addition to your code. You can fix any bugs 
>> or update content in the spec using git patches and the mailing list 
>> similar to code.
>> 
>> 3. Intel FSP - 
>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html 
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>> 
>> 
>> For more information about Intel FSP check out the Intel FSP External 
>> Architecture Specification in the link above. v2.2 is currently the 
>> latest version.
>> 
>> There is an open source QEMU FSP available here 
>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg 
>> does not use FSP.
>> 
>> Firmware is really best learned hands on. Using the links and background 
>> info above, I suggest:
>> 
>> 1. Read the OvmfPkg readme.
>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell 
>> using QEMU.
>> 3. Reading through the EDK II Minimum Platform Specification to gain a 
>> high level understanding of Minimum Platform.
>> 4. Connect what you read to the code in 
>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel 
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
>> Focus on higher level pieces like the board initialization library.
>> 5. Note what each board package is doing. You will find common patterns 
>> for what a board package needs to implement to make the system boot.
>> 6. As you read through the code, reference the general resources listed 
>> above to understand anything not Minimum Platform specific. Part of the 
>> learning process is knowing which spec to use for different interfaces. 
>> If you're unsure which spec something is in, feel free to reach out.
>> 7. While looking through the code in edk2-platforms, think about a patch 
>> you can send to edk2-platforms for something very trivial such as a bug 
>> fix or documentation update.
>> 8. Send the patch and get it reviewed-by the appropriate 
>> maintainers/reviewers and merged into the master branch.
>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to 
>> the board code you reviewed in edk2-platforms.
>> 10. At this point, you could start outlining major pieces of 
>> initialization in OVMF and how they might map to a board package. Try to 
>> identify where the initialization pieces would reside in the board 
>> package and try to identify challenges that might arise. We will likely 
>> spend quite a bit of time here before jumping into too much code.
>> 
>> I know this is a lot of info. Please don't hesitate to reach out if you 
>> have any questions and I look forward to working with you.
>> 
>> Regards,
>> Michael
>> 
>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>> Include Michael Kubacki.
>>>
>>> Thanks
>>> Liming
>>>> -----邮件原件-----
>>>> 发件人: devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>>> GUPTA
>>>> 发送时间: 2021年5月18日 22:42
>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>; 
> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>
>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>> Hey everyone,
>>>>>
>>>>> I have been selected as a student developer for the project MinPlatform
>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>> Thankyou
>>>>> for this opportunity. I have been over the major chapters of Beyond 
>>>>> BIOS
>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>> now to help me undersatnd the community practices and get my hands
>>>>> dirty. Where should I start? What development environment do I need?
>>>>> How can I use this community bonding period to give me a better start
>>>>> for the coding phase?
>>>>>
>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>> to
>>>>> discuss this project's plan to add more details? This would be very
>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>
>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>> exist anymore. Please let me know how I can contact him.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Kaaira
>>>>
>>>> Thanks,
>>>> Kaaira
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
> 
> 
> 
> 
> 
> 

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Daniel Schaefer]

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

Thanks for the answers, that's very helpful, guys!

I've started to replace some of my DSC and FDF with the include files mentioned by Michael.
Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.
Maybe for Qemu there would have be some more non-Intel changes.
Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?

Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you ??
Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)
If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions

My plan is:

  1.  Make DSC and FDF smaller by including generic files (WIP)
  2.  Try to take advantage of "AdvancedFeatures"
  3.  Reformat the FD into the FVs mandated by the MinPlatform spec
  4.  Check the detailed requirements of each stage (e.g. required functions, build files, ...)

I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.
See: https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist

Thanks,
Daniel

________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Michael Kubacki <mikuback@linux.microsoft.com>
Sent: Friday, May 21, 2021 00:32
To: Oram, Isaac W <isaac.w.oram@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Schaefer, Daniel <daniel.schaefer@hpe.com>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

Daniel,

You will specifically find attempts to consolidate common libraries and
modules in DSC and FDF files that can be included into a board package
here -
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
Files are split such that they can be included in the corresponding
section in the board package DSC/FDF file. Note there are some mixed
opinions I've encountered in the industry on the complexity trade off
associated with includes in DSC and FDF files.

But as Isaac mentioned, while MinPlatform is designed to support
multiple architectures, it has only be enabled on Intel platforms,
therefore, you should expect to encounter some problems enabling a
different architecture but identifying and/or resolving those would be
very valuable.

As you are exploring how to port a platform to MinPlatform I also
recommend familiarizing yourself the concept of advanced features
described here -
https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
You might find your board package is relatively simpler than the
original platform package after accounting for advanced features being
separated out.

Thanks,
Michael


On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
> Daniel,
>
> The MinPlatform spec was intended to be architecture and product
> independent for a “mainstream” set of products.  It is intended to
> constrain some of the nearly unlimited extensibility and flexibility of
> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
> design should work for 80% of designs, but some will need to leverage
> full edk2 and UEFI specification flexibility.  I think that a basic QEMU
> kind of port would fit in 80% target.  I would ultimately like to see a
> progression of edk2 use that starts with QEMU then moves more seamlessly
> to open designs and then proprietary product designs.  MinPlatform
> consistency is hoped to help that developer ramp into system firmware
> productivity.
>
> We have only seen MinPlatform applied to Intel based products so far.
> Which is why we are not rushing to move the spec from a 0.7 “broad
> feedback” state to a 1.0 “initially complete” state.  Like edk2,
> MinPlatformPkg and BoardModulePkg content is intended to support
> multiple silicon and product architectures and we will happily promote
> content out of “Intel” scope when that is an accurate reflection of use
> and not just wishful thinking.  While 100% of uses are Intel scope, it
> makes sense to land in the Intel part of edk2-platforms repo.  Similar
> logic applies to Features/Intel content, though more there may have ties
> to Intel specific product features.
>
> The Minimum Platform Arch spec details base requirements for FV layout
> (thus enabling more common code to publish FV details), base silicon
> policy configuration flow (thus more common PEIM/drivers to gather
> config information and reduce board porting to relatively simple
> libraries), and such things.  By enabling more common PEIM and drivers,
> we hope to see benefits to ease of use and consistent quality. Similar
> approaches for the other elements of the spec should help to improve
> code sharing.
>
> Anyway, yes, it should be able to help you reduce the copies of “mostly
> common” code that you encountered and the code and spec are open to
> welcome the additional use and feedback from additional applications.
>
> Regards,
> Isaac
>
> *From:*devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of *Daniel
> Schaefer
> *Sent:* Wednesday, May 19, 2021 8:40 PM
> *To:* devel@edk2.groups.io; gaoliming@byosoft.com.cn;
> kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>;
> mikuback@linux.microsoft.com
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> Hi,
>
> that sounds like a great project!
>
> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
> generic QEMU virt machine.
>
> I don't like how much of my DSC and FDF file has modules that pretty
> much all platforms should have.
>
> MinPlatform would help reduce that, right?
>
> Is MinPlatform flexible enough to account for non-X64 platforms?
>
> If so, then I think Kaaira and I could collaborate.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> *From:*devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Thursday, May 20, 2021 02:57
> *To:* devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn
> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com
> <mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com
> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> I also wanted to add that I will be setting up weekly video calls
> including Ray that we can use to supplement mailing list communication.
>
> I suggest the primary communication mechanism be the mailing list and we
> use those calls for clarification, detailed project planning, and topics
> not directly relevant to the list.
>
> Regards,
> Michael
>
> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>> Thanks Liming.
>>
>> Hi Kaaira,
>>
>> Welcome! You can contact me at mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>. You
> will
>> sometimes see my email as michael.kubacki@microsoft.com <mailto:michael.kubacki@microsoft.com>and
> that is fine
>> to use for communication though I tend to not use it on the mailing list
>> due to way the mail server manipulates plaintext email.
>>
>> GENERIC RESOURCES
>>
>> I'm sharing some general resources in case you are not already familiar
>> with them:
>>
>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>>
>> This one is good for topics like UEFI overview, EDK II concepts, and
>> Minimum Platform.
>>
>> In particular for your project, I recommend looking through the
>> MinPlatform training -
>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>>
>>
>> 2.
>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>>
>>
>> These whitepapers are useful when you need more in depth detail about a
>> particular area (like capsule update or work related to the memory map).
>> I recommend bookmarking it and keeping it in mind as a reference.
>>
>> 3. https://uefi.org/learning_center/presentationsandvideos/
> <https://uefi.org/learning_center/presentationsandvideos/>
>>
>> Scroll through here if you have some time and see if there's anything
>> interesting. To help keep on your project schedule I don't think these
>> are as important but there is a lot of interesting material there.
>>
>> Reading through some of the key concepts in Beyond BIOS can be helpful
>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
>> https://uefi.org/specifications <https://uefi.org/specifications>, I
> believe they are most useful as
>> references when you are solving specific problems.
>>
>> PROJECT-SPECIFIC RESOURCES
>>
>> Since your project involves creating QEMU board within the Minimum
>> Platform architecture, you can start looking into:
>>
>> 1. QEMU - An open source machine emulator
>> 2. Minimum Platform Architecture - A software architecture to create
>> basic platform firmware that can be extended with advanced functionality.
>> 3. Intel FSP - Try to understand the high-level goals and how FSP
>> interfaces with firmware.
>>
>> 1. QEMU - https://www.qemu.org/  <https://www.qemu.org/ >
>>
>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
>> 64-bit DXE.
>>
>> I suggest you start with the OvmfPkg README -
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>>
>> As an initial step you can try to build an OVMF FW with a 32-bit PEI
>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
>> target architectures.
>>
>> Any time you submit patches to edk2, you can check edk2/maintainers.txt
>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
>> appropriate maintainers and reviewers to CC on the patch. As you can
>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
>> reviewer. If there are any questions that require deep expertise in QEMU
>> or OVMF, we will reach out to them. The Minimum Platform code is
>> maintained in the edk2-platforms repository and it has a similar
>> maintainers.txt file for its packages -
>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
>>
>> I suggest you try sending a very trivial patch for a change in the
>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> <https://github.com/tianocore/edk2-platforms>
>> to make sure that your git environment is set up properly to format edk2
>> patches and your email service can send patches correctly.
>>
>> We can discuss the details about how to set up your environment and what
>> to change when you are ready. You can use this page to get started -
>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
>>
>> 2. EDK II Minimum Platform Specification -
>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ >
>>
>> For your project, this spec will be very useful. It describes why
>> Minimum Platform was created and how it works at a high-level. Like the
>> code, this document is open and available to the community. You might
>> contribute content here in addition to your code. You can fix any bugs
>> or update content in the spec using git patches and the mailing list
>> similar to code.
>>
>> 3. Intel FSP -
>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>>
>>
>> For more information about Intel FSP check out the Intel FSP External
>> Architecture Specification in the link above. v2.2 is currently the
>> latest version.
>>
>> There is an open source QEMU FSP available here
>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
>> does not use FSP.
>>
>> Firmware is really best learned hands on. Using the links and background
>> info above, I suggest:
>>
>> 1. Read the OvmfPkg readme.
>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
>> using QEMU.
>> 3. Reading through the EDK II Minimum Platform Specification to gain a
>> high level understanding of Minimum Platform.
>> 4. Connect what you read to the code in
>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
>> Focus on higher level pieces like the board initialization library.
>> 5. Note what each board package is doing. You will find common patterns
>> for what a board package needs to implement to make the system boot.
>> 6. As you read through the code, reference the general resources listed
>> above to understand anything not Minimum Platform specific. Part of the
>> learning process is knowing which spec to use for different interfaces.
>> If you're unsure which spec something is in, feel free to reach out.
>> 7. While looking through the code in edk2-platforms, think about a patch
>> you can send to edk2-platforms for something very trivial such as a bug
>> fix or documentation update.
>> 8. Send the patch and get it reviewed-by the appropriate
>> maintainers/reviewers and merged into the master branch.
>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
>> the board code you reviewed in edk2-platforms.
>> 10. At this point, you could start outlining major pieces of
>> initialization in OVMF and how they might map to a board package. Try to
>> identify where the initialization pieces would reside in the board
>> package and try to identify challenges that might arise. We will likely
>> spend quite a bit of time here before jumping into too much code.
>>
>> I know this is a lot of info. Please don't hesitate to reach out if you
>> have any questions and I look forward to working with you.
>>
>> Regards,
>> Michael
>>
>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>> Include Michael Kubacki.
>>>
>>> Thanks
>>> Liming
>>>> -----邮件原件-----
>>>> 发件人: devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>>> GUPTA
>>>> 发送时间: 2021年5月18日 22:42
>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>;
> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>
>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>> Hey everyone,
>>>>>
>>>>> I have been selected as a student developer for the project MinPlatform
>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>> Thankyou
>>>>> for this opportunity. I have been over the major chapters of Beyond
>>>>> BIOS
>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>> now to help me undersatnd the community practices and get my hands
>>>>> dirty. Where should I start? What development environment do I need?
>>>>> How can I use this community bonding period to give me a better start
>>>>> for the coding phase?
>>>>>
>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>> to
>>>>> discuss this project's plan to add more details? This would be very
>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>
>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>> exist anymore. Please let me know how I can contact him.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Kaaira
>>>>
>>>> Thanks,
>>>> Kaaira
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>






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

Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

[Oram, Isaac W]

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

I think we should patch first and move to a common location later.

Looking at some of your changes and comments, I have these comments:

  *   Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
  *   If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
  *   Rather than commenting out or adding !if modifications, you can set the feature PCD to false in your DSC file before including the file.  We are allowed to have multiple sections and the tools do a good job of applying them and aggregating them in sensible ways.  For example:
#!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE
#  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
#!endif

     *   If you just have:
[PcdsFeatureFlag]
  #
  # MinPlatform control flags
  #
  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE
  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE
  gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE
  gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE
  gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE
  gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE
  gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE
…
!include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc

     *   Then you should get the same result you want.

This is useful feedback and we should think about how we want to enable optimization (stage 7) in a reasonable way.  We haven’t gotten that far into the optimization details as we wanted to get the basics worked out, but it might very much make sense to make more of these things controlled by MinPlatform Arch defined feature flags.  Or to move to Advanced Features.  And some things we haven’t cleaned up yet.  We still have USB in common includes, but those drivers should move to an Advanced Feature.  The main thing is we want intelligent default behavior so new board porting people can get productive fast without having to know all these edk2 special features.  Then as they get things working, they can start to take advantage of more edk2 and UEFI capabilities as they learn them.  Eventually hitting an optimization phase where common things can be quickly stripped out if not needed.  I hadn’t thought much about build optimization, but I think that this is reasonable to include in scope.

Looking at your feedback/challenges, I see a few options:

·         Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.

·         Add Advanced Features for them

·         Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.

Thoughts and preferences?  I think that we need to keep in mind KISS for new board ports and new users.

The checklists should be “Board Porting Activity Checklist” and unfortunately for you both, you are making the first reference QemuOpenBoardPkg and boards and that is a little more involved than making derivatives, which is what those checklists are going to help the most.

Regards,
Isaac


From: Schaefer, Daniel <daniel.schaefer@hpe.com>
Sent: Thursday, May 20, 2021 7:27 PM
To: Oram, Isaac W <isaac.w.oram@intel.com>; devel@edk2.groups.io; gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

Thanks for the answers, that's very helpful, guys!

I've started to replace some of my DSC and FDF with the include files mentioned by Michael.
Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.
Maybe for Qemu there would have be some more non-Intel changes.
Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?

Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you 🙂
Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)
If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions

My plan is:

  1.  Make DSC and FDF smaller by including generic files (WIP)
  2.  Try to take advantage of "AdvancedFeatures"
  3.  Reformat the FD into the FVs mandated by the MinPlatform spec
  4.  Check the detailed requirements of each stage (e.g. required functions, build files, ...)
I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.
See: https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist

Thanks,
Daniel

________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki <mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>>
Sent: Friday, May 21, 2021 00:32
To: Oram, Isaac W <isaac.w.oram@intel.com<mailto:isaac.w.oram@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Schaefer, Daniel <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com> <kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

Daniel,

You will specifically find attempts to consolidate common libraries and
modules in DSC and FDF files that can be included into a board package
here -
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
Files are split such that they can be included in the corresponding
section in the board package DSC/FDF file. Note there are some mixed
opinions I've encountered in the industry on the complexity trade off
associated with includes in DSC and FDF files.

But as Isaac mentioned, while MinPlatform is designed to support
multiple architectures, it has only be enabled on Intel platforms,
therefore, you should expect to encounter some problems enabling a
different architecture but identifying and/or resolving those would be
very valuable.

As you are exploring how to port a platform to MinPlatform I also
recommend familiarizing yourself the concept of advanced features
described here -
https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
You might find your board package is relatively simpler than the
original platform package after accounting for advanced features being
separated out.

Thanks,
Michael


On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
> Daniel,
>
> The MinPlatform spec was intended to be architecture and product
> independent for a “mainstream” set of products.  It is intended to
> constrain some of the nearly unlimited extensibility and flexibility of
> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
> design should work for 80% of designs, but some will need to leverage
> full edk2 and UEFI specification flexibility.  I think that a basic QEMU
> kind of port would fit in 80% target.  I would ultimately like to see a
> progression of edk2 use that starts with QEMU then moves more seamlessly
> to open designs and then proprietary product designs.  MinPlatform
> consistency is hoped to help that developer ramp into system firmware
> productivity.
>
> We have only seen MinPlatform applied to Intel based products so far.
> Which is why we are not rushing to move the spec from a 0.7 “broad
> feedback” state to a 1.0 “initially complete” state.  Like edk2,
> MinPlatformPkg and BoardModulePkg content is intended to support
> multiple silicon and product architectures and we will happily promote
> content out of “Intel” scope when that is an accurate reflection of use
> and not just wishful thinking.  While 100% of uses are Intel scope, it
> makes sense to land in the Intel part of edk2-platforms repo.  Similar
> logic applies to Features/Intel content, though more there may have ties
> to Intel specific product features.
>
> The Minimum Platform Arch spec details base requirements for FV layout
> (thus enabling more common code to publish FV details), base silicon
> policy configuration flow (thus more common PEIM/drivers to gather
> config information and reduce board porting to relatively simple
> libraries), and such things.  By enabling more common PEIM and drivers,
> we hope to see benefits to ease of use and consistent quality. Similar
> approaches for the other elements of the spec should help to improve
> code sharing.
>
> Anyway, yes, it should be able to help you reduce the copies of “mostly
> common” code that you encountered and the code and spec are open to
> welcome the additional use and feedback from additional applications.
>
> Regards,
> Isaac
>
> *From:*devel@edk2.groups.io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> *On Behalf Of *Daniel
> Schaefer
> *Sent:* Wednesday, May 19, 2021 8:40 PM
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
> kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>;
> mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> Hi,
>
> that sounds like a great project!
>
> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
> generic QEMU virt machine.
>
> I don't like how much of my DSC and FDF file has modules that pretty
> much all platforms should have.
>
> MinPlatform would help reduce that, right?
>
> Is MinPlatform flexible enough to account for non-X64 platforms?
>
> If so, then I think Kaaira and I could collaborate.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> *From:*devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Thursday, May 20, 2021 02:57
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn
<mailto:gaoliming@byosoft.com.cn%20%0b>> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com
<mailto:kaaira7319@gmail.com%20%0b>> <mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com
<mailto:ray.ni@intel.com%20%0b>> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> I also wanted to add that I will be setting up weekly video calls
> including Ray that we can use to supplement mailing list communication.
>
> I suggest the primary communication mechanism be the mailing list and we
> use those calls for clarification, detailed project planning, and topics
> not directly relevant to the list.
>
> Regards,
> Michael
>
> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>> Thanks Liming.
>>
>> Hi Kaaira,
>>
>> Welcome! You can contact me at mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com> <mailto:mikuback@linux.microsoft.com>. You
> will
>> sometimes see my email as michael.kubacki@microsoft.com<mailto:michael.kubacki@microsoft.com> <mailto:michael.kubacki@microsoft.com>and
> that is fine
>> to use for communication though I tend to not use it on the mailing list
>> due to way the mail server manipulates plaintext email.
>>
>> GENERIC RESOURCES
>>
>> I'm sharing some general resources in case you are not already familiar
>> with them:
>>
>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>>
>> This one is good for topics like UEFI overview, EDK II concepts, and
>> Minimum Platform.
>>
>> In particular for your project, I recommend looking through the
>> MinPlatform training -
>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>>
>>
>> 2.
>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>>
>>
>> These whitepapers are useful when you need more in depth detail about a
>> particular area (like capsule update or work related to the memory map).
>> I recommend bookmarking it and keeping it in mind as a reference.
>>
>> 3. https://uefi.org/learning_center/presentationsandvideos/
> <https://uefi.org/learning_center/presentationsandvideos/>
>>
>> Scroll through here if you have some time and see if there's anything
>> interesting. To help keep on your project schedule I don't think these
>> are as important but there is a lot of interesting material there.
>>
>> Reading through some of the key concepts in Beyond BIOS can be helpful
>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
>> https://uefi.org/specifications <https://uefi.org/specifications>, I
> believe they are most useful as
>> references when you are solving specific problems.
>>
>> PROJECT-SPECIFIC RESOURCES
>>
>> Since your project involves creating QEMU board within the Minimum
>> Platform architecture, you can start looking into:
>>
>> 1. QEMU - An open source machine emulator
>> 2. Minimum Platform Architecture - A software architecture to create
>> basic platform firmware that can be extended with advanced functionality.
>> 3. Intel FSP - Try to understand the high-level goals and how FSP
>> interfaces with firmware.
>>
>> 1. QEMU - https://urldefense.com/v3/__https://www.qemu.org/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbilPs13w$<https://urldefense.com/v3/__https:/www.qemu.org/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbilPs13w$>  <https://urldefense.com/v3/__https://www.qemu.org/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbilPs13w$ <https://urldefense.com/v3/__https:/www.qemu.org/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbilPs13w$%20> >
>>
>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
>> 64-bit DXE.
>>
>> I suggest you start with the OvmfPkg README -
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>>
>> As an initial step you can try to build an OVMF FW with a 32-bit PEI
>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
>> target architectures.
>>
>> Any time you submit patches to edk2, you can check edk2/maintainers.txt
>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
>> appropriate maintainers and reviewers to CC on the patch. As you can
>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
>> reviewer. If there are any questions that require deep expertise in QEMU
>> or OVMF, we will reach out to them. The Minimum Platform code is
>> maintained in the edk2-platforms repository and it has a similar
>> maintainers.txt file for its packages -
>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
>>
>> I suggest you try sending a very trivial patch for a change in the
>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> <https://github.com/tianocore/edk2-platforms>
>> to make sure that your git environment is set up properly to format edk2
>> patches and your email service can send patches correctly.
>>
>> We can discuss the details about how to set up your environment and what
>> to change when you are ready. You can use this page to get started -
>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
>>
>> 2. EDK II Minimum Platform Specification -
>> https://urldefense.com/v3/__https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbQBLRfuQ$<https://urldefense.com/v3/__https:/edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbQBLRfuQ$>
> <https://urldefense.com/v3/__https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbQBLRfuQ$ <https://urldefense.com/v3/__https:/edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/__;!!NpxR!yx4Srk8BWg-LiB0gZHMcs1EFkzoCLbS_Q3OH7XC-51KlOWhG5Zf1nzOl5UbQBLRfuQ$%20> >
>>
>> For your project, this spec will be very useful. It describes why
>> Minimum Platform was created and how it works at a high-level. Like the
>> code, this document is open and available to the community. You might
>> contribute content here in addition to your code. You can fix any bugs
>> or update content in the spec using git patches and the mailing list
>> similar to code.
>>
>> 3. Intel FSP -
>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>>
>>
>> For more information about Intel FSP check out the Intel FSP External
>> Architecture Specification in the link above. v2.2 is currently the
>> latest version.
>>
>> There is an open source QEMU FSP available here
>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
>> does not use FSP.
>>
>> Firmware is really best learned hands on. Using the links and background
>> info above, I suggest:
>>
>> 1. Read the OvmfPkg readme.
>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
>> using QEMU.
>> 3. Reading through the EDK II Minimum Platform Specification to gain a
>> high level understanding of Minimum Platform.
>> 4. Connect what you read to the code in
>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
>> Focus on higher level pieces like the board initialization library.
>> 5. Note what each board package is doing. You will find common patterns
>> for what a board package needs to implement to make the system boot.
>> 6. As you read through the code, reference the general resources listed
>> above to understand anything not Minimum Platform specific. Part of the
>> learning process is knowing which spec to use for different interfaces.
>> If you're unsure which spec something is in, feel free to reach out.
>> 7. While looking through the code in edk2-platforms, think about a patch
>> you can send to edk2-platforms for something very trivial such as a bug
>> fix or documentation update.
>> 8. Send the patch and get it reviewed-by the appropriate
>> maintainers/reviewers and merged into the master branch.
>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
>> the board code you reviewed in edk2-platforms.
>> 10. At this point, you could start outlining major pieces of
>> initialization in OVMF and how they might map to a board package. Try to
>> identify where the initialization pieces would reside in the board
>> package and try to identify challenges that might arise. We will likely
>> spend quite a bit of time here before jumping into too much code.
>>
>> I know this is a lot of info. Please don't hesitate to reach out if you
>> have any questions and I look forward to working with you.
>>
>> Regards,
>> Michael
>>
>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>> Include Michael Kubacki.
>>>
>>> Thanks
>>> Liming
>>>> -----邮件原件-----
>>>> 发件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>>> GUPTA
>>>> 发送时间: 2021年5月18日 22:42
>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>
>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>
>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>> Hey everyone,
>>>>>
>>>>> I have been selected as a student developer for the project MinPlatform
>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>> Thankyou
>>>>> for this opportunity. I have been over the major chapters of Beyond
>>>>> BIOS
>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>> now to help me undersatnd the community practices and get my hands
>>>>> dirty. Where should I start? What development environment do I need?
>>>>> How can I use this community bonding period to give me a better start
>>>>> for the coding phase?
>>>>>
>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>> to
>>>>> discuss this project's plan to add more details? This would be very
>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>
>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>> exist anymore. Please let me know how I can contact him.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Kaaira
>>>>
>>>> Thanks,
>>>> Kaaira
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>





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

Re: 回复: [edk2-devel] Generic MinPlatform

[Daniel Schaefer]

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

  *

  *   Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
  *   If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.

Hm, you're right. However I added another PCD to exclude things that RISC-V and many other non-x86 platforms don't have: SMM, port-mapped I/O, PC/AT architecture:
https://github.com/riscv/riscv-edk2-platforms/commit/cbec8681916fe2f4276118198a6d315fd06c75d3

Then I have two more issues unrelated to RISC-V: https://github.com/riscv/riscv-edk2-platforms/commit/b68f4587fc28588b4474ff15d43918182c33b4b7
And some related to RISC-V: https://github.com/riscv/riscv-edk2-platforms/commit/579705cf46dafc90e4a2bc243e5aa5cd828cb126

And what's most relevant to Kaaira, the commit to make my QEMU platform use MinPlatform include files:
https://github.com/riscv/riscv-edk2-platforms/commit/54542812912079d6855e2be4186cb8a6978edac6

Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
Yes, absolutely. As above, for now I created one for common x86 concepts. But there should probably be one for PCI and USB should move to AdvancedFeatures, like you said.
The other two RISC-V platforms I'm working on don't have PCI and one of them doesn't have USB.

Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.
Right, that's a good idea. Kaaira and me can create one for QEMU with all of the virtio drivers.
And those for x86 and RISC-V wouldn't actually too big, as you can see in my change. RISC-V needs even less special modules.

Thanks,
Daniel

________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Oram, Isaac W <isaac.w.oram@intel.com>
Sent: Friday, May 21, 2021 11:38
To: Schaefer, Daniel <daniel.schaefer@hpe.com>; devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com <mikuback@linux.microsoft.com>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project


I think we should patch first and move to a common location later.



Looking at some of your changes and comments, I have these comments:

  *   Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
  *   If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
  *   Rather than commenting out or adding !if modifications, you can set the feature PCD to false in your DSC file before including the file.  We are allowed to have multiple sections and the tools do a good job of applying them and aggregating them in sensible ways.  For example:

#!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE

#  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf

#!endif

     *   If you just have:

[PcdsFeatureFlag]

  #

  # MinPlatform control flags

  #

  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE

  gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE

…

!include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc

     *   Then you should get the same result you want.



This is useful feedback and we should think about how we want to enable optimization (stage 7) in a reasonable way.  We haven’t gotten that far into the optimization details as we wanted to get the basics worked out, but it might very much make sense to make more of these things controlled by MinPlatform Arch defined feature flags.  Or to move to Advanced Features.  And some things we haven’t cleaned up yet.  We still have USB in common includes, but those drivers should move to an Advanced Feature.  The main thing is we want intelligent default behavior so new board porting people can get productive fast without having to know all these edk2 special features.  Then as they get things working, they can start to take advantage of more edk2 and UEFI capabilities as they learn them.  Eventually hitting an optimization phase where common things can be quickly stripped out if not needed.  I hadn’t thought much about build optimization, but I think that this is reasonable to include in scope.



Looking at your feedback/challenges, I see a few options:

·         Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.

·         Add Advanced Features for them

·         Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.



Thoughts and preferences?  I think that we need to keep in mind KISS for new board ports and new users.



The checklists should be “Board Porting Activity Checklist” and unfortunately for you both, you are making the first reference QemuOpenBoardPkg and boards and that is a little more involved than making derivatives, which is what those checklists are going to help the most.



Regards,
Isaac





From: Schaefer, Daniel <daniel.schaefer@hpe.com>
Sent: Thursday, May 20, 2021 7:27 PM
To: Oram, Isaac W <isaac.w.oram@intel.com>; devel@edk2.groups.io; gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project



Thanks for the answers, that's very helpful, guys!



I've started to replace some of my DSC and FDF with the include files mentioned by Michael.

Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.

Maybe for Qemu there would have be some more non-Intel changes.

Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?



Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you 🙂

Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)

If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions



My plan is:

  1.  Make DSC and FDF smaller by including generic files (WIP)
  2.  Try to take advantage of "AdvancedFeatures"
  3.  Reformat the FD into the FVs mandated by the MinPlatform spec
  4.  Check the detailed requirements of each stage (e.g. required functions, build files, ...)

I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.

See: https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist<https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist>



Thanks,

Daniel



________________________________

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki <mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>>
Sent: Friday, May 21, 2021 00:32
To: Oram, Isaac W <isaac.w.oram@intel.com<mailto:isaac.w.oram@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Schaefer, Daniel <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com> <kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project



Daniel,

You will specifically find attempts to consolidate common libraries and
modules in DSC and FDF files that can be included into a board package
here -
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
Files are split such that they can be included in the corresponding
section in the board package DSC/FDF file. Note there are some mixed
opinions I've encountered in the industry on the complexity trade off
associated with includes in DSC and FDF files.

But as Isaac mentioned, while MinPlatform is designed to support
multiple architectures, it has only be enabled on Intel platforms,
therefore, you should expect to encounter some problems enabling a
different architecture but identifying and/or resolving those would be
very valuable.

As you are exploring how to port a platform to MinPlatform I also
recommend familiarizing yourself the concept of advanced features
described here -
https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
You might find your board package is relatively simpler than the
original platform package after accounting for advanced features being
separated out.

Thanks,
Michael


On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
> Daniel,
>
> The MinPlatform spec was intended to be architecture and product
> independent for a “mainstream” set of products.  It is intended to
> constrain some of the nearly unlimited extensibility and flexibility of
> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
> design should work for 80% of designs, but some will need to leverage
> full edk2 and UEFI specification flexibility.  I think that a basic QEMU
> kind of port would fit in 80% target.  I would ultimately like to see a
> progression of edk2 use that starts with QEMU then moves more seamlessly
> to open designs and then proprietary product designs.  MinPlatform
> consistency is hoped to help that developer ramp into system firmware
> productivity.
>
> We have only seen MinPlatform applied to Intel based products so far.
> Which is why we are not rushing to move the spec from a 0.7 “broad
> feedback” state to a 1.0 “initially complete” state.  Like edk2,
> MinPlatformPkg and BoardModulePkg content is intended to support
> multiple silicon and product architectures and we will happily promote
> content out of “Intel” scope when that is an accurate reflection of use
> and not just wishful thinking.  While 100% of uses are Intel scope, it
> makes sense to land in the Intel part of edk2-platforms repo.  Similar
> logic applies to Features/Intel content, though more there may have ties
> to Intel specific product features.
>
> The Minimum Platform Arch spec details base requirements for FV layout
> (thus enabling more common code to publish FV details), base silicon
> policy configuration flow (thus more common PEIM/drivers to gather
> config information and reduce board porting to relatively simple
> libraries), and such things.  By enabling more common PEIM and drivers,
> we hope to see benefits to ease of use and consistent quality. Similar
> approaches for the other elements of the spec should help to improve
> code sharing.
>
> Anyway, yes, it should be able to help you reduce the copies of “mostly
> common” code that you encountered and the code and spec are open to
> welcome the additional use and feedback from additional applications.
>
> Regards,
> Isaac
>
> *From:*devel@edk2.groups.io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> *On Behalf Of *Daniel
> Schaefer
> *Sent:* Wednesday, May 19, 2021 8:40 PM
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
> kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>;
> mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> Hi,
>
> that sounds like a great project!
>
> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
> generic QEMU virt machine.
>
> I don't like how much of my DSC and FDF file has modules that pretty
> much all platforms should have.
>
> MinPlatform would help reduce that, right?
>
> Is MinPlatform flexible enough to account for non-X64 platforms?
>
> If so, then I think Kaaira and I could collaborate.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> *From:*devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Thursday, May 20, 2021 02:57
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn
<mailto:gaoliming@byosoft.com.cn%20%0b>> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com
<mailto:kaaira7319@gmail.com%20%0b>> <mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com
<mailto:ray.ni@intel.com%20%0b>> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> I also wanted to add that I will be setting up weekly video calls
> including Ray that we can use to supplement mailing list communication.
>
> I suggest the primary communication mechanism be the mailing list and we
> use those calls for clarification, detailed project planning, and topics
> not directly relevant to the list.
>
> Regards,
> Michael
>
> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>> Thanks Liming.
>>
>> Hi Kaaira,
>>
>> Welcome! You can contact me at mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com> <mailto:mikuback@linux.microsoft.com>. You
> will
>> sometimes see my email as michael.kubacki@microsoft.com<mailto:michael.kubacki@microsoft.com> <mailto:michael.kubacki@microsoft.com>and
> that is fine
>> to use for communication though I tend to not use it on the mailing list
>> due to way the mail server manipulates plaintext email.
>>
>> GENERIC RESOURCES
>>
>> I'm sharing some general resources in case you are not already familiar
>> with them:
>>
>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>>
>> This one is good for topics like UEFI overview, EDK II concepts, and
>> Minimum Platform.
>>
>> In particular for your project, I recommend looking through the
>> MinPlatform training -
>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>>
>>
>> 2.
>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>>
>>
>> These whitepapers are useful when you need more in depth detail about a
>> particular area (like capsule update or work related to the memory map).
>> I recommend bookmarking it and keeping it in mind as a reference.
>>
>> 3. https://uefi.org/learning_center/presentationsandvideos/
> <https://uefi.org/learning_center/presentationsandvideos/>
>>
>> Scroll through here if you have some time and see if there's anything
>> interesting. To help keep on your project schedule I don't think these
>> are as important but there is a lot of interesting material there.
>>
>> Reading through some of the key concepts in Beyond BIOS can be helpful
>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
>> https://uefi.org/specifications <https://uefi.org/specifications>, I
> believe they are most useful as
>> references when you are solving specific problems.
>>
>> PROJECT-SPECIFIC RESOURCES
>>
>> Since your project involves creating QEMU board within the Minimum
>> Platform architecture, you can start looking into:
>>
>> 1. QEMU - An open source machine emulator
>> 2. Minimum Platform Architecture - A software architecture to create
>> basic platform firmware that can be extended with advanced functionality.
>> 3. Intel FSP - Try to understand the high-level goals and how FSP
>> interfaces with firmware.
>>
>> 1. QEMU - https://www.qemu.org/<https://www.qemu.org/>  <https://www.qemu.org/ <https://www.qemu.org/> >
>>
>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
>> 64-bit DXE.
>>
>> I suggest you start with the OvmfPkg README -
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>>
>> As an initial step you can try to build an OVMF FW with a 32-bit PEI
>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
>> target architectures.
>>
>> Any time you submit patches to edk2, you can check edk2/maintainers.txt
>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
>> appropriate maintainers and reviewers to CC on the patch. As you can
>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
>> reviewer. If there are any questions that require deep expertise in QEMU
>> or OVMF, we will reach out to them. The Minimum Platform code is
>> maintained in the edk2-platforms repository and it has a similar
>> maintainers.txt file for its packages -
>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
>>
>> I suggest you try sending a very trivial patch for a change in the
>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> <https://github.com/tianocore/edk2-platforms>
>> to make sure that your git environment is set up properly to format edk2
>> patches and your email service can send patches correctly.
>>
>> We can discuss the details about how to set up your environment and what
>> to change when you are ready. You can use this page to get started -
>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
>>
>> 2. EDK II Minimum Platform Specification -
>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/<https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/> >
>>
>> For your project, this spec will be very useful. It describes why
>> Minimum Platform was created and how it works at a high-level. Like the
>> code, this document is open and available to the community. You might
>> contribute content here in addition to your code. You can fix any bugs
>> or update content in the spec using git patches and the mailing list
>> similar to code.
>>
>> 3. Intel FSP -
>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>>
>>
>> For more information about Intel FSP check out the Intel FSP External
>> Architecture Specification in the link above. v2.2 is currently the
>> latest version.
>>
>> There is an open source QEMU FSP available here
>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
>> does not use FSP.
>>
>> Firmware is really best learned hands on. Using the links and background
>> info above, I suggest:
>>
>> 1. Read the OvmfPkg readme.
>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
>> using QEMU.
>> 3. Reading through the EDK II Minimum Platform Specification to gain a
>> high level understanding of Minimum Platform.
>> 4. Connect what you read to the code in
>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
>> Focus on higher level pieces like the board initialization library.
>> 5. Note what each board package is doing. You will find common patterns
>> for what a board package needs to implement to make the system boot.
>> 6. As you read through the code, reference the general resources listed
>> above to understand anything not Minimum Platform specific. Part of the
>> learning process is knowing which spec to use for different interfaces.
>> If you're unsure which spec something is in, feel free to reach out.
>> 7. While looking through the code in edk2-platforms, think about a patch
>> you can send to edk2-platforms for something very trivial such as a bug
>> fix or documentation update.
>> 8. Send the patch and get it reviewed-by the appropriate
>> maintainers/reviewers and merged into the master branch.
>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
>> the board code you reviewed in edk2-platforms.
>> 10. At this point, you could start outlining major pieces of
>> initialization in OVMF and how they might map to a board package. Try to
>> identify where the initialization pieces would reside in the board
>> package and try to identify challenges that might arise. We will likely
>> spend quite a bit of time here before jumping into too much code.
>>
>> I know this is a lot of info. Please don't hesitate to reach out if you
>> have any questions and I look forward to working with you.
>>
>> Regards,
>> Michael
>>
>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>> Include Michael Kubacki.
>>>
>>> Thanks
>>> Liming
>>>> -----邮件原件-----
>>>> 发件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>>> GUPTA
>>>> 发送时间: 2021年5月18日 22:42
>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>
>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>
>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>> Hey everyone,
>>>>>
>>>>> I have been selected as a student developer for the project MinPlatform
>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>> Thankyou
>>>>> for this opportunity. I have been over the major chapters of Beyond
>>>>> BIOS
>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>> now to help me undersatnd the community practices and get my hands
>>>>> dirty. Where should I start? What development environment do I need?
>>>>> How can I use this community bonding period to give me a better start
>>>>> for the coding phase?
>>>>>
>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>> to
>>>>> discuss this project's plan to add more details? This would be very
>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>
>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>> exist anymore. Please let me know how I can contact him.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Kaaira
>>>>
>>>> Thanks,
>>>> Kaaira
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>







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

Re: 回复: [edk2-devel] Generic MinPlatform

[Daniel Schaefer]

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

I had a closer look at the MinPlatform specification and I made a TODO list: https://github.com/riscv/riscv-edk2-platforms/issues/24

Mostly I just have to:

  *   reorganize and split the FVs to fit the spec
  *   use the include files to ensure that they contain the correct modules
  *   switch to the MinPlatform PCDs instead of the ones that I currently use (for PreMemRamBase for example)
  *   make sure the test functions to validate the stages are included and run

The tasks for x86 QEMU/OVMF should be the same. Doesn't look too scary.

Since there are these test functions, is there a way to test compliance with the spec?
________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Daniel Schaefer <daniel.schaefer@hpe.com>
Sent: Tuesday, May 25, 2021 02:59
To: devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com <mikuback@linux.microsoft.com>; isaac.w.oram@intel.com <isaac.w.oram@intel.com>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] Generic MinPlatform

  *

  *   Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
  *   If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.

Hm, you're right. However I added another PCD to exclude things that RISC-V and many other non-x86 platforms don't have: SMM, port-mapped I/O, PC/AT architecture:
https://github.com/riscv/riscv-edk2-platforms/commit/cbec8681916fe2f4276118198a6d315fd06c75d3

Then I have two more issues unrelated to RISC-V: https://github.com/riscv/riscv-edk2-platforms/commit/b68f4587fc28588b4474ff15d43918182c33b4b7
And some related to RISC-V: https://github.com/riscv/riscv-edk2-platforms/commit/579705cf46dafc90e4a2bc243e5aa5cd828cb126

And what's most relevant to Kaaira, the commit to make my QEMU platform use MinPlatform include files:
https://github.com/riscv/riscv-edk2-platforms/commit/54542812912079d6855e2be4186cb8a6978edac6

Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
Yes, absolutely. As above, for now I created one for common x86 concepts. But there should probably be one for PCI and USB should move to AdvancedFeatures, like you said.
The other two RISC-V platforms I'm working on don't have PCI and one of them doesn't have USB.

Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.
Right, that's a good idea. Kaaira and me can create one for QEMU with all of the virtio drivers.
And those for x86 and RISC-V wouldn't actually too big, as you can see in my change. RISC-V needs even less special modules.

Thanks,
Daniel

________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Oram, Isaac W <isaac.w.oram@intel.com>
Sent: Friday, May 21, 2021 11:38
To: Schaefer, Daniel <daniel.schaefer@hpe.com>; devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com <mikuback@linux.microsoft.com>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project


I think we should patch first and move to a common location later.



Looking at some of your changes and comments, I have these comments:

  *   Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
  *   If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
  *   Rather than commenting out or adding !if modifications, you can set the feature PCD to false in your DSC file before including the file.  We are allowed to have multiple sections and the tools do a good job of applying them and aggregating them in sensible ways.  For example:

#!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE

#  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf

#!endif

     *   If you just have:

[PcdsFeatureFlag]

  #

  # MinPlatform control flags

  #

  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE

  gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE

  gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE

…

!include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc

     *   Then you should get the same result you want.



This is useful feedback and we should think about how we want to enable optimization (stage 7) in a reasonable way.  We haven’t gotten that far into the optimization details as we wanted to get the basics worked out, but it might very much make sense to make more of these things controlled by MinPlatform Arch defined feature flags.  Or to move to Advanced Features.  And some things we haven’t cleaned up yet.  We still have USB in common includes, but those drivers should move to an Advanced Feature.  The main thing is we want intelligent default behavior so new board porting people can get productive fast without having to know all these edk2 special features.  Then as they get things working, they can start to take advantage of more edk2 and UEFI capabilities as they learn them.  Eventually hitting an optimization phase where common things can be quickly stripped out if not needed.  I hadn’t thought much about build optimization, but I think that this is reasonable to include in scope.



Looking at your feedback/challenges, I see a few options:

·         Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.

·         Add Advanced Features for them

·         Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.



Thoughts and preferences?  I think that we need to keep in mind KISS for new board ports and new users.



The checklists should be “Board Porting Activity Checklist” and unfortunately for you both, you are making the first reference QemuOpenBoardPkg and boards and that is a little more involved than making derivatives, which is what those checklists are going to help the most.



Regards,
Isaac





From: Schaefer, Daniel <daniel.schaefer@hpe.com>
Sent: Thursday, May 20, 2021 7:27 PM
To: Oram, Isaac W <isaac.w.oram@intel.com>; devel@edk2.groups.io; gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project



Thanks for the answers, that's very helpful, guys!



I've started to replace some of my DSC and FDF with the include files mentioned by Michael.

Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.

Maybe for Qemu there would have be some more non-Intel changes.

Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?



Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you 🙂

Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)

If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions



My plan is:

  1.  Make DSC and FDF smaller by including generic files (WIP)
  2.  Try to take advantage of "AdvancedFeatures"
  3.  Reformat the FD into the FVs mandated by the MinPlatform spec
  4.  Check the detailed requirements of each stage (e.g. required functions, build files, ...)

I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.

See: https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist<https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist>



Thanks,

Daniel



________________________________

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki <mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>>
Sent: Friday, May 21, 2021 00:32
To: Oram, Isaac W <isaac.w.oram@intel.com<mailto:isaac.w.oram@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Schaefer, Daniel <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn> <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com> <kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project



Daniel,

You will specifically find attempts to consolidate common libraries and
modules in DSC and FDF files that can be included into a board package
here -
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
Files are split such that they can be included in the corresponding
section in the board package DSC/FDF file. Note there are some mixed
opinions I've encountered in the industry on the complexity trade off
associated with includes in DSC and FDF files.

But as Isaac mentioned, while MinPlatform is designed to support
multiple architectures, it has only be enabled on Intel platforms,
therefore, you should expect to encounter some problems enabling a
different architecture but identifying and/or resolving those would be
very valuable.

As you are exploring how to port a platform to MinPlatform I also
recommend familiarizing yourself the concept of advanced features
described here -
https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
You might find your board package is relatively simpler than the
original platform package after accounting for advanced features being
separated out.

Thanks,
Michael


On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
> Daniel,
>
> The MinPlatform spec was intended to be architecture and product
> independent for a “mainstream” set of products.  It is intended to
> constrain some of the nearly unlimited extensibility and flexibility of
> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
> design should work for 80% of designs, but some will need to leverage
> full edk2 and UEFI specification flexibility.  I think that a basic QEMU
> kind of port would fit in 80% target.  I would ultimately like to see a
> progression of edk2 use that starts with QEMU then moves more seamlessly
> to open designs and then proprietary product designs.  MinPlatform
> consistency is hoped to help that developer ramp into system firmware
> productivity.
>
> We have only seen MinPlatform applied to Intel based products so far.
> Which is why we are not rushing to move the spec from a 0.7 “broad
> feedback” state to a 1.0 “initially complete” state.  Like edk2,
> MinPlatformPkg and BoardModulePkg content is intended to support
> multiple silicon and product architectures and we will happily promote
> content out of “Intel” scope when that is an accurate reflection of use
> and not just wishful thinking.  While 100% of uses are Intel scope, it
> makes sense to land in the Intel part of edk2-platforms repo.  Similar
> logic applies to Features/Intel content, though more there may have ties
> to Intel specific product features.
>
> The Minimum Platform Arch spec details base requirements for FV layout
> (thus enabling more common code to publish FV details), base silicon
> policy configuration flow (thus more common PEIM/drivers to gather
> config information and reduce board porting to relatively simple
> libraries), and such things.  By enabling more common PEIM and drivers,
> we hope to see benefits to ease of use and consistent quality. Similar
> approaches for the other elements of the spec should help to improve
> code sharing.
>
> Anyway, yes, it should be able to help you reduce the copies of “mostly
> common” code that you encountered and the code and spec are open to
> welcome the additional use and feedback from additional applications.
>
> Regards,
> Isaac
>
> *From:*devel@edk2.groups.io <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> *On Behalf Of *Daniel
> Schaefer
> *Sent:* Wednesday, May 19, 2021 8:40 PM
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>;
> kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>;
> mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> Hi,
>
> that sounds like a great project!
>
> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
> generic QEMU virt machine.
>
> I don't like how much of my DSC and FDF file has modules that pretty
> much all platforms should have.
>
> MinPlatform would help reduce that, right?
>
> Is MinPlatform flexible enough to account for non-X64 platforms?
>
> If so, then I think Kaaira and I could collaborate.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> *From:*devel@edk2.groups.io
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Thursday, May 20, 2021 02:57
> *To:* devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>>; gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn
<mailto:gaoliming@byosoft.com.cn%20%0b>> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com<mailto:kaaira7319@gmail.com>
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com
<mailto:kaaira7319@gmail.com%20%0b>> <mailto:kaaira7319@gmail.com>>; 'Ray Ni' <ray.ni@intel.com
<mailto:ray.ni@intel.com%20%0b>> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>
> I also wanted to add that I will be setting up weekly video calls
> including Ray that we can use to supplement mailing list communication.
>
> I suggest the primary communication mechanism be the mailing list and we
> use those calls for clarification, detailed project planning, and topics
> not directly relevant to the list.
>
> Regards,
> Michael
>
> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>> Thanks Liming.
>>
>> Hi Kaaira,
>>
>> Welcome! You can contact me at mikuback@linux.microsoft.com<mailto:mikuback@linux.microsoft.com> <mailto:mikuback@linux.microsoft.com>. You
> will
>> sometimes see my email as michael.kubacki@microsoft.com<mailto:michael.kubacki@microsoft.com> <mailto:michael.kubacki@microsoft.com>and
> that is fine
>> to use for communication though I tend to not use it on the mailing list
>> due to way the mail server manipulates plaintext email.
>>
>> GENERIC RESOURCES
>>
>> I'm sharing some general resources in case you are not already familiar
>> with them:
>>
>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>>
>> This one is good for topics like UEFI overview, EDK II concepts, and
>> Minimum Platform.
>>
>> In particular for your project, I recommend looking through the
>> MinPlatform training -
>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>>
>>
>> 2.
>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>>
>>
>> These whitepapers are useful when you need more in depth detail about a
>> particular area (like capsule update or work related to the memory map).
>> I recommend bookmarking it and keeping it in mind as a reference.
>>
>> 3. https://uefi.org/learning_center/presentationsandvideos/
> <https://uefi.org/learning_center/presentationsandvideos/>
>>
>> Scroll through here if you have some time and see if there's anything
>> interesting. To help keep on your project schedule I don't think these
>> are as important but there is a lot of interesting material there.
>>
>> Reading through some of the key concepts in Beyond BIOS can be helpful
>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
>> https://uefi.org/specifications <https://uefi.org/specifications>, I
> believe they are most useful as
>> references when you are solving specific problems.
>>
>> PROJECT-SPECIFIC RESOURCES
>>
>> Since your project involves creating QEMU board within the Minimum
>> Platform architecture, you can start looking into:
>>
>> 1. QEMU - An open source machine emulator
>> 2. Minimum Platform Architecture - A software architecture to create
>> basic platform firmware that can be extended with advanced functionality.
>> 3. Intel FSP - Try to understand the high-level goals and how FSP
>> interfaces with firmware.
>>
>> 1. QEMU - https://www.qemu.org/<https://www.qemu.org/>  <https://www.qemu.org/<https://www.qemu.org/>>
>>
>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
>> 64-bit DXE.
>>
>> I suggest you start with the OvmfPkg README -
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>>
>> As an initial step you can try to build an OVMF FW with a 32-bit PEI
>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
>> target architectures.
>>
>> Any time you submit patches to edk2, you can check edk2/maintainers.txt
>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
>> appropriate maintainers and reviewers to CC on the patch. As you can
>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
>> reviewer. If there are any questions that require deep expertise in QEMU
>> or OVMF, we will reach out to them. The Minimum Platform code is
>> maintained in the edk2-platforms repository and it has a similar
>> maintainers.txt file for its packages -
>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
>>
>> I suggest you try sending a very trivial patch for a change in the
>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms
> <https://github.com/tianocore/edk2-platforms>
>> to make sure that your git environment is set up properly to format edk2
>> patches and your email service can send patches correctly.
>>
>> We can discuss the details about how to set up your environment and what
>> to change when you are ready. You can use this page to get started -
>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
>>
>> 2. EDK II Minimum Platform Specification -
>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/<https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/<https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>>
>>
>> For your project, this spec will be very useful. It describes why
>> Minimum Platform was created and how it works at a high-level. Like the
>> code, this document is open and available to the community. You might
>> contribute content here in addition to your code. You can fix any bugs
>> or update content in the spec using git patches and the mailing list
>> similar to code.
>>
>> 3. Intel FSP -
>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>>
>>
>> For more information about Intel FSP check out the Intel FSP External
>> Architecture Specification in the link above. v2.2 is currently the
>> latest version.
>>
>> There is an open source QEMU FSP available here
>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
>> does not use FSP.
>>
>> Firmware is really best learned hands on. Using the links and background
>> info above, I suggest:
>>
>> 1. Read the OvmfPkg readme.
>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
>> using QEMU.
>> 3. Reading through the EDK II Minimum Platform Specification to gain a
>> high level understanding of Minimum Platform.
>> 4. Connect what you read to the code in
>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
>> Focus on higher level pieces like the board initialization library.
>> 5. Note what each board package is doing. You will find common patterns
>> for what a board package needs to implement to make the system boot.
>> 6. As you read through the code, reference the general resources listed
>> above to understand anything not Minimum Platform specific. Part of the
>> learning process is knowing which spec to use for different interfaces.
>> If you're unsure which spec something is in, feel free to reach out.
>> 7. While looking through the code in edk2-platforms, think about a patch
>> you can send to edk2-platforms for something very trivial such as a bug
>> fix or documentation update.
>> 8. Send the patch and get it reviewed-by the appropriate
>> maintainers/reviewers and merged into the master branch.
>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
>> the board code you reviewed in edk2-platforms.
>> 10. At this point, you could start outlining major pieces of
>> initialization in OVMF and how they might map to a board package. Try to
>> identify where the initialization pieces would reside in the board
>> package and try to identify challenges that might arise. We will likely
>> spend quite a bit of time here before jumping into too much code.
>>
>> I know this is a lot of info. Please don't hesitate to reach out if you
>> have any questions and I look forward to working with you.
>>
>> Regards,
>> Michael
>>
>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>> Include Michael Kubacki.
>>>
>>> Thanks
>>> Liming
>>>> -----邮件原件-----
>>>> 发件人: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io
<mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io>> 代表 KAAIRA
>>>> GUPTA
>>>> 发送时间: 2021年5月18日 22:42
>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com>>;
> devel@edk2.groups.io<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>
>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>
>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>> Hey everyone,
>>>>>
>>>>> I have been selected as a student developer for the project MinPlatform
>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>> Thankyou
>>>>> for this opportunity. I have been over the major chapters of Beyond
>>>>> BIOS
>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>> now to help me undersatnd the community practices and get my hands
>>>>> dirty. Where should I start? What development environment do I need?
>>>>> How can I use this community bonding period to give me a better start
>>>>> for the coding phase?
>>>>>
>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>> to
>>>>> discuss this project's plan to add more details? This would be very
>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>
>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>> exist anymore. Please let me know how I can contact him.
>>>>
>>>>>
>>>>> Thank you,
>>>>> Kaaira
>>>>
>>>> Thanks,
>>>> Kaaira
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>







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

Re: 回复: [edk2-devel] Generic MinPlatform

[Michael Kubacki]

Did you find the TestPointDumpApp?

https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Test/TestPointDumpApp

gEfiAdapterInformationProtocolGuid is used and there is a test-point 
specific adapter information type. FeaturesImplemented can be compared 
with FeaturesVerified to programmatically check individual results.

I don't believe the current test points alone cover full compliance with 
the spec but they can be helpful.


Regards,
Michael

On 5/24/2021 3:13 PM, Daniel Schaefer wrote:
> I had a closer look at the MinPlatform specification and I made a TODO 
> list: https://github.com/riscv/riscv-edk2-platforms/issues/24 
> <https://github.com/riscv/riscv-edk2-platforms/issues/24>
> 
> Mostly I just have to:
> 
>   * reorganize and split the FVs to fit the spec
>   * use the include files to ensure that they contain the correct modules
>   * switch to the MinPlatform PCDs instead of the ones that I currently
>     use (for PreMemRamBase for example)
>   * make sure the test functions to validate the stages are included and run
> 
> The tasks for x86 QEMU/OVMF should be the same. Doesn't look too scary.
> 
> Since there are these test functions, is there a way to test compliance 
> with the spec?
> ------------------------------------------------------------------------
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Daniel 
> Schaefer <daniel.schaefer@hpe.com>
> *Sent:* Tuesday, May 25, 2021 02:59
> *To:* devel@edk2.groups.io <devel@edk2.groups.io>; 
> gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; 
> kaaira7319@gmail.com <kaaira7319@gmail.com>; Ni, Ray <ray.ni@intel.com>; 
> mikuback@linux.microsoft.com <mikuback@linux.microsoft.com>; 
> isaac.w.oram@intel.com <isaac.w.oram@intel.com>
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> *Subject:* Re: 回复: [edk2-devel] Generic MinPlatform
> #
> 
>       * Rather than commenting out things you don’t need in the build,
>         our thinking was to allow some unnecessary building in the
>         interest of reducing porting complexity.  It doesn’t really
>         matter if you don’t need the PciCf8 library as long as it builds
>         fine.
>       * If you need the
>         PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
>         Instead of the
>         PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can
>         just override it in your DSC file after you have included the
>         CoreCommonLib.dsc.  This is to reduce the number of includes
>         that a typical board port needs to deal with correctly, but
>         allow fine tuning and optimization later.
> 
> Hm, you're right. However I added another PCD to exclude things that 
> RISC-V and many other non-x86 platforms don't have: SMM, port-mapped 
> I/O, PC/AT architecture:
> https://github.com/riscv/riscv-edk2-platforms/commit/cbec8681916fe2f4276118198a6d315fd06c75d3 
> <https://github.com/riscv/riscv-edk2-platforms/commit/cbec8681916fe2f4276118198a6d315fd06c75d3>
> 
> Then I have two more issues unrelated to RISC-V: 
> https://github.com/riscv/riscv-edk2-platforms/commit/b68f4587fc28588b4474ff15d43918182c33b4b7 
> <https://github.com/riscv/riscv-edk2-platforms/commit/b68f4587fc28588b4474ff15d43918182c33b4b7>
> And some related to RISC-V: 
> https://github.com/riscv/riscv-edk2-platforms/commit/579705cf46dafc90e4a2bc243e5aa5cd828cb126 
> <https://github.com/riscv/riscv-edk2-platforms/commit/579705cf46dafc90e4a2bc243e5aa5cd828cb126>
> 
> And what's most relevant to Kaaira, the commit to make my QEMU platform 
> use MinPlatform include files:
> https://github.com/riscv/riscv-edk2-platforms/commit/54542812912079d6855e2be4186cb8a6978edac6 
> <https://github.com/riscv/riscv-edk2-platforms/commit/54542812912079d6855e2be4186cb8a6978edac6>
> 
>     Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
> 
> Yes, absolutely. As above, for now I created one for common x86 
> concepts. But there should probably be one for PCI and USB should move 
> to AdvancedFeatures, like you said.
> The other two RISC-V platforms I'm working on don't have PCI and one of 
> them doesn't have USB.
> 
>     Add “Core System Design” includes.  E.G. one for x86, one for QEMU,
>     one for RISKV, etc.  I am not sure how many of these we would need.
> 
> Right, that's a good idea. Kaaira and me can create one for QEMU with 
> all of the virtio drivers.
> And those for x86 and RISC-V wouldn't actually too big, as you can see 
> in my change. RISC-V needs even less special modules.
> 
> Thanks,
> Daniel
> 
> ------------------------------------------------------------------------
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Oram, 
> Isaac W <isaac.w.oram@intel.com>
> *Sent:* Friday, May 21, 2021 11:38
> *To:* Schaefer, Daniel <daniel.schaefer@hpe.com>; devel@edk2.groups.io 
> <devel@edk2.groups.io>; gaoliming@byosoft.com.cn 
> <gaoliming@byosoft.com.cn>; kaaira7319@gmail.com <kaaira7319@gmail.com>; 
> Ni, Ray <ray.ni@intel.com>; mikuback@linux.microsoft.com 
> <mikuback@linux.microsoft.com>
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> I think we should patch first and move to a common location later.
> 
> Looking at some of your changes and comments, I have these comments:
> 
>   * Rather than commenting out things you don’t need in the build, our
>     thinking was to allow some unnecessary building in the interest of
>     reducing porting complexity.  It doesn’t really matter if you don’t
>     need the PciCf8 library as long as it builds fine.
>   * If you need the
>     PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
>     Instead of the
>     PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just
>     override it in your DSC file after you have included the
>     CoreCommonLib.dsc.  This is to reduce the number of includes that a
>     typical board port needs to deal with correctly, but allow fine
>     tuning and optimization later.
>   * Rather than commenting out or adding !if modifications, you can set
>     the feature PCD to false in your DSC file before including the
>     file.  We are allowed to have multiple sections and the tools do a
>     good job of applying them and aggregating them in sensible ways. 
>     For example:
> 
> #!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE
> 
> #
> PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
> 
> #!endif
> 
>       o If you just have:
> 
> [PcdsFeatureFlag]
> 
> #
> 
> # MinPlatform control flags
> 
> #
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE
> 
>    gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE
> 
> …
> 
> !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc
> 
>       o Then you should get the same result you want.
> 
> This is useful feedback and we should think about how we want to enable 
> optimization (stage 7) in a reasonable way. We haven’t gotten that far 
> into the optimization details as we wanted to get the basics worked out, 
> but it might very much make sense to make more of these things 
> controlled by MinPlatform Arch defined feature flags.  Or to move to 
> Advanced Features.  And some things we haven’t cleaned up yet.  We still 
> have USB in common includes, but those drivers should move to an 
> Advanced Feature.  The main thing is we want intelligent default 
> behavior so new board porting people can get productive fast without 
> having to know all these edk2 special features.  Then as they get things 
> working, they can start to take advantage of more edk2 and UEFI 
> capabilities as they learn them.  Eventually hitting an optimization 
> phase where common things can be quickly stripped out if not needed.  I 
> hadn’t thought much about build optimization, but I think that this is 
> reasonable to include in scope.
> 
> Looking at your feedback/challenges, I see a few options:
> 
> ·Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
> 
> ·Add Advanced Features for them
> 
> ·Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one 
> for RISKV, etc.  I am not sure how many of these we would need.
> 
> Thoughts and preferences?  I think that we need to keep in mind KISS for 
> new board ports and new users.
> 
> The checklists should be “Board Porting Activity Checklist” and 
> unfortunately for you both, you are making the first reference 
> QemuOpenBoardPkg and boards and that is a little more involved than 
> making derivatives, which is what those checklists are going to help the 
> most.
> 
> Regards,
> Isaac
> 
> *From:*Schaefer, Daniel <daniel.schaefer@hpe.com>
> *Sent:* Thursday, May 20, 2021 7:27 PM
> *To:* Oram, Isaac W <isaac.w.oram@intel.com>; devel@edk2.groups.io; 
> gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray 
> <ray.ni@intel.com>; mikuback@linux.microsoft.com
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> Thanks for the answers, that's very helpful, guys!
> 
> I've started to replace some of my DSC and FDF with the include files 
> mentioned by Michael.
> 
> Since RISC-V doesn't have I/O registers, SMM and some other things, I 
> had to make some changes but not too many.
> 
> Maybe for Qemu there would have be some more non-Intel changes.
> 
> Would you accept patches to make it more arch agnostic? Or should we 
> first move it out of the Intel directory?
> 
> Sorry for hijacking your thread Kaaira, but I hope this discussion would 
> also be helpful for you 🙂
> 
> Just like you, I'm trying to convert a QEMU platform to MinPlatform. 
> (And then the other RISC-V platforms)
> 
> If you want to have a look, you can check out my progress here: 
> https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions 
> <https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions>
> 
> My plan is:
> 
>  1. Make DSC and FDF smaller by including generic files (WIP)
>  2. Try to take advantage of "AdvancedFeatures"
>  3. Reformat the FD into the FVs mandated by the MinPlatform spec
>  4. Check the detailed requirements of each stage (e.g. required
>     functions, build files, ...)
> 
> I see that each stage in the MinPlatform spec has a checklist. They 
> don't look like checklist but rather steps to achieve a certain state 
> but that's also ok.
> 
> See: 
> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist 
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_stage_1_minimum_debug/311_stage_enabling_checklist>
> 
> Thanks,
> 
> Daniel
> 
> ------------------------------------------------------------------------
> 
> *From:*devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki 
> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>
> *Sent:* Friday, May 21, 2021 00:32
> *To:* Oram, Isaac W <isaac.w.oram@intel.com 
> <mailto:isaac.w.oram@intel.com>>; devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>; Schaefer, Daniel 
> <daniel.schaefer@hpe.com <mailto:daniel.schaefer@hpe.com>>; 
> gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn><gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn>>; kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com><kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com>>; Ni, Ray <ray.ni@intel.com 
> <mailto:ray.ni@intel.com>>
> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
> 
> Daniel,
> 
> You will specifically find attempts to consolidate common libraries and
> modules in DSC and FDF files that can be included into a board package
> here -
> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include 
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include>. 
> 
> Files are split such that they can be included in the corresponding
> section in the board package DSC/FDF file. Note there are some mixed
> opinions I've encountered in the industry on the complexity trade off
> associated with includes in DSC and FDF files.
> 
> But as Isaac mentioned, while MinPlatform is designed to support
> multiple architectures, it has only be enabled on Intel platforms,
> therefore, you should expect to encounter some problems enabling a
> different architecture but identifying and/or resolving those would be
> very valuable.
> 
> As you are exploring how to port a platform to MinPlatform I also
> recommend familiarizing yourself the concept of advanced features
> described here -
> https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md 
> <https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md>. 
> 
> You might find your board package is relatively simpler than the
> original platform package after accounting for advanced features being
> separated out.
> 
> Thanks,
> Michael
> 
> 
> On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
>> Daniel,
>> 
>> The MinPlatform spec was intended to be architecture and product 
>> independent for a “mainstream” set of products.  It is intended to
>> constrain some of the nearly unlimited extensibility and flexibility of 
>> UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base 
>> design should work for 80% of designs, but some will need to leverage 
>> full edk2 and UEFI specification flexibility.  I think that a basic QEMU 
>> kind of port would fit in 80% target.  I would ultimately like to see a 
>> progression of edk2 use that starts with QEMU then moves more seamlessly 
>> to open designs and then proprietary product designs.  MinPlatform 
>> consistency is hoped to help that developer ramp into system firmware 
>> productivity.
>> 
>> We have only seen MinPlatform applied to Intel based products so far.
>> Which is why we are not rushing to move the spec from a 0.7 “broad
>> feedback” state to a 1.0 “initially complete” state.  Like edk2,
>> MinPlatformPkg and BoardModulePkg content is intended to support 
>> multiple silicon and product architectures and we will happily promote 
>> content out of “Intel” scope when that is an accurate reflection of use
>> and not just wishful thinking.  While 100% of uses are Intel scope, it 
>> makes sense to land in the Intel part of edk2-platforms repo.  Similar 
>> logic applies to Features/Intel content, though more there may have ties 
>> to Intel specific product features.
>> 
>> The Minimum Platform Arch spec details base requirements for FV layout 
>> (thus enabling more common code to publish FV details), base silicon 
>> policy configuration flow (thus more common PEIM/drivers to gather 
>> config information and reduce board porting to relatively simple 
>> libraries), and such things.  By enabling more common PEIM and drivers, 
>> we hope to see benefits to ease of use and consistent quality. Similar 
>> approaches for the other elements of the spec should help to improve 
>> code sharing.
>> 
>> Anyway, yes, it should be able to help you reduce the copies of “mostly
>> common” code that you encountered and the code and spec are open to
>> welcome the additional use and feedback from additional applications.
>> 
>> Regards,
>> Isaac
>> 
>> *From:*devel@edk2.groups.io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> *On Behalf Of *Daniel
>> Schaefer
>> *Sent:* Wednesday, May 19, 2021 8:40 PM
>> *To:* devel@edk2.groups.io <mailto:devel@edk2.groups.io>; 
> gaoliming@byosoft.com.cn <mailto:gaoliming@byosoft.com.cn>;
>> kaaira7319@gmail.com <mailto:kaaira7319@gmail.com>; Ni, Ray 
> <ray.ni@intel.com <mailto:ray.ni@intel.com>>;
>> mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>
>> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>> 
>> Hi,
>> 
>> that sounds like a great project!
>> 
>> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64 
>> generic QEMU virt machine.
>> 
>> I don't like how much of my DSC and FDF file has modules that pretty 
>> much all platforms should have.
>> 
>> MinPlatform would help reduce that, right?
>> 
>> Is MinPlatform flexible enough to account for non-X64 platforms?
>> 
>> If so, then I think Kaaira and I could collaborate.
>> 
>> Cheers,
>> Daniel
>> 
>> ------------------------------------------------------------------------
>> 
>> *From:*devel@edk2.groups.io 
>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>> on behalf of Michael Kubacki
>> <mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>>
>> *Sent:* Thursday, May 20, 2021 02:57
>> *To:* devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>>; gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn>
>> <mailto:gaoliming@byosoft.com.cn 
> <mailto:gaoliming@byosoft.com.cn>><gaoliming@byosoft.com.cn
> <mailto:gaoliming@byosoft.com.cn%20%0b>> 
> <mailto:gaoliming@byosoft.com.cn <mailto:gaoliming@byosoft.com.cn>>>; 
> kaaira7319@gmail.com <mailto:kaaira7319@gmail.com>
>> <mailto:kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com>><kaaira7319@gmail.com
> <mailto:kaaira7319@gmail.com%20%0b>> <mailto:kaaira7319@gmail.com 
> <mailto:kaaira7319@gmail.com>>>; 'Ray Ni' <ray.ni@intel.com
> <mailto:ray.ni@intel.com%20%0b>> <mailto:ray.ni@intel.com 
> <mailto:ray.ni@intel.com>>>
>> *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>> 
>> I also wanted to add that I will be setting up weekly video calls
>> including Ray that we can use to supplement mailing list communication.
>> 
>> I suggest the primary communication mechanism be the mailing list and we
>> use those calls for clarification, detailed project planning, and topics
>> not directly relevant to the list.
>> 
>> Regards,
>> Michael
>> 
>> On 5/19/2021 10:29 AM, Michael Kubacki wrote:
>>> Thanks Liming.
>>> 
>>> Hi Kaaira,
>>> 
>>> Welcome! You can contact me at mikuback@linux.microsoft.com 
> <mailto:mikuback@linux.microsoft.com><mailto:mikuback@linux.microsoft.com <mailto:mikuback@linux.microsoft.com>>. 
> You
>> will
>>> sometimes see my email as michael.kubacki@microsoft.com 
> <mailto:michael.kubacki@microsoft.com><mailto:michael.kubacki@microsoft.com 
> <mailto:michael.kubacki@microsoft.com>>and
>> that is fine
>>> to use for communication though I tend to not use it on the mailing list 
>>> due to way the mail server manipulates plaintext email.
>>> 
>>> GENERIC RESOURCES
>>> 
>>> I'm sharing some general resources in case you are not already familiar 
>>> with them:
>>> 
>>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/wiki 
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
>> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki 
> <https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>>
>>> 
>>> This one is good for topics like UEFI overview, EDK II concepts, and 
>>> Minimum Platform.
>>> 
>>> In particular for your project, I recommend looking through the 
>>> MinPlatform training - 
>>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf 
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
>> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf 
> <https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>>
>>> 
>>> 
>>> 2. 
>>> https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html 
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
>> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html 
> <https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>>
>>> 
>>> 
>>> These whitepapers are useful when you need more in depth detail about a 
>>> particular area (like capsule update or work related to the memory map). 
>>> I recommend bookmarking it and keeping it in mind as a reference.
>>> 
>>> 3. https://uefi.org/learning_center/presentationsandvideos/ 
> <https://uefi.org/learning_center/presentationsandvideos/>
>> <https://uefi.org/learning_center/presentationsandvideos/ 
> <https://uefi.org/learning_center/presentationsandvideos/>>
>>> 
>>> Scroll through here if you have some time and see if there's anything 
>>> interesting. To help keep on your project schedule I don't think these 
>>> are as important but there is a lot of interesting material there.
>>> 
>>> Reading through some of the key concepts in Beyond BIOS can be helpful 
>>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at 
>>> https://uefi.org/specifications 
> <https://uefi.org/specifications><https://uefi.org/specifications 
> <https://uefi.org/specifications>>, I
>> believe they are most useful as
>>> references when you are solving specific problems.
>>> 
>>> PROJECT-SPECIFIC RESOURCES
>>> 
>>> Since your project involves creating QEMU board within the Minimum 
>>> Platform architecture, you can start looking into:
>>> 
>>> 1. QEMU - An open source machine emulator
>>> 2. Minimum Platform Architecture - A software architecture to create 
>>> basic platform firmware that can be extended with advanced functionality.
>>> 3. Intel FSP - Try to understand the high-level goals and how FSP 
>>> interfaces with firmware.
>>> 
>>> 1. QEMU - https://www.qemu.org/ <https://www.qemu.org/>  <https://www.qemu.org/ 
> <https://www.qemu.org/>>
>>> 
>>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to 
>>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit 
>>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a 
>>> 64-bit DXE.
>>> 
>>> I suggest you start with the OvmfPkg README - 
>>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
>> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 
> <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>>
>>> 
>>> As an initial step you can try to build an OVMF FW with a 32-bit PEI 
>>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell. 
>>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these 
>>> target architectures.
>>> 
>>> Any time you submit patches to edk2, you can check edk2/maintainers.txt 
>>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
>> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>>for the
>>> appropriate maintainers and reviewers to CC on the patch. As you can 
>>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a 
>>> reviewer. If there are any questions that require deep expertise in QEMU 
>>> or OVMF, we will reach out to them. The Minimum Platform code is 
>>> maintained in the edk2-platforms repository and it has a similar 
>>> maintainers.txt file for its packages - 
>>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>
>> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt 
> <https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>>.
>>> 
>>> I suggest you try sending a very trivial patch for a change in the 
>>> edk2-platforms repository - https://github.com/tianocore/edk2-platforms 
> <https://github.com/tianocore/edk2-platforms>
>> <https://github.com/tianocore/edk2-platforms 
> <https://github.com/tianocore/edk2-platforms>>
>>> to make sure that your git environment is set up properly to format edk2 
>>> patches and your email service can send patches correctly.
>>> 
>>> We can discuss the details about how to set up your environment and what 
>>> to change when you are ready. You can use this page to get started - 
>>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute 
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>
>> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute 
> <https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>>.
>>> 
>>> 2. EDK II Minimum Platform Specification - 
>>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ 
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
>> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ 
> <https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>>
>>> 
>>> For your project, this spec will be very useful. It describes why 
>>> Minimum Platform was created and how it works at a high-level. Like the 
>>> code, this document is open and available to the community. You might 
>>> contribute content here in addition to your code. You can fix any bugs 
>>> or update content in the spec using git patches and the mailing list 
>>> similar to code.
>>> 
>>> 3. Intel FSP - 
>>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html 
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
>> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html 
> <https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>>
>>> 
>>> 
>>> For more information about Intel FSP check out the Intel FSP External 
>>> Architecture Specification in the link above. v2.2 is currently the 
>>> latest version.
>>> 
>>> There is an open source QEMU FSP available here 
>>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>
>> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 
> <https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>>. You will
>>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg 
>>> does not use FSP.
>>> 
>>> Firmware is really best learned hands on. Using the links and background 
>>> info above, I suggest:
>>> 
>>> 1. Read the OvmfPkg readme.
>>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell 
>>> using QEMU.
>>> 3. Reading through the EDK II Minimum Platform Specification to gain a 
>>> high level understanding of Minimum Platform.
>>> 4. Connect what you read to the code in 
>>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel 
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>
>> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel 
> <https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>>.
>>> Focus on higher level pieces like the board initialization library.
>>> 5. Note what each board package is doing. You will find common patterns 
>>> for what a board package needs to implement to make the system boot.
>>> 6. As you read through the code, reference the general resources listed 
>>> above to understand anything not Minimum Platform specific. Part of the 
>>> learning process is knowing which spec to use for different interfaces. 
>>> If you're unsure which spec something is in, feel free to reach out.
>>> 7. While looking through the code in edk2-platforms, think about a patch 
>>> you can send to edk2-platforms for something very trivial such as a bug 
>>> fix or documentation update.
>>> 8. Send the patch and get it reviewed-by the appropriate 
>>> maintainers/reviewers and merged into the master branch.
>>> 9. Read through the code in OvmfPkg. Try to map the work it is doing to 
>>> the board code you reviewed in edk2-platforms.
>>> 10. At this point, you could start outlining major pieces of 
>>> initialization in OVMF and how they might map to a board package. Try to 
>>> identify where the initialization pieces would reside in the board 
>>> package and try to identify challenges that might arise. We will likely 
>>> spend quite a bit of time here before jumping into too much code.
>>> 
>>> I know this is a lot of info. Please don't hesitate to reach out if you 
>>> have any questions and I look forward to working with you.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> On 5/18/2021 6:05 PM, gaoliming wrote:
>>>> Include Michael Kubacki.
>>>>
>>>> Thanks
>>>> Liming
>>>>> -----邮件原件-----
>>>>> 发件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>><devel@edk2.groups.io
> <mailto:devel@edk2.groups.io%20%0b>> <mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>> 代表 KAAIRA
>>>>> GUPTA
>>>>> 发送时间: 2021年5月18日 22:42
>>>>> 收件人: Ray Ni <ray.ni@intel.com <mailto:ray.ni@intel.com 
> <mailto:ray.ni@intel.com>>>;
>> devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io><mailto:devel@edk2.groups.io 
> <mailto:devel@edk2.groups.io>>
>>>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
>>>>>
>>>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
>>>>>> Hey everyone,
>>>>>>
>>>>>> I have been selected as a student developer for the project MinPlatform
>>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
>>>>> Thankyou
>>>>>> for this opportunity. I have been over the major chapters of Beyond 
>>>>>> BIOS
>>>>>> as recommended by Nate DeSimone. I want to get familiar with the code
>>>>>> now to help me undersatnd the community practices and get my hands
>>>>>> dirty. Where should I start? What development environment do I need?
>>>>>> How can I use this community bonding period to give me a better start
>>>>>> for the coding phase?
>>>>>>
>>>>>> How do the mentors want me to connect with them? Can we have a meet
>>>>> to
>>>>>> discuss this project's plan to add more details? This would be very
>>>>>> helpful for me considering I don't have prior experience with EDK2.
>>>>>
>>>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
>>>>> exist anymore. Please let me know how I can contact him.
>>>>>
>>>>>>
>>>>>> Thank you,
>>>>>> Kaaira
>>>>>
>>>>> Thanks,
>>>>> Kaaira
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>>
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
>