> On May 12, 2016, at 1:46 AM, Chang, Abner (HPS SW/FW Technologist) > <[email protected]> wrote: > > Hi Andrew, > Yes. I get the same messages from Mark and Dong to work on a staging branch > for RISC-V as this is a public branch. I will work on branch first and then > Dong will submit the ECRs. > Regards to a driver which provides the version of RISC-V implementation, I > think OSs/softwares can recognize this by checking the EFI spec version from > the system table. Says UEFI spec 2.6 is the pre-UEFI spec RISC-V UEFI system > if RISC-V processor binding is published in UEFI spec 2.7. This works?
I was being paranoid about the version, as some one could merge the wrong thing and mess it up. It is a public repo so it can be cloned by others. If the Cpu DXE driver published the version protocol then it takes a git commit to remove it and it is less likely to get broken. Thanks, Andrew Fish > Thanks > Abner > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, May 12, 2016 5:46 AM > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]> > Cc: Jordan Justen <[email protected]>; Yao, Jiewen > <[email protected]>; [email protected]; Mike Kinney > <[email protected]>; Gao, Liming <[email protected]>; Mangefeste, > Tony <[email protected]> > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > >> On May 9, 2016, at 11:24 AM, Mangefeste, Tony <[email protected]> >> wrote: >> >> Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, >> and perhaps into a platform branch or staging branch (depending on a number >> of factors). >> >> Abner, run this through the PIWG as you stated, that's external to our >> Tianocore community. He can at least stage the code somewhere, so that the >> community can use the code, play with it, and give him feedback. >> > > Abner, > > I started a conversation with Mike Kinney and Leif Lindholm about how we > should handle RISC-V. A staging branch (you are adding an new CPU binding) or > a platform branch (you need one to test the new CPU) is a good place to > start. If having the RISC-V port in the branch becomes an issue we can > discuss promoting it to master. It is a given we will push the RISC-V port to > master when the binding shows up in a UEFI spec, but we don't want UEFI Spec > getting published to block progress on other open source projects so we are > willing to try and do the right thing for the broader open source community > if needed. > > One of the main reasons for the UEFI spec writing black out period is to > prevent vendors form rushing to market with incompatible implementations. > Given this it would be useful for any code in your branch that touches > current edk2 components to have comments documenting the experimental > processor binding (fell free to chose better terminology). After the binding > gets added to the UEFI Spec the comments can be updated to reference the UEFI > spec version they conform to. > > I was also thinking it would be a good idea for all the current RISC-V > implementations to publish a protocol that documents the version of the > implementation. An OS for example could figure out this is the pre UEFI spec > version of RISC-V based on knowing the protocol exists. I assume the versions > in this protocol could be RISC-V spec versions, and/or other versions that > make sense for the RISC-V EFI project. The goal is to make it discoverable by > software that this is a pre-UEFI Spec RISC-V UEFI system. > > Thanks, > > Andrew Fish > >> Good discussion. >> >>> -----Original Message----- >>> From: edk2-devel [mailto:[email protected]] On Behalf >>> Of Jordan Justen >>> Sent: Monday, May 9, 2016 10:46 AM >>> To: Yao, Jiewen <[email protected]>; Chang, Abner (HPS SW/FW >>> Technologist) <[email protected]>; [email protected] >>> Cc: Kinney, Michael D <[email protected]>; Gao, Liming >>> <[email protected]> >>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>> DxeIpl. >>> >>> On 2016-05-09 08:53:12, Yao, Jiewen wrote: >>>> Jordan >>>> Do you know why we have ArmPkg and ArmPlatformPkg? >>>> >>> >>> One reason is because we don't have a DriversPkg. Another reason is >>> probably because the effort wasn't made to put them into common >>> packages. >>> >>>> If you take a look at that, you will find many Arm specific driver >>>> there, including CpuDxe/CpuPei/BaseMemoryLib/ >>>> PeiServicesTablePointerLib/etc... >>>> >>> >>> Should we create a package for IA32 and X64 to do the same? I think >>> instead we put the IA32/X64 modules in other locations, and I think that >>> made sense. >>> If it made sense for IA32 and X64, then it should make sense for >>> other architectures as well. >>> >>>> I do not think it is bad idea to have RiscVPkg, when we are not >>>> clear on where to put it. >>>> >>> >>> So this is the place to dump things that we don't know where else to >>> put them? That doesn't inspire too much confidence. :) >>> >>> I agree that it might be needed, but can we try to minimize it? >>> >>> -Jordan >>> >>>> >>>>> -----Original Message----- >>>>> From: Justen, Jordan L >>>>> Sent: Monday, May 9, 2016 11:46 PM >>>>> To: Yao, Jiewen <[email protected]>; Chang, Abner (HPS SW/FW >>>>> Technologist) <[email protected]>; [email protected] >>>>> Cc: Gao, Liming <[email protected]> >>>>> Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>> DxeIpl. >>>>> >>>>> On 2016-05-09 08:12:20, Yao, Jiewen wrote: >>>>>> Thank Abner. >>>>>> For RiscVPkg, my personally feeling is that it should stick to >>>>>> RiscV architecture, like ArmPkg. >>>>>> >>>>> >>>>> I don't agree. Why don't we have an X64Pkg? I think it is because >>>>> we've defined good locations already for most modules, and many of >>>>> those modules already support multiple architectures. >>>>> >>>>> Can't the first try be to see if we can get by without adding new >>>>> architecture specific packages? >>>>> >>>>>> Below module seems to be software concept only. They are >>>>>> independent to RISV-V architecture, right? >>>>>> I am not sure if it is proper to put to RiscVPkg. >>>>>> >>>>>>> RiscVPkg/Universal/Logo/Logo.uni | Bin 0 -> >>>>> 1948 bytes >>>>>>> RiscVPkg/Universal/Logo/LogoExtra.uni | Bin 0 -> >>>>> 1342 bytes >>>>>>> RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp | Bin 0 -> >>>>> 12446 bytes >>>>>>> RiscVPkg/Universal/Logo/RiscvUefiLogo.inf | 34 + >>>>>>> RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.c | 107 +++ >>>>>>> RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.h | 32 + >>>>>>> .../Universal/RiscvBadgingDxe/RiscvBadgingDxe.inf | 54 ++ >>>>>> >>>>>> Maybe we can put to a RiscV platform pkg? >>>>>> >>>>> >>>>> I think it would be better to add the logo to a common location >>>>> like, perhaps MdeModulePkg/Universal/Logo/RiscV. >>>>> >>>>> Actually, I don't think the new logo is needed. We don't have >>>>> architecture specific logos in other cases, and I don't think it is >>>>> needed here. >>>>> >>>>> -Jordan >>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: edk2-devel [mailto:[email protected]] On >>>>>>> Behalf >>>>> Of >>>>>>> Chang, Abner (HPS SW/FW Technologist) >>>>>>> Sent: Monday, May 9, 2016 10:10 PM >>>>>>> To: Justen, Jordan L <[email protected]>; >>>>> [email protected] >>>>>>> Cc: Yao, Jiewen <[email protected]>; Gao, Liming >>>>>>> <[email protected]> >>>>>>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>>>> DxeIpl. >>>>>>> >>>>>>> Hi Jordan, >>>>>>> I will send out another draft version of patches which address >>>>>>> all >>>>> comments. >>>>>>> Then upstream RISC-V code to the branch. >>>>>>> Sure, I am pleased to check if there is any reusable modules for >>>>>>> RISC- >>> V. >>>>>>> Thanks >>>>>>> Abner >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jordan Justen [mailto:[email protected]] >>>>>>> Sent: Monday, May 09, 2016 2:25 PM >>>>>>> To: Chang, Abner (HPS SW/FW Technologist) >>> <[email protected]>; >>>>>>> [email protected] >>>>>>> Cc: [email protected]; Yao, Jiewen <[email protected]> >>>>>>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>>>> DxeIpl. >>>>>>> >>>>>>> On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) >>> wrote: >>>>>>>> Hi Jordan, >>>>>>>> The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for >>>>>>>> review. I have been told to upstream RISC-V code first and then >>>>>>>> submit the spec. I will confirm this again. >>>>>>> >>>>>>> You were told to upstream EDK II support before the UEFI spec >>>>> documented >>>>>>> the architecture? Or, maybe to just prepare the EDK II code so it >>>>>>> would be ready for upstream once it is in the spec? >>>>>>> >>>>>>> Maybe EDK II could adopt a new idea of an "unsupported >>>>>>> architecture", >>>>> but >>>>>>> it seems like EDK II might make some mistakes if it doesn't wait >>>>>>> for UEFI >>>>> to >>>>>>> standardize the architecture. For example, what if the calling >>>>>>> convention changes before it makes it into the spec? >>>>>>> >>>>>>> I think Jiewen's idea of edk2-staging is good. But, before that, >>>>>>> it seems >>>>> you >>>>>>> should make another draft version of the patches in fork of EDK >>>>>>> II on >>>>> github. >>>>>>> >>>>>>> In a few cases, I asked if the modules could be added to more >>>>>>> generic locations. How about trying to look over everything in a >>>>>>> RiscV*Pkg, and >>>>> ask >>>>>>> if it could instead live in Mde*Pkg, UefiCpuPkg or OvmfPkg? >>>>>>> (And, hopefully by maximally reusing existing modules with >>>>>>> architecture specific sources as needed...) >>>>>>> >>>>>>> For example, we don't have a X64*Pkg... >>>>>>> >>>>>>> -Jordan >>>>>>> >>>>>>>> Below response to your comments, >>>>>>>>> --- >>>>>>>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 6 +- >>>>>>>>> MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 >>>>>>>>> ++++++++++++++++++++++ >>>>>>>>>>> Is it Riscv64 or RiscV64? >>>>>>>>>>> Like MdePkg, I think MdeModulePkg only upports achitectures >>>>>>>>>>> in >>>>> the >>>>>>> UEFI spec. >>>>>>>> >>>>>>>> This is typo, should be RiscV64. RISC-V arch UEFI spec is ready >>>>>>>> for >>>>> review. >>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> RiscVPkg/Include/RiscV.h | 105 >>>>> +++ >>>>>>>>> .../PeiServicesTablePointer.c | 121 +++ >>>>>>>>> .../PeiServicesTablePointerLib.inf | 46 ++ >>>>>>>>> .../PeiServicesTablePointerLib.uni | Bin 0 -> >>>>> 2520 >>>>>>> bytes >>>>>>>>> >>>>>>>>>>> utf-8. (See other my other email.) >>>>>>>>>>> >>>>>>>>>>> I think this library should live in MdePkg, except MdePkg >>>>>>>>>>> only supports architectures that are in the UEFI spec. >>>>>>>> PeiServerTablePointer lib is very processor depends. PI spec >>>>>>>> changes for >>>>>>> this is ready for review as well. >>>>>>>> >>>>>>>>>>> RiscVPkg, >>>>>>>>>>> This package seems to be mash up of things that possibly >>>>>>>>>>> should be in MdePkg, UefiCpuPkg, a chipset package, and >>>>>>>>>>> possibly platform >>>>>>> packages. >>>>>>>>>>> >>>>>>>> Modules and libraries under RiscVPkg are all processor specific. >>>>>>>> Like >>>>> Timer >>>>>>> is provided by RISC-V processor itself instead of using something >>>>>>> else on platform. ResetVector, Sec, exception and etc. are >>> all the same. >>>>>>>> UefiCpuPkg seems to me still not clean enough for common CPU >>>>> usage. >>>>>>> Like sec and ResetVector, we still have to use the modules from >>>>>>> other processor package. So put RISC-V modules under its own >>>>>>> package is >>>>> mush >>>>>>> clean in my opinion for now. >>>>>>>> >>>>>>>>>>> What is the status of the QEMU port? >>>>>>>>>>> I don't think we should put this upstream into EDK II until >>>>>>>>>>> QEMU has it upstream. Maybe >>>>> https://github.com/tianocore/edk2-platforms >>>>>>>>>>> in a ovmf-riscv branch? >>>>>>>> There is no official QEMU supports RISC-V yet. The QEMU which >>>>> supports >>>>>>> RISC-V QEMU is on RISC-V Github. However, I have another RISC-V >>>>> QEMU >>>>>>> port for PC/AT which uses PCI as the platform bus spec because >>>>>>> RISC-V platform spec is not yet ready. >>>>>>>> The RISC-V QEMU PC/AT port is on my github. The detail is >>>>>>>> mentioned >>>>> in >>>>>>>> the readme file in RiscVVirtPkg. You also can refer to this link >>>>>>>> https://github.com/AbnerChang/RiscVQemuPcat >>>>>>>> >>>>>>>>>>> What would prevent this from living under OvmfPkg? Say >>>>>>>>>>> OvmfPkg/OvmfPkgRiscV64.dsc? >>>>>>>> I think it should be no problem to use OvmfPkg as common >>>>>>> processor/platform emulator. Just you still can see few Intel >>>>>>> things. ARM QEMU implementation must be considered as well if we >>>>>>> move RISC-V to OvmfPkg, thus we can have the consistent >>> implementation. >>>>>>>> RISC-V QEMU implementation just follows ARM QEMU implement, that >>>>> is >>>>>>> to have a separate package. But I agree with you that all >>>>>>> processors/platforms emulator should be under OvmfPkg. >>>>>>>> >>>>>>>>>>> This should be utf-8: >>>>>>>>>>> BaseTools/Scripts/ConvertUni.py >>>>>>>> I will fix this. >>>>>>>> >>>>>>>> I think I set the configurations when submit patches. Will >>>>>>>> figure it >>> out. >>>>>>>> Thanks >>>>>>>> Abner >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jordan Justen [mailto:[email protected]] >>>>>>>> Sent: Sunday, May 08, 2016 1:53 PM >>>>>>>> To: Chang, Abner (HPS SW/FW Technologist) <[email protected]>; >>>>>>>> [email protected] >>>>>>>> Cc: [email protected] >>>>>>>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>>>>>> DxeIpl. >>>>>>>> >>>>>>>> On 2016-05-07 21:23:36, Abner Chang wrote: >>>>>>>>> From: AbnerChang <[email protected]> >>>>>>>>> >>>>>>>> >>>>>>>> git config settings. :) >>>>>>>> >>>>>>>>> The implementation of RISC-V DxeIpl. >>>>>>>>> >>>>>>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>>>>>> Signed-off-by: Abner Chang<[email protected]> >>>>>>>> >>>>>>>> space before < >>>>>>>> >>>>>>>>> --- >>>>>>>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 6 +- >>>>>>>>> MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 >>>>>>>>> ++++++++++++++++++++++ >>>>>>>> >>>>>>>> Is it Riscv64 or RiscV64? >>>>>>>> >>>>>>>> Like MdePkg, I think MdeModulePkg only supports achitectures in >>>>>>>> the >>>>> UEFI >>>>>>> spec. >>>>>>>> >>>>>>>> -Jordan >>>>>>>> >>>>>>>>> 2 files changed, 84 insertions(+), 1 deletion(-) create mode >>>>>>>>> 100644 MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>>> >>>>>>>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>>> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>>> index 04ad928..13c0852 100644 >>>>>>>>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>>> @@ -6,6 +6,7 @@ >>>>>>>>> # needed to run the DXE Foundation. >>>>>>>>> # >>>>>>>>> # Copyright (c) 2006 - 2015, Intel Corporation. All rights >>>>>>>>> reserved.<BR> >>>>>>>>> +# Copyright (c) 2016, Hewlett Packard Enterprise Development >>> LP. >>>>>>>>> +All rights reserved.<BR> >>>>>>>>> # This program and the accompanying materials # are >>>>> licensed >>>>>>> and >>>>>>>>> made available under the terms and conditions of the BSD >>>>>>>>> License # which accompanies this distribution. The full text >>>>>>>>> of the license may be found at @@ -29,7 +30,7 @@ # # The >>>>>>>>> following >>>>> information >>>>>>> is >>>>>>>>> for reference only and not required by the build tools. >>>>>>>>> # >>>>>>>>> -# VALID_ARCHITECTURES = IA32 X64 IPF EBC (EBC is >>>>> for >>>>>>> build only) AARCH64 >>>>>>>>> +# VALID_ARCHITECTURES = IA32 X64 IPF EBC (EBC is >>>>> for >>>>>>> build only) AARCH64 RISCV64 >>>>>>>>> # >>>>>>>>> >>>>>>>>> [Sources] >>>>>>>>> @@ -57,6 +58,9 @@ >>>>>>>>> [Sources.ARM, Sources.AARCH64] >>>>>>>>> Arm/DxeLoadFunc.c >>>>>>>>> >>>>>>>>> +[Sources.RISCV64] >>>>>>>>> + Riscv64/DxeLoadFunc.c >>>>>>>>> + >>>>>>>>> [Packages] >>>>>>>>> MdePkg/MdePkg.dec >>>>>>>>> MdeModulePkg/MdeModulePkg.dec diff --git >>>>>>>>> a/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>>> b/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>>> new file mode 100644 >>>>>>>>> index 0000000..6b42e44 >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>>> @@ -0,0 +1,79 @@ >>>>>>>>> +/** @file >>>>>>>>> + RISC-V specific functionality for DxeLoad. >>>>>>>>> + >>>>>>>>> + Copyright (c) 2016, Hewlett Packard Enterprise Development LP. >>>>>>>>> + All rights reserved.<BR> >>>>>>>>> + >>>>>>>>> + This program and the accompanying materials are licensed >>>>>>>>> + and made available under the terms and conditions of the BSD >>>>>>>>> + License which accompanies this distribution. The full text of >>>>>>>>> + the license may be found at >>>>>>>>> + http://opensource.org/licenses/bsd-license.php >>>>>>>>> + >>>>>>>>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN >>>>> "AS >>>>>>> IS" >>>>>>>>> +BASIS, >>>>>>>>> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, >>>>> EITHER >>>>>>> EXPRESS OR IMPLIED. >>>>>>>>> +**/ >>>>>>>>> + >>>>>>>>> +#include "DxeIpl.h" >>>>>>>>> + >>>>>>>>> +typedef >>>>>>>>> +VOID* >>>>>>>>> +(EFIAPI *DXEENTRYPOINT) ( >>>>>>>>> + IN VOID *HobStart >>>>>>>>> + ); >>>>>>>>> + >>>>>>>>> +/** >>>>>>>>> + Transfers control to DxeCore. >>>>>>>>> + >>>>>>>>> + This function performs a CPU architecture specific >>>>>>>>> + operations to >>>>>>> execute >>>>>>>>> + the entry point of DxeCore with the parameters of HobList. >>>>>>>>> + It also installs EFI_END_OF_PEI_PPI to signal the end of >>>>>>>>> + PEI >>>>> phase. >>>>>>>>> + >>>>>>>>> + @param DxeCoreEntryPoint The entry point of >>>>> DxeCore. >>>>>>>>> + @param HobList The start of HobList >>>>> passed >>>>>>> to DxeCore. >>>>>>>>> + >>>>>>>>> +**/ >>>>>>>>> +VOID >>>>>>>>> +HandOffToDxeCore ( >>>>>>>>> + IN EFI_PHYSICAL_ADDRESS DxeCoreEntryPoint, >>>>>>>>> + IN EFI_PEI_HOB_POINTERS HobList >>>>>>>>> + ) >>>>>>>>> +{ >>>>>>>>> + VOID *BaseOfStack; >>>>>>>>> + VOID *TopOfStack; >>>>>>>>> + EFI_STATUS Status; >>>>>>>>> + // >>>>>>>>> + // >>>>>>>>> + // Allocate 128KB for the Stack >>>>>>>>> + // >>>>>>>>> + BaseOfStack = AllocatePages (EFI_SIZE_TO_PAGES >>>>>>>>> +(STACK_SIZE)); >>>>>>>>> + ASSERT (BaseOfStack != NULL); >>>>>>>>> + >>>>>>>>> + // >>>>>>>>> + // Compute the top of the stack we were allocated. >>>>>>>>> + Pre-allocate a UINTN // for safety. >>>>>>>>> + // >>>>>>>>> + TopOfStack = (VOID *) ((UINTN) BaseOfStack + >>>>> EFI_SIZE_TO_PAGES >>>>>>>>> + (STACK_SIZE) * EFI_PAGE_SIZE - CPU_STACK_ALIGNMENT); >>>>>>> TopOfStack = >>>>>>>>> + ALIGN_POINTER (TopOfStack, CPU_STACK_ALIGNMENT); >>>>>>>>> + >>>>>>>>> + // >>>>>>>>> + // End of PEI phase signal // Status = >>>>>>>>> + PeiServicesInstallPpi (&gEndOfPeiSignalPpi); ASSERT_EFI_ERROR >>>>>>>>> + (Status); >>>>>>>>> + >>>>>>>>> + // >>>>>>>>> + // Update the contents of BSP stack HOB to reflect the real >>>>>>>>> + stack >>>>> info >>>>>>> passed to DxeCore. >>>>>>>>> + // >>>>>>>>> + UpdateStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN) BaseOfStack, >>>>>>>>> + STACK_SIZE); >>>>>>>>> + >>>>>>>>> + DEBUG ((EFI_D_INFO, "DXE Core new stack at %x, stack pointer >>>>> at >>>>>>>>> + %x\n", BaseOfStack, TopOfStack)); >>>>>>>>> + >>>>>>>>> + // >>>>>>>>> + // Transfer the control to the entry point of DxeCore. >>>>>>>>> + // >>>>>>>>> + SwitchStack ( >>>>>>>>> + (SWITCH_STACK_ENTRY_POINT)(UINTN)DxeCoreEntryPoint, >>>>>>>>> + HobList.Raw, >>>>>>>>> + NULL, >>>>>>>>> + TopOfStack >>>>>>>>> + ); >>>>>>>>> +} >>>>>>>>> -- >>>>>>>>> 1.9.5.msysgit.0 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> edk2-devel mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>>> _______________________________________________ >>>>>>>> edk2-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>> _______________________________________________ >>>>>>> edk2-devel mailing list >>>>>>> [email protected] >>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
