Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

The old version is not just slow. It cannot work in certain cases. That's why the new version was developed. The new version adds a new API which allows caller to pass in the scratch buffer instead of using the stack. If a platform has limited stack, it can use that API. Thanks/Ray >

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

On 2017-11-08 19:04:35, Ni, Ruiyu wrote: > Jordan, Laszlo, > > I didn't realize that a platform may have less than 4-page stack > before memory is ready. If I was aware of that, I would change the > default scratch buffer size to 2 page, which should be enough too. This does not sound much

Re: [edk2] [PATCH edk2-non-osi v1] Hisilicon D0x: Remove uncacheable attribute from memory resource HOB

Looks good to me. On 2017/11/9 11:30, Ming Huang wrote: If uncacheable attribute is included in memory resource HOB, GCD spaces will also have EFI_MEMORY_UC capability, then NonCoherentPciIoAllocateBuffer of NonDiscoverablePciDeviceDxe module will allocate DMA buffer of EFI_MEMORY_UC type,

Re: [edk2] [PATCH v4 2/7] MdeModulePkg/SmmMemoryAttribute.h: Add new protocol definitions

Good catch. "EFI" should be removed and "IN" should be "OUT". Thanks for the feedback. > -Original Message- > From: Zeng, Star > Sent: Thursday, November 09, 2017 1:13 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Dong, Eric ; Yao,

Re: [edk2] [PATCH v4 2/7] MdeModulePkg/SmmMemoryAttribute.h: Add new protocol definitions

Suggest to use " SMM Memory Attribute Protocol " instead of " EFI SMM Memory Attribute Protocol " in the comments. Should "+ IN UINT64 *Attributes" be "+ OUT UINT64 *Attributes" for EDKII_SMM_GET_MEMORY_ATTRIBUTES? Thanks, Star

Re: [edk2] [PATCH] Tftp assert fix for openfile failure case

> -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Wednesday, November 08, 2017 8:52 PM > To: Udit Kumar > Cc: Vabhav Sharma ; edk2-devel@lists.01.org; > ruiyu...@intel.com; jaben.car...@intel.com;

[edk2] [PATCH edk2-non-osi v1] Update D03/D05 MemoryInit.efi binary for bug 3419

https://bugs.linaro.org/show_bug.cgi?id=3061 For fix this bug,the function PciIoPciRead of NonDiscoverablePciDeviceDxe should be modifyed also. Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: rp-osi-bug-v1 Ming Huang (1): Hisilicon D0x: Remove

[edk2] [PATCH edk2-non-osi v1] Hisilicon D0x: Remove uncacheable attribute from memory resource HOB

If uncacheable attribute is included in memory resource HOB, GCD spaces will also have EFI_MEMORY_UC capability, then NonCoherentPciIoAllocateBuffer of NonDiscoverablePciDeviceDxe module will allocate DMA buffer of EFI_MEMORY_UC type, which will cause alignment fault exception with

[edk2] 答复: [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

Laszlo, PiSmmCpuDxeSmm isn’t the problem, it also only consumed MtrrSetAllMtrrs() that will not consume big local variable buffer. Jeff From: edk2-devel on behalf of Ni, Ruiyu Sent: Thursday,

Re: [edk2] [PATCH v4 0/7] Implement heap guard feature

Jiewen, Thanks for the comments. 1) I agree. 2) I forgot to remove them since we added new SMM protocol to do the same thing instead. > -Original Message- > From: Yao, Jiewen > Sent: Thursday, November 09, 2017 10:53 AM > To: Wang, Jian J ; Dong, Eric

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

Jordan, Laszlo, I didn't realize that a platform may have less than 4-page stack before memory is ready. If I was aware of that, I would change the default scratch buffer size to 2 page, which should be enough too. But I do not think we may need to change the scratch buffer size. Let me

Re: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI mapping for TRIANGLE and ARROW

Thanks for the explanation. Reviewed-by: Ruiyu Ni Thanks/Ray > -Original Message- > From: Kinney, Michael D > Sent: Thursday, November 9, 2017 12:29 AM > To: Ni, Ruiyu ; edk2-devel@lists.01.org; Kinney, Michael > D >

Re: [edk2] [PATCH v4 0/7] Implement heap guard feature

That is great. I have minor suggestion below: 1) Since StaticPaging and HeapGuard are conflicted feature, I suggest we use ASSERT to tell the end user, instead of disable StaticPaging silently. + // + // Don't mark page table as read-only if heap guard is enabled. + // + // BIT2: SMM

Re: [edk2] [PATCH v4 0/7] Implement heap guard feature

Just a friendly reminder. The recent commits have fixed two blocking issues for checking in heap guard feature. 6fe575d052e36b243657a5885b5457decac41f03 (BaseCryptLib memory overflow) cf8197a39d07179027455421a182598bd698 5df73e2cc8e39da97d56da058667607f1c43acac

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

On 2017-11-08 17:36:01, Laszlo Ersek wrote: > Hi Ray, > > On 10/12/17 10:48, Ruiyu Ni wrote: > > The new algorithm converts the problem calculating optimal > > MTRR settings (using least MTRR registers) to the problem finding > > the shortest path in a graph. > > The memory required in extreme

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

Great. Glad to know my memory is still good enough. > -Original Message- > From: Yao, Jiewen > Sent: Thursday, November 09, 2017 9:49 AM > To: Wang, Jian J ; Laszlo Ersek ; > edk2-devel@lists.01.org > Cc: Dong, Eric >

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

FED0 is HPET region. It is MMIO. Thank you Yao Jiewen > -Original Message- > From: Wang, Jian J > Sent: Thursday, November 9, 2017 8:42 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Dong, Eric >

[edk2] [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

> v4: > a. Remove DoUpdate and check attributes mismatch all the time to avoid >a logic hole > b. Add warning message if failed to update capability > c. Add local variable to hold new attributes to make code cleaner > v3: > a. Add comment to explain more on updating memory capabilities > b.

Re: [edk2] [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings

Hi Ray, On 10/12/17 10:48, Ruiyu Ni wrote: > The new algorithm converts the problem calculating optimal > MTRR settings (using least MTRR registers) to the problem finding > the shortest path in a graph. > The memory required in extreme but rare case can be up to 256KB, > so using local stack

Re: [edk2] [PATCH v3 2/3] ShellPkg: Fix misuses of AllocateCopyPool

You're right StrCpyS is better for this case. Since the patch has checked in, maybe we can refine those code in another patch. Thanks for the comment. > -Original Message- > From: Carsey, Jaben > Sent: Wednesday, November 08, 2017 11:50 PM > To: Wang, Jian J ;

Re: [edk2] [PATCH V2] MdeModulePkg SerialDxe: Handle Timeout change more robustly

Pushed at a7fd8452964c1a6ffeee1fe07537cb900c0ccb07. Thanks for review and test. Star -Original Message- From: Julien Grall [mailto:julien.gr...@linaro.org] Sent: Wednesday, November 8, 2017 10:36 PM To: Zeng, Star ; edk2-devel@lists.01.org Cc: Laszlo Ersek

Re: [edk2] [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

Hi Laszlo, > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, November 08, 2017 10:37 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Dong, Eric ; Yao, Jiewen > Subject: Re:

Re: [edk2] Why do we use -g option of gcc even for RELEASE build?

That makes sense. Thank you all :) Regards, Heyi 在 11/8/2017 11:32 PM, Gao, Liming 写道: In build_rule.txt, GCC built image will be strip first, then be converted to EFI image by GenFw. There is no symbol in the final EFI image. All symbols are kept into original GCC built image. Thanks

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

Hi Laszlo, The memory range is FED0 - FED003FF. Actually I don't know if it's for MMIO or not. I might be mess it with other things. Thanks, Jian > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, November 08, 2017 10:17 PM > To:

[edk2] [Patch] QuarkPlatformPkg/Readme.md: Fix markdown format issue

https://bugzilla.tianocore.org/show_bug.cgi?id=769 Remove extra carriage return that causes formatting issues. Cc: Kelly Steele Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney

[edk2] [Patch] QuarkPlatformPkg/PlatformBootManagerLib: Update boot mode handling

https://bugzilla.tianocore.org/show_bug.cgi?id=768 Update and simplify boot mode handling logic. This includes performing minimum connects for the following boot modes: BOOT_ASSUMING_NO_CONFIGURATION_CHANGES BOOT_WITH_MINIMAL_CONFIGURATION BOOT_ON_S4_RESUME Cc: Kelly Steele

[edk2] [Patch] MdeModulePkg/UsbMassStorageDxe: Verify Get Max LUN value

The USB Mass Storage Class Specification states that a maximum LUN value larger than 0x0F is invalid. Add a check to make sure this maximum LUN value is in this valid range, and if it is not, then assume that the device does not support multiple LUNs and return a maximum LUN value of 0. This

[edk2] [Patch] MdeModulePkg/UsbMassStorageDxe: Fix USB Mass Storage detection

https://bugzilla.tianocore.org/show_bug.cgi?id=766 Update logic to not return an error from UsbBootRequestSense() if a Request Sense command responds with no sense information. It is legal for a USB mass storage device to respond to a Request Sense command with a SenseKey of

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

On Wed, Nov 08, 2017 at 05:45:11PM +, Ard Biesheuvel wrote: > On 8 November 2017 at 16:47, Leif Lindholm wrote: > > On Fri, Nov 03, 2017 at 10:16:52AM +, Ard Biesheuvel wrote: > >> Add a RealTimeClockLib implementation for the NXP PCF8563 as used on > >> the

[edk2] [Patch] MdeModulePkg/Core/Dxe: Remove extra connects for UEFI Applications

https://bugzilla.tianocore.org/show_bug.cgi?id=765 The UEFI Specification Boot Services chapter, StartImage() service, EFF 1.10 Extension requires extra calls to ConnectController() if a UEFI Driver produces handles. The DXE Core is performing these extra calls to ConnectController() without

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

On 8 November 2017 at 16:47, Leif Lindholm wrote: > On Fri, Nov 03, 2017 at 10:16:52AM +, Ard Biesheuvel wrote: >> Add a RealTimeClockLib implementation for the NXP PCF8563 as used on >> the Socionext Developer Box board. Note that the standard I2C protocol >> stack

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

On 8 November 2017 at 16:43, Leif Lindholm wrote: > On Fri, Nov 03, 2017 at 10:16:52AM +, Ard Biesheuvel wrote: >> Add a RealTimeClockLib implementation for the NXP PCF8563 as used on >> the Socionext Developer Box board. Note that the standard I2C protocol >> stack

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

On Fri, Nov 03, 2017 at 10:16:52AM +, Ard Biesheuvel wrote: > Add a RealTimeClockLib implementation for the NXP PCF8563 as used on > the Socionext Developer Box board. Note that the standard I2C protocol > stack does not support runtime use, so this driver invokes the I2C master > protocol

Re: [edk2] [RFC PATCH edk2-platforms 3/3] Platform/DeveloperBox: wire up RTC support

On Fri, Nov 03, 2017 at 10:16:54AM +, Ard Biesheuvel wrote: > Add the drivers, library resolutions and PCD settings to enable RTC > support on DeveloperBox. Also, update PlatformDxe to register the > non-discoverable device handles for both I2C controllers. > > Contributed-under: TianoCore

Re: [edk2] [RFC PATCH edk2-platforms 1/3] Silicon/NXP: add RTC support library for PCF8563 I2C IP

On Fri, Nov 03, 2017 at 10:16:52AM +, Ard Biesheuvel wrote: > Add a RealTimeClockLib implementation for the NXP PCF8563 as used on > the Socionext Developer Box board. Note that the standard I2C protocol > stack does not support runtime use, so this driver invokes the I2C master > protocol

Re: [edk2] [Patch] MdeModulePkg/TerminalDxe: Fix PCANSI mapping for TRIANGLE and ARROW

When DOS uses CodePage 437, 18 is an up arrow glyph. A PC ANSI terminal interprets 18 as a control character. Mike > -Original Message- > From: Ni, Ruiyu > Sent: Tuesday, November 7, 2017 11:47 PM > To: Kinney, Michael D ; > edk2-devel@lists.01.org > Cc:

Re: [edk2] [PATCH v2] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core

On Sun, Nov 05, 2017 at 04:29:15PM +, Ard Biesheuvel wrote: > >> OK, this may sound completely unreasonable, but seeing those > >> implementations overwrite callee-saved registers without saving them > >> makes my brain unhappy. (Yes, I know.) > >> > >> Could they either: > >> - Have a comment

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

On 11/08/2017 07:34 AM, Heyi Guo wrote: On 11/08/2017 05:07 PM, Gerd Hoffmann wrote: On Wed, Nov 08, 2017 at 04:44:37PM +0800, Heyi Guo wrote: 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道: No. Even a terminal tool can recognize F10, it still needs to translate it into "ESC [ V" and send the three

Re: [edk2] [PATCH v3 2/3] ShellPkg: Fix misuses of AllocateCopyPool

Why not use the StrCpy_s function to copy strings? CopyMem and StrSize feels odd to me. > -Original Message- > From: Wang, Jian J > Sent: Tuesday, November 07, 2017 6:12 PM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben ; Ni, Ruiyu > ; Bi,

Re: [edk2] Why do we use -g option of gcc even for RELEASE build?

On 08/11/2017 03:25, Heyi Guo wrote: > From gcc manual, -g option seems to produce debugging information. In > tools_def.template, -g is included in GCC_ALL_CC_FLAGS, so it will also > be enabled for RELEASE build with gcc tool chain. Any special reason to > do that? Why *not* actually? Debug

Re: [edk2] Why do we use -g option of gcc even for RELEASE build?

In build_rule.txt, GCC built image will be strip first, then be converted to EFI image by GenFw. There is no symbol in the final EFI image. All symbols are kept into original GCC built image. Thanks Liming > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent:

Re: [edk2] [PATCH] Tftp assert fix for openfile failure case

On Wed, Nov 08, 2017 at 05:15:49AM +, Udit Kumar wrote: > > > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c > > > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c > > > index fbde3bf..6425fc5 100755 > > > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c > > > +++

Re: [edk2] Why do we use -g option of gcc even for RELEASE build?

On 11/08/17 03:25, Heyi Guo wrote: > Hi folks, > > From gcc manual, -g option seems to produce debugging information. In > tools_def.template, -g is included in GCC_ALL_CC_FLAGS, so it will also > be enabled for RELEASE build with gcc tool chain. Any special reason to > do that? In the edk2

Re: [edk2] [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

On 11/08/17 11:52, Jian J Wang wrote: >> v3: >> a. Add comment to explain more on updating memory capabilities >> b. Fix logic hole in updating attributes >> c. Instead of checking illegal memory space address and size, use return >>status of gDS->SetMemorySpaceCapabilities() to skip memory

Re: [edk2] [PATCH V2] MdeModulePkg SerialDxe: Handle Timeout change more robustly

Hi Star, On 07/11/17 01:36, Star Zeng wrote: https://lists.01.org/pipermail/edk2-devel/2017-October/016479.html reported "Xen Console input very slow in recent UEFI" that appears after 4cf3f37c87ba1f9d58072444bd735e40e4779e70 "MdeModulePkg SerialDxe: Process timeout consistently in SerialRead".

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

On 11/08/17 01:10, Wang, Jian J wrote: > Hi Laszlo, > >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Wednesday, November 08, 2017 1:14 AM >> To: Wang, Jian J ; edk2-devel@lists.01.org >> Cc: Yao, Jiewen ; Dong,

Re: [edk2] GRUB issue on device priority

On Tue, Nov 07, 2017 at 10:02:30PM +0800, Haojian Zhuang wrote: > Hi all, > > It seems there's a device priority issue in GRUB. GRUB is behaving as expected. > All block io handles are linked into the list in edk2, and GRUB could fetch > it. Then GRUB creates its own ascending on HD priority. >

Re: [edk2] GRUB issue on device priority

On Wed, Nov 08, 2017 at 01:46:13PM +0800, Haojian Zhuang wrote: > On 2017/11/7 23:14, Vladimir 'phcoder' Serbinenko wrote: > > On Tue, Nov 7, 2017, 15:23 Haojian Zhuang > > wrote: > > > > Hi all, > > > > It seems there's a

[edk2] UserIdentification in Security Package

Hello, I am trying to make the UserIdentification from the security package to work or at least see how this behaves. At this point I am missing out on something to get this working in my tree. Can you point out what needs to be done to give this a try? At this point I added the stuff to the

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

On 11/08/2017 05:07 PM, Gerd Hoffmann wrote: On Wed, Nov 08, 2017 at 04:44:37PM +0800, Heyi Guo wrote: 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道: No. Even a terminal tool can recognize F10, it still needs to translate it into "ESC [ V" and send the three bytes to firmware. Got it. But the 2

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

On 11/08/17 04:13, Zeng, Star wrote: > https://bugzilla.tianocore.org/show_bug.cgi?id=763 is submitted to track this. I'd like to ask a question about the impact of BZ#763: Regarding BZ#753 ("UEFI memory map regression (runtime code entry splitting) introduced by c1cab54ce57c"), we seem to have

[edk2] [PATCH] SecurityPkg/SecureBootConfigDxe: Fix deleting signature data issue.

Replace "(UINT8 *)NewVariableData" with (UINT8 *)NewVariableData + Offset" to avoid the header of EFI_SIGNATURE_LIST being copied to the front of NewVariableData every time and update ListWalker when handling the current EFI_SIGNATURE_LIST finishes. Cc: Zhang Chao

[edk2] [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

> v3: > a. Add comment to explain more on updating memory capabilities > b. Fix logic hole in updating attributes > c. Instead of checking illegal memory space address and size, use return >status of gDS->SetMemorySpaceCapabilities() to skip memory block which >cannot be updated with new

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

Some updates below > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, > Jian J > Sent: Wednesday, November 08, 2017 8:11 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Dong, Eric

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

On Wed, Nov 08, 2017 at 04:44:37PM +0800, Heyi Guo wrote: > > > 在 11/8/2017 4:34 PM, Ni, Ruiyu 写道: > > No. > > Even a terminal tool can recognize F10, it still needs to translate it into > > "ESC [ V" > > and send the three bytes to firmware. > Got it. But the 2 seconds timeout is not for this

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

That makes sense. Thanks very much for your explanation. Regards, Heyi 在 11/8/2017 4:46 PM, Ni, Ruiyu 写道: Yes. 2 seconds is for some other terminal tools, that cannot do the F10 translation. Thanks/Ray -Original Message- From: Heyi Guo [mailto:heyi@linaro.org] Sent:

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

Yes. 2 seconds is for some other terminal tools, that cannot do the F10 translation. Thanks/Ray > -Original Message- > From: Heyi Guo [mailto:heyi@linaro.org] > Sent: Wednesday, November 8, 2017 4:45 PM > To: Ni, Ruiyu ; Zeng, Star ; edk2- >

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

在 11/8/2017 4:34 PM, Ni, Ruiyu 写道: No. Even a terminal tool can recognize F10, it still needs to translate it into "ESC [ V" and send the three bytes to firmware. Got it. But the 2 seconds timeout is not for this situation, right? If terminal tool could translate and send the key sequence, I

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

No. Even a terminal tool can recognize F10, it still needs to translate it into "ESC [ V" and send the three bytes to firmware. Thanks/Ray > -Original Message- > From: Heyi Guo [mailto:heyi@linaro.org] > Sent: Wednesday, November 8, 2017 4:31 PM > To: Ni, Ruiyu ;

Re: [edk2] [MdeModulePkg/TerminalDxe] Why do we delay 2s for ESC being pressed?

在 11/8/2017 3:55 PM, Ni, Ruiyu 写道: Heyi, If you check the comments below in TerminalConIn.c: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c#L1319 TerminalDxe driver needs to determine whether user wants to press ESC alone, or press

Re: [edk2] [PATCH v2 0/2] Add NVDIMM related spec definitions

Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Ruiyu Ni >Sent: Wednesday, November 08, 2017 2:33 PM >To: edk2-devel@lists.01.org >Subject: [edk2] [PATCH v2 0/2] Add NVDIMM related spec definitions