Re: 回复: [edk2-devel] Generic MinPlatform
Michael Kubacki
mikuback at linux.microsoft.com
Wed May 26 05:33:50 UTC 2021
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 at edk2.groups.io <devel at edk2.groups.io> on behalf of Daniel
> Schaefer <daniel.schaefer at hpe.com>
> *Sent:* Tuesday, May 25, 2021 02:59
> *To:* devel at edk2.groups.io <devel at edk2.groups.io>;
> gaoliming at byosoft.com.cn <gaoliming at byosoft.com.cn>;
> kaaira7319 at gmail.com <kaaira7319 at gmail.com>; Ni, Ray <ray.ni at intel.com>;
> mikuback at linux.microsoft.com <mikuback at linux.microsoft.com>;
> isaac.w.oram at intel.com <isaac.w.oram at intel.com>
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang at 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 at edk2.groups.io <devel at edk2.groups.io> on behalf of Oram,
> Isaac W <isaac.w.oram at intel.com>
> *Sent:* Friday, May 21, 2021 11:38
> *To:* Schaefer, Daniel <daniel.schaefer at hpe.com>; devel at edk2.groups.io
> <devel at edk2.groups.io>; gaoliming at byosoft.com.cn
> <gaoliming at byosoft.com.cn>; kaaira7319 at gmail.com <kaaira7319 at gmail.com>;
> Ni, Ray <ray.ni at intel.com>; mikuback at linux.microsoft.com
> <mikuback at linux.microsoft.com>
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang at 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 at hpe.com>
> *Sent:* Thursday, May 20, 2021 7:27 PM
> *To:* Oram, Isaac W <isaac.w.oram at intel.com>; devel at edk2.groups.io;
> gaoliming at byosoft.com.cn; kaaira7319 at gmail.com; Ni, Ray
> <ray.ni at intel.com>; mikuback at linux.microsoft.com
> *Cc:* Chang, Abner (HPS SW/FW Technologist) <abner.chang at 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 at edk2.groups.io
> <mailto:devel at edk2.groups.io><devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>> on behalf of Michael Kubacki
> <mikuback at linux.microsoft.com <mailto:mikuback at linux.microsoft.com>>
> *Sent:* Friday, May 21, 2021 00:32
> *To:* Oram, Isaac W <isaac.w.oram at intel.com
> <mailto:isaac.w.oram at intel.com>>; devel at edk2.groups.io
> <mailto:devel at edk2.groups.io><devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>>; Schaefer, Daniel
> <daniel.schaefer at hpe.com <mailto:daniel.schaefer at hpe.com>>;
> gaoliming at byosoft.com.cn
> <mailto:gaoliming at byosoft.com.cn><gaoliming at byosoft.com.cn
> <mailto:gaoliming at byosoft.com.cn>>; kaaira7319 at gmail.com
> <mailto:kaaira7319 at gmail.com><kaaira7319 at gmail.com
> <mailto:kaaira7319 at gmail.com>>; Ni, Ray <ray.ni at intel.com
> <mailto:ray.ni at 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 at edk2.groups.io <devel at edk2.groups.io <mailto:devel at edk2.groups.io>> *On Behalf Of *Daniel
>> Schaefer
>> *Sent:* Wednesday, May 19, 2021 8:40 PM
>> *To:* devel at edk2.groups.io <mailto:devel at edk2.groups.io>;
> gaoliming at byosoft.com.cn <mailto:gaoliming at byosoft.com.cn>;
>> kaaira7319 at gmail.com <mailto:kaaira7319 at gmail.com>; Ni, Ray
> <ray.ni at intel.com <mailto:ray.ni at intel.com>>;
>> mikuback at linux.microsoft.com <mailto:mikuback at 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 at edk2.groups.io
>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>><devel at edk2.groups.io
> <mailto:devel at edk2.groups.io%20%0b>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>>> on behalf of Michael Kubacki
>> <mikuback at linux.microsoft.com <mailto:mikuback at linux.microsoft.com <mailto:mikuback at linux.microsoft.com>>>
>> *Sent:* Thursday, May 20, 2021 02:57
>> *To:* devel at edk2.groups.io <mailto:devel at edk2.groups.io>
>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>><devel at edk2.groups.io
> <mailto:devel at edk2.groups.io%20%0b>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>>>; gaoliming at byosoft.com.cn
> <mailto:gaoliming at byosoft.com.cn>
>> <mailto:gaoliming at byosoft.com.cn
> <mailto:gaoliming at byosoft.com.cn>><gaoliming at byosoft.com.cn
> <mailto:gaoliming at byosoft.com.cn%20%0b>>
> <mailto:gaoliming at byosoft.com.cn <mailto:gaoliming at byosoft.com.cn>>>;
> kaaira7319 at gmail.com <mailto:kaaira7319 at gmail.com>
>> <mailto:kaaira7319 at gmail.com
> <mailto:kaaira7319 at gmail.com>><kaaira7319 at gmail.com
> <mailto:kaaira7319 at gmail.com%20%0b>> <mailto:kaaira7319 at gmail.com
> <mailto:kaaira7319 at gmail.com>>>; 'Ray Ni' <ray.ni at intel.com
> <mailto:ray.ni at intel.com%20%0b>> <mailto:ray.ni at intel.com
> <mailto:ray.ni at 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 at linux.microsoft.com
> <mailto:mikuback at linux.microsoft.com><mailto:mikuback at linux.microsoft.com <mailto:mikuback at linux.microsoft.com>>.
> You
>> will
>>> sometimes see my email as michael.kubacki at microsoft.com
> <mailto:michael.kubacki at microsoft.com><mailto:michael.kubacki at microsoft.com
> <mailto:michael.kubacki at 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 at edk2.groups.io <mailto:devel at edk2.groups.io>
>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>><devel at edk2.groups.io
> <mailto:devel at edk2.groups.io%20%0b>> <mailto:devel at edk2.groups.io
> <mailto:devel at edk2.groups.io>>> 代表 KAAIRA
>>>>> GUPTA
>>>>> 发送时间: 2021年5月18日 22:42
>>>>> 收件人: Ray Ni <ray.ni at intel.com <mailto:ray.ni at intel.com
> <mailto:ray.ni at intel.com>>>;
>> devel at edk2.groups.io
> <mailto:devel at edk2.groups.io><mailto:devel at edk2.groups.io
> <mailto:devel at 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75594): https://edk2.groups.io/g/devel/message/75594
Mute This Topic: https://groups.io/mt/83063724/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list