[edk2] [Patch] BaseTools: Support multiple .h file

for structure Pcd declaration in DEC file. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao --- BaseTools/Source/Python/Workspace/BuildClassObject.py | 2 +-

[edk2] [Patch] BaseTools: Structure Pcd in CommandLine.

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao --- BaseTools/Source/Python/AutoGen/AutoGen.py| 110 +++- BaseTools/Source/Python/Common/Expression.py | 2 +-

Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine

Hi Arthur, There is a related fix in the same file (FbGop.c): Line 896: FbGopPrivate->GraphicsOutput.Mode->Info->PixelsPerScanLine = HorizontalResolution; must be changed to: FbGopPrivate->GraphicsOutput.Mode->Info->PixelsPerScanLine = BytesPerScanLine / (BitsPerPixel / 8); I will

Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers

One minor comment, please help to remove the line (around line 1067): @param[in] Capability The capability of the slot. within function description comment for SdMmcHcInitHost() in file: MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c Other than that, the series is good to me: Reviewed-by:

[edk2] [PATCH] MdeModulePkg/Core: fix guard page missing issue

This issue is a regression one caused by a patch at 425d25699be83c35e12df8470b827d7fbcef3bce That fix didn't take the 0 page to free into account, which still needs to call UnsetGuardPage() even no memory needs to free. The fix is just moving the calling of UnsetGuardPage() to the place

[edk2] [Patch] BaseTool: Enhance error handling.

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng Cc: Liming Gao --- BaseTools/Source/Python/Workspace/DscBuildData.py | 113 - .../Source/Python/Workspace/MetaFileParser.py | 3 + 2 files

Re: [edk2] [Patch] BaseTools: Enhance parse performance by optimize ValueExpressionEx

The bad performance was caused by newly PCD flexible value format support patch, eg: { 'AB', L'AB', 0x1, L"AB", UINT16(8)} Original tool doesn't parse byte array PCD value format and let complier to do it, while after we add this new flexible value format support, BaseTool parse its format

Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine

Hi Nico, Thanks for the documentation that is very clear. Thanks, - ben > -Original Message- > From: Nico Huber [mailto:nic...@gmx.de] > Sent: Sunday, January 28, 2018 10:34 PM > To: You, Benjamin ; edk2-devel@lists.01.org > Cc: Arthur Heymans

Re: [edk2] [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into two parts

Hi Laszlo, We've found this issue. The patch for it has sent out at https://lists.01.org/pipermail/edk2-devel/2018-January/020467.html It will be checked in soon. Regards, Jian > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, January 29, 2018

Re: [edk2] [PATCH 4/6] UefiCpuPkg/PiSmmCpuDxeSmm: Enable NXE if it's supported

Hello Jian, On 01/15/18 09:54, Jian J Wang wrote: > If PcdDxeNxMemoryProtectionPolicy is set to enable protection for memory > of EfiBootServicesCode, EfiConventionalMemory, the BIOS will hang at a page > fault exception triggered by PiSmmCpuDxeSmm. > > The root cause is that PiSmmCpuDxeSmm will

Re: [edk2] [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into two parts

On 01/27/18 17:17, Laszlo Ersek wrote: > Hello Jian, > > On 01/15/18 09:54, Jian J Wang wrote: >> If PcdDxeNxMemoryProtectionPolicy is set to enable protection for memory >> of EfiBootServicesCode, EfiConventionalMemory, the BIOS will hang at a page >> fault exception during MP initialization. >>

Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine

Hi Ben, On 28.01.2018 09:49, You, Benjamin wrote: > Hi Nico, > > Thanks for the detailed information. It makes sense. I do like the idea of > documenting the lb_framebuffer. > >> The only guarantee for `bytes_per_pixel` (typo? 'bytes_per_scanline') yes, typo. >> and `x_resolution` you get as

Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine

Hi Nico, Thanks for the detailed information. It makes sense. I do like the idea of documenting the lb_framebuffer. > The only guarantee for `bytes_per_pixel` (typo? 'bytes_per_scanline') > and `x_resolution` you get as a consumer, is that the former is big > enough to hold `x_resolution`