From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web12.3533.1622007230573941318 for ; Tue, 25 May 2021 22:33:50 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=YMzxN5fQ; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: mikuback@linux.microsoft.com) Received: from [10.124.238.202] (unknown [167.220.2.74]) by linux.microsoft.com (Postfix) with ESMTPSA id C074020B7178; Tue, 25 May 2021 22:33:49 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C074020B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1622007229; bh=40AyvaVQflkY/CagtsszMwV4Ei+c5DwznN+mSxKviAw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YMzxN5fQVqln73rnxmYXjZrf8qHVYdSN5MKLuIPgvVnn6DOPzkPIiekCpujHW1JnM DsJugo6gszcaPtp6aZAi1ZjoWMFggzWsqol/g5wORhxGwG9cDDsC7xcyxR85ICPc3J 2r2rY2ghEidcYr2vPTkePrF4rvGMV9jGNhSymzaI= Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIEdlbmVyaWMgTWluUGxhdGZvcm0=?= To: devel@edk2.groups.io, daniel.schaefer@hpe.com, "gaoliming@byosoft.com.cn" , "kaaira7319@gmail.com" , "Ni, Ray" , "isaac.w.oram@intel.com" Cc: "Chang, Abner (HPS SW/FW Technologist)" References: <20210518143156.GA24025@kaaira-HP-Pavilion-Notebook> <20210518144155.GA25679@kaaira-HP-Pavilion-Notebook> <000001d74c4b$1ae82a80$50b87f80$@byosoft.com.cn> <2162525c-4e35-0c09-4594-ecbfbc740dcc@linux.microsoft.com> <276316c8-9355-2a6d-3786-ca743e1e772d@linux.microsoft.com> <6b42f62c-9f91-7310-4156-530da5c49012@linux.microsoft.com> <168215E7E28C9D49.19255@groups.io> From: "Michael Kubacki" Message-ID: Date: Tue, 25 May 2021 22:33:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Did you find the TestPointDumpApp? https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/Min= PlatformPkg/Test/TestPointDumpApp gEfiAdapterInformationProtocolGuid is used and there is a test-point=20 specific adapter information type. FeaturesImplemented can be compared=20 with FeaturesVerified to programmatically check individual results. I don't believe the current test points alone cover full compliance with= =20 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= =20 > list: https://github.com/riscv/riscv-edk2-platforms/issues/24=20 > >=20 > Mostly I just have to: >=20 > * reorganize and split the FVs to fit the spec > * use the include files to ensure that they contain the correct module= s > * 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 >=20 > The tasks for x86 QEMU/OVMF should be the same. Doesn't look too scary. >=20 > Since there are these test functions, is there a way to test compliance= =20 > with the spec? > ------------------------------------------------------------------------ > *From:* devel@edk2.groups.io on behalf of Daniel= =20 > Schaefer > *Sent:* Tuesday, May 25, 2021 02:59 > *To:* devel@edk2.groups.io ;=20 > gaoliming@byosoft.com.cn ;=20 > kaaira7319@gmail.com ; Ni, Ray ;= = =20 > mikuback@linux.microsoft.com ;=20 > isaac.w.oram@intel.com > *Cc:* Chang, Abner (HPS SW/FW Technologist) > *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] Generic MinPlatform > # >=20 > * Rather than commenting out things you don=E2=80=99t need in the = build, > our thinking was to allow some unnecessary building in the > interest of reducing porting complexity.=C2=A0 It doesn=E2=80=99= t really > matter if you don=E2=80=99t need the PciCf8 library as long as i= t 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.=C2=A0 This is to reduce the number of include= s > that a typical board port needs to deal with correctly, but > allow fine tuning and optimization later. >=20 > Hm, you're right. However I added another PCD to exclude things that=20 > RISC-V and many other non-x86 platforms don't have: SMM, port-mapped=20 > I/O, PC/AT architecture: > https://github.com/riscv/riscv-edk2-platforms/commit/cbec8681916fe2f4276= 118198a6d315fd06c75d3=20 > >=20 > Then I have two more issues unrelated to RISC-V:=20 > https://github.com/riscv/riscv-edk2-platforms/commit/b68f4587fc28588b447= 4ff15d43918182c33b4b7=20 > > And some related to RISC-V:=20 > https://github.com/riscv/riscv-edk2-platforms/commit/579705cf46dafc90e4a= 2bc243e5aa5cd828cb126=20 > >=20 > And what's most relevant to Kaaira, the commit to make my QEMU platform= =20 > use MinPlatform include files: > https://github.com/riscv/riscv-edk2-platforms/commit/54542812912079d6855= e2be4186cb8a6978edac6=20 > >=20 > Add more MinPlatform Arch defined feature flags for PCI, SMM, etc. >=20 > Yes, absolutely. As above, for now I created one for common x86=20 > concepts. But there should probably be one for PCI and USB should move= =20 > to AdvancedFeatures, like you said. > The other two RISC-V platforms I'm working on don't have PCI and one of= =20 > them doesn't have USB. >=20 > Add =E2=80=9CCore System Design=E2=80=9D includes. =C2=A0E.G. one fo= r x86, one for QEMU, > one for RISKV, etc. =C2=A0I am not sure how many of these we would n= eed. >=20 > Right, that's a good idea. Kaaira and me can create one for QEMU with=20 > all of the virtio drivers. > And those for x86 and RISC-V wouldn't actually too big, as you can see= =20 > in my change. RISC-V needs even less special modules. >=20 > Thanks, > Daniel >=20 > ------------------------------------------------------------------------ > *From:* devel@edk2.groups.io on behalf of Oram,= =20 > Isaac W > *Sent:* Friday, May 21, 2021 11:38 > *To:* Schaefer, Daniel ; devel@edk2.groups.io= =20 > ; gaoliming@byosoft.com.cn=20 > ; kaaira7319@gmail.com ;= = =20 > Ni, Ray ; mikuback@linux.microsoft.com=20 > > *Cc:* Chang, Abner (HPS SW/FW Technologist) > *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] GSoC 2021 Qemu OpenBoard= Pkg Project >=20 > I think we should patch first and move to a common location later. >=20 > Looking at some of your changes and comments, I have these comments: >=20 > * Rather than commenting out things you don=E2=80=99t need in the buil= d, our > thinking was to allow some unnecessary building in the interest of > reducing porting complexity.=C2=A0 It doesn=E2=80=99t really matter = if you don=E2=80=99t > 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.=C2=A0 This is to reduce the number of includes th= at 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.=C2=A0 We are allowed to have multiple sections and the tools d= o a > good job of applying them and aggregating them in sensible ways.=20 > For example: >=20 > #!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable =3D=3D TRUE >=20 > # > PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.= inf >=20 > #!endif >=20 > o If you just have: >=20 > [PcdsFeatureFlag] >=20 > # >=20 > #=C2=A0MinPlatform=C2=A0control=C2=A0flags >=20 > # >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|FALSE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|FALSE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|FALSE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable=C2=A0= = =C2=A0=C2=A0|FALSE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|FALSE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TR= UE >=20 > =C2=A0=C2=A0gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable=C2=A0=C2= = =A0=C2=A0=C2=A0=C2=A0=C2=A0|FALSE >=20 > =E2=80=A6 >=20 > !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc >=20 > o Then you should get the same result you want. >=20 > This is useful feedback and we should think about how we want to enable= =20 > optimization (stage 7) in a reasonable way. We haven=E2=80=99t gotten th= at far=20 > into the optimization details as we wanted to get the basics worked out,= = =20 > but it might very much make sense to make more of these things=20 > controlled by MinPlatform Arch defined feature flags.=C2=A0 Or to move t= o=20 > Advanced Features.=C2=A0 And some things we haven=E2=80=99t cleaned up y= et.=C2=A0 We still=20 > have USB in common includes, but those drivers should move to an=20 > Advanced Feature.=C2=A0 The main thing is we want intelligent default=20 > behavior so new board porting people can get productive fast without=20 > having to know all these edk2 special features.=C2=A0 Then as they get t= hings=20 > working, they can start to take advantage of more edk2 and UEFI=20 > capabilities as they learn them.=C2=A0 Eventually hitting an optimizatio= n=20 > phase where common things can be quickly stripped out if not needed.=C2= =A0 I=20 > hadn=E2=80=99t thought much about build optimization, but I think that t= his is=20 > reasonable to include in scope. >=20 > Looking at your feedback/challenges, I see a few options: >=20 > =C2=B7Add more MinPlatform Arch defined feature flags for PCI, SMM, etc. >=20 > =C2=B7Add Advanced Features for them >=20 > =C2=B7Add =E2=80=9CCore System Design=E2=80=9D includes.=C2=A0 E.G. one = for x86, one for QEMU, one=20 > for RISKV, etc.=C2=A0 I am not sure how many of these we would need. >=20 > Thoughts and preferences?=C2=A0 I think that we need to keep in mind KIS= S for=20 > new board ports and new users. >=20 > The checklists should be =E2=80=9CBoard Porting Activity Checklist=E2=80= = =9D and=20 > unfortunately for you both, you are making the first reference=20 > QemuOpenBoardPkg and boards and that is a little more involved than=20 > making derivatives, which is what those checklists are going to help the= = =20 > most. >=20 > Regards, > Isaac >=20 > *From:*Schaefer, Daniel > *Sent:* Thursday, May 20, 2021 7:27 PM > *To:* Oram, Isaac W ; devel@edk2.groups.io;=20 > gaoliming@byosoft.com.cn; kaaira7319@gmail.com; Ni, Ray=20 > ; mikuback@linux.microsoft.com > *Cc:* Chang, Abner (HPS SW/FW Technologist) > *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] GSoC 2021 Qemu OpenBoard= Pkg Project >=20 > Thanks for the answers, that's very helpful, guys! >=20 > I've started to replace some of my DSC and FDF with the include files=20 > mentioned by Michael. >=20 > Since RISC-V doesn't have I/O registers, SMM and some other things, I=20 > had to make some changes but not too many. >=20 > Maybe for Qemu there would have be some more non-Intel changes. >=20 > Would you accept patches to make it more arch agnostic? Or should we=20 > first move it out of the Intel directory? >=20 > Sorry for hijacking your thread Kaaira, but I hope this discussion would= = =20 > also be helpful for you =F0=9F=99=82 >=20 > Just like you, I'm trying to convert a QEMU platform to MinPlatform.=20 > (And then the other RISC-V platforms) >=20 > If you want to have a look, you can check out my progress here:=20 > https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplat= form-gh-actions=20 > >=20 > My plan is: >=20 > 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, ...) >=20 > I see that each stage in the MinPlatform spec has a checklist. They=20 > don't look like checklist but rather steps to achieve a certain state=20 > but that's also ok. >=20 > See:=20 > https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/3_sta= ge_1_minimum_debug/311_stage_enabling_checklist=20 > >=20 > Thanks, >=20 > Daniel >=20 > ------------------------------------------------------------------------ >=20 > *From:*devel@edk2.groups.io=20 > > on behalf of Michael Kubacki=20 > > > *Sent:* Friday, May 21, 2021 00:32 > *To:* Oram, Isaac W >; devel@edk2.groups.io=20 > >; Schaefer, Daniel=20 > >;=20 > gaoliming@byosoft.com.cn=20 > >; kaaira7319@gmail.com=20 > >; Ni, Ray > > *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] GSoC 2021 Qemu OpenBoard= Pkg Project >=20 > Daniel, >=20 > 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/M= inPlatformPkg/Include=20 > .=20 >=20 > 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. >=20 > 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. >=20 > 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/R= eadme.md=20 > .=20 >=20 > You might find your board package is relatively simpler than the > original platform package after accounting for advanced features being > separated out. >=20 > Thanks, > Michael >=20 >=20 > On 5/20/2021 8:05 AM, Oram, Isaac W wrote: >> Daniel, >>=20 >> The MinPlatform spec was intended to be architecture and product=20 >> independent for a =E2=80=9Cmainstream=E2=80=9D set of products.=C2=A0 I= t is intended to >> constrain some of the nearly unlimited extensibility and flexibility of= = =20 >> UEFI specs and edk2 codebase.=C2=A0 We took an 80/20 kind of approach.= =C2=A0 Base=20 >> design should work for 80% of designs, but some will need to leverage= =20 >> full edk2 and UEFI specification flexibility.=C2=A0 I think that a basi= c QEMU=20 >> kind of port would fit in 80% target.=C2=A0 I would ultimately like to = see a=20 >> progression of edk2 use that starts with QEMU then moves more seamlessl= y=20 >> to open designs and then proprietary product designs.=C2=A0 MinPlatform= = =20 >> consistency is hoped to help that developer ramp into system firmware= =20 >> productivity. >>=20 >> 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 =E2=80=9Cbr= oad >> feedback=E2=80=9D state to a 1.0 =E2=80=9Cinitially complete=E2=80=9D s= tate.=C2=A0 Like edk2, >> MinPlatformPkg and BoardModulePkg content is intended to support=20 >> multiple silicon and product architectures and we will happily promote= =20 >> content out of =E2=80=9CIntel=E2=80=9D scope when that is an accurate r= eflection of use >> and not just wishful thinking.=C2=A0 While 100% of uses are Intel scope= , it=20 >> makes sense to land in the Intel part of edk2-platforms repo.=C2=A0 Sim= ilar=20 >> logic applies to Features/Intel content, though more there may have tie= s=20 >> to Intel specific product features. >>=20 >> The Minimum Platform Arch spec details base requirements for FV layout= =20 >> (thus enabling more common code to publish FV details), base silicon=20 >> policy configuration flow (thus more common PEIM/drivers to gather=20 >> config information and reduce board porting to relatively simple=20 >> libraries), and such things.=C2=A0 By enabling more common PEIM and dri= vers,=20 >> we hope to see benefits to ease of use and consistent quality. Similar= =20 >> approaches for the other elements of the spec should help to improve=20 >> code sharing. >>=20 >> Anyway, yes, it should be able to help you reduce the copies of =E2=80= =9Cmostly >> common=E2=80=9D code that you encountered and the code and spec are ope= n to >> welcome the additional use and feedback from additional applications. >>=20 >> Regards, >> Isaac >>=20 >> *From:*devel@edk2.groups.io > *On Behalf Of *Daniel >> Schaefer >> *Sent:* Wednesday, May 19, 2021 8:40 PM >> *To:* devel@edk2.groups.io ;=20 > gaoliming@byosoft.com.cn ; >> kaaira7319@gmail.com ; Ni, Ray=20 > >; >> mikuback@linux.microsoft.com >> *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] GSoC 2021 Qemu OpenBoar= dPkg Project >>=20 >> Hi, >>=20 >> that sounds like a great project! >>=20 >> I'm currently trying to create an equivalent of OvmfPkg for the RISCV64= = =20 >> generic QEMU virt machine. >>=20 >> I don't like how much of my DSC and FDF file has modules that pretty=20 >> much all platforms should have. >>=20 >> MinPlatform would help reduce that, right? >>=20 >> Is MinPlatform flexible enough to account for non-X64 platforms? >>=20 >> If so, then I think Kaaira and I could collaborate. >>=20 >> Cheers, >> Daniel >>=20 >> -----------------------------------------------------------------------= - >>=20 >> *From:*devel@edk2.groups.io=20 >> > > >> on behalf of Michael Kubacki >> >> >> *Sent:* Thursday, May 20, 2021 02:57 >> *To:* devel@edk2.groups.io >> > > >>; gaoliming@byosoft.com.cn=20 > >> > >=20 > >>;=20 > kaaira7319@gmail.com >> > > >>; 'Ray Ni' > >> >> *Subject:* Re: =E5=9B=9E=E5=A4=8D: [edk2-devel] GSoC 2021 Qemu OpenBoar= dPkg Project >>=20 >> 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. >>=20 >> I suggest the primary communication mechanism be the mailing list and w= e >> use those calls for clarification, detailed project planning, and topic= s >> not directly relevant to the list. >>=20 >> Regards, >> Michael >>=20 >> On 5/19/2021 10:29 AM, Michael Kubacki wrote: >>> Thanks Liming. >>>=20 >>> Hi Kaaira, >>>=20 >>> Welcome! You can contact me at mikuback@linux.microsoft.com=20 > >.=20 > You >> will >>> sometimes see my email as michael.kubacki@microsoft.com=20 > >and >> that is fine >>> to use for communication though I tend to not use it on the mailing li= st=20 >>> due to way the mail server manipulates plaintext email. >>>=20 >>> GENERIC RESOURCES >>>=20 >>> I'm sharing some general resources in case you are not already familia= r=20 >>> with them: >>>=20 >>> 1. https://github.com/tianocore-training/Tianocore_Training_Contents/w= iki=20 > >> = > >>>=20 >>> This one is good for topics like UEFI overview, EDK II concepts, and= =20 >>> Minimum Platform. >>>=20 >>> In particular for your project, I recommend looking through the=20 >>> MinPlatform training -=20 >>> https://github.com/tianocore-training/Presentation_FW/blob/master/FW/P= resentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf=20 > >> > >>>=20 >>>=20 >>> 2.=20 >>> https://software.intel.com/content/www/us/en/develop/articles/unified-= extensible-firmware-interface.html=20 > >> > >>>=20 >>>=20 >>> These whitepapers are useful when you need more in depth detail about = a=20 >>> particular area (like capsule update or work related to the memory map= ).=20 >>> I recommend bookmarking it and keeping it in mind as a reference. >>>=20 >>> 3. https://uefi.org/learning_center/presentationsandvideos/=20 > >> > >>>=20 >>> Scroll through here if you have some time and see if there's anything= =20 >>> interesting. To help keep on your project schedule I don't think these= = =20 >>> are as important but there is a lot of interesting material there. >>>=20 >>> Reading through some of the key concepts in Beyond BIOS can be helpful= = =20 >>> and like the UEFI, ACPI, and PI (Platform Initialization) specs at=20 >>> https://uefi.org/specifications=20 > >, I >> believe they are most useful as >>> references when you are solving specific problems. >>>=20 >>> PROJECT-SPECIFIC RESOURCES >>>=20 >>> Since your project involves creating QEMU board within the Minimum=20 >>> Platform architecture, you can start looking into: >>>=20 >>> 1. QEMU - An open source machine emulator >>> 2. Minimum Platform Architecture - A software architecture to create= =20 >>> basic platform firmware that can be extended with advanced functionali= ty. >>> 3. Intel FSP - Try to understand the high-level goals and how FSP=20 >>> interfaces with firmware. >>>=20 >>> 1. QEMU - https://www.qemu.org/ =C2=A0 > >>>=20 >>> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to= = =20 >>> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit= =20 >>> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a=20 >>> 64-bit DXE. >>>=20 >>> I suggest you start with the OvmfPkg README -=20 >>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/README=20 > >> > >>>=20 >>> As an initial step you can try to build an OVMF FW with a 32-bit PEI= =20 >>> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.=20 >>> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these= =20 >>> target architectures. >>>=20 >>> Any time you submit patches to edk2, you can check edk2/maintainers.tx= t=20 >>> - https://github.com/tianocore/edk2/blob/master/Maintainers.txt=20 > >> >for the >>> appropriate maintainers and reviewers to CC on the patch. As you can= =20 >>> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a=20 >>> reviewer. If there are any questions that require deep expertise in QE= MU=20 >>> or OVMF, we will reach out to them. The Minimum Platform code is=20 >>> maintained in the edk2-platforms repository and it has a similar=20 >>> maintainers.txt file for its packages -=20 >>> https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.tx= t=20 > >> >. >>>=20 >>> I suggest you try sending a very trivial patch for a change in the=20 >>> edk2-platforms repository - https://github.com/tianocore/edk2-platform= s=20 > >> > >>> to make sure that your git environment is set up properly to format ed= k2=20 >>> patches and your email service can send patches correctly. >>>=20 >>> We can discuss the details about how to set up your environment and wh= at=20 >>> to change when you are ready. You can use this page to get started -= =20 >>> https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribut= e=20 > >> >. >>>=20 >>> 2. EDK II Minimum Platform Specification -=20 >>> https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/=20 > >> > >>>=20 >>> For your project, this spec will be very useful. It describes why=20 >>> Minimum Platform was created and how it works at a high-level. Like th= e=20 >>> code, this document is open and available to the community. You might= =20 >>> contribute content here in addition to your code. You can fix any bugs= = =20 >>> or update content in the spec using git patches and the mailing list= =20 >>> similar to code. >>>=20 >>> 3. Intel FSP -=20 >>> https://www.intel.com/content/www/us/en/intelligent-systems/intel-firm= ware-support-package/intel-fsp-overview.html=20 > >> > >>>=20 >>>=20 >>> For more information about Intel FSP check out the Intel FSP External= =20 >>> Architecture Specification in the link above. v2.2 is currently the=20 >>> latest version. >>>=20 >>> There is an open source QEMU FSP available here=20 >>> https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64=20 > >> >. You wil= l >>> find the existing Minimum Platform boards use Intel FSP while OvmfPkg= =20 >>> does not use FSP. >>>=20 >>> Firmware is really best learned hands on. Using the links and backgrou= nd=20 >>> info above, I suggest: >>>=20 >>> 1. Read the OvmfPkg readme. >>> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell= =20 >>> using QEMU. >>> 3. Reading through the EDK II Minimum Platform Specification to gain a= = =20 >>> high level understanding of Minimum Platform. >>> 4. Connect what you read to the code in=20 >>> https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel= = =20 > >> = >. >>> Focus on higher level pieces like the board initialization library. >>> 5. Note what each board package is doing. You will find common pattern= s=20 >>> for what a board package needs to implement to make the system boot. >>> 6. As you read through the code, reference the general resources liste= d=20 >>> above to understand anything not Minimum Platform specific. Part of th= e=20 >>> learning process is knowing which spec to use for different interfaces= .=20 >>> 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 pat= ch=20 >>> you can send to edk2-platforms for something very trivial such as a bu= g=20 >>> fix or documentation update. >>> 8. Send the patch and get it reviewed-by the appropriate=20 >>> maintainers/reviewers and merged into the master branch. >>> 9. Read through the code in OvmfPkg. Try to map the work it is doing t= o=20 >>> the board code you reviewed in edk2-platforms. >>> 10. At this point, you could start outlining major pieces of=20 >>> initialization in OVMF and how they might map to a board package. Try = to=20 >>> identify where the initialization pieces would reside in the board=20 >>> package and try to identify challenges that might arise. We will likel= y=20 >>> spend quite a bit of time here before jumping into too much code. >>>=20 >>> I know this is a lot of info. Please don't hesitate to reach out if yo= u=20 >>> have any questions and I look forward to working with you. >>>=20 >>> Regards, >>> Michael >>>=20 >>> On 5/18/2021 6:05 PM, gaoliming wrote: >>>> Include Michael Kubacki. >>>> >>>> Thanks >>>> Liming >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: devel@edk2.groups.io >> > > >> =E4=BB=A3=E8=A1=A8 KAAIRA >>>>> GUPTA >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B45=E6=9C=8818=E6= =97=A5 22:42 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ray Ni >>; >> devel@edk2.groups.io=20 > > >>>>> =E4=B8=BB=E9=A2=98: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Pro= ject >>>>> >>>>> 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 MinPlat= form >>>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki. >>>>> Thankyou >>>>>> for this opportunity. I have been over the major chapters of Beyond= = =20 >>>>>> BIOS >>>>>> as recommended by Nate DeSimone. I want to get familiar with the co= de >>>>>> 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 sta= rt >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>>=20 >>>> >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20