Re: [edk2] PcRtcAcpiTableChangeCallback question

How about to call PcRtcAcpiTableChangeCallback(NULL, NULL) explicitly before or after the event creation instead of signal the event? The event is a group event, it is not same with the event in EfiCreateProtocolNotifyEvent() that is a single event, signal a group event may make other consumer

[edk2] [Patch 1/2] PcAtChipsetPkg/PcRtc: move ACPI parsing code to GetCenturyRtcAddress

The patch moves ACPI parsing code to a separate function GetCenturyRtcAddress() and the next patch will call this function in driver entry point. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Anbazhagan Baraneedharan

[edk2] [Patch 2/2] PcAtChipsetPkg/PcRtc: get century RTC address in entry point

When ACPI table is installed before PcRtc driver runs, the ACPI table installation callback isn't called which causes the century value isn't written to the CMOS. The patch calls GetCenturyRtcAddress() in entry point to fix the bug. Contributed-under: TianoCore Contribution Agreement 1.0

Re: [edk2] [Patch] MdePkg: Update StatusCode Runtime Protocol comments to follow PI spec.

How about to point out which PI version the patch is to follow explicitly in the commit log or title? With that, Reviewed-by: Star Zeng Thanks, Star -Original Message- From: Gao, Liming Sent: Wednesday, May 18, 2016 9:46 AM To: edk2-devel@lists.01.org Cc: Zeng,

Re: [edk2] [Patch] BaseTools: add error condition for Variable PACKAGES_PATH

This error message is for a single path in PACKAGES_PATH, so I think the error message could be more clear. For example my bug using ; vs : on Unix gets an error message that looks like. : error 000E: PACKAGES_PATH doesn't exist

[edk2] Acquire the permission to commit code in edk2-staging tree

Hi Michael and Jordan, I'm going to commit RISC-V to edk2-staging tree, however, I don't have the permission to modify that repository. Could you please help to give me the permission? Thanks Abner ___ edk2-devel mailing list edk2-devel@lists.01.org

Re: [edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

Mike, We could use SmmCpuFeaturesInitializeProcessor ()'s input parameter "IsMonarch" for BSP identification instead of (ProcessorInfo->StatusFlag & PROCESSOR_AS_BSP_BIT) to simply the code. Reviewed-by: Jeff Fan Jeff -Original Message- From: Kinney, Michael D

Re: [edk2] HTTP Boot crashed when downloading remote image

On Thu, May 12, 2016 at 06:26:36PM +0800, Gary Lin wrote: > Hi, > > I was testing HTTP Boot with the latest OMVF and found that it crashed > when downloading the remote image from the http server. Here is my > bisect result: > > commit b347a22aecbfac9aac47831fee9a30aa810d6d0b > NetworkPkg: Avoid

[edk2] [Patch 1/2] MdeModulePkg BootManagerUiLib: Save mode info for later use.

In current code, we use different output modes for boot phase and setup phase. When split BootManagerUiLib from UiApp code, we not add logic to save the boot phase mode info which will be used later. This change add this logic. Contributed-under: TianoCore Contribution Agreement 1.0

Re: [edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

Reviewed by: jiewen@intel.com > -Original Message- > From: Kinney, Michael D > Sent: Wednesday, May 18, 2016 3:08 AM > To: edk2-devel@lists.01.org > Cc: Fan, Jeff ; Yao, Jiewen ; > Tian, Feng > Subject: [Patch V2 1/2]

[edk2] SD is not getting detected in linux

Hi All, I am trying to boot linux on 64 bit ARM based SoC using LinuxLoader.efi application. Problem is if I first load shell and then kernel, everything works just fine, SD comes up properly in Linux. But... if I directly launch kernel without loading shell, then SD didn't respond to any

Re: [edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

Mike, I tested this patch and found DEBUG() cannot be printed as expected if SMM Base/Mask values do not meet SDM requirement. The reason is that PiSmmCpuDxeSmm driver will do SMM relocation on Aps firstly and then do SMM relocation on BSP at last. That means Aps will check SMM Base/Mask

Re: [edk2] [PATCH 0/2] add '!include' support to tools_def.txt parser

I sent v3 with relative path support. Thanks Michael On Mon, May 16, 2016 at 8:19 AM, Gao, Liming wrote: > Michael: > In DSC/FDF, if the file path is relative, Build tool will find it from > $(WORKSPACE) and $(PACKAGES_PATH). I expect the same way is in > tools_def.txt

[edk2] [PATCH v3 2/2] BaseTools: add '!include' support to tools_def.txt parser

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Zimmermann --- .../Source/Python/Common/ToolDefClassObject.py | 71 +++--- 1 file changed, 64 insertions(+), 7 deletions(-) diff --git

Re: [edk2] [PATCH 4/6] BaseTools: Eliminate two shift-negative-value in FvLib.c

CC Andrew On 05/17/16 04:52, Gao, Liming wrote: > Reviewed-by: Liming Gao Liming, before you commit this patch, can you please modify the commit message? Before the "Contributed-under" line, the following line should be added please: Fixes:

Re: [edk2] [staging/branch]: RISC-V

On 05/16/16 10:51, Abner Chang wrote: > Create a new branch (RISC-V) on edk2-stanging for RISC-V edk2 port. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Abner Chang > --- > Readme.MD | 20 > 1 file changed, 20

Re: [edk2] [PATCH 0/2] Fix GCC build failures introduced with a85be3ae48a8

On 05/17/16 04:13, Gao, Liming wrote: > Laszlo: > I push these two patches at 17da28~7b1351. Thanks, I was out of the office yesterday. Laszlo >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Friday, May 13, 2016 5:51 PM >> To: edk2-devel-01

[edk2] [PATCH] MdeModulePkg: PeiCore: Fix PEI Multiple Sub-FV Support issue

FirmwareVolmeInfoPpiNotifyCallback is re-enterable during FV process. PrivateData->FVCount increases when processing each sub FVs. Need to cache Parent FV count in stack before processing any sub FV. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang

Re: [edk2] PcRtcAcpiTableChangeCallback question

On 05/17/16 01:20, Anbazhagan, Baraneedharan wrote: > PcRtcAcpiTableChangeCallback doesn't seem to be called if > gEfiAcpiTableGuid or gEfiAcpi10TableGuid is already installed before > PcRtc module gets loaded. Whether ACPI table Guid can be checked in > system configuration table and then

Re: [edk2] [PATCH 3/6] OvmfPkg: Duplicate twice-iterated VA_LIST passed as argument to XenStoreVSPrint()

On 05/16/16 17:51, Zenith432 wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Zenith432 > --- > OvmfPkg/XenBusDxe/XenStore.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git

[edk2] [PATCH] Emulator Pkg add 'Alt' key map

Add 'Alt' key map. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Pedroa Liu --- EmulatorPkg/Unix/Host/X11GraphicsWindow.c | 16 1 file changed, 16 insertions(+) diff --git a/EmulatorPkg/Unix/Host/X11GraphicsWindow.c

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add SMRR PhysBase/PhysMask fields check

CC Paolo and Radim (Radim: please subscribe to edk2-devel first, if you'd like to respond -- the list software only reflects emails from subscribers. It's wrong, but I can't help it.) On 05/16/16 22:40, Michael Kinney wrote: > From: Jeff Fan > > SMRR range size and

Re: [edk2] PcRtcAcpiTableChangeCallback question

Laszlo, thanks for the quick proposal. I will send out a formal patch to fix this issue. Regards, Ray >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Tuesday, May 17, 2016 5:42 PM >To: Anbazhagan, Baraneedharan ; edk2-devel@lists.01.org

Re: [edk2] [Patch 0/4] MdeModulePkg/PciBus Do not improperly degrade resource

On 05/17/16 04:03, Ruiyu Ni wrote: > The patch serials refined the PciBus code and adds a new feature following > PI spec 1.4a to not improperly degrade resource. > > Ruiyu Ni (4): > MdeModulePkg/PciBus: use better name for local variables. > MdeModulePkg/PciBus: Remove unused fields in

[edk2] [PATCH v2 4/7] OvmfPkg: introduce ICH9_PMBASE_VALUE

According to the ICH9 spec, PMBASE "provides 128 bytes of I/O space for ACPI, GPIO, and TCO logic. This is placed on a 128-byte boundary". On the Q35 machine type of QEMU, our current PMBASE setting of 0xB000 is the only thing that prevents us from lowering the base of the PCI IO port aperture

[edk2] [PATCH v2 2/7] OvmfPkg: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUE

In the next patches, we'll differentiate the PMBA IO port address that we program on PIIX4 vs. Q35. Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However, because we need this value in BaseRomAcpiTimerLib too (which cannot access RAM and dynamic PCDs), it must remain a build

[edk2] [PATCH v2 1/7] OvmfPkg/AcpiTimerLib: don't use possibly unset PMBA register (PEI phase)

We should store the right value to the PMBA (if the PMBA needs initialization) before setting mAcpiTimerIoAddr from the PMBA. Cc: Gabriel Somlo Cc: Jordan Justen Fixes: f122712b42af3d63902c2c141e90d2c200df6790 Contributed-under: TianoCore Contribution

[edk2] [PATCH v2 7/7] OvmfPkg/PlatformPei: provide 10 * 4KB of PCI IO Port space on Q35

This can accommodate 10 bridges (including root bridges, PCIe upstream and downstream ports, etc -- see for more details). 10 is not a whole lot, but closer to the architectural limit of 15 than our current 4, so it can be considered a

[edk2] [PATCH v2 3/7] OvmfPkg: add and use industry standard macro PIIX4_PMBA_MASK

We already have the identical purpose (but different value) macro for ICH9, namely ICH9_PMBASE_MASK in "OvmfPkg/Include/IndustryStandard/Q35MchIch9.h". Also, stop bit-negating signed integer constants. Cc: Gabriel Somlo Cc: Jordan Justen Ref:

[edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

Version 2 of the series at . Changes relative to v1: - Patch #1 is a new patch for a potential issue I independently noticed. It belongs to the front of the series though. I CC'd Gabriel on this patch, and then I decided to CC him on

[edk2] [PATCH v2 5/7] OvmfPkg: determine PMBA value dependent on host bridge device ID

In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei are modified together in order to keep VMs functional across a bisection: they all must agree on the PMBA value used. ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it gets linked into the debug agent,

[edk2] [PATCH v2 6/7] OvmfPkg/PlatformPei: set PCI IO port aperture dynamically

Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our PciHostBridgeLib instance.) Take special care to keep the GCD IO space map unchanged

[edk2] Problem with SD stack

Hi Feng, I am writing UEFI driver for SD/MMC controller on my platform. Unfortunately, I have a problem with communication between card and controller. I implement SdMmcPassThru protocol (mainly based on your implementation, only bigger changes in initialization sequence) and want to use your SD

[edk2] [Patch] BootMaintenanceManagerUiLib: Rollback changes for BootNext.

Commit a85be3ae48a8aaa40b755cd0ff7270c67cfed585 imports errors for BootNext question, this patch rollback the related changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Liming Gao ---

Re: [edk2] [Patch] BaseTools: support private package definition

Reviewed-by: Liming Gao -Original Message- From: Zhu, Yonghong Sent: Tuesday, May 10, 2016 6:17 PM To: edk2-devel@lists.01.org Cc: Gao, Liming Subject: [Patch] BaseTools: support private package definition EDKII build spec and DEC spec

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

Series Reviewed-by: Jordan Justen On 2016-05-17 08:22:43, Laszlo Ersek wrote: > Version 2 of the series at > . > > Changes relative to v1: > - Patch #1 is a new patch for a potential issue I independently

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add SMRR PhysBase/PhysMask fields check

Laszlo, Thanks for the feedback. I agree that a platform can have SMRAM without SMRR. Another option is to move this check into SmmCpuFeaturesInitializeProcessor(). That API is passed in the SMRAM range in CpuHotPlugData and is where SMRR is initially programmed if SMRR is supported. Mike >

[edk2] Using the Shell to launch a kernel using a RAMDISK

I am trying to boot a linux kernel from within the shell that is using a ramdisk filesystem. I allocate memory in the shell for a ramdisk. I read the filesystem out of flash memory after allocating memory in the shell: KernelRootFS = AllocatePages(((KernelFSSize/FOUR_KB_ALIGNED) +1)); I then

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

> On May 17, 2016, at 10:13 AM, Foster, Matthew I > wrote: > > I am trying to boot a linux kernel from within the shell that is using a > ramdisk filesystem. I allocate memory in the shell for a ramdisk. I read the > filesystem out of flash memory after allocating

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

Shouldn't passing the address and size to the kernel command line be enough for the kernel not to walk over it? Is there best known method for setting up a ramdisk in the BIOS and allowing the kernel to use it? console=ttyS0,115200n8 loglevel=8 rootwait root=/dev/mtdblock0

Re: [edk2] [RFC] MdePkg: BaseLib: don't use aligned pointers for unaligned accessors

Leif, What are the specific warnings that are being triggered by CLANG -Weverything for the unaligned access APIs in BaseLib? Are there other options than changing the BaseLib API definitions? My two concerns are: 1) Impacts to modules/libs that call the unaligned access functions in

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

The issue you have is that with AllocatePages lib function, you are allocating a memory type that self-destructs when an ExitBootServices is called. This is typically called when an OS Loader initializes and transitions to the kernel that it's loading. (Specifics vary per OS as to exactly

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add SMRR PhysBase/PhysMask fields check

On 05/17/16 19:12, Kinney, Michael D wrote: > Laszlo, > > Thanks for the feedback. I agree that a platform can have SMRAM without SMRR. > > Another option is to move this check into SmmCpuFeaturesInitializeProcessor(). > That API is passed in the SMRAM range in CpuHotPlugData and is where SMRR

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

On 05/17/16 18:44, Jordan Justen wrote: > Series Reviewed-by: Jordan Justen Thank you very much. I'll await a (hopefully quick ;)) T-b from Gabriel. Cheers! Laszlo > On 2016-05-17 08:22:43, Laszlo Ersek wrote: >> Version 2 of the series at >>

Re: [edk2] [RFC] EDK2 Platforms Proposal

Leif, Have you had a chance to look at this yet? How about a using the name OpenPlatforms as the name of the branch that contains all platforms that are tracking edk2/master, but are not required to be in edk2/master to validate core features? edk2-platforms/master Tracks

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

> On May 17, 2016, at 10:30 AM, Foster, Matthew I > wrote: > > Shouldn't passing the address and size to the kernel command line be enough > for the kernel not to walk over it? Is there best known method for setting up > a ramdisk in the BIOS and allowing the

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

On Tue, May 17, 2016 at 07:45:28PM +0200, Laszlo Ersek wrote: > On 05/17/16 18:44, Jordan Justen wrote: > > Series Reviewed-by: Jordan Justen > > Thank you very much. I'll await a (hopefully quick ;)) T-b from Gabriel. Tested-by: Gabriel Somlo Took me

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

memmap=0x00F42000$0x0C235000 size =0x00F42000 address: 0x0C235000 -Original Message- From: af...@apple.com [mailto:af...@apple.com] Sent: Tuesday, May 17, 2016 10:47 AM To: Foster, Matthew I Cc: edk2-devel@lists.01.org Subject: Re: [edk2] Using the Shell to

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

On Tue, May 17, 2016 at 01:55:56PM -0400, Gabriel L. Somlo wrote: > On Tue, May 17, 2016 at 07:45:28PM +0200, Laszlo Ersek wrote: > > On 05/17/16 18:44, Jordan Justen wrote: > > > Series Reviewed-by: Jordan Justen > > > > Thank you very much. I'll await a (hopefully

Re: [edk2] [RFC] MdePkg: BaseLib: don't use aligned pointers for unaligned accessors

On 05/17/16 19:38, Kinney, Michael D wrote: > Leif, > > What are the specific warnings that are being triggered by CLANG -Weverything > for the > unaligned access APIs in BaseLib? > > Are there other options than changing the BaseLib API definitions? My two > concerns are: > > 1) Impacts to

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

On 05/17/16 20:05, Gabriel L. Somlo wrote: > On Tue, May 17, 2016 at 01:55:56PM -0400, Gabriel L. Somlo wrote: >> On Tue, May 17, 2016 at 07:45:28PM +0200, Laszlo Ersek wrote: >>> On 05/17/16 18:44, Jordan Justen wrote: Series Reviewed-by: Jordan Justen >>> >>>

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

On 05/17/16 19:13, Foster, Matthew I wrote: > I am trying to boot a linux kernel from within the shell that is > using a ramdisk filesystem. I allocate memory in the shell for a > ramdisk. I read the filesystem out of flash memory after allocating > memory in the shell: > > KernelRootFS =

Re: [edk2] [PATCH v2 0/7] OvmfPkg: grow PCI IO Port aperture on Q35

On 05/17/16 17:22, Laszlo Ersek wrote: > Version 2 of the series at > . > > Changes relative to v1: > - Patch #1 is a new patch for a potential issue I independently noticed. > It belongs to the front of the series though. I CC'd Gabriel

[edk2] [Patch V2 0/2] Add SMRR PhysBase/PhysMask fields check

Update SmmCpuFeaturesLib instances that support SMRR to check the SMMRR base and size. Cc: Jeff Fan Cc: Jiewen Yao Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney

[edk2] [Patch V2 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

SMRR range size and alignment should follow the rules like MTRR: a. The minimum range size is 4 KBytes and the base address of the range must be on at least a 4-KByte boundary. b. For ranges greater than 4 KBytes, each range must be of length 2^n and its base address must be aligned on a 2^n

[edk2] [Patch V2 2/2] QuarkSocPkg/SmmCpuFeaturesLib: Add SMRR PhysBase/PhysMask fields check

SMRR range size and alignment should follow the rules like MTRR: a. The minimum range size is 4 KBytes and the base address of the range must be on at least a 4-KByte boundary. b. For ranges greater than 4 KBytes, each range must be of length 2^n and its base address must be aligned on a 2^n

Re: [edk2] [Patch V2 0/2] Add SMRR PhysBase/PhysMask fields check

On 05/17/16 21:08, Michael Kinney wrote: > Update SmmCpuFeaturesLib instances that support SMRR to check > the SMMRR base and size. > > Cc: Jeff Fan > Cc: Jiewen Yao > Cc: Feng Tian > Contributed-under: TianoCore Contribution

[edk2] [PATCH 0/6] OvmfPkg, ArmVirtPkg: remove compatibility with IntelFrameworkModulePkg BDS

Mainly triggered by from about a week ago. In patch #2 the reasons are listed in more detail. Public branch: . Cc: Ard Biesheuvel Cc: Gary

[edk2] [PATCH 1/6] OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in examples

The "UNIXGCC Debug" section happens to name PlatformBdsLib and IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering those even as a fallback option. Cc: Ard Biesheuvel Cc: Gary Ching-Pang Lin Cc: Jordan Justen

[edk2] [PATCH 2/6] OvmfPkg: remove USE_OLD_BDS build fallback macro

Reasons: - USE_OLD_BDS requires duplicating updates between OVMF's library instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples: d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 1da761664949 OvmfPkg/QemuBootOrderLib:

[edk2] [PATCH 6/6] OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLib

This completes the transition to the new BDS. The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed. Cc: Ard Biesheuvel Cc: Gary Ching-Pang Lin Cc: Jordan Justen Cc: Ruiyu Ni

[edk2] [PATCH 5/6] OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter list

With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no longer need the BootOptionList parameter in the SetBootOrderFromQemu() prototype. Update the library class header file (including the function's documentation), and adapt the library instance and the call sites. Cc: Ard

[edk2] [PATCH 3/6] OvmfPkg: remove PlatformBdsLib instance

This library instance is no longer referenced. Cc: Ard Biesheuvel Cc: Gary Ching-Pang Lin Cc: Jordan Justen Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek

[edk2] [PATCH 4/6] OvmfPkg: remove QemuBootOrderLib instance

This library instance is no longer referenced. Cc: Ard Biesheuvel Cc: Gary Ching-Pang Lin Cc: Jordan Justen Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek

Re: [edk2] [RFC] MdePkg: BaseLib: don't use aligned pointers for unaligned accessors

> On May 17, 2016, at 11:15 AM, Laszlo Ersek wrote: > > Hence we need a flag so that CLANG allows such pointer use, without > insisting on strict standards conformance. Maybe "-Wno-cast-align" would > suffice; I'm not sure. > > An interesting URL I've found is: > >

[edk2] [PATCH v2 0/3] *** Add Nvme.h and NvmExpressLib ***

From: Darbin Reyes *** Add Nvme.h and NvmExpressLib *** Darbin Reyes (3): MdePkg: Add a header for NVMe v1.1 spec. definitions. MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h. MdeModulePkg: Add NvmExpressLib.

[edk2] [PATCH v2 1/3] MdePkg: Add a header for NVMe v1.1 spec. definitions.

From: Darbin Reyes Adds a public header for NVMe v1.1 spec. definitions. The majority of these definitions where copied from a private header in MdeModulePkg/Bus/Pci/NvmExpress/NvmExpressHci.h. Additional definitions were added e.g. the NVMe Smart Health Log and

[edk2] [PATCH v2 2/3] MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.

From: Darbin Reyes Move NvmExpressHci.h definitions to a the public industry standard header in MdePkg. The NvmExpressHci.h contains definitions based on the NVMe v1.1 specification. These definitions should be in a public header so that clients of the NVMe passthru

[edk2] [PATCH v2 3/3] MdeModulePkg: Add NvmExpressLib.

From: Darbin Reyes Adds a library for functions that facilitate the execution of NVMe commands using the passthru protocol. These functions are intended for use with NVMe controllers that are compliant with version 1.1 of the NVMe spec. The initial implementation of the

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

Thanks Ersek, I did change my code to match what you have here as far as the allocation. I did some more debugging and registered up a callback in exit boot services, and did an integrity check of the memory I previously allocated and put the ramdisk in. I checked the memory right before I

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

> On May 17, 2016, at 4:08 PM, Foster, Matthew I > wrote: > > Thanks Ersek, > Laszlo... > I did change my code to match what you have here as far as the allocation. I > did some more debugging and registered up a callback in exit boot services, > and did an

[edk2] [BaseTools] RuleOverride = BINARY code location?

I'm trying to track down the code that processes the RuleOverride = BINARY, does anyone have a pointer? I'm porting the master BaseTools to our code base and I'm hitting a size regression. One of the binary files is ending up with extra sections and I 'm trying to track down that logic.

[edk2] [RFC] Proposal to organize packages into directories

Hello, There have been some discussions about organizing packages into directories. Below is a proposal for a top level directory structure and a first pass mapping of the packages from edk2/master. Where applicable, vendor specific directories can be added. The PACKAGES_PATH feature

Re: [edk2] [PATCH 4/6] BaseTools: Eliminate two shift-negative-value in FvLib.c

Yes. From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, May 17, 2016 4:58 PM To: Gao, Liming Cc: Zenith432 ; edk2-devel@lists.01.org ; Andrew Fish Subject: Re: [edk2] [PATCH 4/6]

[edk2] [Patch] MdePkg: Update StatusCode Runtime Protocol comments to follow PI spec.

Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- MdePkg/Include/Protocol/StatusCode.h | 13 ++--- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git

[edk2] [Patch] BaseTools: add error condition for Variable PACKAGES_PATH

This patch adds error condition 1)if PACKAGES_PATH is not exist, 2) if space is exist in the PACKAGES_PATH. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu ---

Re: [edk2] [Patch] BootMaintenanceManagerUiLib: Rollback changes for BootNext.

Reviewed-by: Liming Gao > -Original Message- > From: Dong, Eric > Sent: Tuesday, May 17, 2016 2:14 PM > To: edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: [Patch] BootMaintenanceManagerUiLib: Rollback changes for > BootNext. > > Commit

Re: [edk2] [patch] MdeModulePkg/UiApp: Enhance the error handling

Reviewed-by: Qiu Shumin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi Sent: Tuesday, May 17, 2016 1:41 PM To: edk2-devel@lists.01.org Cc: Qiu, Shumin; Dong, Eric Subject: [edk2] [patch] MdeModulePkg/UiApp:

[edk2] [Patch 0/2] Save the Boot mode info for later use.

In current code, we use different output modes for boot phase and setup phase. When split BootManagerUiLib/BootMaintenanceMangerUiLib from UiApp code, we not add logic to save the boot phase mode info which will be used later. This change add this logic. Eric Dong (2): MdeModulePkg

[edk2] [Patch 2/2] BootMaintenanceMangerUiLib: Save mode info for later use.

In current code, we use different output modes for boot phase and setup phase. When split BootMaintenanceMangerUiLib from UiApp code, we not add logic to save the boot phase mode info which will be used later. This change add this logic. Contributed-under: TianoCore Contribution Agreement 1.0