[edk2] [PATCH v2 0/2] Fix unix style of EOL

> v2: Split patches per package Jian J Wang (2): MdeModulePkg: Fix unix style of EOL UefiCpuPkg: Fix unix style of EOL MdeModulePkg/Core/Dxe/DxeMain.inf |8 +- MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 2394

Re: [edk2] [PATCH v2 0/2] Fix unix style of EOL

The series is good to me. Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J > Wang > Sent: Monday, November 20, 2017 4:22 PM > To: edk2-devel@lists.01.org > Subject: [edk2]

[edk2] [PATCH v2 2/2] UefiCpuPkg: Fix unix style of EOL

Cc: Wu Hao Cc: Star Zeng Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang --- UefiCpuPkg/CpuDxe/CpuPageTable.c | 4 +-

Re: [edk2] [Patch] BaseTools: Guid.xref contain information from FILE statements in FDF

Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Yonghong Zhu >Sent: Thursday, November 16, 2017 5:14 PM >To: edk2-devel@lists.01.org >Cc: Dmitry Antipov ; Gao, Liming

Re: [edk2] [Patch] BaseTools: Fix a bug for single module build with GenC/GenMake option

Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Yonghong Zhu >Sent: Friday, November 17, 2017 12:03 PM >To: edk2-devel@lists.01.org >Cc: Gao, Liming >Subject: [edk2] [Patch]

Re: [edk2] [PATCH] MdeModulePkg EhciPei: Also check Buf against NULL to return error

Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Monday, November 20, 2017 3:33 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wu, Hao A; Yao, Jiewen > Subject: [PATCH] MdeModulePkg EhciPei: Also check Buf against NULL to

Re: [edk2] [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

Pete: Here, I suggest to mention VS version 15.2 or above, because vswhere.exe depends on this version. After later, you may also update this version to 15.4 for ARM and AARCH64 support. >-Original Message- >From: Pete Batard [mailto:p...@akeo.ie] >Sent: Friday, November 17, 2017

[edk2] [PATCH edk2-platforms 3/4] Platform/ARM/Juno: move to migrated FdtPlatformDxe

Move Juno to the migrated version of FdtPlatformDxe. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/JunoPkg/ArmJuno.dsc | 6 +++--- Platform/ARM/JunoPkg/ArmJuno.fdf | 2

[edk2] [PATCH edk2-platforms 1/4] Platform/ARM: import BdsLib from ArmPkg

We are about to migrate the only remaining user of the deprecated ARM BdsLib, i.e., FdtPlatformDxe, into Platform/ARM. So create our own copy of BdsLib, allowing us to finally remove it from upstream EDK2. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH edk2-platforms 2/4] Platform/ARM: import FdtPlatformDxe driver from EDK2

Import FdtPlatformDxe from EmbeddedPkg into Platform/ARM, given that it is not used anywhere else, nor should it be. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c | 461

[edk2] [PATCH edk2-platforms 0/4] Platform/ARM: import BdsLib and FdtPlatformDxe

The only remnant of the deprecated ARM BDS in EDK2 is its BdsLib, which is depended upon by FdtPlatformDxe in EmbeddedPkg, which itself is something we'd prefer to get rid of. Since only TC2 and Juno actually use this driver, let's move both FdtPlatformDxe and BdsLib under Platform/ARM, so that we

[edk2] [PATCH edk2-platforms 4/4] Platform/TC2: move to private FdtPlatformDxe implementation

Move to our own private copy of FdtPlatformDxe and BdsLib so that we can get rid of the upstream version. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 6 +++---

[edk2] [PATCH 1/2] EmbeddedPkg: remove FdtPlatformDxe

With the last users migrated to a private version, we can now remove FdtPlatformDxe. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c | 461 ---

[edk2] [PATCH 2/2] ArmPkg: remove BdsLib and remaining ARM BDS related PCDs

With the last user FdtPlatformDxe removed, we can finally get rid of the last bit of ARM BDS related cruft. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/ArmPkg.dec |8 -

[edk2] [PATCH 0/2] remove ARM BdsLib and FdtPlatformDxe

Remove two pieces of legacy that are only used by platforms residing under Platform/ARM in edk2-platforms, and really shouldn't serve as examples for new contributions. So after migrating the code to edk2-platforms, remove it from EDK2. Ard Biesheuvel (2): EmbeddedPkg: remove FdtPlatformDxe

Re: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

Rebecca, Thanks for your comment. I too did wonder that. However, "MM" abbreviation is used multiple times in PI Specification v1.5 "Volume 4: Management Mode Core Interface" Also, since the package is going to be called "StandaloneMmPkg" and not just MM, thereby avoiding intersection with

Re: [edk2] [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register values

Are we OK with pushing this patch-set? If so, is that something you can do, Ray? Thanks, Leo. > -Original Message- > From: Ni, Ruiyu [mailto:ruiyu...@intel.com] > Sent: Wednesday, November 08, 2017 12:30 AM > To: Duran, Leo ; edk2-devel@lists.01.org > Subject: RE:

Re: [edk2] [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

Hi Liming, On 2017.11.20 08:46, Gao, Liming wrote: Here, I suggest to mention VS version 15.2 or above, because vswhere.exe depends on this version. After later, you may also update this version to 15.4 for ARM and AARCH64 support. I assume you mean replacing the "Microsoft Visual

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

On 11/16/17 08:26, Jian J Wang wrote: > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really > set attributes and change memory paging attribute accordingly. > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by > value from Capabilities in GCD memory map. This might cause > boot

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

On 11/16/17 08:27, Jian J Wang wrote: >> v6: >>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP Another change relative to v5 is the fixing of the first DEBUG_WARN message -- in my v5 review I had missed that the DEBUG_WARN arguments didn't match the preceding

Re: [edk2] [PATCH v6 0/2] Fix multiple entries of RT_CODE in memory map

On 11/16/17 08:26, Jian J Wang wrote: >> v6 >> a. Add workaround in core to filter out all paging related capabilities. >>This is to fix boot issue in Fedora 26 and Windows Server 2016. >> b. Add code to check if EFI_MEMORY_XP should be added for GCD memory map > > More than one entry of

Re: [edk2] [Patch] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

Reviewed-by: Long Qin Best Regards & Thanks, LONG, Qin -Original Message- From: Wu, Jiaxin Sent: Friday, November 17, 2017 11:57 AM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Long, Qin ; Fu, Siyuan ; Wu,

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

Thanks for the comments. V7 patch has added one more variable so that MemoryMapStart will be kept intact. V7 added code to merge memory map after filtering. I have verified that the output keeps the same as v6 on both OVMF and our real platform (default platform configuration). I think it may be

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

You're right about XP/NX in this function. But from DxeCore or other drivers perspective, they have no knowledge of current capability of NX. I think it's the responsibility of cpu driver to add/remove it for the sake of GCD. Actually Star has filed a bz to use GCD service instead of CPU arch

[edk2] [PATCH v7 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

> v7: > Merge memory map after filtering code Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set attributes and change memory paging attribute accordingly. But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from Capabilities in GCD memory map. This might cause boot

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

> v7: >No change. > v6: >Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP > v5: >Coding style clean-up > 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

Re: [edk2] [PATCH v7 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

Reviewed-by: Star Zeng -Original Message- From: Wang, Jian J Sent: Tuesday, November 21, 2017 2:17 PM To: edk2-devel@lists.01.org Cc: Yao, Jiewen ; Zeng, Star ; Laszlo Ersek ; Ard Biesheuvel

[edk2] [platforms: PATCH v2 3/4] Marvell/Drivers: MvSpiDxe: Enable using driver in RT

This patch applies necessary modifications, which allow to use MvSpiDxe driver in variable support as a runtime service. The driver's type is modified to DXE_RUNTIME_DRIVER, as well as a new callback is introduced as a part of the SpiMasterProtocol. It configures the memory space for mmio access

[edk2] [platforms: PATCH v2 1/4] Platform/Marvell: Introduce MvFvbDxe variable support driver

MvFvbDxe driver introduces non-volatile EFI variable support for Armada platforms. It relies on memory-mapped SPI read access. Implementation of EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL is done with using existing Marvell SPI infrastructure (SpiMasterProtocol and SpiFlashProtocol), thanks to which this

[edk2] [platforms: PATCH v2 2/4] Marvell/Drivers: MvSpiFlash: Enable using driver in RT

This patch applies necessary modifications, which allow to use MvSpiFlash driver in variable support as a runtime service. Its type is modified to DXE_RUNTIME_DRIVER, as well as an event is created, which converts the pointers to the SpiMasterProtocol and its routines. In order to ensure proper

[edk2] [platforms: PATCH v2 0/4] Armada 7k/8k variable support

Hi, I submit v2 of the Armada variable support with the style of the MvFvbDxe driver fixed and other minor modifications. Depex configuration was moved from 4/4 to previous patches. Details can be found in the changelog and commit messages. Patches are available in the github:

[edk2] [platforms: PATCH v2 4/4] Marvell/Armada: Enable variables support

Wire up the non-volatile EFI variable store support, by switching from the emulation driver to the real one. Define default values for memory mapped SPI access, which must be configured by the early firmware. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas

[edk2] [PATCH edk2-non-osi 0/2] Fix Linaro RP bug 3464

We have found 2 bugs with Linaro Reference Platform bug 3464: https://bugs.linaro.org/show_bug.cgi?id=3464 1. SAS driver might use uninitialized value which would cause system exception; 2. LpcSerialPortLib used on D03 will cause SerialDxe initialized with failure and exited immediately, which

[edk2] [PATCH edk2-non-osi 1/2] Hisilicon/D0x/Sas: fix occasional exception

There is a temporary variable in SAS driver which was not initialized with SAS disk, so the value of this variable depends on the unknown stack content. Later it will be used as source buffer in gBS->CopyMem, and a translation fault exception would occur if the value is beyond valid memory address

[edk2] [PATCH edk2-non-osi 2/2] Hisilicon/LpcSerialPortLib: return SUCCESS for SetAttributes

After EDK2 upgrades to 91cc526, SerialDxe will exit immediately if SerialPortLib.SetAttributes returns error, and there will be no serial port terminal in UEFI BDS. Since Hisilicon LPC serial port does not support setting attributes, we change SerialPortSetAttributes in LpcSerialPortLib to simply

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Hi Jiewen, (sorry for the late response) On 11/17/2017 1:43 AM, Yao, Jiewen wrote: Thanks for your reply. Comments below: -Original Message- From: Paulo Alcantara [mailto:pca...@zytor.com] Sent: Friday, November 17, 2017 6:13 AM To: Yao, Jiewen Cc: Paulo

Re: [edk2] 答复: [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

Hi Jeff, (sorry for the late response) On 11/17/2017 5:24 AM, Fan Jeff wrote: Paulo, I don't understand why you - 1 when calculating EIP offset in image, it confused me. That's an offset relative to the PE/COFF image base: 0 - (ImageBase + ImageBaseSize - 1) Doesn't that look right to

Re: [edk2] [PATCH v2 0/4] UefiCpuPkg, OvmfPkg: add reset vector docs, tweak temp stack / RAM

Hi Laszlo, Reviewed-by: Eric Dong I'm ok with this change, Sorry for later response. Thanks, Eric > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Saturday, November 18, 2017 1:15 AM > To: edk2-devel-01 > Cc: