Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Hao A > Sent: Wednesday, April 03, 2019 3:27 PM > To: Zhang, Shenglei; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove > AsmFuncs.S in INF > > Reviewed-by: Hao Wu > > I will push this patch shortly to address the build failure for > SourceLevelDebugPkg. Pushed via commit 7ed72121b753a7493a8c5bf3711b5efbc5e80491. > > Best Regards, > Hao Wu > > > > -Original Message- > > From: Zhang, Shenglei > > Sent: Wednesday, April 03, 2019 2:32 PM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A; Zhang, Shenglei > > Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove > AsmFuncs.S > > in INF > > > > AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680. > > And also it should be removed in SecPeiDebugAgentLib.inf and > > SmmDebugAgentLib.inf. > > > > Cc: Hao Wu > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Shenglei Zhang > > --- > > SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 - > - > > SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 - > - > > 2 files changed, 4 deletions(-) > > > > diff --git > > a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > index 03ebbb6e74..8b81795d96 100644 > > --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > +++ > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > @@ -39,14 +39,12 @@ > >DebugAgentCommon/DebugMp.h > > > > [Sources.Ia32] > > - DebugAgentCommon/Ia32/AsmFuncs.S > >DebugAgentCommon/Ia32/AsmFuncs.nasm > >DebugAgentCommon/Ia32/ArchDebugSupport.h > >DebugAgentCommon/Ia32/ArchDebugSupport.c > >DebugAgentCommon/Ia32/DebugException.h > > > > [Sources.X64] > > - DebugAgentCommon/X64/AsmFuncs.S > >DebugAgentCommon/X64/AsmFuncs.nasm > >DebugAgentCommon/X64/ArchDebugSupport.h > >DebugAgentCommon/X64/ArchDebugSupport.c > > diff --git > > a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > index 08ed1777be..f1b32daab3 100644 > > --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > @@ -39,14 +39,12 @@ > >DebugAgentCommon/DebugMp.h > > > > [Sources.Ia32] > > - DebugAgentCommon/Ia32/AsmFuncs.S > >DebugAgentCommon/Ia32/AsmFuncs.nasm > >DebugAgentCommon/Ia32/ArchDebugSupport.h > >DebugAgentCommon/Ia32/ArchDebugSupport.c > >DebugAgentCommon/Ia32/DebugException.h > > > > [Sources.X64] > > - DebugAgentCommon/X64/AsmFuncs.S > >DebugAgentCommon/X64/AsmFuncs.nasm > >DebugAgentCommon/X64/ArchDebugSupport.h > >DebugAgentCommon/X64/ArchDebugSupport.c > > -- > > 2.18.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF
Reviewed-by: Hao Wu I will push this patch shortly to address the build failure for SourceLevelDebugPkg. Best Regards, Hao Wu > -Original Message- > From: Zhang, Shenglei > Sent: Wednesday, April 03, 2019 2:32 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; Zhang, Shenglei > Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S > in INF > > AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680. > And also it should be removed in SecPeiDebugAgentLib.inf and > SmmDebugAgentLib.inf. > > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 -- > SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 -- > 2 files changed, 4 deletions(-) > > diff --git > a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > index 03ebbb6e74..8b81795d96 100644 > --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > @@ -39,14 +39,12 @@ >DebugAgentCommon/DebugMp.h > > [Sources.Ia32] > - DebugAgentCommon/Ia32/AsmFuncs.S >DebugAgentCommon/Ia32/AsmFuncs.nasm >DebugAgentCommon/Ia32/ArchDebugSupport.h >DebugAgentCommon/Ia32/ArchDebugSupport.c >DebugAgentCommon/Ia32/DebugException.h > > [Sources.X64] > - DebugAgentCommon/X64/AsmFuncs.S >DebugAgentCommon/X64/AsmFuncs.nasm >DebugAgentCommon/X64/ArchDebugSupport.h >DebugAgentCommon/X64/ArchDebugSupport.c > diff --git > a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > index 08ed1777be..f1b32daab3 100644 > --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > @@ -39,14 +39,12 @@ >DebugAgentCommon/DebugMp.h > > [Sources.Ia32] > - DebugAgentCommon/Ia32/AsmFuncs.S >DebugAgentCommon/Ia32/AsmFuncs.nasm >DebugAgentCommon/Ia32/ArchDebugSupport.h >DebugAgentCommon/Ia32/ArchDebugSupport.c >DebugAgentCommon/Ia32/DebugException.h > > [Sources.X64] > - DebugAgentCommon/X64/AsmFuncs.S >DebugAgentCommon/X64/AsmFuncs.nasm >DebugAgentCommon/X64/ArchDebugSupport.h >DebugAgentCommon/X64/ArchDebugSupport.c > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for coreboot and Slim Bootloader
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, April 01, 2019 10:05 PM > To: Ni, Ray; Dong, Guo; edk2-devel@lists.01.org > Cc: Wu, Hao A; Kinney, Michael D; Ma, Maurice; David Woodhouse > Subject: Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for > coreboot and Slim Bootloader > > (+David) > > On 03/29/19 06:15, Ni, Ray wrote: > > > > Guo, > > Just to double confirm: UefiPayloadPkg will not require Legacy8254 timer > support. > > The old packages Coreboot*Pkgs will be removed. > > Which means now only QEMU/OVMF needs the Legacy8254 support. > > > > Laszlo, > > Now since QEMU/OVMF is the only consumer of the Legacy8254 driver, do > you > > agree that the Legacy8254 is moved to OvmfPkg? > > Note: We agreed that Legacy8259 will be moved to OvmfPkg/Csm directory > and > > that decision is not going to be changed by this new situation. > > The last status (up to & including comment 12) in > <https://bugzilla.tianocore.org/show_bug.cgi?id=1496> was that: > > (1) 8254TimerDxe would remain a generic driver, with the minimal > interrupt controller programming that it needs flattened into it (no > dependency on gEfiLegacy8259ProtocolGuid) > > (2) the 8259InterruptControllerDxe driver (producing > gEfiLegacy8259ProtocolGuid) would move under OvmfPkg/Csm. > > Now, if 8254TimerDxe becomes specific to OvmfPkg, then I think it's not > necessary to modify it -- it can continue depending on > gEfiLegacy8259ProtocolGuid. Simply move both drivers from PcAtChipsetPkg > to OvmfPkg. (Note: *not* to OvmfPkg/Csm). > > Hao: can you please update > <https://bugzilla.tianocore.org/show_bug.cgi?id=1496> accordingly? (If > you agree, that is.) Sure. I will double confirm the latest direction and update the above BZ. Best Regards, Hao Wu > > Thanks > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 13/14] SourceLevelDebugPkg/PeCoffExtraActionLibDebug: Remove .S files
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zhang, Shenglei > Sent: Monday, April 01, 2019 4:30 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A > Subject: [PATCH v4 13/14] SourceLevelDebugPkg/PeCoffExtraActionLibDebug: > Remove .S files > > .nasm file has been added for X86 arch. .S assembly code > is not required any more. > https://bugzilla.tianocore.org/show_bug.cgi?id=1594 > > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > .../Ia32/IntHandler.S | 28 --- > .../PeCoffExtraActionLibDebug.inf | 2 -- > .../X64/IntHandler.S | 28 --- > 3 files changed, 58 deletions(-) > delete mode 100644 > SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > delete mode 100644 > SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > deleted file mode 100644 > index 69c903788c..00 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > +++ /dev/null > @@ -1,28 +0,0 @@ > -#-- > -# > -# Copyright (c) 2013, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# IntHandler.S > -# > -# Abstract: > -# > -# Assembly interrupt handler function. > -# > -#-- > - > -ASM_GLOBAL ASM_PFX(AsmInterruptHandle) > - > -.text > -ASM_PFX(AsmInterruptHandle): > - cli > - movb $1, %al > - iretl > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > index 1c52a000b0..fd56b8c94a 100644 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > +++ > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > @@ -35,12 +35,10 @@ > [Sources.IA32] >Ia32/IntHandlerFuncs.c >Ia32/IntHandler.nasm > - Ia32/IntHandler.S > > [Sources.X64] >X64/IntHandlerFuncs.c >X64/IntHandler.nasm > - X64/IntHandler.S > > [Packages] >MdePkg/MdePkg.dec > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > deleted file mode 100644 > index 108b40cf6d..00 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > +++ /dev/null > @@ -1,28 +0,0 @@ > -#-- > -# > -# Copyright (c) 2013, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# IntHandler.S > -# > -# Abstract: > -# > -# Assembly interrupt handler function. > -# > -#-- > - > -ASM_GLOBAL ASM_PFX(AsmInterruptHandle) > - > -.text > -ASM_PFX(AsmInterruptHandle): > - cli > - movb $1, %al > - iretq > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/14] SourceLevelDebugPkg/DebugAgentCommon: Remove .S files
> -Original Message-
> From: Zhang, Shenglei
> Sent: Monday, April 01, 2019 4:30 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH v3 12/14] SourceLevelDebugPkg/DebugAgentCommon:
> Remove .S files
>
> .nasm file has been added for X86 arch. .S assembly code
> is not required any more.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1594
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> Reviewed-by: Liming Gao
> ---
> .../DebugAgentCommon/Ia32/AsmFuncs.S | 415 -
> .../DebugAgentCommon/X64/AsmFuncs.S | 431 --
> .../Library/DebugAgent/DxeDebugAgentLib.inf | 2 -
Please help to remove the .s file include in:
SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
With the above changes:
Reviewed-by: Hao Wu
Sorry for missing this in the v2 patch.
Best Regards,
Hao Wu
> 3 files changed, 848 deletions(-)
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmFun
> cs.S
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/X64/AsmFun
> cs.S
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> deleted file mode 100644
> index 30d279e80d..00
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> +++ /dev/null
> @@ -1,415 +0,0 @@
> -#--
> -#
> -# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php.
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -#
> -# Module Name:
> -#
> -# AsmFuncs.S
> -#
> -# Abstract:
> -#
> -# Debug interrupt handle functions.
> -#
> -#--
> -
> -#include "DebugException.h"
> -
> -ASM_GLOBAL ASM_PFX(InterruptProcess)
> -ASM_GLOBAL ASM_PFX(Exception0Handle)
> -ASM_GLOBAL ASM_PFX(ExceptionStubHeaderSize)
> -ASM_GLOBAL ASM_PFX(TimerInterruptHandle)
> -ASM_GLOBAL ASM_PFX(CommonEntry)
> -
> -.macro AGENT_HANDLER_SIGNATURE
> - .byte 0x41, 0x47, 0x54, 0x48 # AGENT_HANDLER_SIGNATURE
> SIGNATURE_32('A','G','T','H')
> -.endm
> -
> -.data
> -
> -ASM_PFX(ExceptionStubHeaderSize): .long ASM_PFX(Exception1Handle) -
> ASM_PFX(Exception0Handle)
> -
> -.text
> -
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception0Handle):
> - cli
> - pushl %eax
> - mov $0, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception1Handle):
> - cli
> - pushl %eax
> - mov $1, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception2Handle):
> - cli
> - pushl %eax
> - mov $2, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception3Handle):
> - cli
> - pushl %eax
> - mov $3, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception4Handle):
> - cli
> - pushl %eax
> - mov $4, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception5Handle):
> - cli
> - pushl %eax
> - mov $5, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception6Handle):
> - cli
> - pushl %eax
> - mov $6, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception7Handle):
> - cli
> - pushl %eax
> - mov $7, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception8Handle):
> - cli
> - pushl %eax
> - mov $8, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception9Handle):
> - cli
> - pushl %eax
> - mov $9, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception10Handle):
> - cli
> - pushl %eax
> - mov $10, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception11Handle):
> - cli
> -
Re: [edk2] [PATCH 0/3] Implement UFS info protocol to pass additional UIC programming data from platform/silicon specific driver
> -Original Message- > From: Albecki, Mateusz > Sent: Thursday, March 28, 2019 9:49 PM > To: edk2-devel@lists.01.org > Cc: Albecki, Mateusz; Wu; Wu, Hao A > Subject: [PATCH 0/3] Implement UFS info protocol to pass additional UIC > programming data from platform/silicon specific driver > > UFS specification allows for additional, implementation specific, programming > to be done during host controller initialization. Since some hosts > might require it to allow for device detection we add a way for > platform/silicon > specific code to pass required attributes and their values to > generic UFS driver. Please see UFS 2.0 specification for details of the host > controller initialization sequence(JESD223B section 7.1.1 step 4). > Patchset consists of 3 patches to achieve this. The first one is a bugfix for > data > transfers that are not aligned to DWORD boundary such as SCSI SENSE > command. The second one is code refactoring for device presence detection > that cleans up the function that sends UIC commands. Final patch defines > UFS info protocol and implements driver logic for servicing it. > > Tests performed: > -Test UFS LU enumeration with UFS 2.0 card with 3 enabled LUs > -Test that no unaligned data transfers are performed during enumeration > -Test that UIC is programmed according to platform table Hello Mateusz, For the additional UIC during HC initialization change, could you help to verify a 'reconnect -r' under Shell to see whether the UFS devices work fine in such case? Thanks. Best Regards, Hao Wu > -Test that driver operation is not impacted when no UFS info protocol is > installed > > CC: Wu, Hao A > > Albecki, Mateusz (3): > MdeModulePkg/UfsPassThruDxe: Fix unaligned data transfer handling > MdeModulePkg/UfsPassThruDxe: Refactor UFS device presence detection > MdeModulePkg/UfsPassThruDxe: Add UFS info protocol > > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 62 + > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 3 + > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruDxe.inf | 1 + > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 299 +++- > - > .../Include/Protocol/UfsHostControllerInfo.h | 75 ++ > MdeModulePkg/MdeModulePkg.dec | 3 + > 6 files changed, 356 insertions(+), 87 deletions(-) > create mode 100644 MdeModulePkg/Include/Protocol/UfsHostControllerInfo.h > > -- > 2.14.1.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] MdeModulePkg/UfsPassThruDxe: Add UFS info protocol
Hello Mateusz,
A couple of general comments:
A. I suggest to break this commit into 2 patches:
The first one will just introduce the new protocol.
The second one will update the UfsPassThruDxe driver to consume this new
protocol.
B. There has been a Bugzilla tracker for the feature you add in this
patch:
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Could you help to add this information in the commit log message? Thanks.
C. I prefer the new protocol to have platform level singleton instance:
I do not see much value for a platform to produce multiple instances of
this protocol, I think the additional UIC commands needed during the UFS
HC initialization for a specific platform is deterministic.
Also, the selection of protocol instance implemented in function
GetUfsHcInfoProtocol() is by:
1) LocateHandleBuffer() to get all protocol instances;
2) Choose the 1st instance if the 'Supported' service returns without
error.
I think this will bring some kind of confusion to the protocol producers,
since they do not know which one will be selected when there are multiple
instances of the protocol.
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 3/3] MdeModulePkg/UfsPassThruDxe: Add UFS info protocol
>
> UFS host controller specification allows for implementation specific
> UIC programming to take place just after host controller enable and before
> device detection. Since there is no way for generic driver to anticipate
> implementation specific programming we add a UFS info protocol
> which allows the implementation specific code to pass this information
> to generic driver. UFS info protocol is located by the driver at the
> BindingStart call and the supported instance is retained throught entire
throught -> through
> driver lifetime. Presence of the protocol is optional.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 62
> ++
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 2 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruDxe.inf | 1 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 60 +
> .../Include/Protocol/UfsHostControllerInfo.h | 75
> ++
> MdeModulePkg/MdeModulePkg.dec | 3 +
> 6 files changed, 203 insertions(+)
> create mode 100644 MdeModulePkg/Include/Protocol/UfsHostControllerInfo.h
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> index ea329618dc..a41079e311 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> @@ -40,6 +40,7 @@ UFS_PASS_THRU_PRIVATE_DATA gUfsPassThruTemplate
> = {
> UfsRwUfsAttribute
>},
>0, // UfsHostController
> + NULL, // UfsInfo
>0, // UfsHcBase
>0, // Capabilities
>0, // TaskTag
> @@ -776,6 +777,66 @@ UfsFinishDeviceInitialization (
>return EFI_SUCCESS;
> }
>
> +/**
> + Locates UFS HC infor protocol suitable for this controller.
infor -> info
> +
> + @param[in] DriverBinding Pointer to driver binding protocol
> + @param[in] Private Pointer to host controller private data
> + @param[in] ControllerHandle Controller to which driver is bound
> +**/
> +VOID
> +GetUfsHcInfoProtocol (
> + IN EFI_DRIVER_BINDING_PROTOCOL *DriverBinding,
> + IN UFS_PASS_THRU_PRIVATE_DATA *Private,
> + IN EFI_HANDLE ControllerHandle
> + )
> +{
> + EFI_STATUSStatus;
> + EFI_HANDLE*ProtocolHandleArray;
> + UINTN NoHandles;
> + UINTN HandleIndex;
> + UFS_HC_INFO_PROTOCOL *UfsHcInfo;
> +
> + Status = gBS->LocateHandleBuffer (
> + ByProtocol,
> + ,
> + NULL,
> + ,
> +
> + );
> + if (EFI_ERROR (Status)) {
> +return;
> + }
> +
> + for (HandleIndex = 0; HandleIndex < NoHandles; HandleIndex++) {
> +Status = gBS->OpenProtocol (
> +ProtocolHandleArray[HandleIndex],
> +,
> +,
> +DriverBinding->DriverBindingHandle,
> +ControllerHandle,
> +EFI_OPEN_PROTOCOL_BY_DRIVER
> +);
> +
Re: [edk2] [PATCH 2/3] MdeModulePkg/UfsPassThruDxe: Refactor UFS device presence detection
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 2/3] MdeModulePkg/UfsPassThruDxe: Refactor UFS device
> presence detection
>
> In current implementation we are checking for device presence every
> time we execute UIC command. To make UfsExecUicCommands more generic
> checking device presence has been moved to UfsDeviceDetection.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 49
> --
> 1 file changed, 18 insertions(+), 31 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> index 9d0793c6be..c37161c4ae 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> @@ -1621,7 +1621,7 @@ Exit1:
> }
>
> /**
> - Sent UIC DME_LINKSTARTUP command to start the link startup procedure.
> + Send UIC command.
>
>@param[in] Private The pointer to the UFS_PASS_THRU_PRIVATE_DATA
> data structure.
>@param[in] UicOpcodeThe opcode of the UIC command.
Please help to update remove the line:
@return EFI_NOT_FOUNDThe presence of the UFS device isn't detected.
from the description of functions UfsExecUicCommands().
Other than this, the patch is good to me:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> @@ -1716,24 +1716,6 @@ UfsExecUicCommands (
> }
>}
>
> - //
> - // Check value of HCS.DP and make sure that there is a device attached to
> the Link.
> - //
> - Status = UfsMmioRead32 (Private, UFS_HC_STATUS_OFFSET, );
> - if (EFI_ERROR (Status)) {
> -return Status;
> - }
> -
> - if ((Data & UFS_HC_HCS_DP) == 0) {
> -Status = UfsWaitMemSet (Private, UFS_HC_IS_OFFSET, UFS_HC_IS_ULSS,
> UFS_HC_IS_ULSS, UFS_TIMEOUT);
> -if (EFI_ERROR (Status)) {
> - return EFI_DEVICE_ERROR;
> -}
> -return EFI_NOT_FOUND;
> - }
> -
> - DEBUG ((DEBUG_INFO, "UfsPassThruDxe: found a attached UFS device\n"));
> -
>return EFI_SUCCESS;
> }
>
> @@ -1907,8 +1889,9 @@ UfsDeviceDetection (
>IN UFS_PASS_THRU_PRIVATE_DATA *Private
>)
> {
> - UINTN Retry;
> - EFI_STATUS Status;
> + UINTN Retry;
> + EFI_STATUS Status;
> + UINT32 Data;
>
>//
>// Start UFS device detection.
> @@ -1916,22 +1899,26 @@ UfsDeviceDetection (
>//
>for (Retry = 0; Retry < 3; Retry++) {
> Status = UfsExecUicCommands (Private, UfsUicDmeLinkStartup, 0, 0, 0);
> -if (!EFI_ERROR (Status)) {
> - break;
> +if (EFI_ERROR (Status)) {
> + return EFI_DEVICE_ERROR;
> }
>
> -if (Status == EFI_NOT_FOUND) {
> - continue;
> +Status = UfsMmioRead32 (Private, UFS_HC_STATUS_OFFSET, );
> +if (EFI_ERROR (Status)) {
> + return EFI_DEVICE_ERROR;
> }
>
> -return EFI_DEVICE_ERROR;
> - }
> -
> - if (Retry == 3) {
> -return EFI_NOT_FOUND;
> +if ((Data & UFS_HC_HCS_DP) == 0) {
> + Status = UfsWaitMemSet (Private, UFS_HC_IS_OFFSET, UFS_HC_IS_ULSS,
> UFS_HC_IS_ULSS, UFS_TIMEOUT);
> + if (EFI_ERROR (Status)) {
> +return EFI_DEVICE_ERROR;
> + }
> +} else {
> + return EFI_SUCCESS;
> +}
>}
>
> - return EFI_SUCCESS;
> + return EFI_NOT_FOUND;
> }
>
> /**
> --
> 2.14.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/3] MdeModulePkg/UfsPassThruDxe: Fix unaligned data transfer handling
Hello Mateusz,
There has been a Bugzilla tracker for the issue you addressed in this
patch:
https://bugzilla.tianocore.org/show_bug.cgi?id=1341
Could you help to add this information in the commit log message? Thanks.
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 1/3] MdeModulePkg/UfsPassThruDxe: Fix unaligned data
> transfer handling
>
> Since UFS spcification requiers the data buffer specified
specification -> specification
requiers -> requires
> in PRDT to be DWORD aligned in size we had a code in
> UfsInitUtpPrdt that aligned the data buffer by rounding down
> the buffer size to DWORD boundary. This meant that for SCSI
> commands that wanted to perform unaligned data transfer(such as
> SENSE command) we specified to small buffer for the data to fit
> and transfer was aborted. This change introduces code that allocates
> auxilary DWORD aligned data buffer for unaligned transfer. Device
auxilary -> auxiliary
There are some 'auxilary' typos within the update in file UfsPassThruHci.c
as well, please help to update them.
> transfers data to aligned buffer and when data transfer is over driver copies
The above line seems too long. Please help to refine it under 76 chars.
> data from aligned buffer to data buffer passed by user.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 1 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 190 +++-
> -
> 2 files changed, 135 insertions(+), 56 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> index b8937842b8..e591e78661 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> @@ -98,6 +98,7 @@ typedef struct {
>UINT32CmdDescSize;
>VOID *CmdDescHost;
>VOID *CmdDescMapping;
> + VOID *AlignedDataBuf;
>VOID *DataBufMapping;
>
>EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET*Packet;
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> index 0238264878..9d0793c6be 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> @@ -400,17 +400,13 @@ UfsInitUtpPrdt (
>UINT8 *Remaining;
>UINTN PrdtNumber;
>
> - if ((BufferSize & (BIT0 | BIT1)) != 0) {
> -BufferSize &= ~(BIT0 | BIT1);
> -DEBUG ((DEBUG_WARN, "UfsInitUtpPrdt: The BufferSize [%d] is not dword-
> aligned!\n", BufferSize));
> - }
> + ASSERT (((UINTN)Buffer & (BIT0 | BIT1)) == 0);
> + ASSERT ((BufferSize & (BIT1 | BIT0)) == 0);
>
>if (BufferSize == 0) {
> return EFI_SUCCESS;
>}
>
> - ASSERT (((UINTN)Buffer & (BIT0 | BIT1)) == 0);
> -
>RemainingLen = BufferSize;
>Remaining= Buffer;
>PrdtNumber = (UINTN)DivU64x32 ((UINT64)BufferSize +
> UFS_MAX_DATA_LEN_PER_PRD - 1, UFS_MAX_DATA_LEN_PER_PRD);
> @@ -1212,8 +1208,6 @@ UfsSetFlag (
>return Status;
> }
>
> -
> -
> /**
>Read specified flag from a UFS device.
>
> @@ -1323,6 +1317,129 @@ Exit:
>return Status;
> }
>
> +/**
> + Cleanup data buffers after data transfer. This function
> + also takes care to copy all data to user memory pool for
> + unaligned data transfers.
> +
> + @param[in] Private Pointer to the UFS_PASS_THRU_PRIVATE_DATA
> + @param[in] TransReq Pointer to the transfer request
> +**/
> +VOID
> +UfsReconcileDataTransferBuffer (
> + IN UFS_PASS_THRU_PRIVATE_DATA *Private,
> + IN UFS_PASS_THRU_TRANS_REQ *TransReq
> + )
> +{
> + if (TransReq->DataBufMapping != NULL) {
> +Private->UfsHostController->Unmap (
> + Private->UfsHostController,
> + TransReq->DataBufMapping
> + );
> + }
> +
> + //
> + // Check if unaligned transfer was performed. If it was and we read
> + // data from device copy memory to user data buffers before cleanup.
> + // The assumption is if auxilary aligned data buffer is not NULL then
> + // unaligned transfer has been performed.
> + //
> + if (TransRe
Re: [edk2] [PATCH v3 12/12] SourceLevelDebugPkg/DebugAgentCommon: Remove .S files
Hello Shenglei,
There are still two .S files under SourceLevelDebugPkg:
edk2\SourceLevelDebugPkg\Library\PeCoffExtraActionLibDebug\Ia32\IntHandler.S
edk2\SourceLevelDebugPkg\Library\PeCoffExtraActionLibDebug\X64\IntHandler.S
Is there any special reason to left them in the repo?
Best Regards,
Hao Wu
> -Original Message-
> From: Zhang, Shenglei
> Sent: Friday, March 29, 2019 3:28 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH v3 12/12] SourceLevelDebugPkg/DebugAgentCommon:
> Remove .S files
>
> .nasm file has been added for X86 arch. .S assembly code
> is not required any more.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1594
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../DebugAgentCommon/Ia32/AsmFuncs.S | 415 -
> .../DebugAgentCommon/X64/AsmFuncs.S | 431 --
> .../Library/DebugAgent/DxeDebugAgentLib.inf | 2 -
> 3 files changed, 848 deletions(-)
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmFun
> cs.S
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/X64/AsmFun
> cs.S
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> deleted file mode 100644
> index 30d279e80d..00
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> +++ /dev/null
> @@ -1,415 +0,0 @@
> -#--
> -#
> -# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> -# This program and the accompanying materials
> -# are licensed and made available under the terms and conditions of the BSD
> License
> -# which accompanies this distribution. The full text of the license may be
> found at
> -# http://opensource.org/licenses/bsd-license.php.
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -#
> -# Module Name:
> -#
> -# AsmFuncs.S
> -#
> -# Abstract:
> -#
> -# Debug interrupt handle functions.
> -#
> -#--
> -
> -#include "DebugException.h"
> -
> -ASM_GLOBAL ASM_PFX(InterruptProcess)
> -ASM_GLOBAL ASM_PFX(Exception0Handle)
> -ASM_GLOBAL ASM_PFX(ExceptionStubHeaderSize)
> -ASM_GLOBAL ASM_PFX(TimerInterruptHandle)
> -ASM_GLOBAL ASM_PFX(CommonEntry)
> -
> -.macro AGENT_HANDLER_SIGNATURE
> - .byte 0x41, 0x47, 0x54, 0x48 # AGENT_HANDLER_SIGNATURE
> SIGNATURE_32('A','G','T','H')
> -.endm
> -
> -.data
> -
> -ASM_PFX(ExceptionStubHeaderSize): .long ASM_PFX(Exception1Handle) -
> ASM_PFX(Exception0Handle)
> -
> -.text
> -
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception0Handle):
> - cli
> - pushl %eax
> - mov $0, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception1Handle):
> - cli
> - pushl %eax
> - mov $1, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception2Handle):
> - cli
> - pushl %eax
> - mov $2, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception3Handle):
> - cli
> - pushl %eax
> - mov $3, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception4Handle):
> - cli
> - pushl %eax
> - mov $4, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception5Handle):
> - cli
> - pushl %eax
> - mov $5, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception6Handle):
> - cli
> - pushl %eax
> - mov $6, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception7Handle):
> - cli
> - pushl %eax
> - mov $7, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception8Handle):
> - cli
> - pushl %eax
> - mov $8, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception9Handle):
> - cli
> - pushl %eax
> - mov $9, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception10Handle):
> - cli
> - pushl %eax
> - mov $10, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception11Handle):
> - cli
> - pu
Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, March 27, 2019 11:37 AM > To: Wu, Hao A > Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/27/19 01:20, Wu, Hao A wrote: > >> -Original Message- > >> From: Laszlo Ersek [mailto:ler...@redhat.com] > >> Sent: Tuesday, March 26, 2019 11:15 PM > >> To: Wu, Hao A > >> Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > >> Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > >> IntelFrameworkModulePkg > >> > >> Hi Hao, > >> > >> On 03/26/19 16:01, Laszlo Ersek wrote: > >>> On 03/26/19 14:03, Anthony PERARD wrote: > >>>> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote: > >>>>> (4) Julien, Anthony: can you please fetch this series (github URL at the > >>>>> top) and see if the PS/2 keyboard, and the serial port, still work on > >>>>> Xen, to interact e.g. with the UEFI shell? > >>>> > >>>> Yes, I can still interact with the UEFI shell with this series applied, > >>>> both via the console and via VNC (which uses respectively the serial > >>>> port and PS/2 I think). > >>> > >>> Thank you -- can you please follow up with a Tested-by, or do you prefer > >>> if I push the set without it? > >> > >> ... actually, I just realize that you can push this series just fine, > >> after Anthony's answer -- so please excuse my confusing comment; I'll of > >> course let you push the series. > > > > Hello Laszlo, > > > > Sure, I will push the series. > > > > But one thing to confirm, for patch 2/3, it only got a couple of 'Ack' > > tags and a 'Tested-by' tag. I am not sure if this meets the criteria for > > pushing. > > Yes, if you get an Acked-by from at least one "M" person for the package > (and no open questions remain), that's sufficient. For edk2, my > interpretation of "Acked-by" is: "although I haven't reviewed in detail, > I agree/approve". Got it. Thanks all for the feedbacks and review/test effort. Series has been pushed via commits: c455bc8c8d..a068102296 Best Regards, Hao Wu > > Thanks, > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Wednesday, March 27, 2019 3:43 AM > To: Wu, Hao A > Cc: Zeng, Star; Laszlo Ersek; edk2-devel@lists.01.org; > ard.biesheu...@linaro.org; Wang, Jian J; Ni, Ray; Andrew Fish; Kinney, Michael > D > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 > in .dsc > > On Mon, Mar 25, 2019 at 02:17:05AM +, Wu, Hao A wrote: > > > My original version is my preferred way of addressing the immediate > > > problem though, mainly to keep the separate .EBC section. > > > > Got it. > > Do you want me to help to push the patch? > > If you could, that would be appreciated. Hello Leif, Pushed at commit: 4a1f6b85c184eecab22df88312a207f5e0ea4264 Thanks for the patch. Best Regards, Hao Wu > > Best Regards, > > Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, March 26, 2019 11:15 PM > To: Wu, Hao A > Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > Hi Hao, > > On 03/26/19 16:01, Laszlo Ersek wrote: > > On 03/26/19 14:03, Anthony PERARD wrote: > >> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote: > >>> (4) Julien, Anthony: can you please fetch this series (github URL at the > >>> top) and see if the PS/2 keyboard, and the serial port, still work on > >>> Xen, to interact e.g. with the UEFI shell? > >> > >> Yes, I can still interact with the UEFI shell with this series applied, > >> both via the console and via VNC (which uses respectively the serial > >> port and PS/2 I think). > > > > Thank you -- can you please follow up with a Tested-by, or do you prefer > > if I push the set without it? > > ... actually, I just realize that you can push this series just fine, > after Anthony's answer -- so please excuse my confusing comment; I'll of > course let you push the series. Hello Laszlo, Sure, I will push the series. But one thing to confirm, for patch 2/3, it only got a couple of 'Ack' tags and a 'Tested-by' tag. I am not sure if this meets the criteria for pushing. Best Regards, Hao Wu > > Thanks > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Monday, March 25, 2019 7:22 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Justen, Jordan L > Subject: Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver > > On 03/25/19 06:28, Hao Wu wrote: > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 > > > > There is a plan to remove the IntelFrameworkModulePkg: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1605 > > > > This patch will a new OVMF Super I/O bus driver which will create the > > below child devices: > > > > * COM 1 UART > > * COM 2 UART > > * PS/2 Keyboard > > > > and installs the Super I/O Protocol on them. > > > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Ard Biesheuvel > > Cc: Ray Ni > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > OvmfPkg/OvmfPkgIa32.dsc | 1 + > > OvmfPkg/OvmfPkgIa32X64.dsc| 1 + > > OvmfPkg/OvmfPkgX64.dsc| 1 + > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > 10 files changed, 1825 insertions(+) > > Acked-by: Laszlo Ersek > > but please don't push the series before answering my questions under 0/3. Thanks Laszlo, I have replied your comments under patch 0/3. I will wait for your approval, since I saw there is an open with regard to the file license header for the new files. Best Regards, Hao Wu > > Thanks! > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, March 25, 2019 7:29 PM > To: Wu, Hao A; edk2-devel@lists.01.org; Julien Grall; Anthony Perard > Cc: Justen, Jordan L; Ard Biesheuvel; Ni, Ray > Subject: Re: [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/25/19 11:58, Laszlo Ersek wrote: > > On 03/25/19 06:28, Hao Wu wrote: > >> The series is also available at: > >> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2 > >> > >> V2 changes: > >> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files > >> for users to select between the ISA driver stacks. > >> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the > >> new OVMF SioBusDxe driver and list it in the DSC files. Then second one > >> will add the whole new ISA stack in DSC/FDF files. > >> > >> > >> V1 history: > >> > >> This series will update the OVMF to stop using the ISA drivers within > >> IntelFrameworkModulePkg. > >> > >> As the replacement, a new OVMF Super I/O bus driver has been add which > >> will install the Super I/O protocol for ISA serial and PS2 keyboard > >> devices. By doing so, these devices can be managed by: > >> > >> MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > >> MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > >> > >> respectively. > >> > >> > >> Tests done: > >> A. GCC5 & VS2015x86 tool chains build pass > >> B. Launch QEMU (2.4.50, Windows) with command: > >>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > >> > >>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > >>using command 'devtree'; > >> > >>Both the serials and PS2 keyboard are working fine; > > > > Can you please confirm the following: > > > > (1) In the PrepareLpcBridgeDevicePath() function, in file > > "OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add > > IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut. > > > > This function takes the "LPC Bridge device" handle from its caller, > > namely DetectAndPreparePlatformPciDevicePath(), and appends some > > constant device path nodes, from "BdsPlatform.h" / "PlatformData.c". > > > > Can you please confirm that the existing Platform BDS code described > > above is compatible with the new driver? > > > > In other words, do DetectAndPreparePlatformPciDevicePath() + > > PrepareLpcBridgeDevicePath() still add the proper device paths to > > ConIn/ConOut/ErrOut? > > > > (Note, they need not be identical to the previous device paths, but the > > *logic* must continue to work -- i.e. *some* device paths have to be > > added, and they should be correct.) Hello Laszlo, For (1), since I saw in function PrepareLpcBridgeDevicePath() there are already some codes to print out the device path for COM1/COM2. So I just add some logic to print the device path for the PS2 keyboard as well. I ran the qemu with command: qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log -global isa-debugcon.iobase=0x402 For the new and origin ISA stack, their logs both show: Found LPC Bridge device BdsPlatform.c+585: PS2 Keyboard DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Acpi(PNP0303,0x0) BdsPlatform.c+615: COM1 DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D) BdsPlatform.c+647: COM2 DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D) Thus, I think the Platform BDS code behavior remains the same. > > > > (2) Can you please confirm if the new build survives repeated > > > > reconnect -r > > > > commands in the UEFI shell? Both the ISA keyboard and the serial console > > should resume working after "reconnect -r". For (2), I also run the qemu with: qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log -global isa-debugcon.iobase=0x402 After running 'reconnect -r' under Shell, the PS2 keyboard works fine. Then I switch the display from 'VGA' to 'serial0', and the serial works fine. (I just re-run the 'reconnect -r' under 'serial0', after the command finishes, the keyboard is responding and there is still output on 'serial0'.) > > (3) Hao, can you please verify the above steps on the "q35" machine type > as well? > > (The QEMU command line that you mention selects the "
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 22, 2019 6:56 PM > To: Ard Biesheuvel > Cc: Wu, Hao A; edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/22/19 10:41, Ard Biesheuvel wrote: > > On Fri, 22 Mar 2019 at 10:25, Laszlo Ersek wrote: > >> > >> On 03/22/19 02:33, Wu, Hao A wrote: > >>>> -Original Message- > >>>> From: Laszlo Ersek [mailto:ler...@redhat.com] > >>>> Sent: Friday, March 22, 2019 3:04 AM > >>>> To: Ard Biesheuvel; Wu, Hao A > >>>> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > >>>> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > >>>> IntelFrameworkModulePkg > >>>> > >>>> On 03/21/19 11:08, Ard Biesheuvel wrote: > >>>>> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A wrote: > >>>>>> > >>>>>>>>> > >>>>>>>>> Just a couple of notes from my side - I'm sure Laszlo will have a > much > >>>>>>>>> longer list :-) > >>>>>>>>> > >>>>>>>>> - Dropping the floppy driver is fine with me. > >>>>>>>>> - What is OVMF specific about this driver? Is it only the hardcoded > >>>>>>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >>>>>>>>> driver and a library class, where the driver lives in MdeModulePkg, > >>>>>>>>> and the library is implemented in the context of OVMF? > >>>>>>>> > >>>>>>>> Hello Ard, > >>>>>>>> > >>>>>>>> I think the special thing for this one is that: > >>>>>>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > >>>>>>>> know, the SIO chip exists on other platforms. The driver proposed > here > >>>>>>>> simulates the behavior of an SIO chip. IMO, if we find more platforms > >>>> that > >>>>>>>> do not have a SIO chip, we can convert the driver into a general one. > >>>>>>>> > >>>>>>>> Also, for the implementation of the services in the Super I/O > >>>>>>>> protocol, > >>>>>>>> the proposed driver just does the minimal effort in order to support > the > >>>>>>>> serial/PS2 keyboard. > >>>>>>> > >>>>>>> Here's why I'd like the majority of this driver to live under > >>>>>>> MdeModulePkg (for example through a lib class separation like Ard > >>>> suggests): > >>>>>>> > >>>>>>> Because then its maintenance would not be the responsibility of > OvmfPkg > >>>>>>> maintainers. > >>>>>>> > >>>>>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > >>>>>>> minimal effort in order to support the serial/PS2 keyboard". > >>>>>>> > >>>>>>> The risk of regressions is extreme (the PS/2 keyboard is the default > >>>>>>> one, and if it breaks *subtly*, almost all users will be > >>>>>>> inconvenienced, > >>>>>>> but not necessarily soon enough for us to get reports about it *early* > >>>>>>> in the current development cycle). > >>>>>>> > >>>>>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > >>>>>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but > >>>>>>> they have also proved themselves to *work*, and (as far as I > remember) > >>>>>>> they have required practically zero fixes in order to function well on > QEMU. > >>>>>>> > >>>>>>> It is very unwelcome by me to take on the maintenance burden for a > >>>>>>> driver that is all of: > >>>>>>> - not widely tested, > >>>>>>> - replacing a proven set of drivers that is critical to users, > >>>>>>> - large. > >>>>>>> > >>>>>
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Saturday, March 23, 2019 2:13 AM
> To: Wu, Hao A
> Cc: Zeng, Star; Laszlo Ersek; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Wang, Jian J; Ni, Ray; Andrew Fish; Kinney, Michael
> D
> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> On Thu, Mar 21, 2019 at 03:27:45AM +, Wu, Hao A wrote:
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Thursday, March 21, 2019 9:03 AM
> > > To: Leif Lindholm; Laszlo Ersek
> > > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> > > Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> > > Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > > in .dsc
> > >
> > > Another way to update the file is
> > >
> > > [LibraryClasses.EBC]
> > > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> > >
> > > ->
> > >
> > > [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> > > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> > Hello Leif,
> >
> > The current proposed patch seems great to me.
> > Reviewed-by: Hao Wu
> >
> > I am also fine with the above suggestion by Star. So if you prefer the
> > above approach, please feel free to propose another patch. Thanks in
> > advance.
>
> Laszlo convinced me that this change makes sense. But the argument for
> that was that each architecture needs to decide itself how to
> implement LockBoxLib (or not).
>
> What does not make sense to me is that
> MdeModulePkg/Library/SmmLockBoxLib/ is used as a global default, and
> set as the resolution for LockBoxLib in common sections, when it is
> only valid for 2 of the 6 architectures supported by the UEFI
> specification.
Hello Leif,
I filed a BZ tracker according to your above concern:
https://bugzilla.tianocore.org/show_bug.cgi?id=1660
We will find an approach to address it.
>
> My original version is my preferred way of addressing the immediate
> problem though, mainly to keep the separate .EBC section.
Got it.
Do you want me to help to push the patch?
Best Regards,
Hao Wu
>
> Best Regards,
>
> Leif
>
> > Best Regards,
> > Hao Wu
> >
> > >
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Thursday, March 21, 2019 1:43 AM
> > > To: Laszlo Ersek
> > > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> > > ; Wu, Hao A ; Ni, Ray
> > > ; Zeng, Star ; Andrew Fish
> > > ; Kinney, Michael D
> > > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > > in .dsc
> > >
> > > On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > > > Hi Leif,
> > > >
> > > > On 03/18/19 15:56, Leif Lindholm wrote:
> > > > > Commit 05fd2a926833
> > > > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > > > LockBox") added a dependency on LockBoxLib to NvmExpressPei,
> causing
> > > > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > > > IA32/X64 with missing reference to
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > > > >
> > > > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Leif Lindholm
> > > > > ---
> > > > >
> > > > > Note: this patch hides the symptom, but this isn't really the fix I
> > > > > would like to see.
> > > > >
> > > > > The build error is caused by the chain of:
> > > > > 1) NvmExpressPei depending on LockBoxLib
> > > > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > > > [LibraryClasses.common.PEIM]
> > > > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > > > 4) PcdDxeIplSwitchToLongMode being declared in
> > > > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > > > >
> > > > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > > &g
Re: [edk2] [PATCH 1/3] Nt32Pkg/Nt32Pkg.dsc: Remove EdkCompatibilityPkg information
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Shenglei Zhang > Sent: Friday, March 22, 2019 10:35 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A > Subject: [edk2] [PATCH 1/3] Nt32Pkg/Nt32Pkg.dsc: Remove > EdkCompatibilityPkg information > > EdkCompatibilityPkg will be removed from edk2/master. > The dependency about EdkCompatibilityPkg in Nt32Pkg.dsc should > also be removed. > > Cc: Ray Ni > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > Nt32Pkg/Nt32Pkg.dsc | 51 - > 1 file changed, 51 deletions(-) > > diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc > index 4dbde0cc45..d7b78007d2 100644 > --- a/Nt32Pkg/Nt32Pkg.dsc > +++ b/Nt32Pkg/Nt32Pkg.dsc > @@ -545,54 +545,3 @@ >NOOPT_*_*_DLINK_FLAGS = > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x1 /ALIGN:4096 > /FILEALIGN:4096 /SUBSYSTEM:CONSOLE >RELEASE_*_*_DLINK_FLAGS = /ALIGN:4096 /FILEALIGN:4096 > > - > > # > -# NOTE: > -# The following [Libraries] section is for building EDK module under the > EDKII > tool chain. > -# If you want build EDK module for Nt32 platform, please uncomment > [Libraries] section and > -# libraries used by that EDK module. > -# Currently, Nt32 platform do not has any EDK style module > -# > -# > -#[Libraries] > - # > - # Libraries common to PEI and DXE > - # > - # EdkCompatibilityPkg/Foundation/Efi/Guid/EfiGuidLib.inf > - # > EdkCompatibilityPkg/Foundation/Framework/Guid/EdkFrameworkGuidLib.inf > - # EdkCompatibilityPkg/Foundation/Guid/EdkGuidLib.inf > - # EdkCompatibilityPkg/Foundation/Library/EfiCommonLib/EfiCommonLib.inf > - # EdkCompatibilityPkg/Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf > - # EdkCompatibilityPkg/Foundation/Cpu/Itanium/CpuIa64Lib/CpuIA64Lib.inf > - # > EdkCompatibilityPkg/Foundation/Library/CustomizedDecompress/CustomizedD > ecompress.inf > - # > EdkCompatibilityPkg/Foundation/Library/CompilerStub/CompilerStubLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Hob/HobLib.inf > - > - # > - # PEI libraries > - # > - # EdkCompatibilityPkg/Foundation/Framework/Ppi/EdkFrameworkPpiLib.inf > - # EdkCompatibilityPkg/Foundation/Ppi/EdkPpiLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Pei/PeiLib/PeiLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Pei/Hob/PeiHobLib.inf > - > - # > - # DXE libraries > - # > - # > EdkCompatibilityPkg/Foundation/Core/Dxe/ArchProtocol/ArchProtocolLib.inf > - # EdkCompatibilityPkg/Foundation/Efi/Protocol/EfiProtocolLib.inf > - # > EdkCompatibilityPkg/Foundation/Framework/Protocol/EdkFrameworkProtocolLi > b.inf > - # EdkCompatibilityPkg/Foundation/Protocol/EdkProtocolLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiDriverLib/EfiDriverLib.inf > - # > EdkCompatibilityPkg/Foundation/Library/RuntimeDxe/EfiRuntimeLib/EfiRuntim > eLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Graphics/Graphics.inf > - # > EdkCompatibilityPkg/Foundation/Library/Dxe/EfiIfrSupportLib/EfiIfrSupportLib.i > nf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Print/PrintLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiScriptLib/EfiScriptLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiUiLib/EfiUiLib.inf > - > - # > - # Print/Graphics Library consume SetupBrowser Print Protocol > - # > - # EdkCompatibilityPkg/Foundation/Library/Dxe/PrintLite/PrintLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/GraphicsLite/Graphics.inf > - > -- > 2.18.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
If it follows the EDK II C Coding Standards Specification, then ignore my relating comments then, Best Regards, Hao Wu > -Original Message- > From: Gao, Zhichao > Sent: Friday, March 22, 2019 10:19 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Gao, Liming; Wang, Jian J; Ni, Ray; Zeng, Star; Sean Brogan; Michael > Turner; > Bret Barkelew > Subject: RE: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI > debug lib > > For the sections you point. It seems good to watch the patch downloaded. > The indention is one or two space behind the function name depend on tab > expand(2 space). > Is it need to adjust them? > > Thanks, > Zhichao > > > -Original Message- > > From: Wu, Hao A > > Sent: Friday, March 22, 2019 10:09 AM > > To: Gao, Zhichao ; edk2-devel@lists.01.org > > Cc: Gao, Liming ; Wang, Jian J > > ; Ni, Ray ; Zeng, Star > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > > > Subject: RE: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add > > PEI debug lib > > > > > -Original Message- > > > From: Gao, Zhichao > > > Sent: Thursday, March 21, 2019 10:05 PM > > > To: edk2-devel@lists.01.org > > > Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean > > > Brogan; Michael Turner; Bret Barkelew > > > Subject: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI > > > debug lib > > > > > > From: Liming Gao > > > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > > > > > Add a PEI debug library instance PeiDebugLibDebugPpi base on DebugPpi. > > > Using the combination of the DebugServicePei and this lib instance can > > > reduce the image size of PEI drivers. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Zhichao Gao > > > Cc: Jian J Wang > > > Cc: Hao Wu > > > Cc: Ray Ni > > > Cc: Star Zeng > > > Cc: Liming Gao > > > Cc: Sean Brogan > > > Cc: Michael Turner > > > Cc: Bret Barkelew > > > --- > > > .../Library/PeiDebugLibDebugPpi/DebugLib.c | 456 > > > + > > > .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++ > > > 2 files changed, 511 insertions(+) > > > create mode 100644 > > > MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > create mode 100644 > > > MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf > > > > > > diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > new file mode 100644 > > > index 00..75859163ae > > > --- /dev/null > > > +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > @@ -0,0 +1,456 @@ > > > +/** @file > > > + PEI debug lib instance base on DebugPpi to save size > > > + > > > + Copyright (c) 2019, Intel Corporation. All rights reserved. > > > + > > > + This program and the accompanying materials are licensed and made > > > + available under the terms and conditions of the BSD > > > License > > > + which accompanies this distribution. The full text of the license > > > + may be > > > found at > > > + http://opensource.org/licenses/bsd-license.php > > > + > > > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > > > BASIS, > > > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > > > EXPRESS OR IMPLIED. > > > + > > > +**/ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +EDKII_DEBUG_PPI *mDebugPpi = NULL; > > > + > > > +/** > > > + Prints a debug message to the debug output device if the specified > > > + error level is enabled. > > > + > > > + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib > > > + function GetDebugPrintErrorLevel (), then print the message > > > + specified by Format and the associated variable argument list to the > > debug output device. > > > + > > > + If Format is NULL, then ASSERT(). > > > + > > > + @param ErrorLevelThe error level of the debug message. > > > + @param FormatFormat stri
Re: [edk2] [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on
> DebugPpi. Using the combination of the DebugServicePei and
> this lib instance can reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c | 456
> +
> .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++
> 2 files changed, 511 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..75859163ae
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,456 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mDebugPpi = NULL;
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param ... Variable argument list whose contents are accessed
> +based on the format string specified by Format.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> + //
> + // Check driver Debug Level value and global debug level
> + //
> + if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
> +return;
> + }
> +
> + if (mDebugPpi == NULL) {
> +Status = PeiServicesLocatePpi (
*
> +,
> +0,
> +NULL,
> +(VOID **)
> +);
Re: [edk2] [PATCH V4 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEIM to install Debug PPI so that PEI debug library
> instance can locate gEdkiiDebugPpiGuid to implement the
> debug functions. Using this PPI can reduce the size of
> PEIMs which consume the debug library.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Universal/DebugServicePei/DebugService.c | 60
> ++
> .../Universal/DebugServicePei/DebugService.h | 56
>
> .../Universal/DebugServicePei/DebugServicePei.c| 54
> +++
> .../Universal/DebugServicePei/DebugServicePei.inf | 52
> +++
> .../Universal/DebugServicePei/DebugServicePei.uni | 20
> 5 files changed, 242 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.h
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.uni
>
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> new file mode 100644
> index 00..a9ea14db81
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> @@ -0,0 +1,60 @@
> +/** @file
> + Debug services instances for PEI phase.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugBPrint(
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + )
> +{
> + DebugBPrint(ErrorLevel, Format, Marker);
> +}
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugAssert(
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + )
> +{
> + DebugAssert(FileName, LineNumber, Description);
> +}
> +
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> new file mode 100644
> index 00..3e234f76b6
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> @@ -0,0 +1,56 @@
> +/** @file
> + Header file of Debug services instances.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> +
Re: [edk2] [PATCH V4 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a debug PPI for PEI phase. This PPI will provide basic
> services of debug. PEI debug lib instance can use these
> services to implement debug function to reduce the PEIMs
> which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 82
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 85 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..dc50ed1b46
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,82 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug port.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions
> + of the BSD License which accompanies this distribution. The
> + full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48,
> 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +///
> +typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] VaListMarker BASE_LIST marker for the variable
> argument list.
Minor comment:
Parameter name is not consistent between function description comment
'VaListMarker' and the service prototype 'Marker'.
With this handled:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
> +///
> +/// This PPI contains a set of services to print message to debug output
> device
> +///
> +struct _EDKII_DEBUG_PPI {
> + EDKII_DEBUG_BPRINTDebugBPrint;
> + EDKII_DEBUG_ASSERTDebugAssert;
> +};
> +
> +extern EFI_GUID gEdkiiDebugPpiGuid;
> +
> +#endif
> +
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index a2130bc439..9bbd0572f5 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -492,6 +492,9 @@
>## Include/Ppi/AtaPassThru.h
>gEdkiiPeiAtaPassThruPpiGuid = { 0xa1
Re: [edk2] [PATCH V4 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode:
> Add new APIs
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 171
> +
> 1 file changed, 144 insertions(+), 27 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index 6f0f416273..d593752050 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++ b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -4,7 +4,7 @@
>Note that if the debug message length is larger than the maximum allowable
>record length, then the debug message will be ignored directly.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -27,6 +27,12 @@
> #include
> #include
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level
> is enabled.
>
> @@ -52,12 +58,48 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + Only one list type is used.
> + If BaseListMarker == NULL, then use VaListMarker.
> + Otherwise use BaseListMarker and the VaListMarker should be initilized as
> + mVaListNull.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
> + 1];
>EFI_DEBUG_INFO *DebugInfo;
>UINTN TotalSize;
> - VA_LIST VaListMarker;
> - BASE_LIST BaseListMarker;
> + BASE_LIST BaseListMarkerPointer;
>CHAR8 *FormatString;
>BOOLEAN Long;
>
> @@ -78,22 +120,22 @@ DebugPrint (
>// Note that the passing-in format string and variable parameters will be
> constructed to
>// the following layout:
>//
> - // Buffer->||
> - // | Padding| 4 bytes
> - // DebugInfo->||
> - // | EFI_DEBUG_INFO| sizeof(EFI_DEBUG_INFO)
> - // BaseListMarker->||
> - // | ... |
> - // | variable arguments | 12 * sizeof (UINT64)
> - // | ... |
> - // ||
> - // | F
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 22, 2019 3:04 AM > To: Ard Biesheuvel; Wu, Hao A > Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/21/19 11:08, Ard Biesheuvel wrote: > > On Thu, 21 Mar 2019 at 07:44, Wu, Hao A wrote: > >> > >>>>> > >>>>> Just a couple of notes from my side - I'm sure Laszlo will have a much > >>>>> longer list :-) > >>>>> > >>>>> - Dropping the floppy driver is fine with me. > >>>>> - What is OVMF specific about this driver? Is it only the hardcoded > >>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >>>>> driver and a library class, where the driver lives in MdeModulePkg, > >>>>> and the library is implemented in the context of OVMF? > >>>> > >>>> Hello Ard, > >>>> > >>>> I think the special thing for this one is that: > >>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > >>>> know, the SIO chip exists on other platforms. The driver proposed here > >>>> simulates the behavior of an SIO chip. IMO, if we find more platforms > that > >>>> do not have a SIO chip, we can convert the driver into a general one. > >>>> > >>>> Also, for the implementation of the services in the Super I/O protocol, > >>>> the proposed driver just does the minimal effort in order to support the > >>>> serial/PS2 keyboard. > >>> > >>> Here's why I'd like the majority of this driver to live under > >>> MdeModulePkg (for example through a lib class separation like Ard > suggests): > >>> > >>> Because then its maintenance would not be the responsibility of OvmfPkg > >>> maintainers. > >>> > >>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > >>> minimal effort in order to support the serial/PS2 keyboard". > >>> > >>> The risk of regressions is extreme (the PS/2 keyboard is the default > >>> one, and if it breaks *subtly*, almost all users will be inconvenienced, > >>> but not necessarily soon enough for us to get reports about it *early* > >>> in the current development cycle). > >>> > >>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > >>> upon nowadays, they may be ugly / platform specific / etc etc etc, but > >>> they have also proved themselves to *work*, and (as far as I remember) > >>> they have required practically zero fixes in order to function well on > >>> QEMU. > >>> > >>> It is very unwelcome by me to take on the maintenance burden for a > >>> driver that is all of: > >>> - not widely tested, > >>> - replacing a proven set of drivers that is critical to users, > >>> - large. > >>> > >>> I understand that Intel wants to stop maintaining > >>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for > me. > >>> > >>> Compare the case if we simply moved the > >>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: > >>> - still large, > >>> - but widely tested (with minimal churn in the past), > >>> - and no risk of regressions. > >>> > >>> So in this form, I'm generally opposed to the switch. The two sets of > >>> drivers need to coexist for a while, and we must expose the new drivers > >>> to users while providing them with some sort of easy fallback. (I'd > >>> prefer that fallback to be dynamically configurable, but, again, if your > >>> keyboard breaks, how do you interact with e.g. the UEFI shell? So I > >>> guess a static build flag would do as well.) I think the old drivers > >> > >> Hello Laszlo, > >> > >> I agree with your point. So your suggestion is to: > >> > >> 1. Duplicate the below drivers into OvmfPkg: > >> PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf > >> IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf > >> IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf > >> IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf > >> > >> 2. Meanwhile, add the proposed SioBusDxe driver i
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, March 21, 2019 2:58 PM
> To: Gao, Zhichao; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan; Michael Turner;
> Bret Barkelew
> Subject: RE: [PATCH V3 13/17]
> MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
> Zhichao:
> Why do below change? Seemly, this change is not related to add new APIs. In
> fact, current log is added as the purpose by commit
> 137ed15511e2045a7333e33ae7f1e873ce1961dd.
I would suggest to add another separate commit to refine the below
comments to state the message truncating behavior here:
//
// If the TotalSize is larger than the maximum record size, then return
^^^
//
if (TotalSize > sizeof (Buffer)) {
TotalSize = sizeof (Buffer);
}
Best Regards,
Hao Wu
>
> if (TotalSize > sizeof (Buffer)) {
> TotalSize = sizeof (Buffer); ==> return;
> }
>
> Thanks
> Liming
> >-Original Message-
> >From: Gao, Zhichao
> >Sent: Tuesday, March 19, 2019 11:26 PM
> >To: edk2-devel@lists.01.org
> >Cc: Wang, Jian J ; Wu, Hao A ;
> >Ni, Ray ; Zeng, Star ; Gao, Liming
> >; Sean Brogan ;
> >Michael Turner ; Bret Barkelew
> >
> >Subject: [PATCH V3 13/17]
> >MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> >
> >REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> >
> >Add new APIs' implementation (DebugVPrint, DebugBPrint)
> >in the DebugLib instance. These APIs would expose print
> >routines with VaList parameter and BaseList parameter.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Zhichao Gao
> >Cc: Jian J Wang
> >Cc: Hao Wu
> >Cc: Ray Ni
> >Cc: Star Zeng
> >Cc: Liming Gao
> >Cc: Sean Brogan
> >Cc: Michael Turner
> >Cc: Bret Barkelew
> >---
> > .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
> >++---
> > 1 file changed, 128 insertions(+), 16 deletions(-)
> >
> >diff --git
> >a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >index 6f0f416273..f1d31cb619 100644
> >--- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >+++
> >b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >@@ -4,7 +4,7 @@
> > Note that if the debug message length is larger than the maximum
> allowable
> > record length, then the debug message will be ignored directly.
> >
> >- Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> >+ Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> >License
> > which accompanies this distribution. The full text of the license may be
> >found at
> >@@ -27,6 +27,12 @@
> > #include
> > #include
> >
> >+//
> >+// VA_LIST can not initialize to NULL for all compiler, so we use this to
> >+// indicate a null VA_LIST
> >+//
> >+VA_LIST mVaListNull;
> >+
> > /**
> > Prints a debug message to the debug output device if the specified error
> >level is enabled.
> >
> >@@ -52,12 +58,43 @@ DebugPrint (
> > IN CONST CHAR8 *Format,
> > ...
> > )
> >+{
> >+ VA_LIST Marker;
> >+
> >+ VA_START (Marker, Format);
> >+ DebugVPrint (ErrorLevel, Format, Marker);
> >+ VA_END (Marker);
> >+}
> >+
> >+/**
> >+ Prints a debug message to the debug output device if the specified
> >+ error level is enabled base on Null-terminated format string and a
> >+ VA_LIST argument list or a BASE_LIST argument list.
> >+
> >+ If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> >+ GetDebugPrintErrorLevel (), then print the message specified by Format
> >and
> >+ the associated variable argument list to the debug output device.
> >+
> >+ If Format is NULL, then ASSERT().
> >+
> >+ @param ErrorLevel The error level of the debug message.
> >+ @param Format Format string for the debug message to print.
> >+ @param VaListMarkerVA_LIST marker for the variable argument list.
> >+ @param BaseListMarker BASE_LIST marker for the variable argument list.
> >+
> >+**/
> >+VOID
> >+DebugPrintMarker (
> >+ IN UINTN ErrorLev
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> >> > >> Just a couple of notes from my side - I'm sure Laszlo will have a much > >> longer list :-) > >> > >> - Dropping the floppy driver is fine with me. > >> - What is OVMF specific about this driver? Is it only the hardcoded > >> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >> driver and a library class, where the driver lives in MdeModulePkg, > >> and the library is implemented in the context of OVMF? > > > > Hello Ard, > > > > I think the special thing for this one is that: > > For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > > know, the SIO chip exists on other platforms. The driver proposed here > > simulates the behavior of an SIO chip. IMO, if we find more platforms that > > do not have a SIO chip, we can convert the driver into a general one. > > > > Also, for the implementation of the services in the Super I/O protocol, > > the proposed driver just does the minimal effort in order to support the > > serial/PS2 keyboard. > > Here's why I'd like the majority of this driver to live under > MdeModulePkg (for example through a lib class separation like Ard suggests): > > Because then its maintenance would not be the responsibility of OvmfPkg > maintainers. > > Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > minimal effort in order to support the serial/PS2 keyboard". > > The risk of regressions is extreme (the PS/2 keyboard is the default > one, and if it breaks *subtly*, almost all users will be inconvenienced, > but not necessarily soon enough for us to get reports about it *early* > in the current development cycle). > > I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > upon nowadays, they may be ugly / platform specific / etc etc etc, but > they have also proved themselves to *work*, and (as far as I remember) > they have required practically zero fixes in order to function well on QEMU. > > It is very unwelcome by me to take on the maintenance burden for a > driver that is all of: > - not widely tested, > - replacing a proven set of drivers that is critical to users, > - large. > > I understand that Intel wants to stop maintaining > IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me. > > Compare the case if we simply moved the > IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: > - still large, > - but widely tested (with minimal churn in the past), > - and no risk of regressions. > > So in this form, I'm generally opposed to the switch. The two sets of > drivers need to coexist for a while, and we must expose the new drivers > to users while providing them with some sort of easy fallback. (I'd > prefer that fallback to be dynamically configurable, but, again, if your > keyboard breaks, how do you interact with e.g. the UEFI shell? So I > guess a static build flag would do as well.) I think the old drivers Hello Laszlo, I agree with your point. So your suggestion is to: 1. Duplicate the below drivers into OvmfPkg: PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf 2. Meanwhile, add the proposed SioBusDxe driver in the OvmfPkg as well 3. Add a static build flag within OvmfPkg to let users choose between: a) New OVMF SioBusDxe driver + ISA device drivers under MdeModulePkg/Bus/Isa; b) Legacy ISA stack copied from PcAtChipsetPkg & IntelFrameworkModulePkg Is my understanding correct? > should be removed only in the edk2 stable tag that comes *after* the > next one, once we've given the drivers enough time to "prove themselves". Do you mean we should keep the copy of the legacy ISA stack from PcAtChipsetPkg & IntelFrameworkModulePkg until the announcement of edk2-stable201905 tag? Best Regards, Hao Wu > > (We did something similar when we switched to the central PCI root > bridge driver in OVMF as well -- an OVMF lib instance for it was > implemented, so the maintenance burden wasn't fully under OvmfPkg to > begin with, plus we kept the old driver around with a build flag for a > while. IIRC.) > > Obviously I might feel safer if I could do a thorough review of the > driver, but I *absolutely* don't have time for it now. I'm sorry about that. > > Thanks, > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEIM to install Debug PPI so that PEI debug library
> instance can locate gEdkiiDebugPpiGuid to implement the
> debug functions. Using this PPI can reduce the size of
> PEIMs which consume the debug library.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Universal/DebugServicePei/DebugService.c | 68
> ++
> .../Universal/DebugServicePei/DebugService.h | 64
>
> .../Universal/DebugServicePei/DebugServicePei.c| 54
> +
> .../Universal/DebugServicePei/DebugServicePei.inf | 51
>
> .../Universal/DebugServicePei/DebugServicePei.uni | 20 +++
> 5 files changed, 257 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.h
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.uni
>
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> new file mode 100644
> index 00..54ae6974d1
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> @@ -0,0 +1,68 @@
> +/** @file
> + Debug services instances for PEI phase.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugBPrint(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + )
> +{
> + DebugBPrint(ErrorLevel, Format, Marker);
> +}
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugAssert(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN
Re: [edk2] [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on
> DebugPpi. Using the combination of the DebugServicePei and
> this lib instance can reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c | 469
> +
> .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++
> 2 files changed, 524 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..839dff5268
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,469 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mDebugPpi = NULL;
> +CONST EFI_PEI_SERVICES **mPeiServicesTablePointer = NULL;
If the EDKII_DEBUG_PPI interface changes, the above variable can be
removed.
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> + //
> + // Check driver Debug Level value and global debug level
> + //
> + if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
> +ret
Re: [edk2] [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Gao, Zhichao > Sent: Tuesday, March 19, 2019 11:26 PM > To: edk2-devel@lists.01.org > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan; > Michael Turner; Bret Barkelew > Subject: [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > Add the new PEIM DebugServicePei and library instance > PeiDebugLibDebugPpi to dsc file to verify it can build > correctly. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhichao Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ray Ni > Cc: Star Zeng > Cc: Liming Gao > Cc: Sean Brogan > Cc: Michael Turner > Cc: Bret Barkelew > --- > MdeModulePkg/MdeModulePkg.dsc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 6cd1727a0d..dec441e23e 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -297,6 +297,7 @@ > > MdeModulePkg/Library/PlatformHookLibSerialPortPpi/PlatformHookLibSeria > lPortPpi.inf > > MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompr > essLib.inf > > MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLib > ReportStatusCode.inf > + MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf >MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf > > MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManage > rLibNull.inf >MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > @@ -423,6 +424,8 @@ >MdeModulePkg/Universal/SerialDxe/SerialDxe.inf >MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf > > + MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf > + >MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf > > MdeModulePkg/Library/FmpAuthenticationLibNull/FmpAuthenticationLibNu > ll.inf >MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a debug PPI for PEI phase. This PPI will provide basic
> services of debug. PEI debug lib instance can use these
> services to implement debug function to reduce the PEIMs
> which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 90
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 93 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..40db304f3d
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,90 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug
> port.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions
> + of the BSD License which accompanies this distribution. The
> + full text of the license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48,
> 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +///
> +typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
Hello,
I checked the PEIM that implements this PPI (patch 15/17), and I did not
find the parameters 'PeiServices' & 'This' are being used there.
Thus, I suggest to remove those 2 parameters from the interfaces of
EFIAPI *EDKII_DEBUG_BPRINT
EFIAPI *EDKII_DEBUG_ASSERT
Best Regards,
Hao Wu
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
> +///
> +///
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
Sorry for the delayed response.
One minor comment below.
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 13/17]
> MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
> ++---
> 1 file changed, 128 insertions(+), 16 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index 6f0f416273..f1d31cb619 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -4,7 +4,7 @@
>Note that if the debug message length is larger than the maximum
> allowable
>record length, then the debug message will be ignored directly.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at
> @@ -27,6 +27,12 @@
> #include
> #include
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level is enabled.
>
> @@ -52,12 +58,43 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
> + 1];
>EFI_DEBUG_INFO *DebugInfo;
>UINTN TotalSize;
> - VA_LIST VaListMarker;
> - BASE_LIST BaseListMarker;
> + BASE_LIST BaseListMarkerPointer;
Please help to update the comments in DebugPrintMarker() as well to
reflect the above name change of the variable.
Other than that, the patch is good to me:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>CHAR8 *FormatString;
>BOOLEAN Long;
>
> @@ -96,7 +133,7 @@ DebugPrint (
>// If the TotalSize is larger than the maximum record size, then return
>//
>if (TotalSize > sizeof (Buffer)) {
> -TotalSize = sizeof (Buffer);
> +return;
>}
>
>//
> @@ -109,7 +146,7 @@ DebugPrint (
>//
>DebugInfo = (EFI_DEBUG_INFO *)(Buffer) + 1;
>DebugInfo->ErrorLevel = (UINT32)ErrorLevel;
> - BaseListMarker= (BASE_LIST)(DebugInfo + 1);
> + BaseListMarkerPointer = (BASE_LIST)(DebugInfo + 1);
>FormatString = (CHAR8 *)((UINT64 *)(DebugInfo + 1) + 12);
>
>//
> @@ -125,7 +162,6 @@ DebugPrint (
>// of format in DEBUG str
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, March 21, 2019 9:03 AM
> To: Leif Lindholm; Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> Another way to update the file is
>
> [LibraryClasses.EBC]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
> ->
>
> [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
Hello Leif,
The current proposed patch seems great to me.
Reviewed-by: Hao Wu
I am also fine with the above suggestion by Star. So if you prefer the
above approach, please feel free to propose another patch. Thanks in
advance.
Best Regards,
Hao Wu
>
>
> Thanks,
> Star
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, March 21, 2019 1:43 AM
> To: Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> ; Wu, Hao A ; Ni, Ray
> ; Zeng, Star ; Andrew Fish
> ; Kinney, Michael D
> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > Hi Leif,
> >
> > On 03/18/19 15:56, Leif Lindholm wrote:
> > > Commit 05fd2a926833
> > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > IA32/X64 with missing reference to
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > >
> > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Leif Lindholm
> > > ---
> > >
> > > Note: this patch hides the symptom, but this isn't really the fix I
> > > would like to see.
> > >
> > > The build error is caused by the chain of:
> > > 1) NvmExpressPei depending on LockBoxLib
> > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > [LibraryClasses.common.PEIM]
> > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > 4) PcdDxeIplSwitchToLongMode being declared in
> > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > >
> > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > > section. But that would leave NvmExpressPei unbuildable on anything
> > > not IA32/X64.
> > >
> > > Another option would be to add default declaration (for all other
> > > architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> > > MdeModulePkg.dec, but the current way this is expressed seems to
> > > treat this as an architecture-specific feature (which it is).
> > >
> > > What I believe would be the cleanest solution would be to abstract
> > > NvmExpressPei to the point where it can function without the LockBoxLib.
> > > But regardless, it does not look valid to me for something as
> > > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> > > under .common sections in the .dsc. (And if this changes at some
> > > point, because we implement an ARM/AARCH64 equivalent based on
> > > StandaloneMmPkg, we will need a major refactoring of that library
> > > anyway.)
> > >
> > > /
> > > Leif
> > >
> > > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > > b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68
> 100644
> > > --- a/MdeModulePkg/MdeModulePkg.dsc
> > > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> > >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> > >
> > >#
> > ># It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
> > >
> >
> > I think this patch is exactly th
Re: [edk2] [Patch MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
Thanks Ming and Leif.
Reviewed-by: Hao Wu
Patch was committed at 6c27a4d337d0034cecf9f2c05d1f20c342d41e01.
Best Regards,
Hao Wu
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, March 19, 2019 9:47 PM
> To: Ming Huang
> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Wu, Hao A; Kinney,
> Michael D; Gao, Liming; ard.biesheu...@linaro.org;
> wanghuiqi...@huawei.com; huangmin...@huawei.com;
> zhangjinso...@huawei.com; mengfanr...@huawei.com;
> huangda...@hisilicon.com
> Subject: Re: [Patch MdeModulePkg/Library v1 1/1]
> MdeModulePkg/UefiBootManangerLib: Fix exception issue
>
> Thanks, Ming.
>
> On Tue, Mar 19, 2019 at 08:59:13PM +0800, Ming Huang wrote:
> > The system environment: virtual-CDROM(USB interface) via BMC, insert a
> > iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> > to first boot option.
> > With release version bios, disconnecting CDROM when boot to
> > "1 seconds left, Press Esc or F2 to enter Setup"
> > then system will get a exception.
> >
> > The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be
> uninstalled
> > in this situation after print some transfer error. The status will be
> > invalid parameter. This line will get a exception for BlockIo not point
> > to right address:
> > AllocatePool (BlockIo->Media->BlockSize)
> > So, here need to judge the status after ASSERT_EFI_ERROR.
> >
> > The Bugzilla tracker for this:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1631
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ming Huang
>
> Reviewed-by: Leif Lindholm
>
> > ---
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 4ce83ce22d61..0535cd7335b4 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1069,6 +1069,9 @@ BmExpandMediaDevicePath (
> >//
> >Status = gBS->HandleProtocol (Handle, , (VOID
> **) );
> >ASSERT_EFI_ERROR (Status);
> > + if (EFI_ERROR (Status)) {
> > +return NULL;
> > + }
> >Buffer = AllocatePool (BlockIo->Media->BlockSize);
> >if (Buffer != NULL) {
> > BlockIo->ReadBlocks (
> > --
> > 2.9.5
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
> -Original Message- > From: Ming Huang [mailto:ming.hu...@linaro.org] > Sent: Tuesday, March 19, 2019 12:14 PM > To: Wu, Hao A; Leif Lindholm > Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; Dong, > Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; Kinney, > Michael D; Gao, Liming; wanghuiqi...@huawei.com; > huangmin...@huawei.com; zhangjinso...@huawei.com; > huangda...@hisilicon.com; wai...@126.com; Wang, Jian J > Subject: Re: [MdeModulePkg/Library v1 1/1] > MdeModulePkg/UefiBootManangerLib: Fix exception issue > > > > On 3/19/2019 10:25 AM, Wu, Hao A wrote: > >> -Original Message- > >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > >> Sent: Monday, March 18, 2019 8:43 PM > >> To: Ming Huang > >> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; > >> Dong, > >> Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; > Kinney, > >> Michael D; Gao, Liming; wanghuiqi...@huawei.com; > >> huangmin...@huawei.com; zhangjinso...@huawei.com; > >> huangda...@hisilicon.com; wai...@126.com; Wang, Jian J; Wu, Hao A; > Ni, > >> Ray > >> Subject: Re: [MdeModulePkg/Library v1 1/1] > >> MdeModulePkg/UefiBootManangerLib: Fix exception issue > >> > >> +MdeModulePkg maintainers (you added MdePkg maintainers to cc) > >> > >> This looks like an improvement to me. > >> > >> Am I correct in guessing this behaviour refers to some specific corner > >> case of a USB CDROM emulated from a BMC? > >> > >> On Mon, Feb 25, 2019 at 05:10:52PM +0800, Ming Huang wrote: > >>> The system environment: virtual-CDROM(USB interface) via BMC, insert > a > >>> iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM > >>> to first boot option. > >>> With release version bios, disconnecting CDROM when boot to > >>> "1 seconds left, Press Esc or F2 to enter Setup" > >>> then system will get a exception. > >>> > >>> The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be > >> uninstalled > >>> in this situation after print some transfer error. The status will be > >>> invalid parameter. This line will get a exception for BlockIo not point > > > > Do you mean 'EFI_INVALID_PARAMETER' is returned from: > > Status = gBS->HandleProtocol (Handle, , (VOID > **) ); > > Yes. > > > > > If so, my guess is that 'Handle' is NULL at this point. An improvement can > > be adding a previous check for 'Status' after the ASSERT at: > > > > Status = gBS->LocateDevicePath (, > , ); > > ASSERT_EFI_ERROR (Status); > > As my debug output, this 'Status' is seccuss and Handle is not NULL, but > gBS->ConnectController return:Not Found > > Debug output: > [BmExpandMediaDevicePath]:[1056L] Handle=3E3F3D18 BlockIo=3B2757B6 > Media=AFAF6C617470AFAF Status=Success > EhcExecTransfer: transfer failed with 40 > EhcBulkTransfer: error - Device Error, transfer - 40 > . > [UsbOnHubInterrupt]:[632L] SignalEvent (HubIf->HubNotify) > UsbBotExecCommand: UsbBotSendCommand (Device Error) > UsbBootExecCmd: Device Error to Exec 0x0 Cmd (Result = 1) > EhcExecTransfer: transfer failed with 40 > ... > [USBMassDriverBindingStop]:[1010L] Uninstall USB block io, free: > 3E44F218(F0) > [BmExpandMediaDevicePath]:[1064L] Connect Not Found > [BmExpandMediaDevicePath]:[1076L] Handle=3E3F3D18 BlockIo=3B2757B6 > Media=AFAF6C617470AFAF Status=Invalid Parameter Thanks for the debug information, I got it now. The call to the gBS->ConnectController() leads to protocols being uninstalled from 'Handle' and removing 'Handle' from the database. Then within the call to gBS->HandleProtocol(), CoreValidateHandle() returns EFI_INVALID_PARAMETER since the handle cannot be found. I am good with this patch, please help to address Leif's previous comment to keep the ASSERT. Also, I have filed a Bugzilla tracker for this: https://bugzilla.tianocore.org/show_bug.cgi?id=1631 Could you help to add the reference to the above BZ in the commit log message? Thanks. Best Regards, Hao Wu > > Thanks > > > > > And leave: > > > > Status = gBS->HandleProtocol (Handle, , (VOID > **) ); > > ASSERT_EFI_ERROR (Status); > > > > unchanged. > > > > > > > Best Regards, > > Hao Wu > > > >>> to right address: > >>> AllocatePool (BlockIo->Media->BlockSize) > >>> So, here need to judge the status not using ASSERT_EF
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, March 18, 2019 8:43 PM
> To: Ming Huang
> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; Dong,
> Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; Kinney,
> Michael D; Gao, Liming; wanghuiqi...@huawei.com;
> huangmin...@huawei.com; zhangjinso...@huawei.com;
> huangda...@hisilicon.com; wai...@126.com; Wang, Jian J; Wu, Hao A; Ni,
> Ray
> Subject: Re: [MdeModulePkg/Library v1 1/1]
> MdeModulePkg/UefiBootManangerLib: Fix exception issue
>
> +MdeModulePkg maintainers (you added MdePkg maintainers to cc)
>
> This looks like an improvement to me.
>
> Am I correct in guessing this behaviour refers to some specific corner
> case of a USB CDROM emulated from a BMC?
>
> On Mon, Feb 25, 2019 at 05:10:52PM +0800, Ming Huang wrote:
> > The system environment: virtual-CDROM(USB interface) via BMC, insert a
> > iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> > to first boot option.
> > With release version bios, disconnecting CDROM when boot to
> > "1 seconds left, Press Esc or F2 to enter Setup"
> > then system will get a exception.
> >
> > The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be
> uninstalled
> > in this situation after print some transfer error. The status will be
> > invalid parameter. This line will get a exception for BlockIo not point
Do you mean 'EFI_INVALID_PARAMETER' is returned from:
Status = gBS->HandleProtocol (Handle, , (VOID **)
);
If so, my guess is that 'Handle' is NULL at this point. An improvement can
be adding a previous check for 'Status' after the ASSERT at:
Status = gBS->LocateDevicePath (, ,
);
ASSERT_EFI_ERROR (Status);
And leave:
Status = gBS->HandleProtocol (Handle, , (VOID **)
);
ASSERT_EFI_ERROR (Status);
unchanged.
Best Regards,
Hao Wu
> > to right address:
> > AllocatePool (BlockIo->Media->BlockSize)
> > So, here need to judge the status not using ASSERT_EFI_ERROR.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ming Huang
> > ---
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index d5957db610d9..c2f1c651b02f 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1068,7 +1068,9 @@ BmExpandMediaDevicePath (
> >// Block IO read/write will success.
> >//
> >Status = gBS->HandleProtocol (Handle, , (VOID
> **) );
> > - ASSERT_EFI_ERROR (Status);
> > + if (EFI_ERROR (Status)) {
>
> It would still be worth including an ASSERT here, to let DEBUG builds
> report on point of failure rather than several steps up the chain.
>
> /
> Leif
>
> > +return NULL;
> > + }
> >Buffer = AllocatePool (BlockIo->Media->BlockSize);
> >if (Buffer != NULL) {
> > BlockIo->ReadBlocks (
> > --
> > 2.9.5
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/PiSmmCore: Control S3 related functionality with flag.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Tuesday, March 05, 2019 10:07 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] MdeModulePkg/PiSmmCore: Control S3 related
> functionality with flag.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1590
>
> Use PcdAcpiS3Enable to control whether need to enable S3 related
> functionality
The above line does not pass the PatchCheck.py tool. Please help to
re-format it.
Also, please help to update the copyright year for the modified files.
With the above things handled,
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> in Pi SMM Core.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 70
> ++-
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
> 2 files changed, 51 insertions(+), 20 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> index d0bc65b564..bd19803c37 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> @@ -77,6 +77,12 @@ BOOLEAN mInLegacyBoot = FALSE;
> //
> BOOLEAN mDuringS3Resume = FALSE;
>
> +//
> +// Flag to determine if platform enabled S3.
> +// Get the value from PcdAcpiS3Enable.
> +//
> +BOOLEAN mAcpiS3Enable = FALSE;
> +
> //
> // Table of SMI Handlers that are registered by the SMM Core when it is
> initialized
> //
> @@ -87,6 +93,13 @@ SMM_CORE_SMI_HANDLERS
> mSmmCoreSmiHandlers[] = {
>{ SmmExitBootServicesHandler, , NULL,
> FALSE },
>{ SmmReadyToBootHandler, , NULL,
> FALSE },
>{ SmmEndOfDxeHandler, , NULL,
> TRUE },
> + { NULL, NULL,NULL,
> FALSE }
> +};
> +
> +//
> +// Table of SMI Handlers that are registered by the SMM Core when it is
> initialized
> +//
> +SMM_CORE_SMI_HANDLERS mSmmCoreS3SmiHandlers[] = {
>{ SmmS3SmmInitDoneHandler,,NULL,
> FALSE },
>{ SmmEndOfS3ResumeHandler,,NULL,
> FALSE },
>{ NULL, NULL,NULL,
> FALSE }
> @@ -445,28 +458,30 @@ SmmEndOfDxeHandler (
> NULL
> );
>
> - //
> - // Locate SmmSxDispatch2 protocol.
> - //
> - Status = SmmLocateProtocol (
> - ,
> - NULL,
> - (VOID **)
> - );
> - if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> + if (mAcpiS3Enable) {
> //
> -// Register a S3 entry callback function to
> -// determine if it will be during S3 resume.
> +// Locate SmmSxDispatch2 protocol.
> //
> -EntryRegisterContext.Type = SxS3;
> -EntryRegisterContext.Phase = SxEntry;
> -Status = SxDispatch->Register (
> - SxDispatch,
> - SmmS3EntryCallBack,
> - ,
> -
> - );
> -ASSERT_EFI_ERROR (Status);
> +Status = SmmLocateProtocol (
> + ,
> + NULL,
> + (VOID **)
> + );
> +if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> + //
> + // Register a S3 entry callback function to
> + // determine if it will be during S3 resume.
> + //
> + EntryRegisterContext.Type = SxS3;
> + EntryRegisterContext.Phase = SxEntry;
> + Status = SxDispatch->Register (
> + SxDispatch,
> + SmmS3EntryCallBack,
> + ,
> +
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
>}
>
>return EFI_SUCCESS;
> @@ -883,6 +898,21 @@ SmmMain (
> ASSERT_EFI_ERROR (Status);
>}
>
> + mAcpiS3Enable = PcdGetBool (PcdAcpiS3Enable);
> + if (mAcpiS3Enable) {
> +//
> +// Register all S3 related SMI Handlers required by the SMM Core
> +//
> +for (Index = 0; mSmmCoreS3SmiHandlers[Index].HandlerType != NULL;
> Index++) {
> + Status = SmiHandlerRegister (
> + mSmmCoreS3SmiHandlers[Index].Handler,
> + mSmmCoreS3SmiHandlers[Index].HandlerType,
> + [Index].DispatchHandle
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
> + }
> +
>RegisterSmramProfileHandler ();
>SmramProfileInstallProtocol ();
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> index f3ece22121..9a31cb79d6 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> @@ -101,6 +101,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType ##
> CONSUMES
>
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Saturday, March 16, 2019 2:17 AM > To: Ard Biesheuvel; Wu, Hao A > Cc: edk2-devel@lists.01.org; Laszlo Ersek > Subject: Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 2019-03-15 04:09:56, Ard Biesheuvel wrote: > > On Fri, 15 Mar 2019 at 08:16, Hao Wu wrote: > > > > > > This series will update the OVMF to stop using the ISA drivers within > > > IntelFrameworkModulePkg. > > > > > > As the replacement, a new OVMF Super I/O bus driver has been add > which > > > will install the Super I/O protocol for ISA serial and PS2 keyboard > > > devices. By doing so, these devices can be managed by: > > > > > > MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > > > MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > > > > > > respectively. > > > > > > > Just a couple of notes from my side - I'm sure Laszlo will have a much > > longer list :-) > > > > - Dropping the floppy driver is fine with me. > > - What is OVMF specific about this driver? Is it only the hardcoded > > list of COM1/COM2/PS2 keyboard? If so, should we split this into a > > driver and a library class, where the driver lives in MdeModulePkg, > > and the library is implemented in the context of OVMF? > > - Regardless of the previous, adding the new driver should be a patch > > of its own. > > Yeah. I think the first patch should add the new driver, and update > the .dsc files to build the new driver. But, don't update the .fdf, so > there shouldn't be a functional change to the OVMF output after the > first patch. > > Then the second patch can modify the .dsc and .fdf files to swap out > the drivers. Hello Jordan, Agree. I will follow your suggestion in the next version of the patch. Thanks for the feedback. Best Regards, Hao Wu > > -Jordan > > > - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2) > > > > > > > > > > > > Tests done: > > > A. GCC5 & VS2015x86 tool chains build pass > > > B. Launch QEMU (2.4.50, Windows) with command: > > >> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > > > > > >Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > > >using command 'devtree'; > > > > > >Both the serials and PS2 keyboard are working fine; > > > > > > Cc: Jordan Justen > > > Cc: Laszlo Ersek > > > Cc: Ard Biesheuvel > > > Cc: Ray Ni > > > > > > Hao Wu (2): > > > OvmfPkg: Drop the ISA Floppy device support > > > OvmfPkg: Add an Super IO bus driver to replace the current ISA support > > > > > > OvmfPkg/OvmfPkgIa32.dsc | 10 +- > > > OvmfPkg/OvmfPkgIa32X64.dsc| 10 +- > > > OvmfPkg/OvmfPkgX64.dsc| 10 +- > > > OvmfPkg/OvmfPkgIa32.fdf | 10 +- > > > OvmfPkg/OvmfPkgIa32X64.fdf| 10 +- > > > OvmfPkg/OvmfPkgX64.fdf| 10 +- > > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > > 13 files changed, 1846 insertions(+), 36 deletions(-) > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h > > > create mode 100644 OvmfPkg/SioBusDxe/SioService.h > > > create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioService.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni > > > > > > -- > > > 2.12.0.windows.1 > > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, March 15, 2019 7:10 PM > To: Wu, Hao A > Cc: edk2-devel@lists.01.org; Justen, Jordan L; Laszlo Ersek; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On Fri, 15 Mar 2019 at 08:16, Hao Wu wrote: > > > > This series will update the OVMF to stop using the ISA drivers within > > IntelFrameworkModulePkg. > > > > As the replacement, a new OVMF Super I/O bus driver has been add which > > will install the Super I/O protocol for ISA serial and PS2 keyboard > > devices. By doing so, these devices can be managed by: > > > > MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > > MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > > > > respectively. > > > > Just a couple of notes from my side - I'm sure Laszlo will have a much > longer list :-) > > - Dropping the floppy driver is fine with me. > - What is OVMF specific about this driver? Is it only the hardcoded > list of COM1/COM2/PS2 keyboard? If so, should we split this into a > driver and a library class, where the driver lives in MdeModulePkg, > and the library is implemented in the context of OVMF? Hello Ard, I think the special thing for this one is that: For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I know, the SIO chip exists on other platforms. The driver proposed here simulates the behavior of an SIO chip. IMO, if we find more platforms that do not have a SIO chip, we can convert the driver into a general one. Also, for the implementation of the services in the Super I/O protocol, the proposed driver just does the minimal effort in order to support the serial/PS2 keyboard. > - Regardless of the previous, adding the new driver should be a patch > of its own. Agree. I will adopt the detailed approach suggested by Jordan for this one. Thanks for the feedback. > - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2) Thanks for the catch. I will address this comment typo in the next version of the series. I will wait a little longer to see if Laszlo has additional comments/feedbacks on this. Best Regards, Hao Wu > > > > > > > Tests done: > > A. GCC5 & VS2015x86 tool chains build pass > > B. Launch QEMU (2.4.50, Windows) with command: > >> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > > > >Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > >using command 'devtree'; > > > >Both the serials and PS2 keyboard are working fine; > > > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Ard Biesheuvel > > Cc: Ray Ni > > > > Hao Wu (2): > > OvmfPkg: Drop the ISA Floppy device support > > OvmfPkg: Add an Super IO bus driver to replace the current ISA support > > > > OvmfPkg/OvmfPkgIa32.dsc | 10 +- > > OvmfPkg/OvmfPkgIa32X64.dsc| 10 +- > > OvmfPkg/OvmfPkgX64.dsc| 10 +- > > OvmfPkg/OvmfPkgIa32.fdf | 10 +- > > OvmfPkg/OvmfPkgIa32X64.fdf| 10 +- > > OvmfPkg/OvmfPkgX64.fdf| 10 +- > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > 13 files changed, 1846 insertions(+), 36 deletions(-) > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h > > create mode 100644 OvmfPkg/SioBusDxe/SioService.h > > create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c > > create mode 100644 OvmfPkg/SioBusDxe/SioService.c > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni > > > > -- > > 2.12.0.windows.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA vs PA ambiguity
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, March 11, 2019 11:36 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel; Wang, Jian J; Wu, Hao A; Zeng, Star; Kinney, Michael D; > Gao, Liming; Achin Gupta; Yao, Jiewen; Supreeth Venkatesh; Jagadeesh Ujja > Subject: [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA > vs PA ambiguity > > This series proposes one possible approach to work around the issue that the > traditional MM and standalone MM implement versions of the communicate > protocol > that are fundamentally incompatible from the point of view of the caller. > > In traditional MM, the MM communicate protocol takes a physical pointer for > the buffer, so that the SMM execution context can access the memory > directly > without having to translate it according to the translation regime of the > caller. > > In standalone MM, the buffer that is shared with the MM context is > preallocated, > and so it is up to the implementation of the MM communicate protocol to > copy the > data from the caller allocated buffer into the preallocated shared buffer. In > order to be able to do so, the DXE driver needs to copy the contents, and for > this it needs to know the virtual address not the physical address. > > So this means we have two incompatible versions of the same protocol, and > given > that we have even re-used the EFI_SMM_COMMUNICATE_PROTOCOL GUID > for the new > EFI_MM_COMMUNICATE_PROTOCOL, we cannot distinguish > programmatically between a > MM context that takes physical addresses vs one that takes virtual ones. > > Since this is known at build time, one way to deal with this is to have two > different implementations of a library that defines an abstract > MmCommunicate() > function, allowing the correct implementation to be selected at integration > time. Hello Ard, It seems to me that for platforms that include the VariableSmmRuntimeDxe driver, they need to add the 'MmCommunicateLib' dependency. Please grant us some time to evaluate this proposal and its impact. We will inform you as soon as there is a result. Thanks. Best Regards, Hao Wu > > Cc: Jian J Wang > Cc: Hao Wu > Cc: Star Zeng > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Achin Gupta > Cc: Jiewen Yao > Cc: Supreeth Venkatesh > Cc: Jagadeesh Ujja > > Ard Biesheuvel (4): > MdeModulePkg: introduce MmCommunicationLib library class > MdeModulePkg: add implementation of MmCommunicateLib > StandaloneMmPkg: add implementation of MmCommunicateLib > MdeModulePkg/VariableSmmRuntimeDxe: switch to MmCommunicateLib > library > > MdeModulePkg/MdeModulePkg.dec > | 4 + > MdeModulePkg/MdeModulePkg.dsc > | 2 + > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.inf| 51 + > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.i > nf | 4 +- > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.inf | 51 + > MdeModulePkg/Include/Library/MmCommunicateLib.h > | > 50 + > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.c | 114 > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe. > c| 10 +- > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.c | 113 +++ > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.uni| 19 > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.uni | 19 > 11 files changed, 428 insertions(+), 9 deletions(-) > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.inf > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.inf > create mode 100644 > MdeModulePkg/Include/Library/MmCommunicateLib.h > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.c > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.c > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.uni > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.uni > > -- > 2.20.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Ashish and Eugene,
The patch has been pushed as commit:
690d60c0ada5ff137c84982220b3fdd112697aa3
Thanks a lot for the contribution and testing effort.
Best Regards,
Hao Wu
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, March 07, 2019 9:33 AM
> To: Ashish Singhal; edk2-devel@lists.01.org
> Cc: eug...@hp.com
> Subject: RE: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Ashish,
>
> Thanks for the contribution.
> Reviewed-by: Hao Wu
>
> I will push this one after the release tag is created.
>
> Best Regards,
> Hao Wu
>
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Wednesday, March 06, 2019 10:05 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> > Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> > Support
> >
> > Driver was supporting only 32b DMA support for V3 controllers. Add
> > support for 64b DMA as well for completeness.
> >
> > For V4.0 64b support, driver was looking at incorrect capability
> > register bit. Fix for that is present as well.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 189
> > ++---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 +++-
> > 4 files changed, 161 insertions(+), 73 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > index b474f8d..9b7b88c 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > @@ -6,7 +6,7 @@
> >
> >It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer
> use.
> >
> > - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> > + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> >Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the
> BSD
> > License
> > @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> > // If any of the slots does not support 64b system bus
> > // do not enable 64b DMA in the PCI layer.
> > //
> > -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> > -Private->Capability[Slot].SysBus64V4 == 0) {
> > +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300
> &&
> > + Private->Capability[Slot].SysBus64V3 == 0) ||
> > +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400
> &&
> > + Private->Capability[Slot].SysBus64V3 == 0) ||
> > +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410
> &&
> > + Private->Capability[Slot].SysBus64V4 == 0)) {
> >Support64BitDma = FALSE;
> > }
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > index 1bb701a..8846fde 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > @@ -2,7 +2,7 @@
> >
> >Provides some data structure definitions used by the SD/MMC host
> > controller driver.
> >
> > -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> > +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> > Copyright (c) 2015, Intel Corporation. All rights reserved.
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > @@ -145,13 +145,15 @@ typedef struct {
> >EFI_PHYSICAL_ADDRESSDataPhy;
> >VOID*DataMap;
> >SD_MMC_HC_TRANSFER_MODE Mode;
> > + SD_MMC_HC_ADMA_LENGTH_MODE AdmaLengthMode;
> >
> >EFI_EVENT Event;
> >BOOLEAN Started;
> >UINT64 Timeout;
> >
> >SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
&
Re: [edk2] [PATCH v2 1/2] MdeModulePkg/HiiDatabase: Fix potential integer overflow (CVE-2018-12181)
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Ni, Ray
> Sent: Friday, March 08, 2019 10:35 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan; Wu, Hao A
> Subject: [PATCH v2 1/2] MdeModulePkg/HiiDatabase: Fix potential integer
> overflow (CVE-2018-12181)
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1135
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ray Ni
> Cc: Dandan Bi
> Cc: Hao A Wu
> ---
> MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 126
> ++
> 1 file changed, 103 insertions(+), 23 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> index 71ebc559c0..80a4ec1114 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> @@ -16,6 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "HiiDatabase.h"
>
> +#define MAX_UINT240xFF
>
> /**
>Get the imageid of last image block: EFI_HII_IIBT_END_BLOCK when input
> @@ -651,8 +652,16 @@ HiiNewImage (
>
>EfiAcquireLock ();
>
> - NewBlockSize = sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof
> (EFI_HII_RGB_PIXEL) +
> - BITMAP_LEN_24_BIT ((UINT32) Image->Width, Image->Height);
> + //
> + // Calcuate the size of new image.
> + // Make sure the size doesn't overflow UINT32.
> + // Note: 24Bit BMP occpuies 3 bytes per pixel.
> + //
> + NewBlockSize = (UINT32)Image->Width * Image->Height;
> + if (NewBlockSize > (MAX_UINT32 - (sizeof
> (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof (EFI_HII_RGB_PIXEL))) / 3) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> + NewBlockSize = NewBlockSize * 3 + (sizeof
> (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof (EFI_HII_RGB_PIXEL));
>
>//
>// Get the image package in the package list,
> @@ -671,6 +680,18 @@ HiiNewImage (
> //
> // Update the package's image block by appending the new block to the
> end.
> //
> +
> +//
> +// Make sure the final package length doesn't overflow.
> +// Length of the package header is represented using 24 bits. So MAX
> length is MAX_UINT24.
> +//
> +if (NewBlockSize > MAX_UINT24 - ImagePackage-
> >ImagePkgHdr.Header.Length) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +//
> +// Because ImagePackage->ImageBlockSize < ImagePackage-
> >ImagePkgHdr.Header.Length,
> +// So (ImagePackage->ImageBlockSize + NewBlockSize) <= MAX_UINT24
> +//
> ImageBlocks = AllocatePool (ImagePackage->ImageBlockSize +
> NewBlockSize);
> if (ImageBlocks == NULL) {
>EfiReleaseLock ();
> @@ -701,6 +722,13 @@ HiiNewImage (
> PackageListNode->PackageListHdr.PackageLength += NewBlockSize;
>
>} else {
> +//
> +// Make sure the final package length doesn't overflow.
> +// Length of the package header is represented using 24 bits. So MAX
> length is MAX_UINT24.
> +//
> +if (NewBlockSize > MAX_UINT24 - (sizeof
> (EFI_HII_IMAGE_PACKAGE_HDR) + sizeof (EFI_HII_IIBT_END_BLOCK))) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> //
> // The specified package list does not contain image package.
> // Create one to add this image block.
> @@ -902,8 +930,11 @@ IGetImage (
> // Use the common block code since the definition of these structures is
> the same.
> //
> CopyMem (, CurrentImageBlock, sizeof
> (EFI_HII_IIBT_IMAGE_1BIT_BLOCK));
> -ImageLength = sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) *
> - ((UINT32) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height);
> +ImageLength = (UINTN) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height;
> +if (ImageLength > MAX_UINTN / sizeof
> (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +ImageLength *= sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL);
> Image->Bitmap = AllocateZeroPool (ImageLength);
> if (Image->Bitmap == NULL) {
>return EFI_OUT_OF_RESOURCES;
> @@ -952,9 +983,13 @@ IGetImage (
> // fall through
> //
>case EFI_HII_IIBT_IMAGE_24BIT:
> -Width = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)-
> >Bitmap.Width);
> +Width = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)-
> >Bitmap.Width);
> Height = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)-
> >Bitmap.Height);
> -ImageL
Re: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver
Quick comment, please add the CVE number in the patch subject. Liming has already documented the new rule for this kind of fix: https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ray Ni > Sent: Friday, March 08, 2019 10:21 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver > > Ray Ni (2): > MdeModulePkg/HiiDatabase: Fix potential integer overflow > MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is > parsed > > MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 130 > ++ > 1 file changed, 105 insertions(+), 25 deletions(-) > > -- > 2.20.1.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Thursday, March 07, 2019 8:54 AM
> To: Ashish Singhal; Wu, Hao A; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b
> DMA Support
>
> Tested-by: Eugene Cohen
Eugene,
Thanks for the testing. Really appreciate your help.
Best Regards,
Hao Wu
>
> Thanks again.
>
> From: Ashish Singhal
> Sent: Wednesday, March 6, 2019 4:07 PM
> To: Cohen, Eugene ; Wu, Hao A ;
> edk2-devel@lists.01.org
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Hi Eugene,
>
> Thanks for confirming. Can you please validate the v2 patch I sent as well for
> completeness?
>
> Thanks
> Ashish
>
> From: Cohen, Eugene mailto:eug...@hp.com>>
> Sent: Wednesday, March 6, 2019 4:05 PM
> To: Wu, Hao A mailto:hao.a...@intel.com>>; Ashish
> Singhal mailto:ashishsin...@nvidia.com>>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
>
> Ø I verified the patch on SDHC version 3.00 with 64-bit System Address
> Ø Support. Hope more configurations are available for testing on Eugene's
> Ø side.
>
> This patch works for us. Tested that the V3 64-bit DMA works and verified
> that addresses above 4GB DMA correctly.
>
> Thanks for putting this together.
>
> Feel free to add my Tested-By.
>
> Eugene
>
> From: Wu, Hao A mailto:hao.a...@intel.com>>
> Sent: Tuesday, March 5, 2019 8:01 PM
> To: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Cohen, Eugene mailto:eug...@hp.com>>
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Hi Ashish,
>
> One thing to confirm, for the updated checks within
> SdMmcPciHcDriverBindingStart():
>
> > if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> > Private->Capability[Slot].SysBus64V4 == 0)) {
> > Support64BitDma = FALSE;
> > }
>
> When the SDHC with version greater than 4.10, the check is only performed
> against the 'SysBus64V4' bit. My understanding of the purpose is that:
>
> 1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
> 64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
> that the possible support case is both or neither.
>
> 2. The spec states that SDHC with version greater than 4.10 divides the V3
> mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
> V3 mode support can be optional.
>
> So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
> when HC version >= 4.10. Is that right?
>
>
> I verified the patch on SDHC version 3.00 with 64-bit System Address
> Support. Hope more configurations are available for testing on Eugene's
> side.
>
>
> Besides, some minor comments below:
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Saturday, March 02, 2019 2:30 AM
> > To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Wu, Hao A; eug...@hp.com<mailto:eug...@hp.com>; Ashish Singhal
> > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> > Support
>
> Please help to add the below Bugzilla tracker for reference:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1583<https://bugzilla.tianoc
> ore.org/show_bug.cgi?id=1583>
>
> I have updated the above tracker to match the purpose of the proposed
> patch.
>
>
> >
> > Driver was supporting only 32b DMA support for V3 controllers. Add
> > support for 64b DMA as well for completeness.
> >
> > For V4.0 64b support, driver was looking at incorrect capability
> > register bit. Fix for that is present as well.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> > ++---
> > MdeModulePkg/Bus/Pci/SdMmcPci
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Ashish,
Thanks for the contribution.
Reviewed-by: Hao Wu
I will push this one after the release tag is created.
Best Regards,
Hao Wu
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, March 06, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 189
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 +++-
> 4 files changed, 161 insertions(+), 73 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..8846fde 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -145,13 +145,15 @@ typedef struct {
>EFI_PHYSICAL_ADDRESSDataPhy;
>VOID*DataMap;
>SD_MMC_HC_TRANSFER_MODE Mode;
> + SD_MMC_HC_ADMA_LENGTH_MODE AdmaLengthMode;
>
>EFI_EVENT Event;
>BOOLEAN Started;
>UINT64 Timeout;
>
>SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> - SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
> + SD_MMC_HC_ADMA_64_V3_DESC_LINE *Adma64V3Desc;
> + SD_MMC_HC_ADMA_64_V4_DESC_LINE *Adma64V4Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32 AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index d73fa10..6fefed1 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation.
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Hi Ashish,
One thing to confirm, for the updated checks within
SdMmcPciHcDriverBindingStart():
> if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
When the SDHC with version greater than 4.10, the check is only performed
against the 'SysBus64V4' bit. My understanding of the purpose is that:
1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
that the possible support case is both or neither.
2. The spec states that SDHC with version greater than 4.10 divides the V3
mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
V3 mode support can be optional.
So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
when HC version >= 4.10. Is that right?
I verified the patch on SDHC version 3.00 with 64-bit System Address
Support. Hope more configurations are available for testing on Eugene's
side.
Besides, some minor comments below:
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Saturday, March 02, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
Please help to add the below Bugzilla tracker for reference:
https://bugzilla.tianocore.org/show_bug.cgi?id=1583
I have updated the above tracker to match the purpose of the proposed
patch.
>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..68d8a5c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> Licen
Re: [edk2] [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Wu, Hao A > Sent: Tuesday, March 05, 2019 9:14 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; Eugene Cohen; Ard Biesheuvel; Ashish Singhal > Subject: [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 64-bit systems Since Ashish already posted a patch to add the 64-bit System Address support for V3 mode SDHC: https://www.mail-archive.com/edk2-devel@lists.01.org/msg52057.html I think this patch can be dropped. But since Ashish's patch above is considered as a new feature addition, it will be pushed (if passes the review process) after the 19`Q1 release tag. So Eugene, Ard and Ashish, do you have concern on this? Best Regards, Hao Wu > > V2 changes: > > On behalf of Eugene, V2 patch does not have functional changes compared > with V1, only the reference Bugzilla tracker link is added in the commit > log message. > > I added the previous 'Ack' tag from Ard and Ashish, I added my > 'Reviewed-by' as well. > > Cc: Eugene Cohen > Cc: Ard Biesheuvel > Cc: Ashish Singhal > > Cohen, Eugene (1): > MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Monday, March 04, 2019 12:00 PM > To: Wu, Hao A; Cohen, Eugene; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Hao, > > I agree that there has been a bug all along which got exposed just now. We > should submit the patch as proposed by Eugene. Yes. I will co-work with Eugene to address this soon. > > Also, I have submitted the patch for enabling 64b DMA for V3. Please take > that into consideration once the freeze is over so that we can fix the issue > in > real sense. Sure. I will take a look at your proposed patch. Please grant me some time for the review and test. Best Regards, Hao Wu > > Eugene, > > Please let me know once you have tried my patch on your board. > > Thanks > Ashish > > -Original Message- > From: Wu, Hao A > Sent: Sunday, March 3, 2019 7:39 PM > To: Cohen, Eugene ; Ashish Singhal > ; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Eugene, Ashish and Ard > > Sorry for the delayed response, I was out of office in the previous several > days. > > According to the discussion, my understanding is that (quote the comments > from > Ard): > > > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > > attribute 1. If the device does not support it; 2. If the driver does > > not implement the 64-bit DMA mode that the device does > >support. > > Thus, for the current implementation of the SdMmcPciHcDxe driver > (including the > V4 ADMA descriptor support from Ashish): > > * The driver should set the DUAL_ADDRESS_CYCLE attribute only when > 'SysBus64V4' > bit set, because of the statement 2 above. > > And for the previous implementation (before the change from Ashish): > > * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since > the > implementation was written to support only the 32b ADMA descriptor. > > If this is true, I am fine with your proposed fix. > > > Eugene, > > Could you help to state the reason for the fix a bit more clear in the commit > log? > > Also, I have filed a Bugzilla tracker for this one: > https://bugzilla.tianocore.org/show_bug.cgi?id=1583 > > Could you help to add this information into the commit log as well? Thanks. > > Best Regards, > Hao Wu > > > -Original Message- > > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > > Sent: Friday, March 01, 2019 11:25 PM > > To: Ard Biesheuvel; Cohen, Eugene > > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > Acked-by: Ashish Singhal > > > > -Original Message- > > From: Ard Biesheuvel > > Sent: Friday, March 1, 2019 4:39 AM > > To: Cohen, Eugene > > Cc: Ashish Singhal ; Wu, Hao A > > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > > SW1Lab.) > > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > > > Ard, > > > > > > > So before these changes, we were in the exact same situation, but > > > > since PC platforms never enable DMA above 4 GB in the first place, > > > > nobody ever noticed until we started running this code on arm64 > > > > platforms that have no 32-bit addressable DRAM to begin with. > > > > > > Interesting - I did not realize that there were designs that were > > > crazy > > enough to have no addressable DRAM below 4G. > > > > > > > You must be new here :-) > > > > But seriously, it does make sense for an implementation to, say, put > > all peripherals, PCIe resource windows etc in the bottom half and all > > DRAM in the top half of a 40-bit address space, which is how the AMD > > Seattle SoC ended with its system memory at address 0x80__. > > Note that on this platform, we can still use 32-bit DMA if we want to > > with the help of the SMMUs, but we haven't wired those up in UEFI (and > > the generic host bridge driver did not have the IOMMU hooks at the > > time) > > > > > > The obvious conclusion is that the driver should not set the > > > > EFI_PCI_IO_ATTRIBUTE_DUAL_ADD
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Hi Eugene, Ashish and Ard Sorry for the delayed response, I was out of office in the previous several days. According to the discussion, my understanding is that (quote the comments from Ard): > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute > 1. If the device does not support it; > 2. If the driver does not implement the 64-bit DMA mode that the device does >support. Thus, for the current implementation of the SdMmcPciHcDxe driver (including the V4 ADMA descriptor support from Ashish): * The driver should set the DUAL_ADDRESS_CYCLE attribute only when 'SysBus64V4' bit set, because of the statement 2 above. And for the previous implementation (before the change from Ashish): * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since the implementation was written to support only the 32b ADMA descriptor. If this is true, I am fine with your proposed fix. Eugene, Could you help to state the reason for the fix a bit more clear in the commit log? Also, I have filed a Bugzilla tracker for this one: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Could you help to add this information into the commit log as well? Thanks. Best Regards, Hao Wu > -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Friday, March 01, 2019 11:25 PM > To: Ard Biesheuvel; Cohen, Eugene > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Acked-by: Ashish Singhal > > -Original Message- > From: Ard Biesheuvel > Sent: Friday, March 1, 2019 4:39 AM > To: Cohen, Eugene > Cc: Ashish Singhal ; Wu, Hao A > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > SW1Lab.) > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > Ard, > > > > > So before these changes, we were in the exact same situation, but > > > since PC platforms never enable DMA above 4 GB in the first place, > > > nobody ever noticed until we started running this code on arm64 > > > platforms that have no 32-bit addressable DRAM to begin with. > > > > Interesting - I did not realize that there were designs that were crazy > enough to have no addressable DRAM below 4G. > > > > You must be new here :-) > > But seriously, it does make sense for an implementation to, say, put all > peripherals, PCIe resource windows etc in the bottom half and all DRAM in > the top half of a 40-bit address space, which is how the AMD Seattle SoC > ended with its system memory at address 0x80__. > Note that on this platform, we can still use 32-bit DMA if we want to with the > help of the SMMUs, but we haven't wired those up in UEFI (and the generic > host bridge driver did not have the IOMMU hooks at the > time) > > > > The obvious conclusion is that the driver should not set the > > > EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device > does > > > not support it, or, which seems to be our case, if the driver does > > > not implement the 64-bit DMA mode that the driver does support. > > > However, since there are platforms for which bounce buffering is not > > > an option (since there is no 32-bit addressable memory to bounce > > > to), this is not just a performance optimization, and so it would be > > > useful to fix the code so it can drive all 64-bit DMA capable hardware. > > > > Okay, that's a great reason - let's get V3 64b ADMA2 in! > > > > Any objection to committing the original patch in the short term? > > > > not at all > > Acked-by: Ard Biesheuvel > > --- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > --- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Loop Ashish in.
Some comments below.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Wednesday, February 27, 2019 6:59 PM
> To: edk2-devel@lists.01.org; Wu, Hao A
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC
> v3 64-bit systems
>
> The SdMmcPciHcDriverBindingStart function was checking two
> different capability bits in determining whether 64-bit DMA
> modes were supported, one mode is defined in the SDHC version
> 3 specification (using 96-bit descriptors) and another is
> defined in the SDHC version 4 specification (using 128-bit
> descriptors). Since the currently implementation of 64-bit
> ADMA2 only supports the SDHC version 4 implementation it is
> incorrect to check the V3 64-bit capability bit since this
> will activate V4 ADMA2 on V3 controllers.
I remember the commit b5547b9ce97e80c3127682a2a5d4b9bd14af353e from Ashish
only handles the controllers with version greater or equal to 4.00.
And the ADMA2 (96-bit Descriptor) mode for V3 controllers is selected by
setting the 'DMA Select' filed in the Host Control 1 Register to 11b. But
the currently behavior of the driver is setting the field to 10b, which I
think will not switch to the ADMA2 (96-bit Descriptor) mode for V3.
Maybe there is something I miss here. Could you help to provide some more
detail on the issue you met? Thanks.
Best Regards,
Hao Wu
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eugene Cohen
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..5bc91c5 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -666,8 +666,7 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if (Private->Capability[Slot].SysBus64V4 == 0) {
>Support64BitDma = FALSE;
> }
>
> --
> 2.7.4
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, February 26, 2019 7:45 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross > boundary access in Ramdisk > > On 02/26/19 08:45, Hao Wu wrote: > > V2 changes: > > > > Correct CC list information. > > > > > > V1 history: > > > > The series will resolve a buffer cross boundary access issue during the > > use of RAM disks. It is the mitigation for issue CVE-2018-12180. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Star Zeng > > > > Hao Wu (2): > > MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX) > > MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE > FIX) > > > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h | 6 +++--- > > MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 - > > MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 - > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 20 > ++-- > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c | 5 +++-- > > 5 files changed, 36 insertions(+), 13 deletions(-) > > > > Please put the exact CVE numbers in the subject lines. Hello Laszlo and Liming, I totally agree the commit subject line should include the CVE number. But I have one feedback that, if the commit is for a CVE fix, is it possible to exempt the commit subject from 71 characters limit? I found it can be hard to summary the commit with the Package/Module plus the CVE number information. Best Regards, Hao Wu > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, February 26, 2019 7:45 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross > boundary access in Ramdisk > > On 02/26/19 08:45, Hao Wu wrote: > > V2 changes: > > > > Correct CC list information. > > > > > > V1 history: > > > > The series will resolve a buffer cross boundary access issue during the > > use of RAM disks. It is the mitigation for issue CVE-2018-12180. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Star Zeng > > > > Hao Wu (2): > > MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX) > > MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE > FIX) > > > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h | 6 +++--- > > MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 - > > MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 - > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 20 > ++-- > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c | 5 +++-- > > 5 files changed, 36 insertions(+), 13 deletions(-) > > > > Please put the exact CVE numbers in the subject lines. Thanks. V3 series proposed. Best Regards, Hao Wu > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from Opal driver
Thanks all, Series pushed via commits: 94e0dd1afe53d23286968130d836ff0755c17c9b..a3efbc29c45183fe69bcb311c2d974ddc4e7c00a Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Hao Wu > Sent: Thursday, February 21, 2019 8:24 AM > To: edk2-devel@lists.01.org > Cc: Dong, Eric; Wu, Hao A; Yao, Jiewen; Zeng, Star; Laszlo Ersek; Zhang, Chao > B > Subject: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from > Opal driver > > The series is also available at: > https://github.com/hwu25/edk2/tree/opal_remodel_v6 > > V6 changes: > For patch 6, rename driver internal function NvmeCheckHcDevicePath() to > NvmeIsHcDevicePathValid(). > > For patch 7, add more comments for purpose of selective NVM Express > controller initialization during S3 resume. > > For patch 8: > * Rename driver internal function AhciCheckHcDevicePath() to > AhciIsHcDevicePathValid(); > * Add more comments for purpose of selective port enumeration/ > initialization on a ATA AHCI controller during S3 resume. > > For patch 6~8, since no functional impact, I still keep the 'Reviewed-by' > from Eric. > > For patch 13, as suggested by Ray, simplifies the logic within PPI > notification callback to directly use the PPI instance provided by the > input parameter of callback function. > > > V5 history: > For patch 11, as suggested by Star: > * Refine the UpdateLockBox() API description comment to be more precise; > * Ensure the parameter for macro 'EFI_SIZE_TO_PAGES' is of type 'UINTN'; > > Since the changes are minor, I still keep the origin 'Reviewed-by' from > Ray and the 'Acked-by' tag from Laszlo. > > For patch 12, sync the UpdateLockBox() API description comment with the > change made in patch 11. > > Since the changes are minor, I still keep the origin 'Reviewed-by' from > Laszlo an Ray. > > For patch 13, additional handling logic to prevent NULL pointer > de-reference, just as what has been done in commit > d72d8561fbe03a64e01c2ad57a93777de4b9ae2f. > > > V4 history: > > As suggested by Laszlo, add a new patch to sync the API description > comment for UpdateLockBox() in file > "OvmfPkg/Library/LockBoxLib/LockBoxLib.c" with its counterparts in > MdeModulePkg. > > For patch 13 (compared with patch 12 in V3), minor type refinement in > structure definition 'OPAL_DEVICE_LOCKBOX_DATA'. > > V3 history: > > For patch 2, reuse the definitions within AtaPassThru protocol header file > to reduce code duplication. > > For patch 4, add detailed comments to illustrate the content that will be > stored in the newly introduced LockBox. > > For patch 6, device path validity check refinement within function > NvmeCheckHcDevicePath(). > > For patch 7: > * Remove a redundant check within function NvmeS3SkipThisController(); > * Replace internal implementation of GetNextDevicePathInstance() with > GetDevicePathInstanceSize(), which avoids unnecessary memory allocation. > > For patch 8: > * Device path validity check refinement within function > AhciCheckHcDevicePath(); > * Remove a redundant check within function AhciS3GetEumeratePorts(); > * Replace internal implementation of GetNextDevicePathInstance() with > GetDevicePathInstanceSize(), which avoids unnecessary memory allocation. > > For patch 11: > * Remove the ASSERT() for memory allocation failure. Since error handling > codes already exist, no new code is added for this; > * Refine the codes to only allocate new SMM buffer when the required > LockBox size is greater than the size of origin pages allocated; > * Add additional parameter check for 'Offset' & 'Length' to prevent > potential numeric overflow. > > > V2 history: > > For patch 8, the new series removes the codes to produce the Block IO PPIs > from the AhciPei driver. > > The task to produce the Block IO services is out of the scope of BZ-1409 > (actually covered by BZ-1483). And we will later propose seperate patch(s) > to address this. > > V1 history: > > For the below 2 types of storage device: > > 1. NVM Express devices; > 2. ATA hard disk devices working under AHCI mode. > > the OpalPassword driver supports auto-unlocking those devices during S3 > resume. > > Current implementation of the OpalPassword driver is handling the device > initialization (using boot script to restore the host controller PCI > configuration space also counts) in the PEI phase during S3 resume by > itself. > > Meanwhile, the NvmExpressPei driver in MdeModulePkg also handles the > NVME > device initialization during the PEI phase in order to produce the Block > IO
Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: Friday, February 22, 2019 4:57 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Albecki, Mateusz
> Subject: Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix
> eMMC HS400 switch sequence
>
> Hi Hao A,
>
> On 2/20/19 2:11 AM, Wu, Hao A wrote:
> > Thanks Mateusz,
> >
> > Reviewed-by: Hao Wu
> > And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
>
> I think you mean "pushed 'after' commit
> 68c67d3a2a33261e41ff0123129b4e9759617f71".
Yes, the commit should have been 195f673f6270aaf73dd34b75f1da26451b63c316.
It is my mistake.
>
> Commit 68c67d3a2a33261e41ff0123129b4e9759617f71 is:
> "BaseTools: Fixed a code bug for Pcd Array", while
> this patch is commited as 195f673f6270aaf73dd34b75f1da26451b63c316.
>
> Now about this commit 195f673f6270aaf, I think you have an issue with
> your configuration, as the patch author was remplaced from:
> Albecki, Mateusz
> to:
> Albecki, Mateusz (FYDIBOHF23SPDLT)/cn=Recipients/cn=Albecki, Mateusz3be>
You are right, there is something wrong with my local settings when
abstracting the patch. Thanks for pointing out.
Best Regards,
Hao Wu
>
> Regards,
>
> Phil.
>
> >
> > Best Regards,
> > Hao Wu
> >
> >
> >> -Original Message-
> >> From: Albecki, Mateusz
> >> Sent: Monday, February 18, 2019 7:12 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Albecki, Mateusz; Wu, Hao A
> >> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC
> HS400
> >> switch sequence
> >>
> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
> >>
> >> In eMMC HS400 switch sequence flow eMMC driver attempted
> >> to execute SEND_STATUS just after switching bus timing to high
> >> speed and before downgrading clock frequency to 52MHz. Since link
> >> was at that time in incorrect state SEND_STATUS was failing which
> >> made driver think switch to HS400 failed.
> >> This change makes driver always change clock frequency after
> >> switching bus timing and before executing SEND_STATUS.
> >>
> >> Cc: Hao Wu
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Albecki Mateusz
> >> ---
> >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
> >> +
> >> 1 file changed, 20 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> index 4ef849fd0962..15db8a87a5c4 100644
> >> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> >> }
> >>
> >> /**
> >> - Switch the clock frequency to the specified value.
> >> + Switch the bus timing and clock frequency.
> >>
> >>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> >> Controller
> >>Simplified Spec 3.0 Figure 3-3 for details.
> >> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
> >>
> >> **/
> >> EFI_STATUS
> >> -EmmcSwitchClockFreq (
> >> +EmmcSwitchBusTiming (
> >>IN EFI_PCI_IO_PROTOCOL*PciIo,
> >>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
> >>IN UINT8 Slot,
> >> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
> >>
> >>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
> >>if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >> return Status;
> >>}
> >>
> >> - Status = EmmcSendStatus (PassThru, Slot, Rca, );
> >> - if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> >> with %r\n", Status));
> >> -return Status;
> >> - }
> >> - //
> >> - // Check the switch operation is really successful or not.
> >> - //
> >> - if ((DevStatus & BIT7) != 0) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch
> operation
> >>
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, February 03, 2019 8:39 PM
> To: Wu, Hao A
> Cc: Jeff Brasen; edk2-devel@lists.01.org; Edgar Handal; Marcin Wojtas
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> IO widths
>
> On Fri, 1 Feb 2019 at 06:55, Wu, Hao A wrote:
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jeff
> > > Brasen
> > > Sent: Thursday, January 31, 2019 7:59 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Edgar Handal; Jeff Brasen
> > > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> IO
> > > widths
> > >
> > > From: Edgar Handal
> > >
> > > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > > accesses from being split up into 8-bit accesses.
> > >
> > > The SDHCI specification states that the registers shall be accessable in
> > > byte, word, and double word accesses.
> >
>
> Acked-by: Ard Biesheuvel
Ard,
Really sorry for missing your 'Acked-by' tag.
It came to me after I pushed the commit.
Sorry again for this.
Best Regards,
Hao Wu
>
> I think we should always prefer accessing MMIO registers using their
> native size, unless there are pressing reasons not to.
>
>
> > Hi,
> >
> > Thanks for the contribution. The change seems good to me.
> >
> > Just curious, if the accesses are always slit into byte(8-bit), is there any
> > issue or performance impact is encountered during your usage?
> >
> > It will be helpful to get more information on the purpose of the patch.
> > Thanks.
> >
> > Best Regards,
> > Hao Wu
> >
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jeff Brasen
> > > ---
> > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> > >
> > > 1 file changed, 21 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > index 5aec8c6..82f4493 100644
> > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> > >)
> > > {
> > >EFI_STATUS Status;
> > > + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> > >
> > >if ((PciIo == NULL) || (Data == NULL)) {
> > > return EFI_INVALID_PARAMETER;
> > >}
> > >
> > > - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > > -return EFI_INVALID_PARAMETER;
> > > + switch (Count) {
> > > +case 1:
> > > + Width = EfiPciIoWidthUint8;
> > > + break;
> > > +case 2:
> > > + Width = EfiPciIoWidthUint16;
> > > + Count = 1;
> > > + break;
> > > +case 4:
> > > + Width = EfiPciIoWidthUint32;
> > > + Count = 1;
> > > + break;
> > > +case 8:
> > > + Width = EfiPciIoWidthUint32;
> > > + Count = 2;
> > > + break;
> > > +default:
> > > + return EFI_INVALID_PARAMETER;
> > >}
> > >
> > >if (Read) {
> > > Status = PciIo->Mem.Read (
> > >PciIo,
> > > - EfiPciIoWidthUint8,
> > > + Width,
> > >BarIndex,
> > >(UINT64) Offset,
> > >Count,
> > > @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
> > >} else {
> > > Status = PciIo->Mem.Write (
> > >PciIo,
> > > - EfiPciIoWidthUint8,
> > > + Width,
> > >BarIndex,
> > >(UINT64) Offset,
> > >Count,
> > > --
> > > 2.7.4
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
Thanks Jeff.
Reviewed-by: Hao Wu
And pushed via commit f168816c49e388dcd097dd62d766d63f73aaabb3.
Best Regards,
Hao Wu
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Wednesday, February 20, 2019 1:07 AM
> To: edk2-devel@lists.01.org
> Cc: Edgar Handal; Jeff Brasen; Wu, Hao A
> Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> From: Edgar Handal
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1537
>
> Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> accesses from being split up into 8-bit accesses.
>
> The SDHCI specification states that the registers shall be accessible in
> byte, word, and double word accesses. (SD Host Controller Simplified
> Specification 4.20 Section 1.2)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jeff Brasen
> Cc: Hao A Wu
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
>
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 4c64da3..d73fa10 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -154,19 +154,36 @@ SdMmcHcRwMmio (
>)
> {
>EFI_STATUS Status;
> + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
>
>if ((PciIo == NULL) || (Data == NULL)) {
> return EFI_INVALID_PARAMETER;
>}
>
> - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> -return EFI_INVALID_PARAMETER;
> + switch (Count) {
> +case 1:
> + Width = EfiPciIoWidthUint8;
> + break;
> +case 2:
> + Width = EfiPciIoWidthUint16;
> + Count = 1;
> + break;
> +case 4:
> + Width = EfiPciIoWidthUint32;
> + Count = 1;
> + break;
> +case 8:
> + Width = EfiPciIoWidthUint32;
> + Count = 2;
> + break;
> +default:
> + return EFI_INVALID_PARAMETER;
>}
>
>if (Read) {
> Status = PciIo->Mem.Read (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> @@ -175,7 +192,7 @@ SdMmcHcRwMmio (
>} else {
> Status = PciIo->Mem.Write (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> --
> 2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
Thanks Mateusz,
Reviewed-by: Hao Wu
And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
Best Regards,
Hao Wu
> -Original Message-
> From: Albecki, Mateusz
> Sent: Monday, February 18, 2019 7:12 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400
> switch sequence
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
>
> In eMMC HS400 switch sequence flow eMMC driver attempted
> to execute SEND_STATUS just after switching bus timing to high
> speed and before downgrading clock frequency to 52MHz. Since link
> was at that time in incorrect state SEND_STATUS was failing which
> made driver think switch to HS400 failed.
> This change makes driver always change clock frequency after
> switching bus timing and before executing SEND_STATUS.
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
> +
> 1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 4ef849fd0962..15db8a87a5c4 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> }
>
> /**
> - Switch the clock frequency to the specified value.
> + Switch the bus timing and clock frequency.
>
>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> Controller
>Simplified Spec 3.0 Figure 3-3 for details.
> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>
> **/
> EFI_STATUS
> -EmmcSwitchClockFreq (
> +EmmcSwitchBusTiming (
>IN EFI_PCI_IO_PROTOCOL*PciIo,
>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
>IN UINT8 Slot,
> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
>
>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
>if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to hstiming %d
> fails with %r\n", HsTiming, Status));
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to hstiming %d
> fails with %r\n", HsTiming, Status));
> return Status;
>}
>
> - Status = EmmcSendStatus (PassThru, Slot, Rca, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> -return Status;
> - }
> - //
> - // Check the switch operation is really successful or not.
> - //
> - if ((DevStatus & BIT7) != 0) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> -return EFI_DEVICE_ERROR;
> - }
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> + Status = EmmcSendStatus (PassThru, Slot, Rca, );
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Send status fails
> with %r\n", Status));
> +return Status;
> + }
> + //
> + // Check the switch operation is really successful or not.
> + //
> + if ((DevStatus & BIT7) != 0) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> +return EFI_DEVICE_ERROR;
> + }
> +
>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> Status = mOverride->NotifyPhase (
>Private->ControllerHandle,
> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>}
>
>HsTiming = 1;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>
>return Status;
> }
> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CLOCK_CTRL, sizeof
> (ClockCtrl), );
>
>HsTiming = 2;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>if (EFI_ERROR (Status)) {
> return Status;
>}
> @@ -937,7 +938,7 @@ EmmcSwitchToHS400 (
>// Set to Hight Speed timing and set the clock frequency to a value less
> than
> 52MHz.
>//
>HsTiming = 1;
> - Status = EmmcSwit
Re: [edk2] [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
> -Original Message- > From: Dong, Eric > Sent: Monday, February 18, 2019 10:59 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Wang, Jian J; Ni, Ray > Subject: RE: [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to > produce SSC PPI > > Hi Hao, > > > -----Original Message- > > From: Wu, Hao A > > Sent: Friday, February 15, 2019 2:24 PM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A ; Wang, Jian J > ; > > Ni, Ray ; Dong, Eric > > Subject: [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to > > produce SSC PPI > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 > > > > For the NvmExpressPei driver, this commit will add codes to produce the > > Storage Security Command PPI if the underlying NVM Express controller > > supports the Security Send and Security Receive commands. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Eric Dong > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 10 > +- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h| 58 > ++- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h | 20 > +- > > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h > > | 247 > > MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c | 231 > > +++ > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 > > +-- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c | 32 > +- > > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c > > | 423 > > 8 files changed, 1075 insertions(+), 89 deletions(-) > > > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > index 9591572fec..0666e5892b 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > @@ -2,7 +2,7 @@ > > # The NvmExpressPei driver is used to manage non-volatile memory > > subsystem > > # which follows NVM Express specification at PEI phase. > > # > > -# Copyright (c) 2018, Intel Corporation. All rights reserved. > > +# Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > > BSD License > > @@ -30,6 +30,7 @@ > > # > > > > [Sources] > > + DevicePath.c > >DmaMem.c > >NvmExpressPei.c > >NvmExpressPei.h > > @@ -39,6 +40,8 @@ > >NvmExpressPeiHci.h > >NvmExpressPeiPassThru.c > >NvmExpressPeiPassThru.h > > + NvmExpressPeiStorageSecurity.c > > + NvmExpressPeiStorageSecurity.h > > > > [Packages] > >MdePkg/MdePkg.dec > > @@ -54,11 +57,12 @@ > >PeimEntryPoint > > > > [Ppis] > > - gEfiPeiVirtualBlockIoPpiGuid ## PRODUCES > > - gEfiPeiVirtualBlockIo2PpiGuid ## PRODUCES > >gEdkiiPeiNvmExpressHostControllerPpiGuid ## CONSUMES > >gEdkiiIoMmuPpiGuid ## CONSUMES > >gEfiEndOfPeiSignalPpiGuid ## CONSUMES > > + gEfiPeiVirtualBlockIoPpiGuid ## SOMETIMES_PRODUCES > > + gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES > > + gEdkiiPeiStorageSecurityCommandPpiGuid ## > > SOMETIMES_PRODUCES > > > > [Depex] > >gEfiPeiMemoryDiscoveredPpiGuid AND > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > index 0135eca6f0..92c3854c6e 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -44,6 +45,7 @@ typedef struct > > _PEI_NVME_CONTROLLER_PRIVATE_DATA > > PEI_NVME_CONTROLLER_PRIVATE_DA > > #include "NvmExpressPeiHci.h" > > #include "NvmExpressPeiPassThru.h" > > #include "NvmExpressPeiBlockIo.h" > > +#include "NvmExpressPeiStorageSecurity.h" > > > > // >
Re: [edk2] [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
Hi Mateusz,
I found that the patch proposed is actually handling one of the issues
reported in the below BZ tracker:
https://bugzilla.tianocore.org/show_bug.cgi?id=1140
According to the discussion within the tracker, there are 2 fixes needed
for the SdMmcPciHcDxe:
1. Move the clock supply before doing send status
2. More robust handle to the send status CRC error on the switch to HS200
I think the proposed patch is handling the 1st issue listed above.
So could you help to add the below line:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
at the beginning of your commit log message?
Also, please see the below inline comments below:
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Albecki, Mateusz
> Sent: Friday, February 15, 2019 10:45 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [edk2] [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC
> HS400 switch sequence
>
> In eMMC HS400 switch sequence flow eMMC driver attampted
'attampted' -> 'attempted'
> to execute SEND_STATUS just after switching bus timing to high
> speed and before downgrading clock frequency to 52MHz. Since link
> was at that time in incorrect state SEND_STATUS was failing which
> made driver think switch to HS400 failed.
> This change makes driver always change clock frequency after
> switching bus timing and before executing SEND_STATUS.
>
> Change-Id: Ib1f2c78a8693c2a4ef6e1f1b5da2f4133f6210d2
Please help to remove the above 'Change-Id' information.
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 37
> +
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 4ef849fd0962..22200f806f26 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> }
>
> /**
> - Switch the clock frequency to the specified value.
> + Switch the bus timing and clock frequency.
>
>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> Controller
>Simplified Spec 3.0 Figure 3-3 for details.
> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>
> **/
> EFI_STATUS
> -EmmcSwitchClockFreq (
> +EmmcSwitchBusTiming (
Could you help to update the debug messages that include keyword
'EmmcSwitchClockFreq' to 'EmmcSwitchBusTiming' to align with the function
name change?
Best Regards,
Hao Wu
>IN EFI_PCI_IO_PROTOCOL*PciIo,
>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
>IN UINT8 Slot,
> @@ -693,18 +693,6 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> - Status = EmmcSendStatus (PassThru, Slot, Rca, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> -return Status;
> - }
> - //
> - // Check the switch operation is really successful or not.
> - //
> - if ((DevStatus & BIT7) != 0) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> -return EFI_DEVICE_ERROR;
> - }
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> + Status = EmmcSendStatus (PassThru, Slot, Rca, );
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> +return Status;
> + }
> + //
> + // Check the switch operation is really successful or not.
> + //
> + if ((DevStatus & BIT7) != 0) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> +return EFI_DEVICE_ERROR;
> + }
> +
>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> Status = mOverride->NotifyPhase (
>Private->ControllerHandle,
> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>}
>
>HsTiming = 1;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>
>return Status;
> }
> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CLOCK_CTRL, sizeof
> (ClockCtrl), );
>
>HsTiming = 2;
> - Statu
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
Hello Jeff,
Sorry for the delayed response.
I have verified your patch with the board on my side and it is working
fine. And I saw around 3~4 milliseconds performance boost. So I think the
patch will bring performance benefit to the driver.
Some minor inline comments below:
From: Jeff Brasen [mailto:jbra...@nvidia.com]
Sent: Saturday, February 02, 2019 1:53 AM
To: Wu, Hao A; edk2-devel@lists.01.org
Cc: Edgar Handal
Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
From: Wu, Hao A
Sent: Friday, February 1, 2019 12:54 AM
To: Jeff Brasen; edk2-devel@lists.01.org
Cc: Edgar Handal
Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Friday, February 01, 2019 3:12 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
>
>
> -----Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:56 PM
> To: Jeff Brasen ; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff Brasen
> > Sent: Thursday, January 31, 2019 7:59 AM
> > To: edk2-devel@lists.01.org
> > Cc: Edgar Handal; Jeff Brasen
> > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> > widths
> >
Could you help to file a Bugzilla tracker to state the purpose of this
patch and make a reference in the commit log message here? Thanks.
> > From: Edgar Handal
> >
> > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > accesses from being split up into 8-bit accesses.
> >
> > The SDHCI specification states that the registers shall be accessable
> > in byte, word, and double word accesses.
'accessable' -> 'accessible'.
Also, could you help to quote the detailed context from the SD HCI spec
for the above statement?
Lastly, could you help to add your performance evaluation data in the
commit log message as well?
With the above 3 minor comments handled:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>
> Hi,
>
> Thanks for the contribution. The change seems good to me.
>
> Just curious, if the accesses are always slit into byte(8-bit), is there any
> issue or
> performance impact is encountered during your usage?
>
> It will be helpful to get more information on the purpose of the patch.
> Thanks.
>
> Best Regards,
> Hao Wu
>
> [JMB] We were working with a simulation module that has some issues when
> accessing 16 or 32 bit registers by byte (This should be supported per the
> SDHCI
> specification.), and this patch resolves this while we work on getting the
> model
> fixed. This should also optimize performance as there will less read/write
> instructions (My guess is this is a marginal improvement as most of the SD
> access time would be DMA operations.)
Thanks Jeff,
Got it. May I know is it possible for you to collect some performance data
for the change?
[JMB] Sure, did a several boots on silicon platform and see an average boot
time improvement of 15ms. With a range of 10-20ms and never saw the performance
get worse.
Meanwhile, I will test this patch with the boards I own and try to collect
some data. Please grant me some time for this. Since the current
implementation does not violate the spec, let us evaluate whether better
performance will be brought.
Best Regards,
Hao Wu
>
> Thanks,
> Jeff
>
>
>
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jeff Brasen
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> >
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > index 5aec8c6..82f4493 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> >)
> > {
> >EFI_STATUS Status;
> > + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> >
> >if ((PciIo == NULL) || (Data == NULL)) {
> > return EFI_INVALID_PARAMETER;
> >}
> >
> > - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > -return EFI_INVALID_PARAMETER;
> > + switch (Count) {
&g
Re: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ray Ni > Sent: Tuesday, February 12, 2019 5:48 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 > BAR isn't restored sometimes > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505 > > v2: fixed all typos in PciBus driver. > changed RomSize to UINT32 and added type cast to PPB MEM32 BAR > Base/Length to avoid using RShiftU64(). For the series: Reviewed-by: Hao Wu Best Regards, Hao Wu > > > Ray Ni (3): > MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 type > MdeModulePkg/PciBus: Correct typos > MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored > sometimes > > MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h | 4 +- > MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 14 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h | 16 +-- > .../Bus/Pci/PciBusDxe/PciDeviceSupport.c | 20 ++-- > .../Bus/Pci/PciBusDxe/PciDeviceSupport.h | 14 +-- > .../Bus/Pci/PciBusDxe/PciDriverOverride.c | 4 +- > .../Bus/Pci/PciBusDxe/PciDriverOverride.h | 4 +- > .../Bus/Pci/PciBusDxe/PciEnumerator.c | 8 +- > .../Bus/Pci/PciBusDxe/PciEnumerator.h | 8 +- > .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 42 +++ > .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h | 16 +-- > .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 16 +-- > .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 18 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c| 16 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h| 4 +- > MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 4 +- > .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 6 +- > .../Bus/Pci/PciBusDxe/PciOptionRomSupport.h | 4 +- > .../Bus/Pci/PciBusDxe/PciPowerManagement.c| 4 +- > .../Bus/Pci/PciBusDxe/PciPowerManagement.h| 4 +- > .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 113 +- > .../Bus/Pci/PciBusDxe/PciResourceSupport.h| 41 --- > MdeModulePkg/Bus/Pci/PciBusDxe/PciRomTable.h | 7 +- > 23 files changed, 190 insertions(+), 197 deletions(-) > > -- > 2.20.1.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: Chen, Chen A
> Sent: Wednesday, February 13, 2019 8:53 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 87
> ---
> 1 file changed, 60 insertions(+), 27 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..9fd4af4e55 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
> - FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
> + FileInfoBuffer = AllocateZeroPool (sizeof (FileInfo) * FileCount);
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
>
>Print(L"The infomation of the capsules:\n");
> @@ -875,27 +897,28 @@ DumpCapsuleFromDisk (
> FileHandle = NULL;
> Status = DirHandle->Open (DirHandle, , FileInfoBuffer[Index]-
> >FileName, EFI_FILE_MODE_READ, 0);
> if (EFI_ERROR (Status)) {
> -
Re: [edk2] [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, February 12, 2019 3:56 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 83
> ---
> 1 file changed, 58 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..732472bb9c 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
>FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
For me, AllocateZeroPool() should be used here.
Please refer to the reason below.
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
If the memory allocation somehow fails during the 'do-while' loop, the
elements within array 'FileInfoBuffer' will not all have valid pointer
values.
So I believe, an 'AllocateZeroPool' should be used above.
With this addressed,
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
>
>Print(L"The infomation of the capsules:\n");
> @@
Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix potential NULL pointer dereference issue
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Monday, February 11, 2019 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Gao, Liming
> Subject: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix potential NULL pointer
> dereference issue
>
> To avoid potential NULL pointer dereference issue. Initialize them at
> the beginning of the function. This patch is a supplement which was missed
> at e98212cb5d59fff8f385d9179ad7f1a3ce9cf215 commit.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 23
> +-
> .../Application/CapsuleApp/CapsuleOnDisk.c | 5 -
> 2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index 33d2ecc582..cbbfda1424 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -1001,12 +1001,15 @@ DumpProvisionedCapsule (
>EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Fs;
>EFI_SHELL_PROTOCOL *ShellProtocol;
>
> - ShellProtocol = GetShellProtocol ();
> -
>Index = 0;
>CapsuleDataPtr64 = NULL;
>BootNext = NULL;
> - ShellProtocol = NULL;
> +
> + ShellProtocol = GetShellProtocol ();
> + if (ShellProtocol == NULL) {
> +Print (L"Get Shell Protocol Fail\n");
> +return ;
> + }
>
>//
>// Dump capsule provisioned on Memory
> @@ -1033,16 +1036,16 @@ DumpProvisionedCapsule (
>(VOID **) ,
>NULL
>);
> -if (EFI_ERROR (Status)) {
> +if (EFI_ERROR (Status) || CapsuleDataPtr64 == NULL) {
>if (Index == 0) {
> Print (L"No data.\n");
>}
>break;
> -} else {
> - Index++;
> - Print (L"Capsule Description at 0x%08x\n", *CapsuleDataPtr64);
> - DumpBlockDescriptors ((EFI_CAPSULE_BLOCK_DESCRIPTOR*) (UINTN)
> *CapsuleDataPtr64, DumpCapsuleInfo);
> }
> +
> +Index++;
> +Print (L"Capsule Description at 0x%08x\n", *CapsuleDataPtr64);
> +DumpBlockDescriptors ((EFI_CAPSULE_BLOCK_DESCRIPTOR*) (UINTN)
> *CapsuleDataPtr64, DumpCapsuleInfo);
>}
>
>//
> @@ -1057,7 +1060,9 @@ DumpProvisionedCapsule (
> (VOID **) ,
> NULL
> );
> - if (!EFI_ERROR (Status)) {
> + if (EFI_ERROR (Status) || BootNext == NULL) {
> +Print (L"Get BootNext Variable Fail. Status = %r\n", Status);
> + } else {
> UnicodeSPrint (BootOptionName, sizeof (BootOptionName), L"Boot%04x",
> *BootNext);
> Status = EfiBootManagerVariableToLoadOption (BootOptionName,
> );
> if (!EFI_ERROR (Status)) {
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> index 4faa863bca..f6e46cbdb1 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -445,7 +445,10 @@ GetUpdateFileSystem (
> (VOID **),
> NULL
> );
> -if (!EFI_ERROR (Status)) {
> +if (EFI_ERROR (Status) || BootNextData == NULL) {
> + Print (L"Get Boot Next Data Fail. Status = %r\n", Status);
> + return EFI_NOT_FOUND;
> +} else {
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>UnicodeSPrint (BootOptionName, sizeof (BootOptionName), L"Boot%04x",
> *BootNextData);
>Status = EfiBootManagerVariableToLoadOption (BootOptionName,
> );
>if (!EFI_ERROR (Status)) {
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Monday, February 11, 2019 2:17 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Gao, Liming; Zhang, Chao B
> Subject: [edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 81
> ---
> 1 file changed, 56 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index 7bef5a1378..00cf45d66a 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
>FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, )
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
An error handling may be needed here as well.
Also, if memory allocation does fail here during the 'do-while' loop,
elements in array 'FileInfoBuffer' may not all have valid values.
For this case, the cleanup under tag 'Done' may not be proper.
Best Regards,
Hao Wu
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
>
>Print(L"The infomation of the capsules:\n");
> @@ -875,19 +897,20 @@ DumpCapsuleFromDisk (
&g
Re: [edk2] [PATCH] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu,
> Hao A
> Sent: Thursday, February 07, 2019 10:18 AM
> To: Ni, Ray; edk2-devel@lists.01.org
> Cc: Bi, Dandan
> Subject: Re: [edk2] [PATCH] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR
> isn't restored sometimes
>
> > -Original Message-
> > From: Ni, Ray
> > Sent: Friday, February 01, 2019 4:59 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ray; Wu, Hao A; Bi, Dandan
> > Subject: [PATCH] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't
> > restored sometimes
> >
> > From: Ruiyu Ni
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505
> >
> > When a device under PPB contains option ROM but doesn't require 32bit
> > MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the
> > PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may
> > cause system hangs in boot.
> >
> > The root cause is when ProgrameUpstreamBridgeForRom() calls
> > ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the
> > ProgramPpbApperture() skips to program the BAR when the resource
> > length is 0.
> >
> > This patch fixes this issue by not calling ProgramPpbApperture().
> > Instead, it directly programs the PPB MEM32 RANGE BAR.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ray Ni
> > Cc: Hao Wu
> > Cc: Dandan Bi
> > ---
> > .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 53 +--
> > 1 file changed, 24 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> > index d3cbefbadf..77cdc3e844 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> > @@ -1,7 +1,7 @@
> > /** @file
> >PCI resouces support functions implemntation for PCI Bus module.
> >
> > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > which accompanies this distribution. The full text of the license may be
> found
> > at
> > @@ -1661,57 +1661,52 @@ ProgrameUpstreamBridgeForRom (
>
> Not directly related to the purpose of the patch, seems to me there is a
> typo for the function name:
> Programe -> Program
>
> >IN BOOLEAN Enable
> >)
> > {
> > - PCI_IO_DEVICE *Parent;
> > - PCI_RESOURCE_NODE Node;
> > - UINT64Base;
> > - UINT64Length;
> > + PCI_IO_DEVICE *Parent;
> > + EFI_PCI_IO_PROTOCOL *PciIo;
> > + UINT16 Base;
> > + UINT16 Limit;
> >//
> >// For root bridge, just return.
> >//
> >Parent = PciDevice->Parent;
> > - ZeroMem (, sizeof (Node));
> >while (Parent != NULL) {
> > if (!IS_PCI_BRIDGE (>Pci)) {
> >break;
> > }
> >
> > -Node.PciDev = Parent;
> > -Node.Alignment = 0;
> > -Node.Bar= PPB_MEM32_RANGE;
> > -Node.ResType= PciBarTypeMem32;
> > -Node.Offset = 0;
> > +PciIo = >PciIo;
> >
> > //
> > // Program PPB to only open a single <= 16MB apperture
>
> Also not directly related:
> apperture -> aperture
>
> There seems lots of 'apperture' within this driver.
> I would suggest to propose another patch to address those typos.
>
> > //
> > if (Enable) {
> > - //
> > - // Save the original PPB_MEM32_RANGE BAR.
> > - // The values will be changed by ProgramPpbApperture().
> > - //
> > - Base = Parent->PciBar[Node.Bar].BaseAddress;
> > - Length = Parent->PciBar[Node.Bar].Length;
> > -
> >//
> >// Only cover MMIO for Option ROM.
> >//
> > - Node.Length = PciDevice->RomSize;
> > - ProgramPpbApperture (OptionRomBase, );
> > -
> > - //
> > - // Restore the original PPB_MEM32_RANGE BAR.
> > - // So the MEM32 RANGE BAR register can be restored when disable the
> > decoding.
> > - //
> > - Parent->PciBar[Node.Bar].BaseAddress = Base;
> > - Parent->PciBa
Re: [edk2] [PATCH] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes
> -Original Message-
> From: Ni, Ray
> Sent: Friday, February 01, 2019 4:59 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray; Wu, Hao A; Bi, Dandan
> Subject: [PATCH] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't
> restored sometimes
>
> From: Ruiyu Ni
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505
>
> When a device under PPB contains option ROM but doesn't require 32bit
> MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the
> PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may
> cause system hangs in boot.
>
> The root cause is when ProgrameUpstreamBridgeForRom() calls
> ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the
> ProgramPpbApperture() skips to program the BAR when the resource
> length is 0.
>
> This patch fixes this issue by not calling ProgramPpbApperture().
> Instead, it directly programs the PPB MEM32 RANGE BAR.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ray Ni
> Cc: Hao Wu
> Cc: Dandan Bi
> ---
> .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 53 +--
> 1 file changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> index d3cbefbadf..77cdc3e844 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
> @@ -1,7 +1,7 @@
> /** @file
>PCI resouces support functions implemntation for PCI Bus module.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -1661,57 +1661,52 @@ ProgrameUpstreamBridgeForRom (
Not directly related to the purpose of the patch, seems to me there is a
typo for the function name:
Programe -> Program
>IN BOOLEAN Enable
>)
> {
> - PCI_IO_DEVICE *Parent;
> - PCI_RESOURCE_NODE Node;
> - UINT64Base;
> - UINT64Length;
> + PCI_IO_DEVICE *Parent;
> + EFI_PCI_IO_PROTOCOL *PciIo;
> + UINT16 Base;
> + UINT16 Limit;
>//
>// For root bridge, just return.
>//
>Parent = PciDevice->Parent;
> - ZeroMem (, sizeof (Node));
>while (Parent != NULL) {
> if (!IS_PCI_BRIDGE (>Pci)) {
>break;
> }
>
> -Node.PciDev = Parent;
> -Node.Alignment = 0;
> -Node.Bar= PPB_MEM32_RANGE;
> -Node.ResType= PciBarTypeMem32;
> -Node.Offset = 0;
> +PciIo = >PciIo;
>
> //
> // Program PPB to only open a single <= 16MB apperture
Also not directly related:
apperture -> aperture
There seems lots of 'apperture' within this driver.
I would suggest to propose another patch to address those typos.
> //
> if (Enable) {
> - //
> - // Save the original PPB_MEM32_RANGE BAR.
> - // The values will be changed by ProgramPpbApperture().
> - //
> - Base = Parent->PciBar[Node.Bar].BaseAddress;
> - Length = Parent->PciBar[Node.Bar].Length;
> -
>//
>// Only cover MMIO for Option ROM.
>//
> - Node.Length = PciDevice->RomSize;
> - ProgramPpbApperture (OptionRomBase, );
> -
> - //
> - // Restore the original PPB_MEM32_RANGE BAR.
> - // So the MEM32 RANGE BAR register can be restored when disable the
> decoding.
> - //
> - Parent->PciBar[Node.Bar].BaseAddress = Base;
> - Parent->PciBar[Node.Bar].Length = Length;
> + Base = (UINT16) (OptionRomBase >> 16);
> + Limit = (UINT16) ((OptionRomBase + PciDevice->RomSize - 1) >> 16);
> + PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01,
> Bridge.MemoryBase), 1, );
> + PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01,
> Bridge.MemoryLimit), 1, );
>
>PCI_ENABLE_COMMAND_REGISTER (Parent,
> EFI_PCI_COMMAND_MEMORY_SPACE);
> } else {
>//
>// Cover 32bit MMIO for devices below the bridge.
>//
> - Node.Length = Parent->PciBar[Node.Bar].Length;
> - ProgramPpbApperture (Parent->PciBar[Node.Bar].BaseAddress, );
> + if (Parent->PciBar[PPB_MEM32_RANGE].Length == 0) {
> +//
> +// When devices under the bridge contains Option ROM and doesn't
>
Re: [edk2] [PATCH v3 11/12] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, February 01, 2019 5:40 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: Re: [edk2] [PATCH v3 11/12] MdeModulePkg/SmmLockBoxLib: Support > LockBox enlarge in UpdateLockBox() > > Hi Hao, > > On 02/01/19 06:47, Hao Wu wrote: > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 > > > > This commit will add the support to enlarge a LockBox when using the > > LockBoxLib API UpdateLockBox(). > > > > Please note that the new support will ONLY work for LockBox with attribute > > LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY set. > > > > The functional uni-test for the commit is available at: > > https://github.com/hwu25/edk2/tree/lockbox_unitest > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Star Zeng > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > MdeModulePkg/Include/Library/LockBoxLib.h | 7 +- > > MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c | 7 +- > > MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c | 5 +- > > MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 5 +- > > MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 72 > ++-- > > 5 files changed, 86 insertions(+), 10 deletions(-) > > > > diff --git a/MdeModulePkg/Include/Library/LockBoxLib.h > b/MdeModulePkg/Include/Library/LockBoxLib.h > > index 5921731419..addce3bd4a 100644 > > --- a/MdeModulePkg/Include/Library/LockBoxLib.h > > +++ b/MdeModulePkg/Include/Library/LockBoxLib.h > > @@ -2,7 +2,7 @@ > >This library is only intended to be used by DXE modules that need save > >confidential information to LockBox and get it by PEI modules in S3 > > phase. > > > > -Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved. > > +Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved. > > > > This program and the accompanying materials > > are licensed and made available under the terms and conditions > > @@ -85,7 +85,10 @@ SetLockBoxAttributes ( > >@retval RETURN_SUCCESSthe information is saved successfully. > >@retval RETURN_INVALID_PARAMETER the Guid is NULL, or Buffer is NULL, > or Length is 0. > >@retval RETURN_NOT_FOUND the requested GUID not found. > > - @retval RETURN_BUFFER_TOO_SMALL the original buffer to too small to > hold new information. > > + @retval RETURN_BUFFER_TOO_SMALL for lockbox with attribute > LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE, > > +the original buffer to too small to > > hold new > information. > > + @retval RETURN_OUT_OF_RESOURCES for lockbox with attribute > LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY, > > +no enough resource to save the > > information. > >@retval RETURN_ACCESS_DENIED it is too late to invoke this interface > >@retval RETURN_NOT_STARTEDit is too early to invoke this > > interface > >@retval RETURN_UNSUPPORTEDthe service is not supported by > implementaion. > > diff --git a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c > b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c > > index c40dfea398..0adda1e2a9 100644 > > --- a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c > > +++ b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c > > @@ -1,6 +1,6 @@ > > /** @file > > > > -Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved. > > +Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved. > > > > This program and the accompanying materials > > are licensed and made available under the terms and conditions > > @@ -76,7 +76,10 @@ SetLockBoxAttributes ( > >@retval RETURN_SUCCESSthe information is saved successfully. > >@retval RETURN_INVALID_PARAMETER the Guid is NULL, or Buffer is NULL, > or Length is 0. > >@retval RETURN_NOT_FOUND the requested GUID not found. > > - @retval RETURN_BUFFER_TOO_SMALL the original buffer to too small to > hold new information. > > + @retval RETURN_BUFFER_TOO_SMALL for lockbox with attribute > LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE, > > +the original buffer to too small to > > hold new > information. > > + @retval RETURN_OUT_OF_RESOURCES for lockbox with attribute > LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY, > > +no enough reso
Re: [edk2] [PATCH v3 10/12] MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 01, 2019 5:18 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Zeng, Star
> Subject: Re: [edk2] [PATCH v3 10/12] MdeModulePkg/SmmLockBox(PEI):
> Remove an ASSERT in RestoreLockBox()
>
> On 02/01/19 06:47, Hao Wu wrote:
> > This commit is out of the scope for BZ-1409. It is a refinement for the
> > PEI library instance within SmmLockBoxLib.
> >
> > For the below ASSERT statement within function RestoreLockBox():
> > Status = SmmCommunicationPpi->Communicate (
> > SmmCommunicationPpi,
> > [0],
> >
> > );
> > if (Status == EFI_NOT_STARTED) {
> > //
> > // Pei SMM communication not ready yet, so we access SMRAM directly
> > //
> > DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n",
> Status));
> > Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
> > LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
> > if (Length != NULL) {
> > LockBoxParameterRestore->Length = (UINT64)*Length;
> > }
> > }
> > ASSERT_EFI_ERROR (Status);
> >
> > It is possible for previous codes to return an error status that is
> > possible for happen. One example is that, when the 'if' statement
> > 'if (Status == EFI_NOT_STARTED) {' is entered, function
> > InternalRestoreLockBoxFromSmram() is possible to return
> 'BUFFER_TOO_SMALL'
> > if the caller of RestoreLockBox() provides a buffer that is too small to
> > hold the content of LockBox.
> >
> > Thus, this commit will remove the ASSERT here.
> >
> > Please note that the current implementation of RestoreLockBox() is
> > handling the above-mentioned error case properly, so no additional error
> > handling codes are needed here.
> >
> > Cc: Jian J Wang
> > Cc: Star Zeng
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu
> > Reviewed-by: Ray Ni
> > ---
> > MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > index 9f73480070..8c3e65bc96 100644
> > --- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > +++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > @@ -623,7 +623,6 @@ RestoreLockBox (
> >LockBoxParameterRestore->Length = (UINT64)*Length;
> > }
> >}
> > - ASSERT_EFI_ERROR (Status);
> >
> >if (Length != NULL) {
> > *Length = (UINTN)LockBoxParameterRestore->Length;
> >
>
> OVMF never reaches this code path because it doesn't include an
> EFI_PEI_SMM_COMMUNICATION_PPI instance. Therefore OVMF always goes
> through InternalRestoreLockBoxFromSmram().
>
> See commit bd3afeb1d62c ("MdeModulePkg: SmmLockBoxPeiLib: work without
> EFI_PEI_SMM_COMMUNICATION_PPI", 2015-11-16).
>
> In that regard, I'm OK with this patch; this alone would suffice for me
> to give an Acked-by.
>
> However, having re-reviewed bd3afeb1d62c now, I see that this patch is
> actually technically correct. So I believe I can give an R-b too,
> despite OVMF not using the affected code path.
>
> Reviewed-by: Laszlo Ersek
>
> Other than that, you might want to review existing callers of this
> function, to ensure they don't rely on any such failure being caught
> internally to the function (via the ASSERT that's now being removed).
> Again, this would only be relevant for platforms that produce an
> EFI_PEI_SMM_COMMUNICATION_PPI instance.
Sure. Thanks for the reminder.
I will check those callers before pushing this change.
Best Regards,
Hao Wu
>
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Friday, February 01, 2019 3:12 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
>
>
> -----Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:56 PM
> To: Jeff Brasen ; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff Brasen
> > Sent: Thursday, January 31, 2019 7:59 AM
> > To: edk2-devel@lists.01.org
> > Cc: Edgar Handal; Jeff Brasen
> > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> > widths
> >
> > From: Edgar Handal
> >
> > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > accesses from being split up into 8-bit accesses.
> >
> > The SDHCI specification states that the registers shall be accessable
> > in byte, word, and double word accesses.
>
> Hi,
>
> Thanks for the contribution. The change seems good to me.
>
> Just curious, if the accesses are always slit into byte(8-bit), is there any
> issue or
> performance impact is encountered during your usage?
>
> It will be helpful to get more information on the purpose of the patch.
> Thanks.
>
> Best Regards,
> Hao Wu
>
> [JMB] We were working with a simulation module that has some issues when
> accessing 16 or 32 bit registers by byte (This should be supported per the
> SDHCI
> specification.), and this patch resolves this while we work on getting the
> model
> fixed. This should also optimize performance as there will less read/write
> instructions (My guess is this is a marginal improvement as most of the SD
> access time would be DMA operations.)
Thanks Jeff,
Got it. May I know is it possible for you to collect some performance data
for the change?
Meanwhile, I will test this patch with the boards I own and try to collect
some data. Please grant me some time for this. Since the current
implementation does not violate the spec, let us evaluate whether better
performance will be brought.
Best Regards,
Hao Wu
>
> Thanks,
> Jeff
>
>
>
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jeff Brasen
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> >
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > index 5aec8c6..82f4493 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> >)
> > {
> >EFI_STATUS Status;
> > + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> >
> >if ((PciIo == NULL) || (Data == NULL)) {
> > return EFI_INVALID_PARAMETER;
> >}
> >
> > - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > -return EFI_INVALID_PARAMETER;
> > + switch (Count) {
> > +case 1:
> > + Width = EfiPciIoWidthUint8;
> > + break;
> > +case 2:
> > + Width = EfiPciIoWidthUint16;
> > + Count = 1;
> > + break;
> > +case 4:
> > + Width = EfiPciIoWidthUint32;
> > + Count = 1;
> > + break;
> > +case 8:
> > + Width = EfiPciIoWidthUint32;
> > + Count = 2;
> > + break;
> > +default:
> > + return EFI_INVALID_PARAMETER;
> >}
> >
> >if (Read) {
> > Status = PciIo->Mem.Read (
> >PciIo,
> > - EfiPciIoWidthUint8,
> > + Width,
> >BarIndex,
> >(UINT64) Offset,
> >Count,
> > @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
> >} else {
> > Status = PciIo->Mem.Write (
> >PciIo,
> > - EfiPciIoWidthUint8,
> > + Width,
> >BarIndex,
> >(UINT64) Offset,
Re: [edk2] [patch 1/2] MdeModulePkg: Fix coding style issues
> -Original Message-
> From: Bi, Dandan
> Sent: Friday, February 01, 2019 2:02 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel; Wang, Jian J; Wu, Hao A
> Subject: [patch 1/2] MdeModulePkg: Fix coding style issues
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1479
>
> Fix issues that reported by Edk2 coding style check tool(ECC) that:
> Comment description should end with period '.'
>
> Cc: Ard Biesheuvel
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi
> ---
> .../FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h | 4 ++--
> .../FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c | 2 +-
> .../FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c | 2 +-
> .../Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h| 4 ++--
> .../Universal/Variable/RuntimeDxe/VariableStandaloneMm.c| 6 +++---
> .../Universal/Variable/RuntimeDxe/VariableTraditionalMm.c | 4 ++--
> 6 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> index 61293ca864..cf1aef7ca4 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> @@ -76,11 +76,11 @@ typedef struct {
>BOOLEAN Complete;
>UINT8 Data[1];
> } SMM_FTW_GET_LAST_WRITE_HEADER;
>
> /**
> - Shared entry point of the module
> + Shared entry point of the module.
>
>@retval EFI_SUCCESS The initialization finished successfully.
>@retval EFI_OUT_OF_RESOURCES Allocate memory error
>@retval EFI_INVALID_PARAMETER Workspace or Spare block does not exist
>
> @@ -107,11 +107,11 @@ FtwSmmIsBufferOutsideSmmValid (
>IN EFI_PHYSICAL_ADDRESS Buffer,
>IN UINT64Length
>);
>
> /**
> - Notify the system that the SMM FTW driver is ready
> + Notify the system that the SMM FTW driver is ready.
> **/
> VOID
> FtwNotifySmmReady (
>VOID
>);
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> index 8a4ea5b476..c2aa501465 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> @@ -63,11 +63,11 @@ FtwCalculateCrc32 (
> {
>return CalculateCrc32 (Buffer, Length);
> }
>
> /**
> - Notify the system that the SMM FTW driver is ready
> + Notify the system that the SMM FTW driver is ready.
> **/
> VOID
> FtwNotifySmmReady (
>VOID
>)
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> index 0981c3c2a9..7c76e1f756 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> @@ -70,11 +70,11 @@ FtwCalculateCrc32 (
>
>return ReturnValue;
> }
>
> /**
> - Notify the system that the SMM FTW driver is ready
> + Notify the system that the SMM FTW driver is ready.
> **/
> VOID
> FtwNotifySmmReady (
>VOID
>)
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index 0a886558f4..9b294e6b36 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> @@ -96,19 +96,19 @@ VOID
> VariableSpeculationBarrier (
>VOID
>);
>
> /**
> - Notify the system that the SMM variable driver is ready
> + Notify the system that the SMM variable driver is ready.
> **/
> VOID
> VariableNotifySmmReady (
>VOID
>);
>
> /**
> - Notify the system that the SMM variable write driver is ready
> + Notify the system that the SMM variable write driver is ready.
> **/
> VOID
> VariableNotifySmmWriteReady (
>VOID
>);
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStan
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff
> Brasen
> Sent: Thursday, January 31, 2019 7:59 AM
> To: edk2-devel@lists.01.org
> Cc: Edgar Handal; Jeff Brasen
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> From: Edgar Handal
>
> Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> accesses from being split up into 8-bit accesses.
>
> The SDHCI specification states that the registers shall be accessable in
> byte, word, and double word accesses.
Hi,
Thanks for the contribution. The change seems good to me.
Just curious, if the accesses are always slit into byte(8-bit), is there any
issue or performance impact is encountered during your usage?
It will be helpful to get more information on the purpose of the patch.
Thanks.
Best Regards,
Hao Wu
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jeff Brasen
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
>
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 5aec8c6..82f4493 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
>)
> {
>EFI_STATUS Status;
> + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
>
>if ((PciIo == NULL) || (Data == NULL)) {
> return EFI_INVALID_PARAMETER;
>}
>
> - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> -return EFI_INVALID_PARAMETER;
> + switch (Count) {
> +case 1:
> + Width = EfiPciIoWidthUint8;
> + break;
> +case 2:
> + Width = EfiPciIoWidthUint16;
> + Count = 1;
> + break;
> +case 4:
> + Width = EfiPciIoWidthUint32;
> + Count = 1;
> + break;
> +case 8:
> + Width = EfiPciIoWidthUint32;
> + Count = 2;
> + break;
> +default:
> + return EFI_INVALID_PARAMETER;
>}
>
>if (Read) {
> Status = PciIo->Mem.Read (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
>} else {
> Status = PciIo->Mem.Write (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> --
> 2.7.4
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 10/12] MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, January 31, 2019 1:50 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Ni, Ray; Zeng, Star
> Subject: Re: [PATCH v2 10/12] MdeModulePkg/SmmLockBox(PEI): Remove an
> ASSERT in RestoreLockBox()
>
> On 1/31/2019 10:48 AM, Hao Wu wrote:
> > This commit is out of the scope for BZ-1409. It is a refinement for the
> > PEI library instance within SmmLockBoxLib.
> >
> > For the below ASSERT statement within function RestoreLockBox():
> >Status = SmmCommunicationPpi->Communicate (
> >SmmCommunicationPpi,
> >[0],
> >
> >);
> >if (Status == EFI_NOT_STARTED) {
> > //
> > // Pei SMM communication not ready yet, so we access SMRAM directly
> > //
> > DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n",
> Status));
> > Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
> > LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
> > if (Length != NULL) {
> >LockBoxParameterRestore->Length = (UINT64)*Length;
> > }
> >}
> >ASSERT_EFI_ERROR (Status);
> >
> > It is possible for previous codes to return an error status that is
> > possible for happen. One example is that, when the 'if' statement
> > 'if (Status == EFI_NOT_STARTED) {' is entered, function
> > InternalRestoreLockBoxFromSmram() is possible to return
> 'BUFFER_TOO_SMALL'
> > if the caller of RestoreLockBox() provides a buffer that is too small to
> > hold the content of LockBox.
> >
> > Thus, this commit will remove the ASSERT here.
> >
> > Please note that the current implementation of RestoreLockBox() is
> > handling the above-mentioned error case properly, so no additional error
> > handling codes are needed here.
> >
> > Cc: Jian J Wang
> > Cc: Ray Ni
> > Cc: Star Zeng
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu
> > ---
> > MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > index 9f73480070..9d7b4c3706 100644
> > --- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > +++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
> > @@ -623,7 +623,7 @@ RestoreLockBox (
> > LockBoxParameterRestore->Length = (UINT64)*Length;
> > }
> > }
> > - ASSERT_EFI_ERROR (Status);
> > + //ASSERT_EFI_ERROR (Status);
It comes to me that the above line should be removed rather than being
commented. Will handle in the next series.
Best Regards,
Hao Wu
> >
> > if (Length != NULL) {
> > *Length = (UINTN)LockBoxParameterRestore->Length;
> >
> Reviewed-by: Ray Ni
>
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 07/12] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, January 31, 2019 11:45 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Dong, Eric
> Subject: RE: [PATCH v2 07/12] MdeModulePkg/NvmExpressPei: Consume
> S3StorageDeviceInitList LockBox
>
>
>
> > -----Original Message-
> > From: Wu, Hao A
> > Sent: Thursday, January 31, 2019 10:49 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A ; Wang, Jian J ;
> > Ni, Ray ; Dong, Eric
> > Subject: [PATCH v2 07/12] MdeModulePkg/NvmExpressPei: Consume
> > S3StorageDeviceInitList LockBox
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
> >
> > For the NvmExpressPei driver, this commit will update the driver to consume
> > the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to perform
> > an on-demand (partial) NVM Express device enumeration/initialization to
> > benefit the S3 resume performance.
> >
> > Cc: Jian J Wang
> > Cc: Ray Ni
> > Cc: Eric Dong
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu
> > ---
> > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 8 +-
> > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h | 16 +++
> > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c | 20
> > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c | 106
> >
> > 4 files changed, 149 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> > index 0666e5892b..22b703e971 100644
> > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> > @@ -40,6 +40,7 @@
> >NvmExpressPeiHci.h
> >NvmExpressPeiPassThru.c
> >NvmExpressPeiPassThru.h
> > + NvmExpressPeiS3.c
> >NvmExpressPeiStorageSecurity.c
> >NvmExpressPeiStorageSecurity.h
> >
> > @@ -54,6 +55,7 @@
> >BaseMemoryLib
> >IoLib
> >TimerLib
> > + LockBoxLib
> >PeimEntryPoint
> >
> > [Ppis]
> > @@ -64,9 +66,13 @@
> >gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES
> >gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
> >
> > +[Guids]
> > + gS3StorageDeviceInitListGuid ## SOMETIMES_CONSUMES ##
> > UNDEFINED
> > +
> > [Depex]
> >gEfiPeiMemoryDiscoveredPpiGuid AND
> > - gEdkiiPeiNvmExpressHostControllerPpiGuid
> > + gEdkiiPeiNvmExpressHostControllerPpiGuid AND
> > + gEfiPeiMasterBootModePpiGuid
> >
> > [UserExtensions.TianoCore."ExtraFiles"]
> >NvmExpressPeiExtra.uni
> > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> > index 7047c4f3ff..6f01413e6d 100644
> > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> > @@ -332,4 +332,20 @@ NvmeBuildDevicePath (
> >OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
> >);
> >
> > +/**
> > + Determine if a specific NVM Express controller can be skipped for S3
> > phase.
> > +
> > + @param[in] HcDevicePath Device path of the controller.
> > + @param[in] HcDevicePathLengthLength of the device path specified by
> > +HcDevicePath.
> > +
> > + @retvalThe number of ports that need to be enumerated.
> > +
> > +**/
> > +BOOLEAN
> > +NvmeS3SkipThisController (
> > + IN EFI_DEVICE_PATH_PROTOCOL*HcDevicePath,
> > + IN UINTN HcDevicePathLength
> > + );
> > +
> > #endif
> > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> > index 96622e6fd5..43b2dfc3e7 100644
> > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> > @@ -213,6 +213,7 @@ NvmExpressPeimEntry (
> >)
> > {
> >EFI_STATUS Status;
> > + EFI_BOOT_MODEBootMode;
> >EDKII_NVM_EXPRESS_HOST_CONTROLLER_PPI*NvmeHcPpi;
> >UINT8Controller;
> >UINTNMmioBase;
> > @@ -224,6 +225,15 @@ NvmExpressPeimEntry (
> >DEBUG ((D
Re: [edk2] [PATCH v2 06/12] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
> -Original Message- > From: Ni, Ray > Sent: Thursday, January 31, 2019 11:35 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Wang, Jian J; Dong, Eric > Subject: RE: [PATCH v2 06/12] MdeModulePkg/NvmExpressPei: Add logic to > produce SSC PPI > > > > > -----Original Message- > > From: Wu, Hao A > > Sent: Thursday, January 31, 2019 10:49 AM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A ; Wang, Jian J ; > > Ni, Ray ; Dong, Eric > > Subject: [PATCH v2 06/12] MdeModulePkg/NvmExpressPei: Add logic to > > produce SSC PPI > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 > > > > For the NvmExpressPei driver, this commit will add codes to produce the > > Storage Security Command PPI if the underlying NVM Express controller > > supports the Security Send and Security Receive commands. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Eric Dong > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 10 +- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h| 81 > > +++- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h | 20 +- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h > > | 247 > > MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c | 317 > > +++ > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 > > +-- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c | 32 +- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c > > | 423 > > 8 files changed, 1184 insertions(+), 89 deletions(-) > > > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > index 9591572fec..0666e5892b 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > @@ -2,7 +2,7 @@ > > # The NvmExpressPei driver is used to manage non-volatile memory > > subsystem > > # which follows NVM Express specification at PEI phase. > > # > > -# Copyright (c) 2018, Intel Corporation. All rights reserved. > > +# Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > > BSD License > > @@ -30,6 +30,7 @@ > > # > > > > [Sources] > > + DevicePath.c > >DmaMem.c > >NvmExpressPei.c > >NvmExpressPei.h > > @@ -39,6 +40,8 @@ > >NvmExpressPeiHci.h > >NvmExpressPeiPassThru.c > >NvmExpressPeiPassThru.h > > + NvmExpressPeiStorageSecurity.c > > + NvmExpressPeiStorageSecurity.h > > > > [Packages] > >MdePkg/MdePkg.dec > > @@ -54,11 +57,12 @@ > >PeimEntryPoint > > > > [Ppis] > > - gEfiPeiVirtualBlockIoPpiGuid ## PRODUCES > > - gEfiPeiVirtualBlockIo2PpiGuid ## PRODUCES > >gEdkiiPeiNvmExpressHostControllerPpiGuid ## CONSUMES > >gEdkiiIoMmuPpiGuid ## CONSUMES > >gEfiEndOfPeiSignalPpiGuid ## CONSUMES > > + gEfiPeiVirtualBlockIoPpiGuid ## SOMETIMES_PRODUCES > > + gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES > > + gEdkiiPeiStorageSecurityCommandPpiGuid ## > > SOMETIMES_PRODUCES > > > > [Depex] > >gEfiPeiMemoryDiscoveredPpiGuid AND > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > index 0135eca6f0..7047c4f3ff 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -44,6 +45,7 @@ typedef struct > > _PEI_NVME_CONTROLLER_PRIVATE_DATA > > PEI_NVME_CONTROLLER_PRIVATE_DA > > #include "NvmExpressPeiHci.h" > > #include "NvmExpressPeiPassThru.h" > > #include "NvmExpressPeiBlockIo.h" > > +#include "NvmExpressPeiStorageSecurity.h" > > > > // > > // NVME P
Re: [edk2] [PATCH v2 04/12] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, January 31, 2019 11:27 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Dong, Eric
> Subject: RE: [PATCH v2 04/12] MdeModulePkg: Add GUID for LockBox to save
> storage dev to init in S3
>
>
>
> > -----Original Message-
> > From: Wu, Hao A
> > Sent: Thursday, January 31, 2019 10:49 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A ; Wang, Jian J ;
> > Ni, Ray ; Dong, Eric
> > Subject: [PATCH v2 04/12] MdeModulePkg: Add GUID for LockBox to save
> > storage dev to init in S3
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
> >
> > This commit will add the GUID definitions for LockBox which is used to save
> > a
> > list of storage devices that need to get initialized during the S3 resume.
> >
> > The content of the LockBox will be a DevicePath structure that contains zero
> > or more DevicePath instances. Each instance denotes a storage device that
> > needs to get initialized during the S3 resume.
> >
> > The producers of the content of this LockBox will be drivers like
> > OpalPassword DXE driver. This kind of drivers requires some specific storage
> > devices to be initialized during the PEI phase of in S3 resume.
> > (For the OpalPasword case, it requires the managing devices to be
> > automatically unlocked during the S3 resume).
> >
> > The attribute of the LockBox should be set to
> > LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.
> >
> > The consumers of the content of this LockBox will be PEI storage device
> > controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
> > drivers can use the DevicePath instances stored in the LockBox to get a
> > list of
> > devices that need to get initialized. In such way, an on-demand
> > (partial) device enumeration/initialization can be performed to benefit the
> > S3
> > resume performance.
> >
> > Cc: Jian J Wang
> > Cc: Ray Ni
> > Cc: Eric Dong
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu
> > ---
> > MdeModulePkg/MdeModulePkg.dec | 3 ++
> > MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h | 36
> >
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > b/MdeModulePkg/MdeModulePkg.dec index 7f646d7702..a2130bc439
> > 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -422,6 +422,9 @@
> >## Include/Guid/S3SmmInitDone.h
> >gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71,
> > 0x84, 0x50, 0x25, 0x79, 0x2e, 0xf6 } }
> >
> > + ## Include/Guid/S3StorageDeviceInitList.h
> > + gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e,
> > + 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
> > +
> > [Ppis]
> >## Include/Ppi/AtaController.h
> >gPeiAtaControllerPpiGuid = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0,
> > 0x7a,
> > 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> > diff --git a/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> > b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> > new file mode 100644
> > index 00..cfbd2a78e7
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> > @@ -0,0 +1,36 @@
> > +/** @file
> > + Define the LockBox GUID for list of storage devices need to be
> > +initialized in
> > + S3.
> > +
> > + Copyright (c) 2019, Intel Corporation. All rights reserved.
> > +
> > + This program and the accompanying materials are licensed and made
> > + available under the terms and conditions of the BSD License which
> > + accompanies this distribution. The full text of the license may be
> > + found at http://opensource.org/licenses/bsd-license.php
> > +
> > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#ifndef __S3_STORAGE_DEVICE_INIT_LIST_H__ #define
> > +__S3_STORAGE_DEVICE_INIT_LIST_H__
> > +
> > +#define S3_STORAGE_DEVICE_INIT_LIST \
> > + { \
> > +0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17,
> > +0xc8, 0xef } \
> > + }
> > +
> > +//
> > +// The LockBox will store a DevicePath structure that contains zero or
> > +more // DevicePath instance
Re: [edk2] [PATCH v2 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, January 31, 2019 11:23 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Dong, Eric
> Subject: RE: [PATCH v2 02/12] MdeModulePkg: Add definitions for EDKII PEI
> ATA PassThru PPI
>
> Hao,
> You could re-use the structure definition in AtaPassThru protocol.
> For example: EFI_ATA_PASS_THRU_MODE v.s.
> EDKII_PEI_ATA_PASS_THRU_MODE
> I see more duplicated structure definitions. We can avoid them.
Got it.
I will refine this patch in the next series.
Best Regards,
Hao Wu
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Thursday, January 31, 2019 10:49 AM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A ; Wang, Jian J ;
> > Ni, Ray ; Dong, Eric
> > Subject: [PATCH v2 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA
> > PassThru PPI
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
> >
> > This commit will add the definitions for EDKII PEI ATA PassThru PPI. This
> > PPI
> > will provide services that allow ATA commands to be sent to ATA devices
> > attached to an ATA controller in the PEI phase.
> >
> > More specifically, the PPI will provide services to:
> >
> > * Send ATA commands to an ATA device (by service 'PassThru');
> > * Get the list of the attached ATA device on a controller (by services
> > 'GetNextPort' and 'GetNextDevice');
> > * Get the identification information (DevicePath) of the underlying ATA
> > host controller (by service 'GetDevicePath').
> >
> > Cc: Jian J Wang
> > Cc: Ruiyu Ni
> > Cc: Eric Dong
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Hao Wu
> > ---
> > MdeModulePkg/MdeModulePkg.dec | 3 +
> > MdeModulePkg/Include/Ppi/AtaPassThru.h | 359
> > 2 files changed, 362 insertions(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > b/MdeModulePkg/MdeModulePkg.dec index 4411185073..8efb19e626
> > 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -483,6 +483,9 @@
> >## Include/Ppi/AtaAhciController.h
> >gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0,
> > { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
> >
> > + ## Include/Ppi/AtaPassThru.h
> > + gEdkiiPeiAtaPassThruPpiGuid = { 0xa16473fd, 0xd474, 0x4c89,
> { 0xae,
> > 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9 } }
> > +
> > [Protocols]
> >## Load File protocol provides capability to load and unload EFI image
> > into
> > memory and execute it.
> ># Include/Protocol/LoadPe32Image.h
> > diff --git a/MdeModulePkg/Include/Ppi/AtaPassThru.h
> > b/MdeModulePkg/Include/Ppi/AtaPassThru.h
> > new file mode 100644
> > index 00..9281f0b833
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Ppi/AtaPassThru.h
> > @@ -0,0 +1,359 @@
> > +/** @file
> > +
> > + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> > + program and the accompanying materials are licensed and made
> > + available under the terms and conditions of the BSD License which
> > + accompanies this distribution. The full text of the license may be
> > + found at http://opensource.org/licenses/bsd-license.php
> > +
> > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#ifndef _EDKII_ATA_PASS_THRU_PPI_H_
> > +#define _EDKII_ATA_PASS_THRU_PPI_H_
> > +
> > +#include
> > +
> > +///
> > +/// Global ID for the EDKII_PEI_ATA_PASS_THRU_PPI.
> > +///
> > +#define EDKII_PEI_ATA_PASS_THRU_PPI_GUID \
> > + { \
> > +0xa16473fd, 0xd474, 0x4c89, { 0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73,
> > +0x86, 0x9 } \
> > + }
> > +
> > +//
> > +// Forward declaration for the EDKII_PEI_ATA_PASS_THRU_PPI.
> > +//
> > +typedef struct _EDKII_PEI_ATA_PASS_THRU_PPI
> > +EDKII_PEI_ATA_PASS_THRU_PPI;
> > +
> > +//
> > +// Revision The revision to which the ATA Pass Thru PPI interface adheres.
> > +// All future revisions must be backwards compatible.
> > +// If a future version is not back wards compatible it is not the
> > same
> > GUID.
> > +//
> > +#define EDKII_PEI_ATA_PASS_THRU_PPI_REVISION 0x0001
> > +
Re: [edk2] [PATCH v2 0/3] FatPkg/GPT: Introduce GPT patch v3
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen > A Chen > Sent: Tuesday, January 29, 2019 1:28 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2 0/3] FatPkg/GPT: Introduce GPT patch v3 > > No function change, fix code style issue. Thanks for the contribution. Series has been pushed @8a9301cdd7..0d18f5db32. Best Regards, Hao Wu > > Chen A Chen (3): > FatPkg: Break down Part.c file. > MdePkg/UefiGpt.h: Add new definition for enable GPT support > FatPkg: Add GPT check in FatPei to support Capsule-on-Disk feature. > > FatPkg/FatPei/Eltorito.c | 239 ++ > FatPkg/FatPei/FatLitePeim.h | 3 +- > FatPkg/FatPei/FatPei.inf | 7 +- > FatPkg/FatPei/Gpt.c | 548 > ++ > FatPkg/FatPei/Mbr.c | 181 ++ > FatPkg/FatPei/Part.c | 434 +++-- > MdePkg/Include/Uefi/UefiGpt.h | 6 +- > 7 files changed, 1020 insertions(+), 398 deletions(-) > create mode 100644 FatPkg/FatPei/Eltorito.c > create mode 100644 FatPkg/FatPei/Gpt.c > create mode 100644 FatPkg/FatPei/Mbr.c > > -- > 2.16.2.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 3/3] FatPkg: Add GPT check in FatPei to support Capsule-on-Disk feature.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Tuesday, January 29, 2019 1:28 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray; Zhang, Chao B
> Subject: [edk2] [PATCH v3 3/3] FatPkg: Add GPT check in FatPei to support
> Capsule-on-Disk feature.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> This feature is used for finding GPT partition.
> Follow the following step to check.
> 1) Check Protective MBR.
> 2) Check GPT primary/backup header.
> 3) Check GPT primary/backup entry array.
>
> Cc: Ruiyu Ni
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Reviewed-by: Hao Wu
> ---
> FatPkg/FatPei/FatLitePeim.h | 3 +-
> FatPkg/FatPei/FatPei.inf| 3 +
> FatPkg/FatPei/Gpt.c | 548
>
> FatPkg/FatPei/Part.c| 36 ++-
> 4 files changed, 585 insertions(+), 5 deletions(-)
> create mode 100644 FatPkg/FatPei/Gpt.c
>
> diff --git a/FatPkg/FatPei/FatLitePeim.h b/FatPkg/FatPei/FatLitePeim.h
> index fbf887da5f..82ab045f2a 100644
> --- a/FatPkg/FatPei/FatLitePeim.h
> +++ b/FatPkg/FatPei/FatLitePeim.h
> @@ -1,7 +1,7 @@
> /** @file
>Data structures for FAT recovery PEIM
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>
> This program and the accompanying materials are licensed and made
> available
> under the terms and conditions of the BSD License which accompanies this
> @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/FatPkg/FatPei/FatPei.inf b/FatPkg/FatPei/FatPei.inf
> index 57312a9047..050bc4e157 100644
> --- a/FatPkg/FatPei/FatPei.inf
> +++ b/FatPkg/FatPei/FatPei.inf
> @@ -31,6 +31,7 @@
>
> [Sources]
>Mbr.c
> + Gpt.c
>Eltorito.c
>Part.c
>FatLiteApi.c
> @@ -49,6 +50,7 @@
> [LibraryClasses]
>PcdLib
>BaseMemoryLib
> + MemoryAllocationLib
>PeimEntryPoint
>BaseLib
>DebugLib
> @@ -61,6 +63,7 @@
>gRecoveryOnFatIdeDiskGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
>gRecoveryOnFatFloppyDiskGuid## SOMETIMES_CONSUMES ##
> UNDEFINED
>gRecoveryOnFatNvmeDiskGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
> + gEfiPartTypeUnusedGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
>
>
> [Ppis]
> diff --git a/FatPkg/FatPei/Gpt.c b/FatPkg/FatPei/Gpt.c
> new file mode 100644
> index 00..c3afb668d7
> --- /dev/null
> +++ b/FatPkg/FatPei/Gpt.c
> @@ -0,0 +1,548 @@
> +/** @file
> + Routines supporting partition discovery and
> + logical device reading
> +
> +Copyright (c) 2019 Intel Corporation. All rights reserved.
> +
> +This program and the accompanying materials are licensed and made
> available
> +under the terms and conditions of the BSD License which accompanies this
> +distribution. The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include "FatLitePeim.h"
> +
> +//
> +// Assumption: 'a' and 'blocksize' are all UINT32 or UINT64.
> +// If 'a' and 'blocksize' are not the same type, should use DivU64xU32 to
> calculate.
> +//
> +#define EFI_SIZE_TO_BLOCKS(a, blocksize) (((a) / (blocksize)) + (((a) %
> (blocksize)) ? 1 : 0))
> +
> +//
> +// GPT Partition Entry Status
> +//
> +typedef struct {
> + BOOLEAN OutOfRange;
> + BOOLEAN Overlap;
> + BOOLEAN OsSpecific;
> +} EFI_PARTITION_ENTRY_STATUS;
> +
> +/**
> + Check if the CRC field in the Partition table header is valid.
> +
> + @param[in] PartHeader Partition table header structure
> +
> + @retval TRUE the CRC is valid
> + @retval FALSE the CRC is invalid
> +
> +**/
> +BOOLEAN
> +PartitionCheckGptHeaderCRC (
> + IN EFI_PARTITION_TABLE_HEADER *PartHeader
> + )
> +{
> + UINT32 GptHdrCrc;
> + UINT32 Crc;
> +
> + GptHdrCrc = PartHeader->Header.CRC32;
> +
> + //
> + // Set CRC field to zero when doing calcuation
> + //
> + PartHeader->Header.CRC32 = 0;
> +
> + Crc = CalculateCrc32 (PartHeader, PartHeader->Header.HeaderSize);
> +
> + //
> + // Restore Header CRC
> + //
> + PartHeader->Header.CRC32 = GptHdrCrc;
> +
> + return (GptHdrCrc == Crc);
> +}
> +
> +
> +/**
> + Check if the CRC field in the Partition table header is valid
> + for Partition entry array.
> +
> + @param[in] PartHeader Partition table header structure
> + @param[in] PartEntry The partition entry array
> +
> + @retval TRUE the CRC is valid
> + @retval FALSE the CRC is invalid
> +
> +**/
> +BOOLEAN
>
Re: [edk2] [PATCH v5 4/7] MdeModulePkg/EbcDebugger: Use AsciiCharToUpper and CharToUpper
> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, January 30, 2019 2:34 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star
> Subject: [PATCH v5 4/7] MdeModulePkg/EbcDebugger: Use AsciiCharToUpper
> and CharToUpper
>
> InternalUnicodeToUpper and InternalAsciiToUpper are internal functions,
> so they are substituted by public functions AsciiCharToUpper and CharToUpper.
> And their implements are removed.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1369
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ruiyu Ni
> Cc: Star Zeng
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../EbcDxe/EbcDebugger/EdbSupportString.c | 39 ++-
> 1 file changed, 4 insertions(+), 35 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> index 02e1876ffa..d34acf892b 100644
> --- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> +++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> @@ -307,37 +307,6 @@ AsciiAtoi (
>return RetVal;
> }
>
> -/**
> -
> - Convert the character to upper case.
> -
> - @param Chrthe character to be converted.
> -
> -**/
> -STATIC
> -CHAR16
> -InternalUnicodeToUpper (
> - IN CHAR16Chr
> - )
> -{
> - return (Chr >= L'a' && Chr <= L'z') ? Chr - (L'a' - L'A') : Chr;
> -}
> -
> -/**
> -
> - Convert the character to upper case.
> -
> - @param Chrthe character to be converted.
> -
> -**/
> -STATIC
> -CHAR8
> -InternalAsciiToUpper (
> - IN CHAR8 Chr
> - )
> -{
> - return (Chr >= 'a' && Chr <= 'z') ? Chr - ('a' - 'A') : Chr;
> -}
>
> /**
>Compare the Unicode and Ascii string pointed by String to the string
> pointed
> by String2.
> @@ -390,12 +359,12 @@ StriCmp (
>)
> {
>while ((*String != L'\0') &&
> - (InternalUnicodeToUpper (*String) == InternalUnicodeToUpper
> (*String2))) {
> + (CharToUpper (*String) == CharToUpper (*String2))) {
> String++;
> String2++;
>}
>
> - return InternalUnicodeToUpper (*String) - InternalUnicodeToUpper
> (*String2);
> + return CharToUpper (*String) - CharToUpper (*String2);
> }
>
> /**
> @@ -418,12 +387,12 @@ StriCmpUnicodeAndAscii (
>)
> {
>while ((*String != L'\0') &&
> - (InternalUnicodeToUpper (*String) == (CHAR16)InternalAsciiToUpper
> (*String2))) {
> + (CharToUpper (*String) == (CHAR16)AsciiCharToUpper (*String2))) {
> String++;
> String2++;
>}
>
> - return InternalUnicodeToUpper (*String) - (CHAR16)InternalAsciiToUpper
> (*String2);
> + return CharToUpper (*String) - (CHAR16)AsciiCharToUpper (*String2);
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> }
>
> /**
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 1/7] MdeModulePkg/EbcDebugger: Change function names
> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, January 30, 2019 2:34 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star
> Subject: [PATCH v5 1/7] MdeModulePkg/EbcDebugger: Change function names
>
> Change UnicodeToUpper to InternalUnicodeToUpper.
> Change AsciiToUpper to InternalAsciiToUpper.
> These changes are committed for bisectability, or build failure will
> occur when 2/7 is applied. Because the introduced function names in
> 2/7 are the same as ones in EdbSupporting.c.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1369
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ruiyu Ni
> Cc: Star Zeng
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> Reviewed-by: Hao Wu
> Reviewed-by: Liming Gao
> ---
> .../Universal/EbcDxe/EbcDebugger/EdbSupportString.c | 12 ++--
Please help to update the copyright year for file EdbSupportString.c.
You can keep my 'Reviewed-by' tag and do not need to send a new version of
series for this.
Best Regards,
Hao Wu
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> index 78a0559079..02e1876ffa 100644
> --- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> +++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
> @@ -316,7 +316,7 @@ AsciiAtoi (
> **/
> STATIC
> CHAR16
> -UnicodeToUpper (
> +InternalUnicodeToUpper (
>IN CHAR16Chr
>)
> {
> @@ -332,7 +332,7 @@ UnicodeToUpper (
> **/
> STATIC
> CHAR8
> -AsciiToUpper (
> +InternalAsciiToUpper (
>IN CHAR8 Chr
>)
> {
> @@ -390,12 +390,12 @@ StriCmp (
>)
> {
>while ((*String != L'\0') &&
> - (UnicodeToUpper (*String) == UnicodeToUpper (*String2))) {
> + (InternalUnicodeToUpper (*String) == InternalUnicodeToUpper
> (*String2))) {
> String++;
> String2++;
>}
>
> - return UnicodeToUpper (*String) - UnicodeToUpper (*String2);
> + return InternalUnicodeToUpper (*String) - InternalUnicodeToUpper
> (*String2);
> }
>
> /**
> @@ -418,12 +418,12 @@ StriCmpUnicodeAndAscii (
>)
> {
>while ((*String != L'\0') &&
> - (UnicodeToUpper (*String) == (CHAR16)AsciiToUpper (*String2))) {
> + (InternalUnicodeToUpper (*String) == (CHAR16)InternalAsciiToUpper
> (*String2))) {
> String++;
> String2++;
>}
>
> - return UnicodeToUpper (*String) - (CHAR16)AsciiToUpper (*String2);
> + return InternalUnicodeToUpper (*String) - (CHAR16)InternalAsciiToUpper
> (*String2);
> }
>
> /**
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeHttpLib: Use BaseLib api AsciiCharToUpper
> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, January 30, 2019 2:34 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star
> Subject: [PATCH v5 5/7] MdeModulePkg/DxeHttpLib: Use BaseLib api
> AsciiCharToUpper
>
> Substitute HttpIoCharToUpper with AsciiCharToUpper which is a public function
> with the same effect. And remove the implement of HttpIoCharToUpper.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1369
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ruiyu Ni
> Cc: Star Zeng
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 23 +---
> 1 file changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> index 2fc3da8a2d..3884bc8361 100644
> --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> @@ -898,27 +898,6 @@ typedef struct {
>UINTN CurrentChunkParsedSize;
> } HTTP_BODY_PARSER;
>
> -/**
> -
> - Convert an Ascii char to its uppercase.
> -
> - @param[in] Char Ascii character.
> -
> - @return Uppercase value of the input Char.
> -
> -**/
> -CHAR8
> -HttpIoCharToUpper (
> - IN CHAR8Char
> - )
> -{
> - if (Char >= 'a' && Char <= 'z') {
> -return Char - ('a' - 'A');
> - }
> -
> - return Char;
> -}
> -
> /**
>Convert an hexadecimal char to a value of type UINTN.
>
> @@ -936,7 +915,7 @@ HttpIoHexCharToUintn (
> return Char - '0';
>}
>
> - return (10 + HttpIoCharToUpper (Char) - 'A');
> + return (10 + AsciiCharToUpper (Char) - 'A');
Please help to update the copyright year for file DxeHttpLib.c.
With this handled:
Reviewed-by: Hao Wu
There is no need to send a new version of series for this.
Best Regards,
Hao Wu
> }
>
> /**
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Update comment for spec compliance status
> -Original Message- > From: Wang, Jian J > Sent: Tuesday, January 29, 2019 11:28 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Ni, Ray > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Update comment for > spec compliance status > > Just two typos (see below). With them addressed, > > Reviewed-by: Jian J Wang Thanks for the catch. I will handle them before pushing the patch. Best Regards, Hao Wu > > > -----Original Message- > > From: Wu, Hao A > > Sent: Tuesday, January 29, 2019 11:14 AM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A ; Wang, Jian J ; > > Ni, Ray > > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Update comment for > spec > > compliance status > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1441 > > > > This commit will update the file-level comments within the SdMmcPciHcDxe > > to reflect the latest specification compliance status of the driver. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 5 +++-- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 6 -- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 6 -- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.uni | 5 +++-- > > 4 files changed, 14 insertions(+), 8 deletions(-) > > > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > > index 1246e1d88d..025fb7faba 100644 > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > > @@ -1,11 +1,12 @@ > > ## @file > > # SdMmcPciHcDxe driver is used to manage those host controllers which > > comply with SD > > -# Host Controller Simplified Specifiction version 3.0. > > +# Host Controller Simplified Specifiction version 3.0 plus the 64-bit > > System > > Typo: Specifiction > > > Addressing > > +# support in SD Host Controller Simplified Specification version 4.20. > > # > > # It will produce EFI_SD_MMC_PASS_THRU_PROTOCOL to allow sending > > SD/MMC/eMMC cmds > > # to specified devices from upper layer. > > # > > -# Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. > > +# Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > BSD > > License > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > > index 76c32a4dcd..b474f8decd 100644 > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > > @@ -1,11 +1,13 @@ > > /** @file > >This driver is used to manage SD/MMC PCI host controllers which are > > compliance > > - with SD Host Controller Simplified Specification version 3.00. > > + with SD Host Controller Simplified Specification version 3.00 plus the > > 64-bit > > + System Addressing support in SD Host Controller Simplified Specification > > version > > + 4.20. > > > >It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use. > > > >Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved. > > - Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. > > + Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved. > >This program and the accompanying materials > >are licensed and made available under the terms and conditions of the BSD > > License > >which accompanies this distribution. The full text of the license may be > found > > at > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > > index 5aec8c6992..4c64da3b20 100644 > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > > @@ -1,11 +1,13 @@ > > /** @file > >This driver is used to manage SD/MMC PCI host controllers which are > > compliance > > - with SD Host Controller Simplified Specification version 3.00. > > + with SD Host Controller Simplified Specification version 3.00 plus the > > 64-bit > > + System Addressing support in SD Host Controller Simplified Specification > > ve
Re: [edk2] [PATCH] patch1_add_support_bh720_emmc_chip
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mike
> Li (WH)
> Sent: Monday, January 28, 2019 3:36 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] patch1_add_support_bh720_emmc_chip
Hi,
Thanks for the contribution. I saw you sent out a total of 3 patches for
the SdMmcPciHcDxe driver, and they seem to be related.
Could you please help to do the below things that will help for reviewing
your patches:
* Rebase your changes to the latest mater branch of the edk2;
* Generate a patch series rather than separate patch files if you think
they are related;
* Help to provide detailed information on the purpose of the patches or
the issue you met in the log message of each commit.
You may get some help by referring:
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
Thanks in advance.
Best Regards,
Hao Wu
>
> ---
> .../Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 253 --
> .../Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 47 +---
> 2 files changed, 178 insertions(+), 122 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 4ef849fd09..ac79a2f791 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -527,17 +527,35 @@ EmmcTuningClkForHs200 (
>if (EFI_ERROR (Status)) {
> return Status;
>}
> +
> + if(BhtHostPciSupport(PciIo)){
> + //set data transfer with 4bit
> + Status = SdMmcHcSetBusWidth (PciIo, Slot, 4);
> + //enable hardware tuning
> + HostCtrl2 = (~0x10);
> + Status = SdMmcHcAndMmio (PciIo, Slot, 0x110,sizeof
> (HostCtrl2), );
> +
> + Status = EmmcSendTuningBlk (PassThru, Slot, 4);
> + if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR, "EmmcTuningClkForHs200: Send
> tuning block fails with %r\n", Status));
> + return Status;
> + }
> +
> + }
>//
>// Ask the device to send a sequence of tuning blocks till the tuning
> procedure
> is done.
>//
>Retry = 0;
>do {
> -Status = EmmcSendTuningBlk (PassThru, Slot, BusWidth);
> -if (EFI_ERROR (Status)) {
> - DEBUG ((DEBUG_ERROR, "EmmcTuningClkForHs200: Send tuning block
> fails with %r\n", Status));
> - return Status;
> -}
> -
> + if(!BhtHostPciSupport(PciIo)){
> + Status = EmmcSendTuningBlk (PassThru, Slot, BusWidth);
> + if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR, "EmmcTuningClkForHs200: Send tuning
> block fails with %r\n", Status));
> + return Status;
> + }
> + } else {
> + gBS->Stall(5000);
> + }
> Status = SdMmcHcRwMmio (PciIo, Slot, SD_MMC_HC_HOST_CTRL2, TRUE,
> sizeof (HostCtrl2), );
> if (EFI_ERROR (Status)) {
>return Status;
> @@ -548,6 +566,10 @@ EmmcTuningClkForHs200 (
> }
>
> if ((HostCtrl2 & (BIT6 | BIT7)) == BIT7) {
> + if(BhtHostPciSupport(PciIo)){
> + //set data transfer with default
> + Status = SdMmcHcSetBusWidth (PciIo, Slot, BusWidth);
> + }
>return EFI_SUCCESS;
> }
>} while (++Retry < 40);
> @@ -652,7 +674,6 @@ EmmcSwitchBusWidth (
>@param[in] Slot The slot number of the SD card to send the
> command
> to.
>@param[in] RcaThe relative device address to be assigned.
>@param[in] HsTiming The value to be written to HS_TIMING field of
> EXT_CSD register.
> - @param[in] Timing The bus mode timing indicator.
>@param[in] ClockFreq The max clock frequency to be set, the unit is
> MHz.
>
>@retval EFI_SUCCESS The operation is done correctly.
> @@ -666,7 +687,6 @@ EmmcSwitchClockFreq (
>IN UINT8 Slot,
>IN UINT16 Rca,
>IN UINT8 HsTiming,
> - IN SD_MMC_BUS_MODETiming,
>IN UINT32 ClockFreq
>)
> {
> @@ -708,28 +728,7 @@ EmmcSwitchClockFreq (
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> - Status = SdMmcHcClockSupply (PciIo, Slot, ClockFreq * 1000, Private-
> >BaseClkFreq[Slot], Private->ControllerVersion[Slot]);
> - if (EFI_ERROR (Status)) {
> -return Status;
> - }
> -
> - if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> -Status = mOverride->NotifyPhase (
> - Private->ControllerHandle,
> - Slot,
> - EdkiiSdMmcSwitchClockFreqPost,
> -
> - );
> -if (EFI_ERROR (Status)) {
> - DEBUG ((
> -DEBUG_ERROR,
> -"%a: SD/MMC switch clock freq post notifier callback failed - %r\n",
> -__FUNCTION__,
> -Status
> -));
> - return Status;
> -
Re: [edk2] [PATCH 3/3] FatPkg: Add GPT check in FatPei to support Capsule-on-Disk feature.
Hello,
A general-level comment:
I saw the implementation of function FatFindGptPartitions() has been added
in this patch. But unlike functions:
FatFindMbrPartitions()
FatFindEltoritoPartitions()
I did not see FatFindGptPartitions() being called within the FatPei
driver. Is it supposed to be added within FatFindPartitions()?
Please help to refer to the inline comments below as well:
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chen A Chen
> Sent: Thursday, January 17, 2019 10:03 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray; Zhang, Chao B
> Subject: [edk2] [PATCH 3/3] FatPkg: Add GPT check in FatPei to support
> Capsule-on-Disk feature.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> This feature is used for finding GPT partition, follow the following step to
> check.
> 1) Check Protective MBR.
> 2) Check GPT primary/backup header.
> 3) Check GPT primary/backup entry array.
>
> Cc: Ruiyu Ni
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> FatPkg/FatPei/FatLitePeim.h | 1 +
> FatPkg/FatPei/FatPei.inf| 3 +
> FatPkg/FatPei/Gpt.c | 546
>
> 3 files changed, 550 insertions(+)
> create mode 100644 FatPkg/FatPei/Gpt.c
>
> diff --git a/FatPkg/FatPei/FatLitePeim.h b/FatPkg/FatPei/FatLitePeim.h
> index fbf887da5f..afb429c56e 100644
> --- a/FatPkg/FatPei/FatLitePeim.h
> +++ b/FatPkg/FatPei/FatLitePeim.h
> @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/FatPkg/FatPei/FatPei.inf b/FatPkg/FatPei/FatPei.inf
> index 829e87fe92..dd0869f7cd 100644
> --- a/FatPkg/FatPei/FatPei.inf
> +++ b/FatPkg/FatPei/FatPei.inf
> @@ -31,6 +31,7 @@
>
> [Sources]
>Mbr.c
> + Gpt.c
>Eltorito.c
>Part.c
>FatLiteApi.c
> @@ -49,6 +50,7 @@
> [LibraryClasses]
>PcdLib
>BaseMemoryLib
> + MemoryAllocationLib
>PeimEntryPoint
>BaseLib
>DebugLib
> @@ -61,6 +63,7 @@
>gRecoveryOnFatIdeDiskGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
>gRecoveryOnFatFloppyDiskGuid## SOMETIMES_CONSUMES ##
> UNDEFINED
>gRecoveryOnFatNvmeDiskGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
> + gEfiPartTypeUnusedGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
>
>
> [Ppis]
> diff --git a/FatPkg/FatPei/Gpt.c b/FatPkg/FatPei/Gpt.c
> new file mode 100644
> index 00..d1f4c1c8b5
> --- /dev/null
> +++ b/FatPkg/FatPei/Gpt.c
> @@ -0,0 +1,546 @@
> +/** @file
> + Routines supporting partition discovery and
> + logical device reading
> +
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
A minor comment here:
Since this is a new file with new codes, I think the copyright year can be
2019 only.
> +
> +This program and the accompanying materials are licensed and made
> available
> +under the terms and conditions of the BSD License which accompanies this
> +distribution. The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include "FatLitePeim.h"
> +
> +//
> +// Assumption: 'a' and 'blocksize' are all UINT32 or UINT64.
> +// If 'a' and 'blocksize' are not the same type, should use DivU64xU32 to
> calculate.
> +//
> +#define EFI_SIZE_TO_BLOCKS(a, blocksize) (((a) / (blocksize)) + (((a) %
> (blocksize)) ? 1 : 0))
> +
> +//
> +// GPT Partition Entry Status
> +//
> +typedef struct {
> + BOOLEAN OutOfRange;
> + BOOLEAN Overlap;
> + BOOLEAN OsSpecific;
> +} EFI_PARTITION_ENTRY_STATUS;
> +
> +/**
> + Check if the CRC field in the Partition table header is valid
> +
> + @param[in] BlockIo Parent BlockIo interface
> + @param[in] DiskIo Disk Io Protocol.
> + @param[in] PartHeader Partition table header structure
> +
> + @retval TRUE the CRC is valid
> + @retval FALSE the CRC is invalid
> +
> +**/
> +BOOLEAN
> +PartitionCheckGptHeaderCRC (
> + IN EFI_PARTITION_TABLE_HEADER *PartHeader
> + )
> +{
> + UINT32 GptHdrCrc;
> + UINT32 Crc;
> +
> + GptHdrCrc = PartHeader->Header.CRC32;
> +
> + //
> + // Set CRC field to zero when doing calcuation
> + //
> + PartHeader->Header.CRC32 = 0;
> +
> + Crc = CalculateCrc32 (PartHeader, PartHeader->Header.HeaderSize);
> +
> + //
> + // Restore Header CRC
> + //
> + PartHeader->Header.CRC32 = GptHdrCrc;
> +
> + return (GptHdrCrc == Crc);
> +}
> +
> +
> +/**
> + Check if the CRC field in the Partition table header is valid
> + for Partition entry array.
> +
> + @param[in] BlockIo Parent BlockIo interface
> + @param[in] DiskIo Disk
Re: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for enable GPT support
> -Original Message-
> From: Chen, Chen A
> Sent: Friday, January 25, 2019 3:45 PM
> To: Wu, Hao A; Gao, Liming; edk2-devel@lists.01.org
> Cc: Kinney, Michael D; Zhang, Chao B
> Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> enable GPT support
>
>
>
> -----Original Message-
> From: Wu, Hao A
> Sent: Friday, January 25, 2019 3:27 PM
> To: Chen, Chen A ; Gao, Liming
> ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Zhang, Chao B
>
> Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> enable GPT support
>
> > -Original Message-
> > From: Chen, Chen A
> > Sent: Friday, January 25, 2019 3:16 PM
> > To: Wu, Hao A; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D; Zhang, Chao B; Gao, Liming
> > Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition
> > for enable GPT support
> >
> >
> >
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Friday, January 25, 2019 11:04 AM
> > To: Chen, Chen A ; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D ; Zhang, Chao B
> > ; Gao, Liming
> > Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition
> > for enable GPT support
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Chen A Chen
> > > Sent: Thursday, January 17, 2019 10:03 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D; Zhang, Chao B; Gao, Liming
> > > Subject: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> > > enable GPT support
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> > > This two new definitions are defined for GPT in FatPei diver.
> > >
> > > Cc: Liming Gao
> > > Cc: Michael D Kinney
> > > Cc: Zhang Chao B
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Chen A Chen
> > > ---
> > > MdePkg/Include/Uefi/UefiGpt.h | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/MdePkg/Include/Uefi/UefiGpt.h
> > > b/MdePkg/Include/Uefi/UefiGpt.h index f635b05390..8665c8cbc9 100644
> > > --- a/MdePkg/Include/Uefi/UefiGpt.h
> > > +++ b/MdePkg/Include/Uefi/UefiGpt.h
> > > @@ -24,9 +24,25 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> > ANY KIND,
> > > EITHER EXPRESS OR IMPLIED.
> > > /// EFI Partition Table Signature: "EFI PART".
> > > ///
> > > #define EFI_PTAB_HEADER_ID SIGNATURE_64 ('E','F','I','
> > > ','P','A','R','T')
> > > +///
> > > +/// Minimum bytes reserve for EFI entry array buffer.
> > > +///
> > > +#define GPT_PART_ENTRY_MIN_SIZE 16384
> >
> > May I know where this definition comes from?
> > Does it come from the UEFI spec?
> >
> > Chen: The MACRO is not explicitly defined in UEFI Spec, But UEFI Spec
> > specifies a minimum value for GPT entry araray.
>
> Does it comes from the below content within the UEFI spec?
>
> > A minimum of 16,384 bytes of space must be reserved for the GPT
> > Partition Entry Array.
>
> If so, I am not sure whether 'EFI_' prefix should be added before
> 'GPT_PART_ENTRY_MIN_SIZE'.
>
> Liming, could you help to confirm?
>
> Chen: I have no strong opinion on ' GPT_PART_ENTRY_MIN_SIZE' and
> 'EFI_GPT_PART_ENTRY_MIN_SIZE'.
>
> >
> > >
> > > #pragma pack(1)
> > >
> > > +///
> > > +/// MBR Partition Entry
> > > +///
> > > +typedef struct {
> > > + UINT8 BootIndicator;
> > > + UINT8 StartingCHS[3];
> > > + UINT8 OSType;
> > > + UINT8 EndingCHS[3];
> > > + UINT32 StartingLBA;
> > > + UINT32 SizeInLBA;
> > > +} MBR_PARTITION_ENTRY;
> > > +
> >
> > What about using the 'MBR_PARTITION_RECORD' definition within
> > edk2/MdePkg/Include/IndustryStandard/Mbr.h
> >
> > and thus get rid of adding this one?
> >
> > Chen: This structure defined as the following format in Mbr.h
> >
> > typedef struct {
> > ..
> > UINT8 StartingLBA[4];
> > UINT8 SizeInLBA[4];
> > } MBR_PARTITION_RECORD;
> >
> > For StartingLBA, this field is represented the LBA, so I think it
> > should be
> > UINT32 type not an array type.
>
> I do not get your point, what prevents you from getting the LBA information
> for the byte array?
>
> Chen: Yes, GPT DXE driver use UNPACK_UINT32 macro to extract UINT32
> from array. But I thought use UINT32 type get the value more directly.
I would suggest to use the existing definition and avoid adding a
'duplicated' definition.
Best Regards,
Hao Wu
>
> Best Regards,
> Hao Wu
>
> >
> > The same meaning is also for SizeInLba.
> >
> > Best Regards,
> > Hao Wu
> >
> > > ///
> > > /// GPT Partition Table Header.
> > > ///
> > > --
> > > 2.16.2.windows.1
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for enable GPT support
> -Original Message-
> From: Chen, Chen A
> Sent: Friday, January 25, 2019 3:16 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Kinney, Michael D; Zhang, Chao B; Gao, Liming
> Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> enable GPT support
>
>
>
> -----Original Message-
> From: Wu, Hao A
> Sent: Friday, January 25, 2019 11:04 AM
> To: Chen, Chen A ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Zhang, Chao B
> ; Gao, Liming
> Subject: RE: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> enable GPT support
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Chen A Chen
> > Sent: Thursday, January 17, 2019 10:03 AM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D; Zhang, Chao B; Gao, Liming
> > Subject: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> > enable GPT support
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> > This two new definitions are defined for GPT in FatPei diver.
> >
> > Cc: Liming Gao
> > Cc: Michael D Kinney
> > Cc: Zhang Chao B
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Chen A Chen
> > ---
> > MdePkg/Include/Uefi/UefiGpt.h | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/MdePkg/Include/Uefi/UefiGpt.h
> > b/MdePkg/Include/Uefi/UefiGpt.h index f635b05390..8665c8cbc9 100644
> > --- a/MdePkg/Include/Uefi/UefiGpt.h
> > +++ b/MdePkg/Include/Uefi/UefiGpt.h
> > @@ -24,9 +24,25 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND,
> > EITHER EXPRESS OR IMPLIED.
> > /// EFI Partition Table Signature: "EFI PART".
> > ///
> > #define EFI_PTAB_HEADER_ID SIGNATURE_64 ('E','F','I','
> > ','P','A','R','T')
> > +///
> > +/// Minimum bytes reserve for EFI entry array buffer.
> > +///
> > +#define GPT_PART_ENTRY_MIN_SIZE 16384
>
> May I know where this definition comes from?
> Does it come from the UEFI spec?
>
> Chen: The MACRO is not explicitly defined in UEFI Spec, But UEFI Spec
> specifies a minimum value for GPT entry araray.
Does it comes from the below content within the UEFI spec?
> A minimum of 16,384 bytes of space must be reserved for the GPT
> Partition Entry Array.
If so, I am not sure whether 'EFI_' prefix should be added before
'GPT_PART_ENTRY_MIN_SIZE'.
Liming, could you help to confirm?
>
> >
> > #pragma pack(1)
> >
> > +///
> > +/// MBR Partition Entry
> > +///
> > +typedef struct {
> > + UINT8 BootIndicator;
> > + UINT8 StartingCHS[3];
> > + UINT8 OSType;
> > + UINT8 EndingCHS[3];
> > + UINT32 StartingLBA;
> > + UINT32 SizeInLBA;
> > +} MBR_PARTITION_ENTRY;
> > +
>
> What about using the 'MBR_PARTITION_RECORD' definition within
> edk2/MdePkg/Include/IndustryStandard/Mbr.h
>
> and thus get rid of adding this one?
>
> Chen: This structure defined as the following format in Mbr.h
>
> typedef struct {
> ..
> UINT8 StartingLBA[4];
> UINT8 SizeInLBA[4];
> } MBR_PARTITION_RECORD;
>
> For StartingLBA, this field is represented the LBA, so I think it should be
> UINT32 type not an array type.
I do not get your point, what prevents you from getting the LBA
information for the byte array?
Best Regards,
Hao Wu
>
> The same meaning is also for SizeInLba.
>
> Best Regards,
> Hao Wu
>
> > ///
> > /// GPT Partition Table Header.
> > ///
> > --
> > 2.16.2.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] FatPkg: Break down Part.c file.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chen A Chen
> Sent: Thursday, January 17, 2019 10:03 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray; Zhang, Chao B
> Subject: [edk2] [PATCH 1/2] FatPkg: Break down Part.c file.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> Break down partition parsing logic to 2 parts, Eltorito and MBR.
>
> Cc: Ruiyu Ni
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> FatPkg/FatPei/Eltorito.c | 239 +
> FatPkg/FatPei/FatPei.inf | 2 +
> FatPkg/FatPei/Mbr.c | 182 ++
> FatPkg/FatPei/Part.c | 385
> +--
> 4 files changed, 424 insertions(+), 384 deletions(-)
> create mode 100644 FatPkg/FatPei/Eltorito.c
> create mode 100644 FatPkg/FatPei/Mbr.c
>
> diff --git a/FatPkg/FatPei/Eltorito.c b/FatPkg/FatPei/Eltorito.c
> new file mode 100644
> index 00..ffaef51860
> --- /dev/null
> +++ b/FatPkg/FatPei/Eltorito.c
> @@ -0,0 +1,239 @@
> +/** @file
> + Routines supporting partition discovery and
> + logical device reading
> +
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> +
> +This program and the accompanying materials are licensed and made
> available
> +under the terms and conditions of the BSD License which accompanies this
> +distribution. The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include "FatLitePeim.h"
> +
> +/**
> + This function finds Eltorito partitions. Main algorithm
> + is ported from DXE partition driver.
> +
> + @param PrivateData The global memory map
> + @param ParentBlockDevNo The parent block device
> +
> + @retval TRUE New partitions are detected and logical block
> devices
> +are added to block device array
> + @retval FALSE No New partitions are added;
> +
> +**/
> +BOOLEAN
> +FatFindEltoritoPartitions (
> + IN PEI_FAT_PRIVATE_DATA *PrivateData,
> + IN UINTNParentBlockDevNo
> + )
> +{
> + EFI_STATUS Status;
> + BOOLEAN Found;
> + PEI_FAT_BLOCK_DEVICE*BlockDev;
> + PEI_FAT_BLOCK_DEVICE*ParentBlockDev;
> + UINT32 VolDescriptorLba;
> + UINT32 Lba;
> + CDROM_VOLUME_DESCRIPTOR *VolDescriptor;
> + ELTORITO_CATALOG*Catalog;
> + UINTN Check;
> + UINTN Index;
> + UINTN MaxIndex;
> + UINT16 *CheckBuffer;
> + UINT32 SubBlockSize;
> + UINT32 SectorCount;
> + UINT32 VolSpaceSize;
> +
> + if (ParentBlockDevNo > PEI_FAT_MAX_BLOCK_DEVICE - 1) {
> +return FALSE;
> + }
> +
> + Found = FALSE;
> + ParentBlockDev = &(PrivateData->BlockDevice[ParentBlockDevNo]);
> + VolSpaceSize= 0;
> +
> + //
> + // CD_ROM has the fixed block size as 2048 bytes
> + //
> + if (ParentBlockDev->BlockSize != 2048) {
> +return FALSE;
> + }
> +
> + VolDescriptor = (CDROM_VOLUME_DESCRIPTOR *) PrivateData-
> >BlockData;
> + Catalog = (ELTORITO_CATALOG *) VolDescriptor;
> +
> + //
> + // the ISO-9660 volume descriptor starts at 32k on the media
> + // and CD_ROM has the fixed block size as 2048 bytes, so...
> + //
> + VolDescriptorLba = 15;
> + //
> + // ((16*2048) / Media->BlockSize) - 1;
> + //
> + // Loop: handle one volume descriptor per time
> + //
> + while (TRUE) {
> +
> +VolDescriptorLba += 1;
> +if (VolDescriptorLba > ParentBlockDev->LastBlock) {
> + //
> + // We are pointing past the end of the device so exit
> + //
> + break;
> +}
> +
> +Status = FatReadBlock (
> + PrivateData,
> + ParentBlockDevNo,
> + VolDescriptorLba,
> + ParentBlockDev->BlockSize,
> + VolDescriptor
> + );
> +if (EFI_ERROR (Status)) {
> + break;
> +}
> +//
> +// Check for valid volume descriptor signature
> +//
> +if (VolDescriptor->Unknown.Type == CDVOL_TYPE_END ||
> +CompareMem (VolDescriptor->Unknown.Id, CDVOL_ID, sizeof
> (VolDescriptor->Unknown.Id)) != 0
> +) {
> + //
> + // end of Volume descriptor list
> + //
> + break;
> +}
> +//
> +// Read the Volume Space Size from Primary Volume Descriptor 81-88
> byte
> +//
> +if (VolDescriptor->Unknown.Type == CDVOL_TYPE_CODED) {
> + VolSpaceSize = VolDescriptor->PrimaryVolume.VolSpaceSize[1];
> +}
> +//
> +// Is it an El Torito volume descriptor?
> +//
> +if (CompareMem (
> +
Re: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for enable GPT support
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chen A Chen
> Sent: Thursday, January 17, 2019 10:03 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D; Zhang, Chao B; Gao, Liming
> Subject: [edk2] [PATCH 2/2] MdePkg/UefiGpt.h: Add new definition for
> enable GPT support
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470
> This two new definitions are defined for GPT in FatPei diver.
>
> Cc: Liming Gao
> Cc: Michael D Kinney
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdePkg/Include/Uefi/UefiGpt.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/MdePkg/Include/Uefi/UefiGpt.h
> b/MdePkg/Include/Uefi/UefiGpt.h
> index f635b05390..8665c8cbc9 100644
> --- a/MdePkg/Include/Uefi/UefiGpt.h
> +++ b/MdePkg/Include/Uefi/UefiGpt.h
> @@ -24,9 +24,25 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> /// EFI Partition Table Signature: "EFI PART".
> ///
> #define EFI_PTAB_HEADER_ID SIGNATURE_64 ('E','F','I','
> ','P','A','R','T')
> +///
> +/// Minimum bytes reserve for EFI entry array buffer.
> +///
> +#define GPT_PART_ENTRY_MIN_SIZE 16384
May I know where this definition comes from?
Does it come from the UEFI spec?
>
> #pragma pack(1)
>
> +///
> +/// MBR Partition Entry
> +///
> +typedef struct {
> + UINT8 BootIndicator;
> + UINT8 StartingCHS[3];
> + UINT8 OSType;
> + UINT8 EndingCHS[3];
> + UINT32 StartingLBA;
> + UINT32 SizeInLBA;
> +} MBR_PARTITION_ENTRY;
> +
What about using the 'MBR_PARTITION_RECORD' definition within
edk2/MdePkg/Include/IndustryStandard/Mbr.h
and thus get rid of adding this one?
Best Regards,
Hao Wu
> ///
> /// GPT Partition Table Header.
> ///
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] FatPkg: Add GPT check in FatPei to support Capsule-on-Disk feature.
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Hao A > Sent: Wednesday, January 23, 2019 9:25 AM > To: Ni, Ray; Chen, Chen A; edk2-devel@lists.01.org > Cc: Zhang, Chao B > Subject: Re: [edk2] [PATCH 3/3] FatPkg: Add GPT check in FatPei to support > Capsule-on-Disk feature. > > > -Original Message- > > From: Ni, Ray > > Sent: Thursday, January 17, 2019 11:50 AM > > To: Chen, Chen A; edk2-devel@lists.01.org; Wu, Hao A > > Cc: Zhang, Chao B > > Subject: RE: [PATCH 3/3] FatPkg: Add GPT check in FatPei to support > Capsule- > > on-Disk feature. > > > > Adding Wu Hao in the reviewer list. > > Sorry for the delayed response. > I will try my best to give my comments as soon as possible. > > Please help to ping if there is reply within the next two weeks. Correction: Please help to ping if there is no reply within the next two weeks. > > Best Regards, > Hao Wu > > > > > > -Original Message- > > > From: Chen, Chen A > > > Sent: Thursday, January 17, 2019 10:03 AM > > > To: edk2-devel@lists.01.org > > > Cc: Chen, Chen A ; Ni, Ray ; > > > Zhang, Chao B > > > Subject: [PATCH 3/3] FatPkg: Add GPT check in FatPei to support Capsule- > > on- > > > Disk feature. > > > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1470 > > > This feature is used for finding GPT partition, follow the following step > > > to > > > check. > > > 1) Check Protective MBR. > > > 2) Check GPT primary/backup header. > > > 3) Check GPT primary/backup entry array. > > > > > > Cc: Ruiyu Ni > > > Cc: Zhang Chao B > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Chen A Chen > > > --- > > > FatPkg/FatPei/FatLitePeim.h | 1 + > > > FatPkg/FatPei/FatPei.inf| 3 + > > > FatPkg/FatPei/Gpt.c | 546 > > > > > > 3 files changed, 550 insertions(+) > > > create mode 100644 FatPkg/FatPei/Gpt.c > > > > > > diff --git a/FatPkg/FatPei/FatLitePeim.h b/FatPkg/FatPei/FatLitePeim.h > > index > > > fbf887da5f..afb429c56e 100644 > > > --- a/FatPkg/FatPei/FatLitePeim.h > > > +++ b/FatPkg/FatPei/FatLitePeim.h > > > @@ -27,6 +27,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF > > ANY > > > KIND, EITHER EXPRESS OR IMPLIED. > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > diff --git a/FatPkg/FatPei/FatPei.inf b/FatPkg/FatPei/FatPei.inf index > > > 829e87fe92..dd0869f7cd 100644 > > > --- a/FatPkg/FatPei/FatPei.inf > > > +++ b/FatPkg/FatPei/FatPei.inf > > > @@ -31,6 +31,7 @@ > > > > > > [Sources] > > >Mbr.c > > > + Gpt.c > > >Eltorito.c > > >Part.c > > >FatLiteApi.c > > > @@ -49,6 +50,7 @@ > > > [LibraryClasses] > > >PcdLib > > >BaseMemoryLib > > > + MemoryAllocationLib > > >PeimEntryPoint > > >BaseLib > > >DebugLib > > > @@ -61,6 +63,7 @@ > > >gRecoveryOnFatIdeDiskGuid ## SOMETIMES_CONSUMES ## > > > UNDEFINED > > >gRecoveryOnFatFloppyDiskGuid## SOMETIMES_CONSUMES > ## > > > UNDEFINED > > >gRecoveryOnFatNvmeDiskGuid ## SOMETIMES_CONSUMES > ## > > > UNDEFINED > > > + gEfiPartTypeUnusedGuid ## SOMETIMES_CONSUMES ## > > > UNDEFINED > > > > > > > > > [Ppis] > > > diff --git a/FatPkg/FatPei/Gpt.c b/FatPkg/FatPei/Gpt.c new file mode > > 100644 > > > index 00..d1f4c1c8b5 > > > --- /dev/null > > > +++ b/FatPkg/FatPei/Gpt.c > > > @@ -0,0 +1,546 @@ > > > +/** @file > > > + Routines supporting partition discovery and > > > + logical device reading > > > + > > > +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. > > > + > > > +This program and the accompanying materials are licensed and made > > > +available under the terms and conditions of the BSD License which > > > +accompanies this distribution. The full text of the license may be > > > +found at http://opensource.org/licenses/bsd-license.php > > > + > > > +THE PROG
Re: [edk2] [PATCH v3 0/3] Remove unnecessary NULL pointer check.
> -Original Message- > From: Wu, Jiaxin > Sent: Friday, January 18, 2019 3:18 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu > Subject: [PATCH v3 0/3] Remove unnecessary NULL pointer check. > > v3: Updated the first patch to check the instance token. > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469 > > Since the value retrieved from the list Entry can't be the NULL > pointer, the unnecessary check can be removed. The series is good to me: Reviewed-by: Hao Wu Best Regards, Hao Wu > > Cc: Ye Ting > Cc: Fu Siyuan > Cc: Wu Hao A > Cc: Gao Liming > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Wu Jiaxin > Jiaxin Wu (3): > MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check. > NetworkPkg/IScsiDxe: Remove unnecessary NULL pointer check. > NetworkPkg/DnsDxe: Remove unnecessary NULL pointer check. > > MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 -- > NetworkPkg/DnsDxe/DnsDriver.c | 22 > --- > NetworkPkg/IScsiDxe/IScsiConfig.c | 6 + > 3 files changed, 14 insertions(+), 25 deletions(-) > > -- > 2.17.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Hi Jiaxin,
A comment that is not related with the content of the patch itself:
Please help to send the full patch series when a new version is needed.
Best Regards,
Hao Wu
> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, January 18, 2019 1:16 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu, Jiaxin
> Subject: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary
> NULL pointer check.
>
> v2: The DHCP Instance might be destroyed in PxeDhcpDone. So,
> we need safe-delete.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
>
> Since the value of Instance is retrieved from the list Entry,
> it can't be the NULL pointer, so just remove the unnecessary
> check.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Hao A
> Cc: Gao Liming
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> ---
> MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> index 98a22a77b4..780f8b4224 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> @@ -1,9 +1,9 @@
> /** @file
>EFI DHCP protocol implementation.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> http://opensource.org/licenses/bsd-license.php
>
> @@ -1646,16 +1646,13 @@ ON_EXIT:
>//
>// Iterate through all the DhcpSb Children.
>//
>NET_LIST_FOR_EACH_SAFE (Entry, Next, >Children) {
> Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> -
> -if ((Instance != NULL) && (Instance->Token != NULL)) {
> - Instance->Timeout--;
> - if (Instance->Timeout == 0) {
> -PxeDhcpDone (Instance);
> - }
> +Instance->Timeout--;
> +if (Instance->Timeout == 0) {
> + PxeDhcpDone (Instance);
> }
>}
>
>return ;
>
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Wrong operation made. Please ignore the message. Sorry for the noise. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Hao A > Sent: Wednesday, January 16, 2019 3:42 PM > To: Zeng, Star; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real > variable driver > > Wu, Hao A would like to recall the message, "[edk2] [PATCH V3 00/17] Merge > EmuVariable and Real variable driver". > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Wu, Hao A would like to recall the message, "[edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver". ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Star, The KW scan for the patch series is good. Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Star Zeng > Sent: Tuesday, January 15, 2019 6:29 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable > driver > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > > Purpose: > 1. Add emulated variable NV mode support in >MdeModulePkg\Universal\Variable\RuntimeDxe. >Platform can configure PCD statically (build time) or >dynamically (boot time) to support emulated variable NV mode. > 2. Remove MdeModulePkg\Universal\Variable\EmuRuntimeDxe whose >most codes are duplicated. > > > V3: > Addressed all the great feedbacks from Jian, Hao, Laszlo and Leif, thanks. > Pick up RB and AB tags. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V3 > > Patches 1~9: Preparation > Patch 3 and 9 are new added based on feedbacks. > Patch 10~11: Real work > Patch 12~17: Migration for platforms and cleanup > > > V2: Addressed all the feedbacks from Laszlo, thanks. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V2 > > Patches 1~7: Preparation > Patch 6 and 7 are new separated. > Patch 8~9: Real work > Patch 10~15: Migration for platforms and cleanup > Patch 11 is new added to let ArmVirtXen be aligned with ArmVirtQemuXXX. > > > V1: > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode > > Patches 1~5: Preparation > Patch 6~7: Real work > Patch 8~12: Migration for platforms and cleanup > > Test done: > Build code with VS2012, VS2015 and GCC49. > Regression: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to UEFI > SHELL. > Boot some internal platform to UEFI SHELL and Windows. > Functionality: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to > UEFI SHELL >with PcdEmuVariableNvModeEnable == TRUE. > > More test will be welcome and appreciated. :) > > Patches to update edk2-platforms Repo will be sent out separately. > > Star Zeng (17): > MdeModulePkg Variable: Add some missing changes for 9b18845 > MdeModulePkg Variable: Abstract InitRealNonVolatileVariableStore > MdeModulePkg Variable: Move "extern XXX" to Variable.h > MdeModulePkg Variable: Not get NV PCD in > VariableWriteServiceInitialize > MdeModulePkg Variable: Abstract VariableWriteServiceInitializeDxe/Smm > MdeModulePkg Variable: Remove CacheOffset in UpdateVariable() > MdeModulePkg Variable: type case VolatileBase to UINTN directly > MdeModulePkg: Add PcdEmuVariableNvModeEnable in dec > MdeModulePkg: Refine description a little for > PcdEmuVariableNvStoreReserved > MdeModulePkg Variable: Add emulated variable NV mode support > MdeModulePkg VariablePei: Don't check BOOT_IN_RECOVERY_MODE > ArmVirtXen: Use merged variable driver for emulated NV mode > ArmVirtXen: Link VarCheckUefiLib NULL class library instance > BeagleBoardPkg: Use merged variable driver for emulated NV mode > QuarkMin: Use merged variable driver for emulated NV mode > CorebootPayloadPkg: Use merged variable driver for emulated NV mode > MdeModulePkg: Remove EmuVariableRuntimeDxe > > ArmVirtPkg/ArmVirtXen.dsc | 12 +- > ArmVirtPkg/ArmVirtXen.fdf |4 +- > BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- > BeagleBoardPkg/BeagleBoardPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc | 11 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 11 +- > MdeModulePkg/MdeModulePkg.dec | 16 +- > MdeModulePkg/MdeModulePkg.dsc |5 +- > MdeModulePkg/MdeModulePkg.uni | 14 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 -- > -- > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > MdeModulePkg/Universal/Variable/Pei/Variable.c |8 +- > .../Universal/Variable/Pei/VariablePei.inf |3 +- > .../Universal/Variable/RuntimeDxe/Variable.c | 431 +++-- > .../Universal/Variable/RuntimeDxe/Variable.h | 19 +- > .../Universal/Variable/RuntimeDxe/VariableDxe.c| 103 +- > .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |4 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.c| 90 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.inf |4 +- > QuarkPlatformPkg/QuarkMin.dsc |8 +- > QuarkPlatformPkg/QuarkMin.fdf |
Re: [edk2] [PATCH V3 10/17] MdeModulePkg Variable: Add emulated variable NV mode support
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A; Kinney, Michael D; Gao, Liming; Ni,
> Ray; Laszlo Ersek; Ard Biesheuvel
> Subject: [PATCH V3 10/17] MdeModulePkg Variable: Add emulated variable
> NV mode support
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add emulated variable NV mode support in real variable driver.
> Platform can configure PcdEmuVariableNvModeEnable statically
> (build time) or dynamically (boot time) to support emulated
> variable NV mode.
>
> If PcdEmuVariableNvModeEnable is configured to dynamic, its
> value should be set before Variable driver starts to work,
> otherwise default value will take effect.
>
> Then EmuVariableRuntimeDxe could be removed, the removal of
> EmuVariableRuntimeDxe will be done after platforms are migrated
> to use the merged variable driver.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> Acked-by: Laszlo Ersek
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 318 +++
> --
> .../Universal/Variable/RuntimeDxe/Variable.h | 1 +
> .../Universal/Variable/RuntimeDxe/VariableDxe.c| 27 +-
> .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.c| 29 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 4 +-
> 6 files changed, 271 insertions(+), 112 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index d3df21819abe..e8e19508cd9a 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -34,6 +34,7 @@ VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
>
> ///
> /// Define a memory cache that improves the search performance for a
> variable.
> +/// For EmuNvMode == TRUE, it will be equal to NonVolatileVariableBase.
> ///
> VARIABLE_STORE_HEADER *mNvVariableCache = NULL;
>
> @@ -273,7 +274,7 @@ UpdateVariableStore (
>//
>// Check if the Data is Volatile.
>//
> - if (!Volatile) {
> + if (!Volatile && !mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> if (Fvb == NULL) {
>return EFI_UNSUPPORTED;
> }
> @@ -296,17 +297,30 @@ UpdateVariableStore (
> // Data Pointer should point to the actual Address where data is to be
> // written.
> //
> -VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> -if (SetByIndex) {
> - DataPtr += mVariableModuleGlobal-
> >VariableGlobal.VolatileVariableBase;
> -}
> +if (Volatile) {
> + VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> + if (SetByIndex) {
> +DataPtr += mVariableModuleGlobal-
> >VariableGlobal.VolatileVariableBase;
> + }
>
> -if ((DataPtr + DataSize) > ((UINTN) VolatileBase + VolatileBase->Size)) {
> - return EFI_OUT_OF_RESOURCES;
> + if ((DataPtr + DataSize) > ((UINTN) VolatileBase +
> VolatileBase->Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> +} else {
> + //
> + // Emulated non-volatile variable mode.
> + //
> + if (SetByIndex) {
> +DataPtr += (UINTN) mNvVariableCache;
> + }
> +
> + if ((DataPtr + DataSize) > ((UINTN) mNvVariableCache +
> mNvVariableCache->Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> }
>
> //
> -// If Volatile Variable just do a simple mem copy.
> +// If Volatile/Emulated Non-volatile Variable just do a simple mem copy.
> //
> CopyMem ((UINT8 *)(UINTN)DataPtr, Buffer, DataSize);
> return EFI_SUCCESS;
> @@ -987,7 +1001,7 @@ Reclaim (
>CommonUserVariableTotalSize = 0;
>HwErrVariableTotalSize = 0;
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
> // Start Pointers for the variable.
> //
> @@ -1155,13 +1169,21 @@ Reclaim (
> CurrPtr += NewVariableSize;
>}
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
>
Re: [edk2] [PATCH V3 17/17] MdeModulePkg: Remove EmuVariableRuntimeDxe
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Tuesday, January 15, 2019 6:30 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wang, Jian J; Wu, Hao A > Subject: [PATCH V3 17/17] MdeModulePkg: Remove > EmuVariableRuntimeDxe > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > The real variable driver has been updated to support emulated > variable NV mode. > This patch removes EmuVariableRuntimeDxe after platforms are > migrated to use the merged variable driver. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/MdeModulePkg.dsc |5 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 > > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > 7 files changed, 1 insertion(+), 2489 deletions(-) > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.inf > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.uni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > DxeExtra.uni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/InitVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/Variable.h > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 5d042be3a862..3186f35a1a48 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -2,7 +2,7 @@ > # EFI/PI Reference Module Package for All Architectures > # > # (C) Copyright 2014 Hewlett-Packard Development Company, L.P. > -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > # > #This program and the accompanying materials > #are licensed and made available under the terms and conditions of the > BSD License > @@ -433,9 +433,6 @@ [Components.IA32, Components.X64, > Components.ARM, Components.AARCH64] > > NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32G > uidedSectionExtractLib.inf >} > > -[Components.IA32, Components.X64, Components.Ebc] > - > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.inf > - > [Components.IA32, Components.X64] > > MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo. > inf >MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf > diff --git > a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > b/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > deleted file mode 100644 > index 1bcf931b96a6.. > --- a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > +++ /dev/null > @@ -1,1820 +0,0 @@ > -/** @file > - > - Emulation Variable services operate on the runtime volatile memory. > - The nonvolatile variable space doesn't exist. > - > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. > -This program and the accompanying materials > -are licensed and made available under the terms and conditions of the BSD > License > -which accompanies this distribution. The full text of the license may be > found at > -http://opensource.org/licenses/bsd-license.php > - > -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > - > -**/ > - > -#include "Variable.h" > - > -/// > -/// Don't use module globals after the SetVirtualAddress map is signaled > -/// > -ESAL_VARIABLE_GLOBAL *mVariableModuleGlobal; > - > -VARIABLE_INFO_ENTRY *gVariableInfo = NULL; > - > -/// > -/// The size of a 3 character ISO639 language code. > -/// > -#define ISO_639_2_ENTRY_SIZE3 > - > -/** > - Update the variable region with Variable information. These are the same > - arguments as the EFI Variable services. > - > - @param[in] VariableName Name of variable > - > - @param[in] VendorGuid Guid of variable > - > - @param[in] Data Variable data > - > - @param[in] DataSize Size of data. 0
Re: [edk2] [PATCH V3 04/17] MdeModulePkg Variable: Not get NV PCD in VariableWriteServiceInitialize
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 04/17] MdeModulePkg Variable: Not get NV PCD in
> VariableWriteServiceInitialize
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add macro NV_STORAGE_VARIABLE_BASE.
> Not get NV PCD in VariableWriteServiceInitialize, but in
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitialize could be not aware the NV
> storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 20
> ++--
> .../Universal/Variable/RuntimeDxe/Variable.h | 9 +++--
> .../Universal/Variable/RuntimeDxe/VariableDxe.c | 13 -
> .../Universal/Variable/RuntimeDxe/VariableSmm.c | 15 ++-
> 4 files changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 0b675c8f36df..424f92a53757 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3770,10 +3770,7 @@ InitRealNonVolatileVariableStore (
> return EFI_OUT_OF_RESOURCES;
>}
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> + NvStorageBase = NV_STORAGE_VARIABLE_BASE;
>ASSERT (NvStorageBase != 0);
>
>//
> @@ -4027,7 +4024,7 @@ FlushHobVariableToFlash (
> }
>
> /**
> - Initializes variable write service after FTW was ready.
> + Initializes variable write service.
>
>@retval EFI_SUCCESS Function successfully executed.
>@retval Others Fail to initialize the variable service.
> @@ -4041,23 +4038,10 @@ VariableWriteServiceInitialize (
>EFI_STATUS Status;
>UINTN Index;
>UINT8 Data;
> - EFI_PHYSICAL_ADDRESSVariableStoreBase;
> - EFI_PHYSICAL_ADDRESSNvStorageBase;
>VARIABLE_ENTRY_PROPERTY *VariableEntry;
>
>AcquireLockOnlyAtBootTime(
> >VariableGlobal.VariableServicesLock);
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> - VariableStoreBase = NvStorageBase + (mNvFvHeaderCache-
> >HeaderLength);
> -
> - //
> - // Let NonVolatileVariableBase point to flash variable store base directly
> after FTW ready.
> - //
> - mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase =
> VariableStoreBase;
> -
>//
>// Check if the free area is really free.
>//
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 90507a8e64f6..d128d1a9c680 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -2,7 +2,7 @@
>The internal header file includes the common header files, defines
>internal structure and functions used by Variable modules.
>
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -46,6 +46,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "PrivilegePolymorphic.h"
>
> +#define NV_STORAGE_VARIABLE_BASE (EFI_PHYSICAL_ADDRESS) \
> + (PcdGet64
> (PcdFlashNvStorageVariableBase64) != 0 ? \
> +PcdGet64
> (PcdFlashNvStorageVariableBase64) : \
> +PcdGet32 (PcdFlashNvStorageVariableBase))
> +
> #define EFI_VARIABLE_ATTRIBUTES_MASK (EFI_VARIABLE_N
Re: [edk2] [PATCH V3 11/17] MdeModulePkg VariablePei: Don't check BOOT_IN_RECOVERY_MODE
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 11/17] MdeModulePkg VariablePei: Don't check
> BOOT_IN_RECOVERY_MODE
>
> Don't check BOOT_IN_RECOVERY_MODE, but check
> PcdEmuVariableNvModeEnable
> which platform can configure flexibly.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/Pei/Variable.c | 8 +---
> MdeModulePkg/Universal/Variable/Pei/VariablePei.inf | 3 ++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/Pei/Variable.c
> b/MdeModulePkg/Universal/Variable/Pei/Variable.c
> index 77b3eaeb210d..148c1cfefd90 100644
> --- a/MdeModulePkg/Universal/Variable/Pei/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/Pei/Variable.c
> @@ -2,7 +2,7 @@
>Implement ReadOnly Variable Services required by PEIM and install
>PEI ReadOnly Varaiable2 PPI. These services operates the non volatile
> storage space.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -584,9 +584,9 @@ GetVariableStore (
>break;
>
> case VariableStoreTypeNv:
> - if (GetBootModeHob () != BOOT_IN_RECOVERY_MODE) {
> + if (!PcdGetBool (PcdEmuVariableNvModeEnable)) {
> //
> -// The content of NV storage for variable is not reliable in recovery
> boot mode.
> +// Emulated non-volatile variable mode is not enabled.
> //
>
> NvStorageSize = PcdGet32 (PcdFlashNvStorageVariableSize);
> @@ -594,6 +594,8 @@ GetVariableStore (
> PcdGet64
> (PcdFlashNvStorageVariableBase64) :
> PcdGet32
> (PcdFlashNvStorageVariableBase)
> );
> +ASSERT (NvStorageBase != 0);
> +
> //
> // First let FvHeader point to NV storage base.
> //
> diff --git a/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> b/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> index 565efdc02116..3161617a56c2 100644
> --- a/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> +++ b/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> @@ -3,7 +3,7 @@
> #
> # This module implements ReadOnly Variable Services required by PEIM
> and installs PEI ReadOnly Varaiable2 PPI.
> #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the
> BSD License
> # which accompanies this distribution. The full text of the license may be
> found at
> @@ -68,6 +68,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase ##
> SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize ##
> CONSUMES
> + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
> ## SOMETIMES_CONSUMES
>
> [Depex]
>gEdkiiFaultTolerantWriteGuid
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 09/17] MdeModulePkg: Refine description a little for PcdEmuVariableNvStoreReserved
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Tuesday, January 15, 2019 6:30 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wang, Jian J; Wu, Hao A > Subject: [PATCH V3 09/17] MdeModulePkg: Refine description a little for > PcdEmuVariableNvStoreReserved > > This patch is not related directly to > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > PcdEmuVariableNvStoreReserved actually defines the base address of > reserved memory range. > > This patch refines description a little for PcdEmuVariableNvStoreReserved. > > Suggested-by: Jian J Wang > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/MdeModulePkg.dec | 6 +++--- > MdeModulePkg/MdeModulePkg.uni | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > index 2be77022c948..e5c32d15edcd 100644 > --- a/MdeModulePkg/MdeModulePkg.dec > +++ b/MdeModulePkg/MdeModulePkg.dec > @@ -1594,9 +1594,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] ># @Prompt EMU variable NV mode enable. > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE > |BOOLEAN|0x0111 > > - ## This PCD defines a reserved memory range for EMU variable NV storage. > - # The range is valid if non-zero. The memory range size must be > PcdVariableStoreSize. > - # @Prompt Reserved memory range for EMU variable NV storage. > + ## This PCD defines the base address of reserved memory range for EMU > variable NV storage. > + # A non-ZERO value indicates a valid range reserved with size given by > PcdVariableStoreSize. > + # @Prompt Base of reserved memory range for EMU variable NV storage. > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0|UI > NT64|0x4008 > >## This PCD defines the times to print hello world string. > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > index 2f437d78eba2..787fdf2282c3 100644 > --- a/MdeModulePkg/MdeModulePkg.uni > +++ b/MdeModulePkg/MdeModulePkg.uni > @@ -397,9 +397,9 @@ > > "TRUE - An EMU variable NV > storage will be allocated or reserved for NV variables." > > "FALSE - No EMU variable NV > storage will be allocated or reserved for NV variables." > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _PROMPT #language en-US "Reserved memory range for EMU variable NV > storage" > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _PROMPT #language en-US "Base of reserved memory range for EMU > variable NV storage" > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _HELP #language en-US "This PCD defines a reserved memory range for > EMU variable NV storage. The range is valid if non-zero. The memory range > size must be PcdVariableStoreSize." > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _HELP #language en-US "This PCD defines the base address of reserved > memory range for EMU variable NV storage. A non-ZERO value indicates a > valid range reserved with size given by PcdVariableStoreSize." > > #string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdHelloWorldPrintTimes_PROM > PT #language en-US "HelloWorld print times" > > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 03/17] MdeModulePkg Variable: Move "extern XXX" to Variable.h
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 03/17] MdeModulePkg Variable: Move "extern XXX" to
> Variable.h
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Move "extern XXX" to Variable.h from VariableDxe.c/VariableSmm.c.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h| 11
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 4
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c | 3 ---
> 3 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 938eb5de61fa..90507a8e64f6 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -792,9 +792,14 @@ InitializeVariableQuota (
>VOID
>);
>
> -extern VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
> -
> -extern AUTH_VAR_LIB_CONTEXT_OUT mAuthContextOut;
> +extern VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
> +extern EFI_FIRMWARE_VOLUME_HEADER *mNvFvHeaderCache;
> +extern VARIABLE_STORE_HEADER*mNvVariableCache;
> +extern VARIABLE_INFO_ENTRY *gVariableInfo;
> +extern BOOLEAN mEndOfDxe;
> +extern VAR_CHECK_REQUEST_SOURCE mRequestSource;
> +
> +extern AUTH_VAR_LIB_CONTEXT_OUT mAuthContextOut;
>
> /**
>Finds variable in storage blocks of volatile and non-volatile storage
> areas.
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index f7185df3a7eb..f1304c9dbccc 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -17,13 +17,9 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "Variable.h"
>
> -extern VARIABLE_STORE_HEADER*mNvVariableCache;
> -extern EFI_FIRMWARE_VOLUME_HEADER *mNvFvHeaderCache;
> -extern VARIABLE_INFO_ENTRY *gVariableInfo;
> EFI_HANDLE mHandle= NULL;
> EFI_EVENT mVirtualAddressChangeEvent = NULL;
> EFI_EVENT mFtwRegistration = NULL;
> -extern BOOLEAN mEndOfDxe;
> VOID***mVarCheckAddressPointer = NULL;
> UINTN mVarCheckAddressPointerCount = 0;
> EDKII_VARIABLE_LOCK_PROTOCOLmVariableLock =
> { VariableLockRequestToLock };
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> index 8c53f84ff6e8..623badb0c755 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> @@ -37,14 +37,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include
> #include "Variable.h"
>
> -extern VARIABLE_INFO_ENTRY *gVariableInfo;
> EFI_HANDLE mSmmVariableHandle
> = NULL;
> EFI_HANDLE mVariableHandle
> = NULL;
> BOOLEAN mAtRuntime
> = FALSE;
> UINT8*mVariableBufferPayload
> = NULL;
> UINTN
> mVariableBufferPayloadSize;
> -extern BOOLEAN mEndOfDxe;
> -extern VAR_CHECK_REQUEST_SOURCE mRequestSource;
>
> /**
>SecureBoot Hook for SetVariable.
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
