[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] SATA LED.

Enable SATA LED function on MinnowBoard3 Next pre-production board. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: zwei4 --- .../Board/MinnowBoard3Next/BoardInitPostMem/BoardGpios.h| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Change BIOS Version.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: lushifex --- Platform/BroxtonPlatformPkg/BiosId.env | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Platform/BroxtonPlatformPkg/BiosId.env

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Set Speed.

Add a temporary platform workaround to downgrade eMMC host from HS400 to HS200 on MinnowBoard 3 FAB B and MinnowBoard 3 Next Pre-production board. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: lushifex ---

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

On 30 November 2017 at 02:16, Wu, Hao A wrote: >> -Original Message- >> From: Zeng, Star >> Sent: Thursday, November 30, 2017 10:15 AM >> To: Wu, Hao A; Ard Biesheuvel >> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Kinney, Michael D; >> Gao, >> Liming;

Re: [edk2] [PATCH v2 0/3] BaseTools: Update Makefiles with clear ARCH and dependency

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Tuesday, November 28, 2017 11:19 AM To: edk2-devel@lists.01.org Subject: [edk2] [PATCH v2 0/3]

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

Hi Leif, Mike, NXP boards, at present, have few controllers with big endian and other with little endian memory access. Maximum controllers depend on SocLib library for clock information and endianness for SocLib and controllers is different. So this option will not work for us, You would

Re: [edk2] [PATCH 0/2] Enable page table write protection

I also noticed that, in the cpu driver, there's a potential recursive calling of CpuArchProtocol->SetMemoryAttributes() which is caused by page table allocation: (cpu)SetMemoryAttributes() -> (cpu) AssignMemoryPageAttributes () -> ->

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

> -Original Message- > From: Zeng, Star > Sent: Thursday, November 30, 2017 10:15 AM > To: Wu, Hao A; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Kinney, Michael D; Gao, > Liming; Tian, Feng; Dong, Eric; Zeng, Star > Subject: RE: [RFC PATCH 0/2] quirks handling

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

Hao, IN EFI_SD_MMC_PASS_THRU_PROTOCOL*PassThru Right? Thanks, Star -Original Message- From: Wu, Hao A Sent: Thursday, November 30, 2017 10:11 AM To: Ard Biesheuvel Cc: Zeng, Star ; edk2-devel@lists.01.org;

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

Fix one typo in previous reply. Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu, > Hao A > Sent: Thursday, November 30, 2017 10:11 AM > To: Ard Biesheuvel > Cc: Tian, Feng; Dong, Eric; edk2-devel@lists.01.org; Gao,

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

> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, November 23, 2017 8:57 PM > To: Wu, Hao A > Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindh...@linaro.org; Kinney, > Michael D; Gao, Liming; Tian, Feng; Dong, Eric > Subject: Re: [RFC PATCH

Re: [edk2] [PATCH 0/2] Enable page table write protection

That's a better idea. Maybe we don't to free them but just reserve it for future uses. The reserved 2MB page table can manage 1GB memory. I think in BIOS time typical memory usage I observed is far less than that. > -Original Message- > From: Yao, Jiewen > Sent: Thursday, November 30,

Re: [edk2] [PATCH 0/2] Enable page table write protection

Clarify my word below: Can you just predict and pre-allocate additional pages for future split in worst case? If new one need split, you can just use the additional pages. If not, you can free them later. For example, you can allocate 2M aligned memory for new pages, for make sure they are in

Re: [edk2] [PATCH 0/2] Enable page table write protection

Good idea. I think it will highly reduce the possibility but not solve it still. The dilemma here is: do we need to take care of it? This issue exists in theory but has not yet been encountered in practice. > -Original Message- > From: Yao, Jiewen > Sent: Thursday, November 30, 2017 9:36

Re: [edk2] [PATCH 0/2] Enable page table write protection

Clarify my word below: Can you just predict and pre-allocate additional pages for future split in worst case? If new one need split, you can just use the additional pages. If not, you can free them later. For example, you can allocate 2M aligned memory for new pages, for make sure they are in

Re: [edk2] [PATCH 0/2] Enable page table write protection

> On Nov 29, 2017, at 5:16 PM, Wang, Jian J wrote: > > When you split page tables, you need to allocate new pages for new page table. > Since you have new page tables added, you need to mark them to be read-only > as well, right? When you do this, the page table for the

Re: [edk2] [PATCH 0/2] Enable page table write protection

Can you just allocate 1 more page for split? If new one need split, you can just use the additional page. If not, you can free it later. Thank you Yao Jiewen > -Original Message- > From: Wang, Jian J > Sent: Thursday, November 30, 2017 9:17 AM > To: Yao, Jiewen >

Re: [edk2] [PATCH 0/2] Enable page table write protection

When you split page tables, you need to allocate new pages for new page table. Since you have new page tables added, you need to mark them to be read-only as well, right? When you do this, the page table for the memory newly allocated might still needs to be split. This is the worst case but

Re: [edk2] [PATCH v3 0/3] MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported

Reviewed-by: Star Zeng and pushed the patches at https://github.com/tianocore/edk2/compare/f1f7190bf3bf...7ce5af40c98b with the typo (pointed out by Laszlo) fixed in [Patch 2/3]. Thanks, Star -Original Message- From: Julien Grall [mailto:julien.gr...@linaro.org]

Re: [edk2] [PATCH 0/2] Enable page table write protection

-- whenever you're trying to mark one page used as page table to be read-only, you need to split its page table in advance [Jiewen] Sorry, I do not quite understand the problem statement. To set a page to be ReadOnly, you just flip the R/W bit in the page entry. The step I expect is: 1) You split

Re: [edk2] [PATCH 0/2] Enable page table write protection

I did think of protecting new page table in cpu driver. But I think there's risks to do it, which is that there might be a chance that, whenever you're trying to mark one page used as page table to be read-only, you need to split its page table in advance, and again and again, until all page

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

Haven't had time to look at it yet, but if you've done what you said you were doing, I expect so. Hopefully tomorrow. On Wed, Nov 29, 2017 at 10:35:59PM +0100, Marcin Wojtas wrote: > Hi Leif, > > Would you consider this version of the patch acceptable? > > Best regards, > Marcin > > 2017-11-28

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

Hi Leif, Would you consider this version of the patch acceptable? Best regards, Marcin 2017-11-28 9:19 GMT+01:00 Marcin Wojtas : > MvFvbDxe driver introduces non-volatile EFI variable support > for Armada platforms. It relies on memory-mapped SPI read access. > Implementation

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

I guess there is no strict rule about a driver only directly accessing one piece of HW? Still, that would be one possible solution: breaking accesses to a separate HW in need of byteswapping out into its own module and letting it override IoLib version there. Regards, Leif On Wed, Nov 29, 2017

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

Leif, I agree that this should be described as byte swapping. What about a module that needs to access HW with and without the bytes swapped? It gets more complex if a module is linked against several libs and some libs access HW with bytes swapped and some do not. Thanks, Mike >

Re: [edk2] [PATCH edk2-platforms] Silicon/SynQuacerPciHostBridgeLib: fix weird indentation

Hi Ard, On 11/29/17 19:35, Ard Biesheuvel wrote: > Fix the weird indentation in the various #defines in the file containing > the RC init code. This is a whitespace only change. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH edk2-platforms] Silicon/SynQuacerPciHostBridgeLib: fix weird indentation

On Wed, Nov 29, 2017 at 06:35:05PM +, Ard Biesheuvel wrote: > Fix the weird indentation in the various #defines in the file containing > the RC init code. This is a whitespace only change. I did notice this when reviewing it originally, but since it was completely consistent I didn't raise

Re: [edk2] [PATCH edk2-platforms] Silicon/SynQuacerPciHostBridgeLib: enable Gen2 speed

On Wed, Nov 29, 2017 at 06:44:59PM +, Ard Biesheuvel wrote: > As it turns out, getting the PCIe controllers to switch to Gen2 speed > is surprisingly easy. It only involves setting the 'speed change' bit > in the controller at initialization time, after which the hardware > will automatically

[edk2] [PATCH edk2-platforms] Silicon/SynQuacerPciHostBridgeLib: enable Gen2 speed

As it turns out, getting the PCIe controllers to switch to Gen2 speed is surprisingly easy. It only involves setting the 'speed change' bit in the controller at initialization time, after which the hardware will automatically attempt to switch to Gen2 speed after training at Gen1 speed has

[edk2] [PATCH edk2-platforms] Silicon/SynQuacerPciHostBridgeLib: fix weird indentation

Fix the weird indentation in the various #defines in the file containing the RC init code. This is a whitespace only change. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel ---

Re: [edk2] [PATCH v3 2/3] MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes

On 11/29/17 18:28, Julien Grall wrote: > SerialSetAttributes is meant to match the behavior of the function > EFI_SERIAL_IO_PROTOCOL.SetAttributes() in the UEFI spec (v2.7). This > means the function can only return: > - EFI_SUCCESS > - EFI_INVALID_PARAMETER > - EFI_DEVICE_ERROR > >

[edk2] [PATCH v3 2/3] MdeModulePkg/SerialDxe: Fix return valued in SerialSetAttributes

SerialSetAttributes is meant to match the behavior of the function EFI_SERIAL_IO_PROTOCOL.SetAttributes() in the UEFI spec (v2.7). This means the function can only return: - EFI_SUCCESS - EFI_INVALID_PARAMETER - EFI_DEVICE_ERROR However the function SerialPortSetAttributes may also

[edk2] [PATCH v3 1/3] MdeModulePkg/SerialDxe: Describe correctly EFI_DEVICE_ERROR for SetAttributes

Per the UEFIv2.7 spec, EFI_DEVICE_ERROR is returned when the serial device is not functioning correctly. Update the description to avoid confusion. Contributed-under: Tianocore Contribution Agreement 1.1 Signed-off-by: Julien Grall Reviewed-by: Star Zeng

[edk2] [PATCH v3 3/3] MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported

After commit 91cc526b15 "MdeModulePkg/SerialDxe: Fix not able to change serial attributes", serial is initialized using the reset method that will call SetAttributes. However, SetAttributes may return EFI_INVALID_PARAMETER when a driver does not support some parameters. This will be propagated by

[edk2] [PATCH v3 0/3] MdeModulePkg/SerialDxe: Do not fail reset when SetAttributes is not supported

Hi all, This is another attempt to fix the console issue when using UEFI in Xen guest. This new series is based on Laszlo suggestions on the previous version (see [1]). For all the changes see in each patch. Cheers, [1] https://lists.01.org/pipermail/edk2-devel/2017-October/016181.html

[edk2] [Patch 2/4 V3] BaseTools: Update Trim to generate VfrBinOffset Binary

Its usage is "Trim --Vfr-Uni-Offset -o $(OUTPUT_DIR)(+)$(MODULE_NAME)VfrOffset.sec --ModuleName=$(MODULE_NAME) --DebugDir=$(DEBUG_DIR)" Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao --- BaseTools/Source/Python/Trim/Trim.py | 81

[edk2] [Patch 1/4 V3] BaseTools: GenFfs support to get alignment value from SectionFile

Update GenFfs tool to get alignment value from SectionFile when use the new option -n 0. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu --- BaseTools/Source/C/GenFfs/GenFfs.c | 135

[edk2] [Patch 3/4 V3] BaseTools: Update Gensec to set PROCESSING_REQUIRED value

This patch add new option --dummy file, and we compare the dummpy file with input file to decide whether we need to set PROCESSING_REQUIRED value. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yunhua Feng ---

[edk2] [Patch 0/4 V3] BaseTools: Enable multiple thread to generate FFS file

V3: add a new build option --genfds-multi-thread for this feature, default is False. These patches enable multiple thread to generate ffs file by merge FFS file's generation into Make phase. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1

Re: [edk2] [PATCH v4 2/3] ArmVirtPkg: Fix build failure due to Tftp library removal

Ray, On 11/29/17 11:14, Ruiyu Ni wrote: > The TFTP command was converted from a NULL class library > instance to a dynamic shell command in commit 0961002352e9. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Reviewed-by: Laszlo Ersek

Re: [edk2] [PATCH 0/2] Enable page table write protection

I do think we need update CPU driver to protect new allocated split page. If you verified in shell env, I think it will exposed, please add a test to trigger page split in CPU driver. I recommend to write some unit test to parse page table in shell. thank you! Yao, Jiewen > 在

Re: [edk2] [PATCH v3 6/6] OvmfPkg: Add tftp dynamic command

> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, November 29, 2017 6:54 PM > To: Ni, Ruiyu ; edk2-devel@lists.01.org > Cc: Anthony Perard ; Justen, Jordan L > ; Ard Biesheuvel

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

Hi Meenakshi, I finally got around to looking at the watchdog code (that uses this library), and that has convinced me the best solution is to do what Liming proposed. Looking at this snippet: > +STATIC > +UINT16 > +EFIAPI > +WdogRead ( > +  IN  UINTN     Address > +  ) > +{ > +  if

Re: [edk2] [PATCH 0/2] Enable page table write protection

There's already issue found. So there must be v2. Please wait for it. > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, November 29, 2017 8:39 PM > To: Wang, Jian J > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH

Re: [edk2] [PATCH 0/2] Move MicrocodeUpdate from UefiCpuPkg to IntelSiliconPkg

Reviewed-by: Eric Dong -Original Message- From: Zeng, Star Sent: Wednesday, November 29, 2017 12:59 PM To: edk2-devel@lists.01.org Cc: Zeng, Star; Yao, Jiewen; Kinney, Michael D; Dong, Eric; Laszlo Ersek Subject: [PATCH 0/2] Move MicrocodeUpdate from UefiCpuPkg to

Re: [edk2] [PATCH 0/2] Enable page table write protection

Hi Jian, On 11/29/17 09:46, Jian J Wang wrote: > Write Protect feature (CR0.WP) is always enabled in driver UefiCpuPkg/CpuDxe. > But the memory pages used for page table are not set as read-only in the > driver > DxeIplPeim, after the paging is setup. This might jeopardize the page table >

Re: [edk2] [PATCH] MdeModulePkg/PerformanceLib: add lock protection

Pushed the patch at f1f7190bf3bf932b52287258a65c366ed5bdce13 after updating the title to "MdeModulePkg/DxeCorePerformanceLib: add lock protection" and removing a redundant "with". Thanks, Star -Original Message- From: Heyi Guo [mailto:heyi@linaro.org] Sent: Monday, November 27,

Re: [edk2] [PATCH 0/2] Move MicrocodeUpdate from UefiCpuPkg to IntelSiliconPkg

On 11/29/17 05:58, Star Zeng wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=540 > > To consume FIT table for Microcode update, > UefiCpuPkg/Feature/Capsule/MicrocodeUpdateDxe > needs to be updated to consume > IntelSiliconPkg/Include/IndustryStandard/FirmwareInterfaceTable.h, > but

Re: [edk2] [PATCH 0/2] Enable page table write protection

It's in the DxeIplPeim. By the way, there's an issue in this patch. I forgot to protect page table for 32-bit mode. So this patch works only for 64-bit mode. I'll add it in v2 patch. > -Original Message- > From: Yao, Jiewen > Sent: Wednesday, November 29, 2017 6:56 PM > To: Wang, Jian

Re: [edk2] [PATCH v4 3/3] BeagleBoardPkg: Fix build failure due to Tftp library removal

On Wed, Nov 29, 2017 at 06:15:00PM +0800, Ruiyu Ni wrote: > The TFTP command was converted from a NULL class library > instance to a dynamic shell command in commit 0961002352e9. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Leif

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

On 11/29/17 01:59, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Laszlo Ersek > Cc: Ard Biesheuvel > Cc: Julien Grall > --- >

Re: [edk2] [PATCH 0/2] Enable page table write protection

Is this code in CPU driver? thank you! Yao, Jiewen > 在 2017年11月29日，下午6:24，Wang, Jian J 写道： > > Yes, I validated them manually with JTAG debug tool. > > if ((L3PageTable[Index3] & IA32_PG_PS) != 0) { > // 1G page. Split to 2M. > L2PageTable = AllocatePages (1); >

Re: [edk2] [PATCH v3 6/6] OvmfPkg: Add tftp dynamic command

Hi Ray, On 11/29/17 01:59, Ruiyu Ni wrote: > The TFTP command was converted from a NULL class library instance > to a dynamic shell command in commit 0961002352e9. > This patch complements commit f9bc2f876326, which only removed the > old library, but didn't add the new dynamic command。 > >

Re: [edk2] [PATCH 0/2] Enable page table write protection

Yes, I validated them manually with JTAG debug tool. if ((L3PageTable[Index3] & IA32_PG_PS) != 0) { // 1G page. Split to 2M. L2PageTable = AllocatePages (1); ASSERT (L2PageTable != NULL); PhysicalAddress = L3PageTable[Index3] & PAGING_1G_ADDRESS_MASK_64; for (Index = 0; Index <

[edk2] [PATCH v4 3/3] BeagleBoardPkg: Fix build failure due to Tftp library removal

The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Leif Lindholm Reviewed-by: Ard Biesheuvel

[edk2] [PATCH V2 4/4] MdeModulePkg DxeCore: Support USED_SIZE FV_EXT_TYPE

The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV. When the FV gets shadowed into memory you only need to copy the used bytes into memory and fill the

[edk2] [PATCH v4 2/3] ArmVirtPkg: Fix build failure due to Tftp library removal

The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Laszlo Ersek Cc: Ard Biesheuvel

[edk2] [PATCH v4 1/3] EmulatorPkg: Fix build failure due to Tftp library removal

The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Jordan Justen Cc: Andrew Fish

[edk2] [PATCH v4 0/3] Fix build failure due to tftp/dp library removal

commit 0961002 and 92034c4 converted the tftp and dp from NULL class library to dynamic command drivers. Some platforms referencing the original tftp/dp NULL class libraries need the platform DSC/FDF change to reference to the new dynamic command drivers. v4: Revise the commit message to mention

[edk2] [PATCH V2 1/4] MdePkg PiFirmwareVolume.h: Add USED_SIZE FV_EXT_TYPE definitions

The definitions are introduced by PI 1.6 spec. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV. When the FV gets shadowed into memory you only need to copy the used bytes into memory and fill the rest of the

[edk2] [PATCH V2 3/4] MdeModulePkg DxeCore: Check FvImage alignment

No need to allocate aligned buffer if FvImage has been at required alignment. Then the code logic will be aligned with ProcessFvFile() in MdeModulePkg/Core/Pei/FwVol/FwVol.c. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng

[edk2] [PATCH 0/4] Add USED_SIZE FV_EXT_TYPE support

V2: The first version did not adjust ExtEntryList in the while loop of [PATCH 2/4] and [PATCH 4/4], it is a bug and fixed in this V2. The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find out how many EFI_FVB2_ERASE_POLARITY

[edk2] [PATCH V2 2/4] MdeModulePkg PeiCore: Support USED_SIZE FV_EXT_TYPE

The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV. When the FV gets shadowed into memory you only need to copy the used bytes into memory and fill the

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

On 29 November 2017 at 10:03, Ni, Ruiyu wrote: > I see. Thanks. > I will revise the commit message and send out in V4. > > BTW, which mail client are you using? I use the Gmail web interface. > All mails from lists.01.org are flatly shown in my Outlook, which is very hard >

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

I see. Thanks. I will revise the commit message and send out in V4. BTW, which mail client are you using? All mails from lists.01.org are flatly shown in my Outlook, which is very hard to track. Thanks/Ray > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

On 29 November 2017 at 09:57, Ni, Ruiyu wrote: > I didn't see Laszlo provided any comments for this patch. https://lists.01.org/pipermail/edk2-devel/2017-November/018124.html > Did you mean the below comments from him for OvmfPkg's change? > > (1) Please add the following to

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

I didn't see Laszlo provided any comments for this patch. Did you mean the below comments from him for OvmfPkg's change? (1) Please add the following to the commit message: "The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. This

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

On 29 November 2017 at 09:36, Ni, Ruiyu wrote: > Ard, > Would you mind to give a r-b for this patch? > Hi Ray, Could you please incorporate the feedback you received from Laszlo first? Thanks. > >> -Original Message- >> From: edk2-devel

Re: [edk2] [PATCH v3 3/6] ArmVirtPkg: Fix build failure due to Tftp library removal

Ard, Would you mind to give a r-b for this patch? Thanks/Ray > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ruiyu Ni > Sent: Wednesday, November 29, 2017 9:00 AM > To: edk2-devel@lists.01.org > Cc: Laszlo Ersek ; Ard

Re: [edk2] [PATCH 0/2] Enable page table write protection

Thanks. May I know if this is validated in uefi shell, that all page table is readonly? I did not find the code to set new allocated split page to be readonly. Can you give me a hand on that? thank you! Yao, Jiewen > 在 2017年11月29日，下午4:47，Jian J Wang 写道： > > Write

[edk2] [PATCH 2/2] MdeModulePkg/DxeIpl: Mark page table as read-only

This patch will set the memory pages used for page table as read-only memory after the paging is setup. CR0.WP must set to let it take into effect. Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Contributed-under: TianoCore

[edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: Check CR0.WP before changing page table

The CPU driver will always set CR0.WP if paging is enabled. GetCurrentPagingContext(): if ((AsmReadCr0 () & BIT31) != 0) { PagingContext->ContextData.X64.PageTableBase = (AsmReadCr3 () & PAGING_4K_ADDRESS_MASK_64); if ((AsmReadCr0 () & BIT16) ==

[edk2] [PATCH 0/2] Enable page table write protection

Write Protect feature (CR0.WP) is always enabled in driver UefiCpuPkg/CpuDxe. But the memory pages used for page table are not set as read-only in the driver DxeIplPeim, after the paging is setup. This might jeopardize the page table integrity if there's buffer overflow occured in other part of

Re: [edk2] [PATCH v3 4/6] BeagleBoardPkg: Fix build failure due to Tftp library removal

On 29 November 2017 at 08:28, Ni, Ruiyu wrote: > Ard, > PcdShellLibAutoInitialize is specially set to FALSE in old code for Shell.efi > build. > But in old code line 507, it is set FALSE for Shell.efi build. > So the global setting of this PCD can be removed. > OK, fair

Re: [edk2] [PATCH 1/2] Vlv2TbltDevicePkg: Use DpDynamicCommand to replace PerformancePkg/dp

Reviewed-by: zwei4 Thanks, David Wei Intel SSG/STO/UEFI BIOS > -Original Message- > From: Ni, Ruiyu > Sent: Wednesday, November 29, 2017 4:15 PM > To: edk2-devel@lists.01.org > Cc: Wei, David > Subject:

Re: [edk2] [PATCH v3 4/6] BeagleBoardPkg: Fix build failure due to Tftp library removal

Ard, PcdShellLibAutoInitialize is specially set to FALSE in old code for Shell.efi build. But in old code line 507, it is set FALSE for Shell.efi build. So the global setting of this PCD can be removed. Thanks/Ray > -Original Message- > From: Ard Biesheuvel

[edk2] [PATCH] ShellPkg/ShellPkg.dec: Change comments for PcdShellLibAutoInitialize

When Dynamic command drivers links to ShellLib, the ShellLib constructor shouldn't be called because the Shell and ShellParameters protocols don't exist when the driver starts. So it's required to set PcdShellLibAutoInitialize to FALSE for dynamic command drivers. Update the comments in DEC file

[edk2] [PATCH 1/2] Vlv2TbltDevicePkg: Use DpDynamicCommand to replace PerformancePkg/dp

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: David David --- Vlv2TbltDevicePkg/PlatformPkg.fdf | 9 +++-- Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 9 +++-- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc |

[edk2] [PATCH 2/2] QuarkPlatformPkg: Use DpDynamicCommand to replace PerformancePkg/dp

Remove FvSimpleFileSystemDxe from Quark.dsc/fdf because it's not needed by using DpDynamicCommand driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Michael D Kinney Cc: Kelly Steele

[edk2] [PATCH 0/2] Use DpDynamicCommand to replace PerformancePkg/dp

Ruiyu Ni (2): Vlv2TbltDevicePkg: Use DpDynamicCommand to replace PerformancePkg/dp QuarkPlatformPkg: Use DpDynamicCommand to replace PerformancePkg/dp QuarkPlatformPkg/Quark.dsc | 15 +++ QuarkPlatformPkg/Quark.fdf | 16 +---

Re: [edk2] [PATCH v3 0/4] Add VS2017 tool chain for evaluation

Push them in edk2 trunk. >-Original Message- >From: Zhu, Yonghong >Sent: Tuesday, November 28, 2017 9:56 AM >To: Pete Batard ; edk2-devel@lists.01.org >Cc: Gao, Liming ; Zhu, Yonghong > >Subject: RE: [edk2] [PATCH v3 0/4] Add