Re: [edk2] [PATCH V2 09/12] ArmPlatformPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg

On 17 November 2015 at 12:07, Star Zeng wrote: > It is also to integrate PL011SerialPortExtLib to PL011SerialPortLib. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Leif Lindholm > Cc: Ard

Re: [edk2] [PATCH v3 2/4] ArmVirtPkg/ArmVirtPlatformLib: do not map executable NOR region as device

On 11/19/2015 01:54 PM, Ard Biesheuvel wrote: On 19 November 2015 at 00:55, Heyi Guo wrote: On 11/18/2015 04:25 PM, Ard Biesheuvel wrote: The ARM architecture version 7 and later mandates that device mappings have the XN (non-executable) bit set, to prevent speculative

Re: [edk2] [PATCH v2] ShellPkg: Corrected CatSPrint usage to prevent memory leaks.

Reviewed-by: Qiu Shumin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cecil Sheng Sent: Wednesday, November 18, 2015 4:54 PM To: edk2-devel@lists.01.org Cc: Cecil Sheng Subject: [edk2] [PATCH v2] ShellPkg: Corrected

Re: [edk2] [PATCH] ArmPkg: ArmLib: purge incorrect ArmDrainWriteBuffer () alias

On Thu, Nov 19, 2015 at 04:25:31PM +, Leif Lindholm wrote: > In ArmLib, there exists an alias for ArmDataSynchronizationBarrier, > named after one of several names for the pre-ARMv6 cp15 operation that > was formalised into the Data Synchronization Barrier in ARMv6. > > This alias is also the

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

If we strictly follow the spec, it's only needed to save the century value in CMOS when FADT.CenturyOffset is not zero. But the fact is even we set the FADT.CenturyOffset to 0 indicating the platform doesn't store century value in CMOS, UEFI Win7 still hang during booting until we updates the

Re: [edk2] Ip4Config to Ip4Config2 Transition

Hi Eugene, Yes, the setting data will be stored in the NV variable named by the every NIC's MacString. The driver try to read those config data from NV variable when it started. You don't lose your configuration data after you do some manual setting. Thanks. Jiaxin From: Cohen, Eugene

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

On 18/11/2015 06:08, Zeng, Star wrote: > > @@ -508,6 +509,7 @@ PcRtcSetTime ( > RtcWrite (RTC_ADDRESS_DAY_OF_THE_MONTH, RtcTime.Day); > RtcWrite (RTC_ADDRESS_MONTH, RtcTime.Month); > RtcWrite (RTC_ADDRESS_YEAR, (UINT8) RtcTime.Year); > + RtcWrite (RTC_ADDRESS_CENTURY, Century);

Re: [edk2] [PATCH V2 08/12] BeagleBoardPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg

On 17 November 2015 at 12:07, Star Zeng wrote: > It is also to remove the reference to TemplateSerialPortExtLib in EmbeddedPkg. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Leif Lindholm > Cc:

Re: [edk2] [PATCH V2 12/12] EmbeddedPkg: Remove SerialDxe and SerialPortExtLib libraries

On 17 November 2015 at 12:07, Star Zeng wrote: > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Leif Lindholm > Cc: Ard Biesheuvel > Contributed-under: TianoCore

Re: [edk2] ArmPkg: Dead code stripping

On Thu, Nov 19, 2015 at 03:45:16PM +0100, Ard Biesheuvel wrote: > (+ Leif) > > On 19 November 2015 at 15:42, Cohen, Eugene wrote: > > Ok, I created a script after all - I went ahead and created a > > script to add AREA directives whenever an exported label is found. > > > > Same

Re: [edk2] [PATCH V2 00/12] Upstream SerialDxe from EmbeddedPkg to MdeModulePkg

I have received feedback to this patch series for most packages, except EmulatorPkg and Omap35xxPkg. Thanks very much. I have addressed the comments from Laszlo and Mike in my local git tree. You can see it at g...@github.com:lzeng14/edk2.git branch SerialDxeV3_WIP. I plan to send out the V3

Re: [edk2] Ip4Config to Ip4Config2 Transition

Hi Eugene, Are you asking whether the new driver producing Ip4Config2 protocol can support the previous network setting configured by old driver producing Ip4Config protocol in NVRAM? If yes, I think the answer is no. I think what Jiaxin says is that the new driver will save the configuration

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: ]Sent: Thursday, November 19, 2015 06:37 PM ]To: Paolo Bonzini ; Zeng, Star ; edk2-devel@lists.01.org ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

[edk2] [PATCH v2 6/6] Nt32Pkg:To support new UiApp

Add the new added libraries to the Nt32 platform. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Liming Gao

[edk2] [PATCH v2 5/6] MdeModulePkg: To support new UiApp

Add the new added Guid and libraries to the dec and dsc file in MdeModulePkg. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong

Re: [edk2] [PATCH v4 14/41] OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE

Reviewed-by: Jordan Justen On 2015-11-03 13:00:50, Laszlo Ersek wrote: > During DXE, drivers save data in the LockBox. A save operation is layered > as follows: > > - The unprivileged driver wishing to store data in the LockBox links > against the

[edk2] [PATCH] ArmPkg: ArmLib: purge incorrect ArmDrainWriteBuffer () alias

In ArmLib, there exists an alias for ArmDataSynchronizationBarrier, named after one of several names for the pre-ARMv6 cp15 operation that was formalised into the Data Synchronization Barrier in ARMv6. This alias is also the one called from within ArmLib, in preference of the correct name.

Re: [edk2] Bugs in NvmExpressPkg

Updating cc list to edk2-devel@lists.01.org rather than edk2-de...@lists.sourceforge.net Please note the later has been deprecated. From: Tian, Feng Sent: Friday, November 20, 2015 10:16 To: Simon (Xiang) Lian-SSI Cc:

[edk2] [PATCH v2 1/6] MdeModulePkg:Create Boot Manager Library

Split the boot manager library from UiApp in MdeModulePkg/Application and put the library in MdeModulePkg/Library. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi

[edk2] [PATCH v2 0/6] UiApp remodeling task

Our current UiApp code is huge and hard to understand and maintain. So we split it to several independent libraries:device manager,boot manager, boot maintenance manager.Make the code clear and easy to maintain. The v2 has following updateing: Remove gEfiSetupEnterGuid and do the initialization

[edk2] [PATCH v2 2/6] MdeModulePkg:Create Device Manager Library

Split the device manager library from UiApp in MdeModulePkg/Application and put the library in MdeModulePkg/Library. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi

Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance with x2apic support if SMM_REQUIRE

On 2015-11-04 17:04:34, Laszlo Ersek wrote: > On 11/04/15 22:35, Kinney, Michael D wrote: > > Laszlo, > > > > Yes. They are compatible. And I do recommend switching to > > BaseXApicX2ApicLib unconditionally. > > Thanks everyone for the feedback, I'll update the patch. With that change:

Re: [edk2] [PATCH] ArmPkg: Flush cache after allocating UC memory

On 20 November 2015 at 06:32, Heyi Guo wrote: > It is implied that the memory returned from UncachedMemoryAllocationLib > should have cache cleaned. So we clean and invalidate memory range after > changing memory attribute to uncached. > > Contributed-under: TianoCore

Re: [edk2] [PATCH v4 19/41] OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSE

Reviewed-by: Jordan Justen On 2015-11-03 13:00:55, Laszlo Ersek wrote: > Explanation from Michael Kinney: > > This PCD allows a platform to provide PlatformSmmBspElection() in a > platform specific SmmCpuPlatformHookLib instance to decide which CPU > gets

Re: [edk2] [PATCH V2 07/12] Omap35xxPkg SerialPortLib: Add GetControl/SetControl/SetAttributes implementation

On 17 November 2015 at 12:07, Star Zeng wrote: > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Leif Lindholm > Cc: Ard Biesheuvel > Contributed-under: TianoCore

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

Scott, The UEFI Windows 7 is fresh installed. Could you please tell me how to check whether a platform turns on the RTC alarm? Thanks, Ray > 在 2015年11月20日，10:49，Scott Duplichan 写道： > > Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: > > ]Sent: Thursday, November 19, 2015 06:37

Re: [edk2] ArmPkg: Dead code stripping

Ok, I created a script after all - I went ahead and created a script to add AREA directives whenever an exported label is found. Same question as before: do you want me to submit a patchset with the AREA prefixes added or do you (Ard/Leif) want to handle this? Contributed-under: TianoCore

Re: [edk2] [PATCH] ArmPkg/ArmPlatformPkg: position vectors relative to base

On Thu, Nov 19, 2015 at 03:42:51PM +0100, Ard Biesheuvel wrote: > On 19 November 2015 at 14:44, Mark Rutland wrote: > > We currently rely on .align directives to ensure that each exception > > vector entry is the appropriate offset from the vector base address. > > > > This

Re: [edk2] [PATCH] ArmPkg/ArmPlatformPkg: position vectors relative to base

On 19 November 2015 at 14:44, Mark Rutland wrote: > We currently rely on .align directives to ensure that each exception > vector entry is the appropriate offset from the vector base address. > > This is slightly fragile, as were an entry to become too large (greater > than

Re: [edk2] [PATCH] ArmPkg: correct TCR_EL1 TTBR1_EL1 settings

On 19 November 2015 at 14:43, Mark Rutland wrote: > As EDK2 runs in an idmap, we do not use TTBR1_EL1, nor do we configure > it. TTBR1_EL1 may contain UNKNOWN values if it is not programmed since > reset. > > Prior to enabling the MMU, we do not set TCR_EL1.EPD1, and hence

Re: [edk2] ArmPkg: Dead code stripping

(+ Leif) On 19 November 2015 at 15:42, Cohen, Eugene wrote: > Ok, I created a script after all - I went ahead and created a script to add > AREA directives whenever an exported label is found. > > Same question as before: do you want me to submit a patchset with the AREA >

[edk2] Ip4Config to Ip4Config2 Transition

Jiaxin Wu, I'm updating edk2 to a new version that includes the removal of legacy Ip4Config and addition of the new Ip4Config2 protocol. I'm wondering what this does to network settings already stored in NVRAM? Does the data get lost or will the new driver preserve the existing settings?