Re: [edk2-devel] [PATCH 1/1] CryptoPkg: Fix coding style

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Zhang, Shenglei
> Sent: Friday, August 16, 2019 2:54 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Ye, Ting 
> Subject: [PATCH 1/1] CryptoPkg: Fix coding style
> 
> Update attribute "Out" to "out".
> The original "Out" can not pass ECC check.
> 
> Cc: Jian Wang 
> Cc: Ting Ye 
> Signed-off-by: Shenglei Zhang 
> ---
>  CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c | 2 +-
>  CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c | 2 +-
>  CryptoPkg/Include/Library/BaseCryptLib.h   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> index f0fcef211d3f..3a827dadfcbd 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> @@ -19,7 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>@param[in]   SaltSize Salt size in bytes.
>@param[in]   Info Pointer to the application specific info.
>@param[in]   InfoSize Info size in bytes.
> -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> +  @param[out]  Out  Pointer to buffer to receive hkdf value.
>@param[in]   OutSize  Size of hkdf bytes to generate.
> 
>@retval TRUE   Hkdf generated successfully.
> diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> index 73deb5bc3614..19d795a4cc16 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> @@ -18,7 +18,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>@param[in]   SaltSize Salt size in bytes.
>@param[in]   Info Pointer to the application specific info.
>@param[in]   InfoSize Info size in bytes.
> -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> +  @param[out]  Out  Pointer to buffer to receive hkdf value.
>@param[in]   OutSize  Size of hkdf bytes to generate.
> 
>@retval TRUE   Hkdf generated successfully.
> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index da32bb2444fd..8fe303a0b390 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -3135,7 +3135,7 @@ RandomBytes (
>@param[in]   SaltSize Salt size in bytes.
>@param[in]   Info Pointer to the application specific info.
>@param[in]   InfoSize Info size in bytes.
> -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> +  @param[out]  Out  Pointer to buffer to receive hkdf value.
>@param[in]   OutSize  Size of hkdf bytes to generate.
> 
>@retval TRUE   Hkdf generated successfully.
> --
> 2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45796): https://edk2.groups.io/g/devel/message/45796
Mute This Topic: https://groups.io/mt/32895950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in acpiview

[Krzysztof Koch]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2089

Hi Liming,

Sure, no problem.

Kind regards,

Krzysztof

-Original Message-
From: Gao, Liming  
Sent: Friday, August 16, 2019 5:03
To: devel@edk2.groups.io; Krzysztof Koch 
Cc: Carsey, Jaben ; Ni, Ray ; Gao, 
Zhichao ; Sami Mujawar ; Matteo 
Carlini ; nd 
Subject: RE: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in 
acpiview

Krzysztof:
   Can you submit BZ in https://bugzilla.tianocore.org/ for this change? 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
>Krzysztof Koch
>Sent: Thursday, August 15, 2019 9:11 PM
>To: devel@edk2.groups.io
>Cc: Carsey, Jaben ; Ni, Ray ; 
>Gao, Zhichao ; sami.muja...@arm.com; 
>matteo.carl...@arm.com; n...@arm.com
>Subject: [edk2-devel] [PATCH v1 00/11] Test against invalid pointers in 
>acpiview
>
>Prevent the use of invalid pointers when parsing ACPI tables in the 
>UEFI shell acpiview tool.
>
>The parsing of ACPI tables is often controlled with the values read 
>earlier from the same table. For example, the 'Offset' or 'Count' 
>fields found in a structure are later used to parse the substructures. 
>If such fields lie outside the structure's buffer length provided, then 
>there is a possibility for a wild or dangling pointer.
>
>Currently, if the ParseAcpi() function terminates early because the end 
>of the input table data buffer has been reached, then the pointers 
>which were supposed to be updated by this function are left untouched.
>This is a security issue as the values pointed to by these pointers are 
>later used for flow control.
>
>This patch series aims to solve this security issue by explicitly 
>initializing any pointers lying outside the input ACPI data buffer to 
>NULL and testing for NULL whenever these pointers are dereferenced.
>
>Changes can be seet at:
>https://github.com/KrzysztofKoch1/edk2/tree/612_add_pointer_validation_
>v1
>
>Krzysztof Koch (11):
>  ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields
>  ShellPkg: acpiview: RSDP: Validate global pointer before use
>  ShellPkg: acpiview: FADT: Validate global pointer before use
>  ShellPkg: acpiview: SLIT: Validate global pointer before use
>  ShellPkg: acpiview: SLIT: Validate System Locality count
>  ShellPkg: acpiview: SRAT: Validate global pointers before use
>  ShellPkg: acpiview: MADT: Validate global pointers before use
>  ShellPkg: acpiview: PPTT: Validate global pointers before use
>  ShellPkg: acpiview: IORT: Validate global pointers before use
>  ShellPkg: acpiview: GTDT: Validate global pointers before use
>  ShellPkg: acpiview: DBG2: Validate global pointers before use
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c  |  9 
> ++-
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Dbg2/Dbg2Parser.c
>| 43 ++
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c 
>|
>14 +
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
>| 37 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c 
>|
>52 +
>
>ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Madt/MadtParser.c
>| 13 +
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c 
>|
>25 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Rsdp/RsdpParser.c
>| 12 
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Slit/SlitParser.c 
> | 61
>++--
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c 
>|
>13 +
> 10 files changed, 272 insertions(+), 7 deletions(-)
>
>--
>'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45797): https://edk2.groups.io/g/devel/message/45797
Mute This Topic: https://groups.io/mt/32886564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global pointer before use

[Gao, Zhichao]

For FadtMinorRevision and X_DsdtAddress, I don't think they are required 
section. Maybe we should consider check the length before check them. As I 
know, the OVMF's FACP table doesn't have the section after flag.

Thanks,
Zhichao

> -Original Message-
> From: Krzysztof Koch [mailto:krzysztof.k...@arm.com]
> Sent: Thursday, August 15, 2019 9:11 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Gao, Zhichao ; sami.muja...@arm.com;
> matteo.carl...@arm.com; n...@arm.com
> Subject: [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global pointer
> before use
> 
> Check if global pointers have been successfully updated before they are
> used for further table parsing.
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Notes:
> v1:
> - Test against NULL pointers [Krzysztof]
> 
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
> | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> index
> e40c9ef8ee4b3285faf8c6edf3cb6236ee367397..e218e45926abced1096e75441
> e22108db7a3a811 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtPars
> +++ er.c
> @@ -203,6 +203,20 @@ ParseAcpiFadt (
>  PARSER_PARAMS (FadtParser)
>  );
> 
> +  // Check if the values used to control the parsing logic have been
> + // successfully read.
> +  if ((DsdtAddress == NULL)   ||
> +  (FadtMinorRevision == NULL) ||
> +  (X_DsdtAddress == NULL)) {
> +IncrementErrorCount ();
> +Print (
> +  L"ERROR: Insufficient table length. AcpiTableLength = %d. " \
> +L"FADT parsing aborted.\n",
> +  AcpiTableLength
> +  );
> +return;
> +  }
> +
>if (Trace) {
>  Print (L"\nSummary:\n");
>  PrintFieldName (2, L"FADT Version");
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45798): https://edk2.groups.io/g/devel/message/45798
Mute This Topic: https://groups.io/mt/32886566/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

[Jordan Justen]

On 2019-08-15 19:14:33, Michael D Kinney wrote:
> Fix scripts to support lldb symbolic debugging when
> using XCODE5 tool chain.
> 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Signed-off-by: Andrew Fish 

Is this a Cc/Signed-off-by typo? (See also, patches 7-10).

This makes me wonder if you are taking advantage of the git commit -s
switch to add your Signed-off-by.

Also, I'm wondering if you are taking advantage of git-send-email
automatically Cc'ing the addresses you listed in the commit message.
(I thought it Cc'd for the author and Cc tags, but I wasn't sure about
the Signed-off-by tag, and yet I see Andrew was Cc'd.)

There's a couple long lines below. You could use \ at the end of the
line to split the .sh line. I think the cd can be a separate command
in a shell script. (Not in make)

I hope someone that uses the XCODE toolchain could review/check the
XCODE patches.

-Jordan

> ---
>  EmulatorPkg/Unix/lldbefi.py |  8 +---
>  EmulatorPkg/build.sh| 17 ++---
>  2 files changed, 7 insertions(+), 18 deletions(-)
> 
> diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
> index 218326b8cb..099192d8b5 100755
> --- a/EmulatorPkg/Unix/lldbefi.py
> +++ b/EmulatorPkg/Unix/lldbefi.py
> @@ -346,6 +346,7 @@ def TypePrintFormating(debugger):
>  debugger.HandleCommand("type summary add CHAR8 --python-function 
> lldbefi.CHAR8_TypeSummary")
>  debugger.HandleCommand('type summary add --regex "CHAR8 \[[0-9]+\]" 
> --python-function lldbefi.CHAR8_TypeSummary')
>
> +debugger.HandleCommand('setting set frame-format "frame #${frame.index}: 
> ${frame.pc}{ 
> ${module.file.basename}{:${function.name}()${function.pc-offset}}}{ at 
> ${line.file.fullpath}:${line.number}}\n"')
>
>  gEmulatorBreakWorkaroundNeeded = True
>
> @@ -381,15 +382,16 @@ def LoadEmulatorEfiSymbols(frame, bp_loc , 
> internal_dict):
>  Error = lldb.SBError()
>  FileNamePtr = frame.FindVariable ("FileName").GetValueAsUnsigned()
>  FileNameLen = frame.FindVariable ("FileNameLength").GetValueAsUnsigned()
> +
>  FileName = frame.thread.process.ReadCStringFromMemory (FileNamePtr, 
> FileNameLen, Error)
>  if not Error.Success():
>  print "!ReadCStringFromMemory() did not find a %d byte C string at 
> %x" % (FileNameLen, FileNamePtr)
>  # make breakpoint command contiue
> -frame.GetThread().GetProcess().Continue()
> +return False
>
>  debugger = frame.thread.process.target.debugger
>  if frame.FindVariable ("AddSymbolFlag").GetValueAsUnsigned() == 1:
> -LoadAddress = frame.FindVariable ("LoadAddress").GetValueAsUnsigned()
> +LoadAddress = frame.FindVariable 
> ("LoadAddress").GetValueAsUnsigned() - 0x240
>
>  debugger.HandleCommand ("target modules add  %s" % FileName)
>  print "target modules load --slid 0x%x %s" % (LoadAddress, FileName)
> @@ -405,7 +407,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
>  print "!lldb.target.RemoveModule (%s) FAILED" % SBModule
>
>  # make breakpoint command contiue
> -frame.thread.process.Continue()
> +return False
>
>  def GuidToCStructStr (guid, Name=False):
>#
> diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh
> index 60056e1b6c..35912a7775 100755
> --- a/EmulatorPkg/build.sh
> +++ b/EmulatorPkg/build.sh
> @@ -209,21 +209,8 @@ fi
>  if [[ "$RUN_EMULATOR" == "yes" ]]; then
>case `uname` in
>  Darwin*)
> -  #
> -  # On Darwin we can't use dlopen, so we have to load the real PE/COFF 
> images.
> -  # This .gdbinit script sets a breakpoint that loads symbols for the 
> PE/COFFEE
> -  # images that get loaded in Host
> -  #
> -  if [[ "$CLANG_VER" == *-ccc-host-triple* ]]
> -  then
> -  # only older versions of Xcode support -ccc-host-tripe, for newer 
> versions
> -  # it is -target
> -cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py 
> "$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
> -cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source 
> $WORKSPACE/EmulatorPkg/Unix/lldbinit Host
> -exit $? 
> -  else
> -cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit 
> "$BUILD_OUTPUT_DIR/${BUILDTARGET}_$TARGET_TOOLS/$PROCESSOR"
> -  fi
> +  cd $BUILD_ROOT_ARCH; /usr/bin/lldb -o "command script import 
> $WORKSPACE/EmulatorPkg/Unix/lldbefi.py" -o 'script 
> lldb.debugger.SetAsync(True)' -o "run" ./Host
> +  exit $?
>;;
>esac
>
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45799): https://edk2.groups.io/g/devel/message/45799
Mute This Topic: https://groups.io/mt/32894351/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V4 07/10] EmulatorPkg/Unix/Host: Fix BerkeleyPacketFilter.c issues

[Jordan Justen]

On 2019-08-15 19:14:34, Michael D Kinney wrote:
> * Fix uninitialized Private->ReadBuffer.
> * Remove old debug code that generates an exception.

Bulleted lists in the commit message often makes me think they should
be separate patches. Maybe that could improve the commit message
subject line for the patches too. :)

-Jordan

> 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Signed-off-by: Andrew Fish 
> ---
>  EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c 
> b/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
> index 8d0eb0d197..3013bbc86b 100644
> --- a/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
> +++ b/EmulatorPkg/Unix/Host/BerkeleyPacketFilter.c
> @@ -216,6 +216,7 @@ EmuSnpStart (
>}
>
>Status = EFI_SUCCESS;
> +  Private->ReadBuffer = NULL;
>if (Private->BpfFd == 0) {
>  Status = OpenBpfFileDescriptor (Private, &Private->BpfFd);
>  if (EFI_ERROR (Status)) {
> @@ -766,10 +767,6 @@ EmuSnpGetStatus (
>
>Private = EMU_SNP_PRIVATE_DATA_FROM_THIS (This);
>
> -  if (TxBuf != NULL) {
> -*((UINT8 **)TxBuf) =  (UINT8 *)1;
> -  }
> -
>if ( InterruptStatus != NULL ) {
>  *InterruptStatus = EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT;
>}
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45800): https://edk2.groups.io/g/devel/message/45800
Mute This Topic: https://groups.io/mt/32894352/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Yao, Jiewen]

below

> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, August 16, 2019 3:20 PM
> To: Yao, Jiewen ; Laszlo Ersek
> ; devel@edk2.groups.io
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Chen, Yingwen ; Nakajima, Jun
> ; Boris Ostrovsky ;
> Joao Marcal Lemos Martins ; Phillip Goerl
> 
> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> 
> On 16/08/19 04:46, Yao, Jiewen wrote:
> > Comment below:
> >
> >
> >> -Original Message-
> >> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >> Sent: Friday, August 16, 2019 12:21 AM
> >> To: Laszlo Ersek ; devel@edk2.groups.io; Yao,
> Jiewen
> >> 
> >> Cc: edk2-rfc-groups-io ; qemu devel list
> >> ; Igor Mammedov
> ;
> >> Chen, Yingwen ; Nakajima, Jun
> >> ; Boris Ostrovsky
> ;
> >> Joao Marcal Lemos Martins ; Phillip Goerl
> >> 
> >> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
> >>
> >> On 15/08/19 17:00, Laszlo Ersek wrote:
> >>> On 08/14/19 16:04, Paolo Bonzini wrote:
>  On 14/08/19 15:20, Yao, Jiewen wrote:
> >> - Does this part require a new branch somewhere in the OVMF SEC
> >> code?
> >>   How do we determine whether the CPU executing SEC is BSP or
> >>   hot-plugged AP?
> > [Jiewen] I think this is blocked from hardware perspective, since the
> first
> >> instruction.
> > There are some hardware specific registers can be used to determine
> if
> >> the CPU is new added.
> > I don’t think this must be same as the real hardware.
> > You are free to invent some registers in device model to be used in
> >> OVMF hot plug driver.
> 
>  Yes, this would be a new operation mode for QEMU, that only applies
> to
>  hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI,
> in
>  fact it doesn't reply to anything at all.
> 
> >> - How do we tell the hot-plugged AP where to start execution? (I.e.
> >> that
> >>   it should execute code at a particular pflash location.)
> > [Jiewen] Same real mode reset vector at :FFF0.
> 
>  You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
>  QEMU.  The AP does not start execution at all when it is unplugged,
> so
>  no cache-as-RAM etc.
> 
>  We only need to modify QEMU so that hot-plugged APIs do not reply
> to
>  INIT/SIPI/SMI.
> 
> > I don’t think there is problem for real hardware, who always has CAR.
> > Can QEMU provide some CPU specific space, such as MMIO region?
> 
>  Why is a CPU-specific region needed if every other processor is in SMM
>  and thus trusted.
> >>>
> >>> I was going through the steps Jiewen and Yingwen recommended.
> >>>
> >>> In step (02), the new CPU is expected to set up RAM access. In step
> >>> (03), the new CPU, executing code from flash, is expected to "send
> board
> >>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> >>> message." For that action, the new CPU may need a stack (minimally if
> we
> >>> want to use C function calls).
> >>>
> >>> Until step (03), there had been no word about any other (= pre-plugged)
> >>> CPUs (more precisely, Jiewen even confirmed "No impact to other
> >>> processors"), so I didn't assume that other CPUs had entered SMM.
> >>>
> >>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> >>> as I can. I'm still very confused. If you have a better understanding,
> >>> could you please write up the 15-step process from the thread starter
> >>> again, with all QEMU customizations applied? Such as, unnecessary
> steps
> >>> removed, and platform specifics filled in.
> >>
> >> Sure.
> >>
> >> (01a) QEMU: create new CPU.  The CPU already exists, but it does not
> >>  start running code until unparked by the CPU hotplug controller.
> >>
> >> (01b) QEMU: trigger SCI
> >>
> >> (02-03) no equivalent
> >>
> >> (04) Host CPU: (OS) execute GPE handler from DSDT
> >>
> >> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
> >>  will not enter CPU because SMI is disabled)
> >>
> >> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
> >>  rebase code.
> >>
> >> (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
> >>  new CPU
> >>
> >> (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
> > [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no
> > restriction that INIT/SIPI/SIPI can only be sent in SMM.
> 
> All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded
> before 07a, so this is okay.
[Jiewen] May I know why INIT/SIPI/SIPI is discarded before 07a but is delivered 
at 07a?
I don’t see any extra step between 06 and 07a.
What is the magic here?



> However I do see a problem, because a PCI device's DMA could overwrite
> 0x38000 between (06) and (10) and hijack the code that is executed in
> SMM.  How is this avoided on real hardware?  By the time the new CPU
> enters SMM, it doesn't run off cache-a

Re: [edk2-devel] [PATCH v2 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left

[Zhang, Shenglei]

Hi All,

This is patch to fix build failure. I'd like the patch to be checked in before 
this stable tag.

Thanks,
Shenglei

> -Original Message-
> From: Gao, Zhichao
> Sent: Friday, August 16, 2019 2:19 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> Subject: RE: [PATCH v2 1/1] ShellPkg/UefiShellAcpiViewCommandLib:
> Replace shift logical left
> 
> Reviewed-by: Zhichao Gao 
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Friday, August 16, 2019 2:11 PM
> > To: devel@edk2.groups.io
> > Cc: Carsey, Jaben ; Ni, Ray ;
> > Gao, Zhichao 
> > Subject: [PATCH v2 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Replace
> > shift logical left
> >
> > Replace the operation to shift logical left with the function LShiftU64, 
> > which
> > has the same functionality.
> > The original code causes ShellPkg build failure with build target"-b NOOPT".
> >
> > Cc: Jaben Carsey 
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Signed-off-by: Shenglei Zhang 
> > ---
> > v2: There is no return target from LShiftU64 in v1 patch.
> > So update code to "Val = LShiftU64(Val,32)".
> >
> >  ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> > b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> > index 94bafa22ef4c..a569c3c55406 100644
> > --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> > +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
> > @@ -294,7 +294,7 @@ DumpUint64 (
> >
> >Val = *(UINT32*)(Ptr + sizeof (UINT32));
> >
> > -  Val <<= 32;
> > +  Val = LShiftU64(Val,32);
> >Val |= (UINT64)*(UINT32*)Ptr;
> >
> >Print (Format, Val);
> > --
> > 2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45802): https://edk2.groups.io/g/devel/message/45802
Mute This Topic: https://groups.io/mt/32895687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue of incorrect Module Unique Name

[Bob Feng]

This patch is to fix a critical BaseTools regression bug and it need to be 
merged to edk2 master for the coming stable tag.

Thanks,
Bob 

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bob Feng
Sent: Friday, August 16, 2019 2:38 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Shi, Steven ; 
Feng, Bob C 
Subject: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue of incorrect Module 
Unique Name

https://bugzilla.tianocore.org/show_bug.cgi?id=2088
If there are more than one override instance for a same module, the Module 
Unique Name is generated incorrectly.

Cc: Liming Gao 
Cc: Steven Shi 
Signed-off-by: Bob Feng 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py   | 2 +-
 BaseTools/Source/Python/AutoGen/PlatformAutoGen.py | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 9ecf5c2dbe0c..076ce0e39c37 100644
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -293,11 +293,11 @@ class ModuleAutoGen(AutoGen):
 @property
 def UniqueBaseName(self):
 ModuleNames = self.DataPipe.Get("M_Name")
 if not ModuleNames:
 return self.Name
-return ModuleNames.get(self.Name,self.Name)
+return ModuleNames.get((self.Name,self.MetaFile),self.Name)
 
 # Macros could be used in build_rule.txt (also Makefile)
 @cached_property
 def Macros(self):
 return OrderedDict((
diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
index 4abfc6c29d1b..dd629ba2fac2 100644
--- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
@@ -1364,18 +1364,19 @@ class PlatformAutoGen(AutoGen):
 ModuleNameDict[unique_base_name].append(Module.MetaFile)
 if Module.BaseName not in UniqueName:
 UniqueName[Module.BaseName] = set()
 
UniqueName[Module.BaseName].add((self.ModuleGuid(Module),Module.MetaFile))
 for module_paths in ModuleNameDict.values():
-if len(module_paths) > 1 and len(set(module_paths))>1:
+if len(set(module_paths))>1:
 samemodules = list(set(module_paths))
 EdkLogger.error("build", FILE_DUPLICATED, 'Modules have same 
BaseName and FILE_GUID:\n'
 '  %s\n  %s' % (samemodules[0], 
samemodules[1]))
 for name in UniqueName:
 Guid_Path = UniqueName[name]
 if len(Guid_Path) > 1:
-retVal[name] = '%s_%s' % (name,Guid_Path.pop()[0])
+for guid,mpath in Guid_Path:
+retVal[(name,mpath)] = '%s_%s' % (name,guid)
 return retVal
 ## Expand * in build option key
 #
 #   @param  Options Options to be expanded
 #   @param  ToolDef Use specified ToolDef instead of full version.
--
2.20.1.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45803): https://edk2.groups.io/g/devel/message/45803
Mute This Topic: https://groups.io/mt/32895879/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] CryptoPkg: Fix coding style

[Zhang, Shenglei]

Hi All,

This patch has little impact. So I think it's ok to be checked in before code 
freeze.

Thanks,
Shenglei

> -Original Message-
> From: Wang, Jian J
> Sent: Friday, August 16, 2019 3:18 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Ye, Ting 
> Subject: RE: [PATCH 1/1] CryptoPkg: Fix coding style
> 
> 
> Reviewed-by: Jian J Wang 
> 
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Friday, August 16, 2019 2:54 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Ye, Ting 
> > Subject: [PATCH 1/1] CryptoPkg: Fix coding style
> >
> > Update attribute "Out" to "out".
> > The original "Out" can not pass ECC check.
> >
> > Cc: Jian Wang 
> > Cc: Ting Ye 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c | 2 +-
> >  CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c | 2 +-
> >  CryptoPkg/Include/Library/BaseCryptLib.h   | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > index f0fcef211d3f..3a827dadfcbd 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c
> > @@ -19,7 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >@param[in]   SaltSize Salt size in bytes.
> >@param[in]   Info Pointer to the application specific info.
> >@param[in]   InfoSize Info size in bytes.
> > -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> > +  @param[out]  Out  Pointer to buffer to receive hkdf value.
> >@param[in]   OutSize  Size of hkdf bytes to generate.
> >
> >@retval TRUE   Hkdf generated successfully.
> > diff --git a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> > b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> > index 73deb5bc3614..19d795a4cc16 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c
> > @@ -18,7 +18,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >@param[in]   SaltSize Salt size in bytes.
> >@param[in]   Info Pointer to the application specific info.
> >@param[in]   InfoSize Info size in bytes.
> > -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> > +  @param[out]  Out  Pointer to buffer to receive hkdf value.
> >@param[in]   OutSize  Size of hkdf bytes to generate.
> >
> >@retval TRUE   Hkdf generated successfully.
> > diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h
> > b/CryptoPkg/Include/Library/BaseCryptLib.h
> > index da32bb2444fd..8fe303a0b390 100644
> > --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> > +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> > @@ -3135,7 +3135,7 @@ RandomBytes (
> >@param[in]   SaltSize Salt size in bytes.
> >@param[in]   Info Pointer to the application specific info.
> >@param[in]   InfoSize Info size in bytes.
> > -  @param[Out]  Out  Pointer to buffer to receive hkdf value.
> > +  @param[out]  Out  Pointer to buffer to receive hkdf value.
> >@param[in]   OutSize  Size of hkdf bytes to generate.
> >
> >@retval TRUE   Hkdf generated successfully.
> > --
> > 2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45804): https://edk2.groups.io/g/devel/message/45804
Mute This Topic: https://groups.io/mt/32895950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Patch List for 201908 stable tag

[Liming Gao]

From: Gao, Liming [mailto:liming@intel.com]
Sent: Friday, August 16, 2019 3:59 PM
To: Laszlo Ersek (ler...@redhat.com) ; 
leif.lindh...@linaro.org; Kinney, Michael D ; 
af...@apple.com; Cetola, Stephano 
Cc: edk2-de...@lists.01.org
Subject: Patch List for 201908 stable tag

Hi Stewards and all:
  I collect current patch lists in devel mail list. Those patch contributors 
request to add them for 201908 stable tag. Because the time is very close to 
Soft Feature Freeze, I want to collect your feedback for below patches.

Feature List (those all have pass code review):
https://edk2.groups.io/g/devel/message/45734 [PATCH v6 0/5] Build cache 
enhancement
https://edk2.groups.io/g/devel/message/45707 [PATCH] UefiCpuPkg: Adding a new 
TSC library by using CPUID(0x15) TSC leaf
https://edk2.groups.io/g/devel/message/45503 [PATCH v2 1/1] MdePkg: Add 
STATIC_ASSERT macro

Bug List:
https://edk2.groups.io/g/devel/message/45794  [PATCH 1/1] CryptoPkg: Fix coding 
style
https://edk2.groups.io/g/devel/message/45791 [PATCH v2 1/1] 
ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left
https://edk2.groups.io/g/devel/message/45793 [Patch 1/1] BaseTools: Fixed issue 
of incorrect Module Unique Name
https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
write" mechanism
https://edk2.groups.io/g/devel/message/45317 [Patch] MdeModulePkg DxeCore: Fix 
for missing MAT update

Thanks
Liming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45805): https://edk2.groups.io/g/devel/message/45805
Mute This Topic: https://groups.io/mt/32896302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Soft Feature Freeze starts now for edk2-stable201908

[Liming Gao]

Hi, all
  Now, we enter into Soft Feature Freeze phase. In this phase, the feature 
under review will not be allowed to be pushed. The patch review can continue 
without break in edk2 community.
  If the patch is sent before Soft Feature Freeze, and plans to catch this 
stable tag, the patch contributor need reply to the mail list 
https://edk2.groups.io/g/devel/message/45805 and notify the community.
  If the patch is sent after Soft Feature Freeze, and plans to catch this 
stable tag, please add edk2-stable201908 key words in the patch title and BZ, 
so the community know this patch target and give the feedback.

Below is edk2-stable201908 tag planning.
  Date (00:00:00 UTC-8) Description
  2018-06-06 Beginning of development
  2019-08-16 Soft Feature Freeze
  2019-08-23 Hard Feature Freeze
  2019-08-30 Release

Thanks
Liming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45806): https://edk2.groups.io/g/devel/message/45806
Mute This Topic: https://groups.io/mt/32896331/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

[Vitaly Cheptsov via Groups.Io]

Donald, Michael,

Yes, I see that such a use is quite new and unexpected very well by know. I 
expanded my thoughts in a separate e-mail thread[1] as the consideration opened 
up an apparently separate problem partially related to the patch. Perhaps, we 
could continue the discussion there some time later.

Best regards,
Vitaly

[1] Determining TSC frequency programmatically
https://edk2.groups.io/g/devel/topic/determining_tsc_frequency/32891598?p=,,,100,0,0,0::recentpostdate%2Fsticky,,,100,2,0,32891598

> 16 авг. 2019 г., в 9:56, Kuo, Donald  написал(а):
> 
> Hi Vitaly,
>
> UEFI Application does be another scope. And regards your question on “a way 
> to dynamically determine the difference between Xeon client and server” … is 
> not in current design-in, for long term goal we could consider if there is 
> proper way to identify CPU SKU dynamically.
>
> Thanks for sharing your thought and it could be an enhancement on TimerLib in 
> the future. J
>
> Thanks,
> Donald
>   <>
>  <>From: Kinney, Michael D 
> Sent: Friday, August 16, 2019 12:23 AM
> To: devel@edk2.groups.io; vit9...@protonmail.com; Kuo, Donald 
> ; Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by 
> using CPUID(0x15) TSC leaf
>
> Vitaly,
>
> When implementing a UEFI Application, if you want maximum compatibility, you 
> should use UEFI Services/Protocols and minimize as many HW assumptions as 
> possible.
>
> I understand, especially for accurate time and clock related services, the 
> that the UEFI Specification defined Services/Protocols can be challenging to 
> use.
>
> When adding content that uses HW such as TSC or CPUID the UEFI App should be 
> implemented with good detection logic to know it is safe to use that HW, and 
> contain the fallback logic to use an alternate mechanism if the required HW 
> is not present.  This is a very different approach than some early FW 
> initialization code that can safely make some HW assumptions that helps keep 
> the FW init code small and efficient.  This does imply that different 
> libraries may be required for FW init and UEFI Applications.
>
> Thanks,
>
> Mike
>
> From: devel@edk2.groups.io  
> [mailto:devel@edk2.groups.io ] On Behalf Of 
> Vitaly Cheptsov via Groups.Io
> Sent: Thursday, August 15, 2019 5:10 AM
> To: Kuo, Donald mailto:donald@intel.com>>
> Cc: devel@edk2.groups.io 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by 
> using CPUID(0x15) TSC leaf
>
> Hi Donald,
> 
> Glad to hear it helped a little, and sorry for some outdated quotes.
> 
> Your clarification regarding model range is very helpful. Xeon W being client 
> and thus having client clock makes sense, though I must say it was quite not 
> obvious. I was referring to the same SDM table, and it would have been great 
> to have vertical range binding instead of the misleading CPUID.
> 
> With that, however, I still do not see a way to dynamically determine the 
> difference between Xeon client and server.
> 
> For us it is needed as we use TimerLib differently. For you TimerLib is a 
> part of BSP, so you face no issue statically setting the clock frequency as a 
> PCD. For us TimerLib is used as a part of an UEFI application compatible with 
> different hardware, and in fact not just Intel. We have such "generic 
> TimerLib" library, and to determine CPU frequency, as a fallback to CPUID 
> 15H, it relies on ACPI PM timer. This is not great for two reasons:
> - we have to maintain it ourselves, while we would have liked that be part of 
> EDK II with different vendors contributing to the project.
> - we still cannot find an obvious way to determine crystal clock when it is 
> not reported, in particular for Xeon W and Xeon Scalable case.
> 
> I guess this is now out of the scope of this patch and perhaps even this 
> exact library, but it will be helpful to hear relevant technical details on 
> the issue and opinions on such "generic TimerLib" library to later appear in 
> EDK II.
> 
> Best regards,
> Vitaly
> 
> 15 авг. 2019 г., в 11:40, Kuo, Donald  > написал(а):
>
> Hi Vitaly,
>
> Appreciated for reviewing very detail. And looks your captured some piece of 
> code is older version. And should be ok, I do got your point.
>
> Item #1
> -  I do missed RegEax error handling in case for 
> CpuidCoreClockCalculateTscFrequency () should return 0 and EFI_UNSUPPORTED. 
> AR: Will update it.
>
> Item #2:
> -  Actually the information is from SDM Table 18-85
> o   As we know CPUID signature could be hard to identify processor XTAL 
> frequency is? So we only check CPUID Leaf 0x15
> o   And the PCD will be defined depends on platform specific and during 
> project early development. Based on SDM, Intel processor for CPUID.15h EAX 
> and EBX is enumerated, but ECX could be possible not enumerated. So that is 
> why we based on  S

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Igor Mammedov]

On Thu, 15 Aug 2019 18:24:53 +0200
Paolo Bonzini  wrote:

> On 15/08/19 18:07, Igor Mammedov wrote:
> > Looking at Q35 code and Seabios SMM relocation as example, if I see it
> > right QEMU has:
> > - SMRAM is aliased from DRAM at 0xa
> > - and TSEG steals from the top of low RAM when configured
> > 
> > Now problem is that default SMBASE at 0x3 isn't backed by anything
> > in SMRAM address space and default SMI entry falls-through to the same
> > location in System address space.
> > 
> > The later is not trusted and entry into SMM mode will corrupt area + might
> > jump to 'random' SMI handler (hence save/restore code in Seabios).
> > 
> > Here is an idea, can we map a memory region at 0x3 in SMRAM address
> > space with relocation space/code reserved. It could be a part of TSEG
> > (so we don't have to invent ABI to configure that)?  
> 
> No, there could be real mode code using it.

My impression was that QEMU/KVM's SMM address space is accessible only from
CPU in SMM mode, so SMM CPU should access in-depended SMRAM at 0x3 in
SMM address space while not SMM CPUs (including real mode) should access
0x3 from normal system RAM.


> What we _could_ do is
> initialize SMBASE to 0xa, but I think it's better to not deviate too
> much from processor behavior (even if it's admittedly a 20-years legacy
> that doesn't make any sense).

Agreed, it's better to follow spec, that's one of the reasons why I was toying
with idea of using separate SMRAM at 0x3 mapped only in SMM address space.

Practically we would be following spec: SDM: 34.4 SMRAM
"
System logic can use the SMI acknowledge transaction or the assertion of the 
SMIACT# pin to decode accesses to
the SMRAM and redirect them (if desired) to specific SMRAM memory. If a 
separate RAM memory is used for
SMRAM, system logic should provide a programmable method of mapping the SMRAM 
into system memory space
when the processor is not in SMM. This mechanism will enable start-up 
procedures to initialize the SMRAM space
(that is, load the SMI handler) before executing the SMI handler during SMM.
"

Another benefit that gives us, is that we won't have to pull in
all existing CPUs into SMM (essentially another stop_machine) to
guarantee exclusive access to 0x3 in normal RAM.

> 
> Paolo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45811): https://edk2.groups.io/g/devel/message/45811
Mute This Topic: https://groups.io/mt/32852911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3] IntelSiliconPkg-Vtd: A new PMR interface

[Evelyn Wang]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1770

1) IOMMU PMR feature should be generic to support different hardware
architecture. Platforms may request no overlap between PMR regions
and system reserve memory. Create an interface to control PLMR/PHMR
regions. It allows silicon code to adjust PLMR/PHMR region base on
the project needs.

2) DisableDMAr Function Code Optimization
Optimize the flow to follow the VT-d spec requirements.

3) Renamed InitDmar() to InitGlobalVtd()
The oringal function name is misleading

4) A new GetVtdPmrAlignmentLib for silicon code to get
PMR alignment values.

Signed-off-by: Evelyn Wang 
Cc: Jenny Huang 
Cc: More Shih 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 

---
In V2:
1) Fixed the EFIAPI is missing in library API issue
2) Logs will be provided to make sure the backwards compatibility
3) Replaced BIT0 with EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
4) Renamed GetVtdPmrAlignmentLib to PeiGetVtdPmrAlignmentLib
5) Fixed the indent in IntelVTdPmrPei.c
6) Follow VTd spec to define the data type of the SYSTEM_MEM_INFO_HOB
   Applied few changes coordinately

---
In V3:
1) Fixed the EFIAPI is missing in library API issue
2) Fixed the S3 resume assert
---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
   |  30 +++---
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c 
   |   4 ++--
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c  
   |  71 
+--
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c  
   |  29 ++---
 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
 |   9 +
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.c
 | 167 
+++
 Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
   |   5 -
 Silicon/Intel/IntelSiliconPkg/Include/Library/PeiGetVtdPmrAlignmentLib.h   
   |  31 +++
 Silicon/Intel/IntelSiliconPkg/Include/SysMemInfoHob.h  
   |  25 +
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
   |  11 +--
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  
   |   3 ++-
 
Silicon/Intel/IntelSiliconPkg/Library/PeiGetVtdPmrAlignmentLib/PeiGetVtdPmrAlignmentLib.inf
   |  32 
 12 files changed, 379 insertions(+), 38 deletions(-)

diff --git a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c 
b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
index 22bf821d2b..699639ba88 100644
--- a/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/VtdReg.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -309,6 +309,8 @@ DisableDmar (
   UINTN Index;
   UINTN SubIndex;
   UINT32Reg32;
+  UINT32Status;
+  UINT32Command;
 
   for (Index = 0; Index < mVtdUnitNumber; Index++) {
 DEBUG((DEBUG_INFO, ">>DisableDmar() for engine [%d] \n", Index));
@@ -319,9 +321,31 @@ DisableDmar (
 FlushWriteBuffer (Index);
 
 //
-// Disable VTd
+// Disable Dmar
 //
-MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);
+//
+// Set TE (Translation Enable: BIT31) of Global command register to zero
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
+Command = (Status & ~B_GMCD_REG_TE);
+MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
Command);
+
+//
+// Poll on TE Status bit of Global status register to become zero
+//
+do {
+  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+} while ((Reg32 & B_GSTS_REG_TE) == B_GSTS_REG_TE);
+
+//
+// Set SRTP (Set Root Table Pointer: BIT30) of Global command register in 
order to update the root table pointerDisable VTd
+//
+Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);
+Status = (Reg32 & 0x96FF);   // Reset the one-shot bits
+Command = (Status | B_GMCD_REG_SRTP);
+MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG,

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Paolo Bonzini]

On 15/08/19 17:00, Laszlo Ersek wrote:
> On 08/14/19 16:04, Paolo Bonzini wrote:
>> On 14/08/19 15:20, Yao, Jiewen wrote:
 - Does this part require a new branch somewhere in the OVMF SEC code?
   How do we determine whether the CPU executing SEC is BSP or
   hot-plugged AP?
>>> [Jiewen] I think this is blocked from hardware perspective, since the first 
>>> instruction.
>>> There are some hardware specific registers can be used to determine if the 
>>> CPU is new added.
>>> I don’t think this must be same as the real hardware.
>>> You are free to invent some registers in device model to be used in OVMF 
>>> hot plug driver.
>>
>> Yes, this would be a new operation mode for QEMU, that only applies to
>> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
>> fact it doesn't reply to anything at all.
>>
 - How do we tell the hot-plugged AP where to start execution? (I.e. that
   it should execute code at a particular pflash location.)
>>> [Jiewen] Same real mode reset vector at :FFF0.
>>
>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
>> QEMU.  The AP does not start execution at all when it is unplugged, so
>> no cache-as-RAM etc.
>>
>> We only need to modify QEMU so that hot-plugged APIs do not reply to
>> INIT/SIPI/SMI.
>>
>>> I don’t think there is problem for real hardware, who always has CAR.
>>> Can QEMU provide some CPU specific space, such as MMIO region?
>>
>> Why is a CPU-specific region needed if every other processor is in SMM
>> and thus trusted.
> 
> I was going through the steps Jiewen and Yingwen recommended.
> 
> In step (02), the new CPU is expected to set up RAM access. In step
> (03), the new CPU, executing code from flash, is expected to "send board
> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> message." For that action, the new CPU may need a stack (minimally if we
> want to use C function calls).
> 
> Until step (03), there had been no word about any other (= pre-plugged)
> CPUs (more precisely, Jiewen even confirmed "No impact to other
> processors"), so I didn't assume that other CPUs had entered SMM.
> 
> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> as I can. I'm still very confused. If you have a better understanding,
> could you please write up the 15-step process from the thread starter
> again, with all QEMU customizations applied? Such as, unnecessary steps
> removed, and platform specifics filled in.

Sure.

(01a) QEMU: create new CPU.  The CPU already exists, but it does not
 start running code until unparked by the CPU hotplug controller.

(01b) QEMU: trigger SCI

(02-03) no equivalent

(04) Host CPU: (OS) execute GPE handler from DSDT

(05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
 will not enter CPU because SMI is disabled)

(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
 rebase code.

(07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
 new CPU

(07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.

(08a) New CPU: (Low RAM) Enter protected mode.

(08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop.

(09) Host CPU: (SMM) Send SMI to the new CPU only.

(10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to
 TSEG.

(11) Host CPU: (SMM) Restore 38000.

(12) Host CPU: (SMM) Update located data structure to add the new CPU
 information. (This step will involve CPU_SERVICE protocol)

(13) New CPU: (Flash) do whatever other initialization is needed

(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.

(15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in..


In other words, the cache-as-RAM phase of 02-03 is replaced by the
INIT-SIPI-SIPI sequence of 07b-08a-08b.


>> The QEMU DSDT could be modified (when secure boot is in effect) to OUT
>> to 0xB2 when hotplug happens.  It could write a well-known value to
>> 0xB2, to be read by an SMI handler in edk2.
> 
> I dislike involving QEMU's generated DSDT in anything SMM (even
> injecting the SMI), because the AML interpreter runs in the OS.
> 
> If a malicious OS kernel is a bit too enlightened about the DSDT, it
> could willfully diverge from the process that we design. If QEMU
> broadcast the SMI internally, the guest OS could not interfere with that.
> 
> If the purpose of the SMI is specifically to force all CPUs into SMM
> (and thereby force them into trusted state), then the OS would be
> explicitly counter-interested in carrying out the AML operations from
> QEMU's DSDT.

But since the hotplug controller would only be accessible from SMM,
there would be no other way to invoke it than to follow the DSDT's
instruction and write to 0xB2.  FWIW, real hardware also has plenty of
0xB2 writes in the DSDT or in APEI tables (e.g. for persistent store
access).

Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45812): https://edk2.group

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Paolo Bonzini]

On 16/08/19 04:46, Yao, Jiewen wrote:
> Comment below:
> 
> 
>> -Original Message-
>> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
>> Sent: Friday, August 16, 2019 12:21 AM
>> To: Laszlo Ersek ; devel@edk2.groups.io; Yao, Jiewen
>> 
>> Cc: edk2-rfc-groups-io ; qemu devel list
>> ; Igor Mammedov ;
>> Chen, Yingwen ; Nakajima, Jun
>> ; Boris Ostrovsky ;
>> Joao Marcal Lemos Martins ; Phillip Goerl
>> 
>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>>
>> On 15/08/19 17:00, Laszlo Ersek wrote:
>>> On 08/14/19 16:04, Paolo Bonzini wrote:
 On 14/08/19 15:20, Yao, Jiewen wrote:
>> - Does this part require a new branch somewhere in the OVMF SEC
>> code?
>>   How do we determine whether the CPU executing SEC is BSP or
>>   hot-plugged AP?
> [Jiewen] I think this is blocked from hardware perspective, since the 
> first
>> instruction.
> There are some hardware specific registers can be used to determine if
>> the CPU is new added.
> I don’t think this must be same as the real hardware.
> You are free to invent some registers in device model to be used in
>> OVMF hot plug driver.

 Yes, this would be a new operation mode for QEMU, that only applies to
 hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
 fact it doesn't reply to anything at all.

>> - How do we tell the hot-plugged AP where to start execution? (I.e.
>> that
>>   it should execute code at a particular pflash location.)
> [Jiewen] Same real mode reset vector at :FFF0.

 You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
 QEMU.  The AP does not start execution at all when it is unplugged, so
 no cache-as-RAM etc.

 We only need to modify QEMU so that hot-plugged APIs do not reply to
 INIT/SIPI/SMI.

> I don’t think there is problem for real hardware, who always has CAR.
> Can QEMU provide some CPU specific space, such as MMIO region?

 Why is a CPU-specific region needed if every other processor is in SMM
 and thus trusted.
>>>
>>> I was going through the steps Jiewen and Yingwen recommended.
>>>
>>> In step (02), the new CPU is expected to set up RAM access. In step
>>> (03), the new CPU, executing code from flash, is expected to "send board
>>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
>>> message." For that action, the new CPU may need a stack (minimally if we
>>> want to use C function calls).
>>>
>>> Until step (03), there had been no word about any other (= pre-plugged)
>>> CPUs (more precisely, Jiewen even confirmed "No impact to other
>>> processors"), so I didn't assume that other CPUs had entered SMM.
>>>
>>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
>>> as I can. I'm still very confused. If you have a better understanding,
>>> could you please write up the 15-step process from the thread starter
>>> again, with all QEMU customizations applied? Such as, unnecessary steps
>>> removed, and platform specifics filled in.
>>
>> Sure.
>>
>> (01a) QEMU: create new CPU.  The CPU already exists, but it does not
>>  start running code until unparked by the CPU hotplug controller.
>>
>> (01b) QEMU: trigger SCI
>>
>> (02-03) no equivalent
>>
>> (04) Host CPU: (OS) execute GPE handler from DSDT
>>
>> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
>>  will not enter CPU because SMI is disabled)
>>
>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>>  rebase code.
>>
>> (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
>>  new CPU
>>
>> (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
> [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no
> restriction that INIT/SIPI/SIPI can only be sent in SMM.

All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded
before 07a, so this is okay.

However I do see a problem, because a PCI device's DMA could overwrite
0x38000 between (06) and (10) and hijack the code that is executed in
SMM.  How is this avoided on real hardware?  By the time the new CPU
enters SMM, it doesn't run off cache-as-RAM anymore.

Paolo

>> (08a) New CPU: (Low RAM) Enter protected mode.
>
> [Jiewen] NOTE: The new CPU still cannot use any physical memory, because
> the INIT/SIPI/SIPI may be sent by malicious CPU in non-SMM environment.
> 
>> (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop.
>>
>> (09) Host CPU: (SMM) Send SMI to the new CPU only.
>>
>> (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to
>>  TSEG.
>>
>> (11) Host CPU: (SMM) Restore 38000.
>>
>> (12) Host CPU: (SMM) Update located data structure to add the new CPU
>>  information. (This step will involve CPU_SERVICE protocol)
>>
>> (13) New CPU: (Flash) do whatever other initialization is needed
>>
>> (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.
>>
>> (15) Host CPU: (OS) Sen

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Paolo Bonzini]

On 15/08/19 18:07, Igor Mammedov wrote:
> Looking at Q35 code and Seabios SMM relocation as example, if I see it
> right QEMU has:
> - SMRAM is aliased from DRAM at 0xa
> - and TSEG steals from the top of low RAM when configured
> 
> Now problem is that default SMBASE at 0x3 isn't backed by anything
> in SMRAM address space and default SMI entry falls-through to the same
> location in System address space.
> 
> The later is not trusted and entry into SMM mode will corrupt area + might
> jump to 'random' SMI handler (hence save/restore code in Seabios).
> 
> Here is an idea, can we map a memory region at 0x3 in SMRAM address
> space with relocation space/code reserved. It could be a part of TSEG
> (so we don't have to invent ABI to configure that)?

No, there could be real mode code using it.  What we _could_ do is
initialize SMBASE to 0xa, but I think it's better to not deviate too
much from processor behavior (even if it's admittedly a 20-years legacy
that doesn't make any sense).

Paolo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45808): https://edk2.groups.io/g/devel/message/45808
Mute This Topic: https://groups.io/mt/32852911/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 1/2] Platforms/RPi3: Improve debug output in FdtDxe

[Pete Batard]

Harmonize messages, avoid acronyms and provide human readable status codes.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 24 ++--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
index c84e5b2767e2..da99ef9535c8 100644
--- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
@@ -383,12 +383,12 @@ FdtDxeInitialize (
  * Have FDT passed via config.txt.
  */
 FdtSize = fdt_totalsize (FdtImage);
-DEBUG ((DEBUG_INFO, "DTB passed via config.txt of 0x%lx bytes\n", 
FdtSize));
+DEBUG ((DEBUG_INFO, "Device Tree passed via config.txt (0x%lx bytes)\n", 
FdtSize));
 Status = EFI_SUCCESS;
   } else {
 Internal = TRUE;
-DEBUG ((DEBUG_INFO, "No/bad FDT at %p (%a), trying internal DTB...\n",
-  FdtImage, fdt_strerror (Retval)));
+DEBUG ((DEBUG_INFO, "No/Bad Device Tree found at address 0x%p (%a), "
+  "trying internal one...\n", FdtImage, fdt_strerror (Retval)));
 Status = GetSectionFromAnyFv (&gRaspberryPiFdtFileGuid, EFI_SECTION_RAW, 0,
&FdtImage, &FdtSize);
 if (Status == EFI_SUCCESS) {
@@ -399,7 +399,7 @@ FdtDxeInitialize (
   }
 
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "Failed to locate device tree: %r\n", Status));
+DEBUG ((DEBUG_ERROR, "Failed to locate Device Tree: %r\n", Status));
 return Status;
   }
 
@@ -410,7 +410,7 @@ FdtDxeInitialize (
   Status = gBS->AllocatePages (AllocateAnyPages, EfiBootServicesData,
   EFI_SIZE_TO_PAGES (FdtSize), 
(EFI_PHYSICAL_ADDRESS*)&mFdtImage);
   if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "Failed to allocate new device tree: %r\n", Status));
+DEBUG ((DEBUG_ERROR, "Failed to allocate Device Tree: %r\n", Status));
 return Status;
   }
 
@@ -419,27 +419,27 @@ FdtDxeInitialize (
 
   Status = SanitizePSCI ();
   if (EFI_ERROR (Status)) {
-Print (L"Failed to sanitize PSCI (error %d)\n", Status);
+Print (L"Failed to sanitize PSCI: %r\n", Status);
   }
 
   Status = CleanMemoryNodes ();
   if (EFI_ERROR (Status)) {
-Print (L"Failed to clean memory nodes (error %d)\n", Status);
+Print (L"Failed to clean memory nodes: %r\n", Status);
   }
 
   Status = CleanSimpleFramebuffer ();
   if (EFI_ERROR (Status)) {
-Print (L"Failed to clean frame buffer (error %d)\n", Status);
+Print (L"Failed to clean frame buffer: %r\n", Status);
   }
 
   Status = FixEthernetAliases ();
   if (EFI_ERROR (Status)) {
-Print (L"Failed to fix ethernet aliases (error %d)\n", Status);
+Print (L"Failed to fix ethernet aliases: %r\n", Status);
   }
 
   Status = UpdateMacAddress ();
   if (EFI_ERROR (Status)) {
-Print (L"Failed to update MAC address (error %d)\n", Status);
+Print (L"Failed to update MAC address: %r\n", Status);
   }
 
   if (Internal) {
@@ -448,11 +448,11 @@ FdtDxeInitialize (
  */
 Status = UpdateBootArgs ();
 if (EFI_ERROR (Status)) {
-  Print (L"Failed to update boot arguments (error %d)\n", Status);
+  Print (L"Failed to update boot arguments: %r\n", Status);
 }
   }
 
-  DEBUG ((DEBUG_INFO, "Installed FDT is at %p\n", mFdtImage));
+  DEBUG ((DEBUG_INFO, "Installed Device Tree at address 0x%p\n", mFdtImage));
   Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mFdtImage);
   ASSERT_EFI_ERROR (Status);
 
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45814): https://edk2.groups.io/g/devel/message/45814
Mute This Topic: https://groups.io/mt/32896986/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 0/2] Platforms/RPi3: Device Tree driver improvements

[Pete Batard]

Changes from v1:
- Break down DEBUB output embellishments from the other code changes.
- Use GUIDs that are explicitly named after each platform/model rather than
  generic ones.
- Drop the use of a GUID table/index and use a single GUID variable instead.
- Add additional fallback in case the required internal Device Tree cannot
  be located (e.g. missing from the FDF).
- Ensures that all of the Device Tree selection and fallback can be set up
  in the .dec (FdtDxe reusability).
- Add premilinary Raspberry Pi 4 support (FdtDxe reusability).

Note: Since the changes required to support the Raspberry Pi 4 are a direct
byproduct of the changes required for multiple Device Tree support, I did
not feel the need to break them down into a separate patch.

Pete Batard (2):
  Platforms/RPi3: Improve debug output in FdtDxe
  Platforms/RPi3: Add multiple embedded Device Tree selection

 Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c   | 78 +++-
 Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf |  5 +-
 Platform/RaspberryPi/RPi3/RPi3.dec  |  8 +-
 Platform/RaspberryPi/RPi3/RPi3.fdf  |  6 +-
 4 files changed, 77 insertions(+), 20 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45813): https://edk2.groups.io/g/devel/message/45813
Mute This Topic: https://groups.io/mt/32896985/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 2/2] Platforms/RPi3: Add multiple embedded Device Tree selection

[Pete Batard]

The Raspberry Pi 3 platform currently has 2 different models, each with a
different Device Tree. Rather than embedding a single one, and requiring
users to manually provide the other, this patch ensures that we now embed
both and and serve the relevant one at runtime.

This patch also adds support for the Raspberry Pi 4 in FdtDxe.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c   | 56 +---
 Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf |  5 +-
 Platform/RaspberryPi/RPi3/RPi3.dec  |  8 ++-
 Platform/RaspberryPi/RPi3/RPi3.fdf  |  6 ++-
 4 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
index da99ef9535c8..45ffe2e394a2 100644
--- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
@@ -366,9 +366,11 @@ FdtDxeInitialize (
   )
 {
   EFI_STATUS Status;
+  EFI_GUID   *FdtGuid;
   VOID   *FdtImage;
   UINTN  FdtSize;
   INT32  Retval;
+  UINT32 BoardRevision;
   BOOLEANInternal;
 
   Status = gBS->LocateProtocol (&gRaspberryPiFirmwareProtocolGuid, NULL,
@@ -386,16 +388,58 @@ FdtDxeInitialize (
 DEBUG ((DEBUG_INFO, "Device Tree passed via config.txt (0x%lx bytes)\n", 
FdtSize));
 Status = EFI_SUCCESS;
   } else {
+/*
+ * Use one of the embedded FDT's.
+ */
 Internal = TRUE;
 DEBUG ((DEBUG_INFO, "No/Bad Device Tree found at address 0x%p (%a), "
-  "trying internal one...\n", FdtImage, fdt_strerror (Retval)));
-Status = GetSectionFromAnyFv (&gRaspberryPiFdtFileGuid, EFI_SECTION_RAW, 0,
-   &FdtImage, &FdtSize);
-if (Status == EFI_SUCCESS) {
-  if (fdt_check_header (FdtImage) != 0) {
-Status = EFI_INCOMPATIBLE_VERSION;
+  "looking up internal one...\n", FdtImage, fdt_strerror (Retval)));
+/*
+ * Query the board revision to differentiate between models.
+ */
+Status = mFwProtocol->GetModelRevision (&BoardRevision);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to get board type: %r\n", Status));
+  DEBUG ((DEBUG_INFO, "Using default internal Device Tree\n"));
+  FdtGuid = &gRaspberryPiDefaultFdtGuid;
+} else {
+  // 
www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
+  switch ((BoardRevision >> 4) & 0xFF) {
+  case 0x08:
+DEBUG ((DEBUG_INFO, "Using Raspberry Pi 3 Model B internal Device 
Tree\n"));
+FdtGuid = &gRaspberryPi3ModelBFdtGuid;
+break;
+  case 0x0D:
+DEBUG ((DEBUG_INFO, "Using Raspberry Pi 3 Model B+ internal Device 
Tree\n"));
+FdtGuid = &gRaspberryPi3ModelBPlusFdtGuid;
+break;
+  case 0x11:
+DEBUG ((DEBUG_INFO, "Using Raspberry Pi 4 Model B internal Device 
Tree\n"));
+FdtGuid = &gRaspberryPi4ModelBFdtGuid;
+break;
+  default:
+DEBUG ((DEBUG_INFO, "Using default internal Device Tree\n"));
+FdtGuid = &gRaspberryPiDefaultFdtGuid;
+break;
   }
 }
+do {
+  Status = GetSectionFromAnyFv (FdtGuid, EFI_SECTION_RAW, 0, &FdtImage, 
&FdtSize);
+  if (Status == EFI_SUCCESS) {
+if (fdt_check_header (FdtImage) != 0) {
+  Status = EFI_INCOMPATIBLE_VERSION;
+}
+  }
+  // No retry needed if we are successful or are dealing with the default 
Fdt.
+  if ( (Status == EFI_SUCCESS) ||
+   (CompareGuid (FdtGuid, &gRaspberryPiDefaultFdtGuid)) )
+break;
+  // Otherwise, try one more time with the default Fdt. An example of this
+  // is if we detected a non-default Fdt, that isn't included in the FDF.
+  DEBUG ((DEBUG_INFO, "Internal Device Tree was not found for this 
platform, "
+"falling back to default...\n"));
+  FdtGuid = &gRaspberryPiDefaultFdtGuid;
+} while (1);
   }
 
   if (EFI_ERROR (Status)) {
diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf 
b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf
index 5b0b1a09f374..570b05b62564 100644
--- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf
+++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf
@@ -35,7 +35,10 @@ [LibraryClasses]
 
 [Guids]
   gFdtTableGuid
-  gRaspberryPiFdtFileGuid
+  gRaspberryPi3ModelBFdtGuid
+  gRaspberryPi3ModelBPlusFdtGuid
+  gRaspberryPi4ModelBFdtGuid
+  gRaspberryPiDefaultFdtGuid
 
 [Protocols]
   gRaspberryPiFirmwareProtocolGuid  ## CONSUMES
diff --git a/Platform/RaspberryPi/RPi3/RPi3.dec 
b/Platform/RaspberryPi/RPi3/RPi3.dec
index 22de439fde8f..d2a813417648 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dec
+++ b/Platform/RaspberryPi/RPi3/RPi3.dec
@@ -24,9 +24,15 @@ [Protocols]
 
 [Guids]
   gRaspberryPiTokenSpaceGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 0x63, 
0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}
-  gRaspberryPiFdtFileGuid = {0xDF5DA223, 0x1D27, 0x47C3, { 0x8D, 0x1B, 0x9A, 

Re: [edk2-devel] [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global pointer before use

[Krzysztof Koch]

Hi Zhichao,

I think you're right. I will submit a v2 patch that minimizes the amount of 
pointer validation required for parsing the remaining tables.

Kind regards,

Krzysztof

-Original Message-
From: Gao, Zhichao  
Sent: Friday, August 16, 2019 8:35
To: Krzysztof Koch ; devel@edk2.groups.io
Cc: Carsey, Jaben ; Ni, Ray ; Sami 
Mujawar ; Matteo Carlini ; nd 

Subject: RE: [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global pointer 
before use

For FadtMinorRevision and X_DsdtAddress, I don't think they are required 
section. Maybe we should consider check the length before check them. As I 
know, the OVMF's FACP table doesn't have the section after flag.

Thanks,
Zhichao

> -Original Message-
> From: Krzysztof Koch [mailto:krzysztof.k...@arm.com]
> Sent: Thursday, August 15, 2019 9:11 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> ; Gao, Zhichao ; 
> sami.muja...@arm.com; matteo.carl...@arm.com; n...@arm.com
> Subject: [PATCH v1 03/11] ShellPkg: acpiview: FADT: Validate global 
> pointer before use
> 
> Check if global pointers have been successfully updated before they 
> are used for further table parsing.
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Notes:
> v1:
> - Test against NULL pointers [Krzysztof]
> 
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
> | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> index
> e40c9ef8ee4b3285faf8c6edf3cb6236ee367397..e218e45926abced1096e75441
> e22108db7a3a811 100644
> ---
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.
> c
> +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtPars
> +++ er.c
> @@ -203,6 +203,20 @@ ParseAcpiFadt (
>  PARSER_PARAMS (FadtParser)
>  );
> 
> +  // Check if the values used to control the parsing logic have been 
> + // successfully read.
> +  if ((DsdtAddress == NULL)   ||
> +  (FadtMinorRevision == NULL) ||
> +  (X_DsdtAddress == NULL)) {
> +IncrementErrorCount ();
> +Print (
> +  L"ERROR: Insufficient table length. AcpiTableLength = %d. " \
> +L"FADT parsing aborted.\n",
> +  AcpiTableLength
> +  );
> +return;
> +  }
> +
>if (Trace) {
>  Print (L"\nSummary:\n");
>  PrintFieldName (2, L"FADT Version");
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45816): https://edk2.groups.io/g/devel/message/45816
Mute This Topic: https://groups.io/mt/32886566/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue of incorrect Module Unique Name

[Liming Gao]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Feng, Bob C
> Sent: Friday, August 16, 2019 3:55 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Shi, Steven 
> Subject: RE: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue of incorrect 
> Module Unique Name
> 
> This patch is to fix a critical BaseTools regression bug and it need to be 
> merged to edk2 master for the coming stable tag.
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bob Feng
> Sent: Friday, August 16, 2019 2:38 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Shi, Steven ; 
> Feng, Bob C 
> Subject: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue of incorrect Module 
> Unique Name
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2088
> If there are more than one override instance for a same module, the Module 
> Unique Name is generated incorrectly.
> 
> Cc: Liming Gao 
> Cc: Steven Shi 
> Signed-off-by: Bob Feng 
> ---
>  BaseTools/Source/Python/AutoGen/ModuleAutoGen.py   | 2 +-
>  BaseTools/Source/Python/AutoGen/PlatformAutoGen.py | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> index 9ecf5c2dbe0c..076ce0e39c37 100644
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> @@ -293,11 +293,11 @@ class ModuleAutoGen(AutoGen):
>  @property
>  def UniqueBaseName(self):
>  ModuleNames = self.DataPipe.Get("M_Name")
>  if not ModuleNames:
>  return self.Name
> -return ModuleNames.get(self.Name,self.Name)
> +return ModuleNames.get((self.Name,self.MetaFile),self.Name)
> 
>  # Macros could be used in build_rule.txt (also Makefile)
>  @cached_property
>  def Macros(self):
>  return OrderedDict((
> diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> index 4abfc6c29d1b..dd629ba2fac2 100644
> --- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
> @@ -1364,18 +1364,19 @@ class PlatformAutoGen(AutoGen):
>  ModuleNameDict[unique_base_name].append(Module.MetaFile)
>  if Module.BaseName not in UniqueName:
>  UniqueName[Module.BaseName] = set()
>  
> UniqueName[Module.BaseName].add((self.ModuleGuid(Module),Module.MetaFile))
>  for module_paths in ModuleNameDict.values():
> -if len(module_paths) > 1 and len(set(module_paths))>1:
> +if len(set(module_paths))>1:
>  samemodules = list(set(module_paths))
>  EdkLogger.error("build", FILE_DUPLICATED, 'Modules have same 
> BaseName and FILE_GUID:\n'
>  '  %s\n  %s' % (samemodules[0], 
> samemodules[1]))
>  for name in UniqueName:
>  Guid_Path = UniqueName[name]
>  if len(Guid_Path) > 1:
> -retVal[name] = '%s_%s' % (name,Guid_Path.pop()[0])
> +for guid,mpath in Guid_Path:
> +retVal[(name,mpath)] = '%s_%s' % (name,guid)
>  return retVal
>  ## Expand * in build option key
>  #
>  #   @param  Options Options to be expanded
>  #   @param  ToolDef Use specified ToolDef instead of full version.
> --
> 2.20.1.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45817): https://edk2.groups.io/g/devel/message/45817
Mute This Topic: https://groups.io/mt/32895879/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

[Michael D Kinney]

Jordan,

It is not a typo.

Andrew generated the XCODE specific changes, so they have 
been tested by him.  I have also reviewed and tested the XCODE
changes and verified that all 6 combinations build and boot
to shell (IA32/X64 for RELEASE/DEBUG/NOOPT). Since they are
all related to making EmulatorPkg work, we decided to fold
them into the same patch set that was already being reviewed.

I also verified build and boot to shell for 6 combinations
on GCC5 (IA32/X64 for RELEASE/DEBUG/NOOPT) and the 12
combinations of VS2015/VS2017, IA323/X64, RELEASE/DEBUG/NOOPT.

I have been working on some CI experiments using Azure Pipelines.
Here is a pointer to the build logs for all the combinations 
listed above.

https://dev.azure.com/mikekinney/edk2-ci/_build/results?buildId=312

Mike

> -Original Message-
> From: Justen, Jordan L
> Sent: Friday, August 16, 2019 12:41 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Ni, Ray ; Andrew Fish
> 
> Subject: Re: [Patch V4 06/10] EmulatorPkg: Fix XCODE5
> lldb issues
> 
> On 2019-08-15 19:14:33, Michael D Kinney wrote:
> > Fix scripts to support lldb symbolic debugging when
> using XCODE5 tool
> > chain.
> >
> > Cc: Jordan Justen 
> > Cc: Ray Ni 
> > Cc: Michael D Kinney 
> > Signed-off-by: Andrew Fish 
> 
> Is this a Cc/Signed-off-by typo? (See also, patches 7-
> 10).
> 
> This makes me wonder if you are taking advantage of the
> git commit -s switch to add your Signed-off-by.
> 
> Also, I'm wondering if you are taking advantage of git-
> send-email automatically Cc'ing the addresses you
> listed in the commit message.
> (I thought it Cc'd for the author and Cc tags, but I
> wasn't sure about the Signed-off-by tag, and yet I see
> Andrew was Cc'd.)
> 
> There's a couple long lines below. You could use \ at
> the end of the line to split the .sh line. I think the
> cd can be a separate command in a shell script. (Not in
> make)
> 
> I hope someone that uses the XCODE toolchain could
> review/check the XCODE patches.
> 
> -Jordan
> 
> > ---
> >  EmulatorPkg/Unix/lldbefi.py |  8 +---
> >  EmulatorPkg/build.sh| 17 ++---
> >  2 files changed, 7 insertions(+), 18 deletions(-)
> >
> > diff --git a/EmulatorPkg/Unix/lldbefi.py
> b/EmulatorPkg/Unix/lldbefi.py
> > index 218326b8cb..099192d8b5 100755
> > --- a/EmulatorPkg/Unix/lldbefi.py
> > +++ b/EmulatorPkg/Unix/lldbefi.py
> > @@ -346,6 +346,7 @@ def TypePrintFormating(debugger):
> >  debugger.HandleCommand("type summary add CHAR8 -
> -python-function lldbefi.CHAR8_TypeSummary")
> >  debugger.HandleCommand('type summary add --regex
> "CHAR8
> > \[[0-9]+\]" --python-function
> lldbefi.CHAR8_TypeSummary')
> >
> > +debugger.HandleCommand('setting set frame-format
> "frame
> > + #${frame.index}: ${frame.pc}{
> > +
> ${module.file.basename}{:${function.name}()${function.p
> c-offset}}}{
> > + at ${line.file.fullpath}:${line.number}}\n"')
> >
> >  gEmulatorBreakWorkaroundNeeded = True
> >
> > @@ -381,15 +382,16 @@ def
> LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
> >  Error = lldb.SBError()
> >  FileNamePtr = frame.FindVariable
> ("FileName").GetValueAsUnsigned()
> >  FileNameLen = frame.FindVariable
> > ("FileNameLength").GetValueAsUnsigned()
> > +
> >  FileName =
> frame.thread.process.ReadCStringFromMemory
> (FileNamePtr, FileNameLen, Error)
> >  if not Error.Success():
> >  print "!ReadCStringFromMemory() did not find
> a %d byte C string at %x" % (FileNameLen, FileNamePtr)
> >  # make breakpoint command contiue
> > -frame.GetThread().GetProcess().Continue()
> > +return False
> >
> >  debugger = frame.thread.process.target.debugger
> >  if frame.FindVariable
> ("AddSymbolFlag").GetValueAsUnsigned() == 1:
> > -LoadAddress = frame.FindVariable
> ("LoadAddress").GetValueAsUnsigned()
> > +LoadAddress = frame.FindVariable
> > + ("LoadAddress").GetValueAsUnsigned() - 0x240
> >
> >  debugger.HandleCommand ("target modules add
> %s" % FileName)
> >  print "target modules load --slid 0x%x %s" %
> (LoadAddress,
> > FileName) @@ -405,7 +407,7 @@ def
> LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
> >  print "!lldb.target.RemoveModule
> (%s) FAILED" %
> > SBModule
> >
> >  # make breakpoint command contiue
> > -frame.thread.process.Continue()
> > +return False
> >
> >  def GuidToCStructStr (guid, Name=False):
> >#
> > diff --git a/EmulatorPkg/build.sh
> b/EmulatorPkg/build.sh index
> > 60056e1b6c..35912a7775 100755
> > --- a/EmulatorPkg/build.sh
> > +++ b/EmulatorPkg/build.sh
> > @@ -209,21 +209,8 @@ fi
> >  if [[ "$RUN_EMULATOR" == "yes" ]]; then
> >case `uname` in
> >  Darwin*)
> > -  #
> > -  # On Darwin we can't use dlopen, so we have to
> load the real PE/COFF images.
> > -  # This .gdbinit script sets a breakpoint that
> loads symbols for the PE/COFFEE
> > -  # images that get loaded in Host
> > -  #
> > -  if [

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

[Laszlo Ersek]

On 08/14/19 17:55, Gao, Liming wrote:

> If Platform PEIM doesn't build HOB, DxeIpl will not build HOB, 

My reading of the code is the opposite. If the platform PEIM does not build the 
HOB, then the DXE IPL PEIM will attempt to build the HOB, from the UEFI 
variable.

At commit caa7d3a896f6, in file "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c", 
function DxeLoadCore(), we have:

   363if (GetFirstGuidHob ((CONST EFI_GUID 
*)&gEfiMemoryTypeInformationGuid) == NULL) {
   364  //
   365  // Don't build GuidHob if GuidHob has been installed.
   366  //
   367  Status = PeiServicesLocatePpi (
   368 &gEfiPeiReadOnlyVariable2PpiGuid,
   369 0,
   370 NULL,
   371 (VOID **)&Variable
   372 );
   373  if (!EFI_ERROR (Status)) {
   374DataSize = sizeof (MemoryData);
   375Status = Variable->GetVariable (
   376 Variable,
   377 EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
   378 &gEfiMemoryTypeInformationGuid,
   379 NULL,
   380 &DataSize,
   381 &MemoryData
   382 );
   383if (!EFI_ERROR (Status) && 
ValidateMemoryTypeInfoVariable(MemoryData, DataSize)) {
   384  //
   385  // Build the GUID'd HOB for DXE
   386  //
   387  BuildGuidDataHob (
   388&gEfiMemoryTypeInformationGuid,
   389MemoryData,
   390DataSize
   391);
   392}
   393  }
   394}

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45819): https://edk2.groups.io/g/devel/message/45819
Mute This Topic: https://groups.io/mt/32821535/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] static data in dxe_runtime modules

[Laszlo Ersek]

On 08/14/19 18:26, Andrew Fish wrote:
> 
> 
>> On Aug 14, 2019, at 8:16 AM, Laszlo Ersek  wrote:
>>
>> On 08/13/19 13:23, Roman Kagan wrote:
>>> On Tue, Aug 13, 2019 at 11:10:27AM +0200, Laszlo Ersek wrote:
 On 08/12/19 20:43, Roman Kagan wrote:
> On Fri, Aug 09, 2019 at 04:07:00PM +, Roman Kagan via Groups.Io wrote:
>> On Thu, Aug 08, 2019 at 07:39:14PM +0200, Laszlo Ersek wrote:
>>> On 08/07/19 19:41, Andrew Fish wrote:
> On Aug 7, 2019, at 10:29 AM, Laszlo Ersek  wrote:
> On 08/05/19 12:18, Roman Kagan wrote:
>> On Sat, Aug 03, 2019 at 04:03:04AM +0200, Laszlo Ersek via Groups.Io 
>> wrote:
>>> On 08/01/19 21:16, Roman Kagan wrote:
> I'm convinced that OpenSSL needs to expose a new API for this 
> particular
> problem.
>>
>> Since, as you point out below, the problem only affects the essentially
>> broken configuration (SECURE_BOOT_ENABLE && !SMM_REQUIRE), I'm fine with
>> saving time and effort and sticking to the hack-ish approach proposed in
>> the bugzilla issue, which is to iterate over "thread-local" pointers and
>> EfiConvertPointer() on each.  (As long as it fixes the problem of
>> course; I'll test and report back.)
>
> It doesn't :(  It just gets slightly further and hits another static
> pointer variable which is not part of the thread-local array:
>
> ...
>  Pkcs7Verify
>EVP_add_digest
>  OBJ_NAME_add
>
> this one uses a few static pointer variables that are also initialized
> on demand and become stale upon SetVirtualAddressMap().

 So it looks like the issue can't be solved without making OpenSSL aware
 of this use case.
>>>
>>> Is reloading the module from scratch ruled out completely?
>>
>> Not my place to say authoritatively, but:
>> - it would be a first, as much as I can say,
>> - it would duplicate (in purpose) an existing facility.
>>
>> Personally I'd expect it to be rejected, but it's not up to me. If
>> you're willing to "build one to (possibly) throw away", that could be
>> the most direct way to get authoritative (= maintainer) feedback.
>>
> 
> Laszlo,
> 
> I thunk it is more likely to get rejected as it would not work. 
> 
> Every runtime driver I've every seen usually works like this:
> 1) Loads as an EFI driver and uses EFI Boot Services in its constructor (gBS, 
> gDS, AllocatePool(), etc.)
> 2) You use the EFI Boot Service to register the ExitBootServices Event. 
> 3) SetVirtualAddressMap event fires and converts all the pointers 
> 4) After all the ExitBootServices events have been processed the DXE Runtime 
> driver re-relocates the Runtime Driver
> 5) The next code that runs is a call from the kernel virtual mapping, and the 
> system is at runtime 
> 
> It is important to remember that when gRT->SetVirtualAddressMap() is called 
> by the OS Loader (or early kernel) that gBS->ExitBootServices() has already 
> been called. So by the time you get 3) almost all of EFI is gone. The only 
> services that remain are gRT. Note you find the location of gRT by using the 
> gST passed into the entry point of the driver. So here is lies the problem 
> the entry point is passed a Handle (EFI Boot Services concept) and a pointer 
> to gST (another boot services table). So you can't really reload a module and 
> expect it to work. 
> 
> In EFI the transition from Boot Service time to Runtime already requires a 
> lot of coding discipline to not call services at runtime that will go away 
> after ExitBootServices. Having C code that can be called in Physical mode, 
> and then with a virtual mapping is a very unnatural and what EFI does today 
> is the minimum required to make things work. 
> 
> Also remember dumping more into EFI runtime is stealing memory and usually 
> kernel virtual address space from the OS. 

Thank you for the detailed explanation!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45820): https://edk2.groups.io/g/devel/message/45820
Mute This Topic: https://groups.io/mt/32686575/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

[Liming Gao]

Laszlo:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
> Ersek
> Sent: Friday, August 16, 2019 11:18 PM
> To: Gao, Liming ; devel@edk2.groups.io; Kinney, Michael 
> D 
> Cc: Mike Turner ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan
> 
> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT 
> update
> 
> On 08/14/19 17:55, Gao, Liming wrote:
> 
> > If Platform PEIM doesn't build HOB, DxeIpl will not build HOB,
> 
> My reading of the code is the opposite. If the platform PEIM does not build 
> the HOB, then the DXE IPL PEIM will attempt to build the HOB,
> from the UEFI variable.
> 
> At commit caa7d3a896f6, in file "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c", 
> function DxeLoadCore(), we have:
> 
>363if (GetFirstGuidHob ((CONST EFI_GUID 
> *)&gEfiMemoryTypeInformationGuid) == NULL) {
>364  //
>365  // Don't build GuidHob if GuidHob has been installed.
>366  //
>367  Status = PeiServicesLocatePpi (
>368 &gEfiPeiReadOnlyVariable2PpiGuid,
>369 0,
>370 NULL,
>371 (VOID **)&Variable
>372 );
>373  if (!EFI_ERROR (Status)) {
>374DataSize = sizeof (MemoryData);
>375Status = Variable->GetVariable (
>376 Variable,
>377 EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
>378 &gEfiMemoryTypeInformationGuid,
>379 NULL,
>380 &DataSize,
>381 &MemoryData
>382 );
>383if (!EFI_ERROR (Status) && 
> ValidateMemoryTypeInfoVariable(MemoryData, DataSize)) {

Only when this variable exists, Hob will be built. But, if no PEIM builds Hob, 
BDS will not set the variable. 
So, there is still no HOB.

Thanks
Liming
>384  //
>385  // Build the GUID'd HOB for DXE
>386  //
>387  BuildGuidDataHob (
>388&gEfiMemoryTypeInformationGuid,
>389MemoryData,
>390DataSize
>391);
>392}
>393  }
>394}
> 
> Thanks
> Laszlo
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45821): https://edk2.groups.io/g/devel/message/45821
Mute This Topic: https://groups.io/mt/32821535/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [POC Seabios PATCH] seabios: use isolated SMM address space for relocation

[Igor Mammedov]

for purpose of demo SMRAM (at 0x3) is aliased at a in system address 
space
for easy initialization of SMI entry point.
Here is resulting debug output showing that RAM at 0x3 is not affected
by SMM and only RAM in SMM adderss space is modified:

init smm
smm_relocate: before relocaten
smm_relocate: RAM codeentry 0
smm_relocate: RAM  cpu.i64.smm_base  0
smm_relocate: SMRAM  codeentry f000c831eac88c
smm_relocate: SMRAM  cpu.i64.smm_base  0
handle_smi cmd=0 smbase=0x0003
smm_relocate: after relocaten
smm_relocate: RAM codeentry 0
smm_relocate: RAM  cpu.i64.smm_base  0
smm_relocate: SMRAM  codeentry f000c831eac88c
smm_relocate: SMRAM  cpu.i64.smm_base  a

Patch depends on QEMU POC patch that adds SMRAM at 0x3 in SMM address space

PS:
configure bios with level 9 debugging and debug port

Signed-off-by: Igor Mammedov 
---
 src/fw/smm.c | 43 +++
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/src/fw/smm.c b/src/fw/smm.c
index d90e43a9..27f9747e 100644
--- a/src/fw/smm.c
+++ b/src/fw/smm.c
@@ -140,21 +140,22 @@ extern void entry_smi(void);
   | ((u64)((u32)entry_smi - BUILD_BIOS_ADDR) << 24))
 
 static void
-smm_save_and_copy(void)
+smm_relocate(void)
 {
-// save original memory content
 struct smm_layout *initsmm = (void*)BUILD_SMM_INIT_ADDR;
 struct smm_layout *smm = (void*)BUILD_SMM_ADDR;
-memcpy(&smm->cpu, &initsmm->cpu, sizeof(smm->cpu));
-memcpy(&smm->codeentry, &initsmm->codeentry, sizeof(smm->codeentry));
 
-// Setup code entry point.
-initsmm->codeentry = SMI_INSN;
-}
+dprintf(3, "smm_relocate: before relocaten\n");
+dprintf(3, "smm_relocate: RAM codeentry %llx\n", initsmm->codeentry);
+dprintf(3, "smm_relocate: RAM  cpu.i64.smm_base  %lx\n", 
initsmm->cpu.i64.smm_base);
+
+
+/* BUILD_SMM_ADDR aliased to BUILD_SMM_INIT_ADDR in SMM AS
+ * so we could set SMI entry point there */
+smm->codeentry = SMI_INSN;
+dprintf(3, "smm_relocate: SMRAM  codeentry %llx\n", smm->codeentry);
+dprintf(3, "smm_relocate: SMRAM  cpu.i64.smm_base  %lx\n", 
smm->cpu.i64.smm_base);
 
-static void
-smm_relocate_and_restore(void)
-{
 /* init APM status port */
 outb(0x01, PORT_SMI_STATUS);
 
@@ -165,15 +166,13 @@ smm_relocate_and_restore(void)
 while (inb(PORT_SMI_STATUS) != 0x00)
 ;
 
-/* restore original memory content */
-struct smm_layout *initsmm = (void*)BUILD_SMM_INIT_ADDR;
-struct smm_layout *smm = (void*)BUILD_SMM_ADDR;
-memcpy(&initsmm->cpu, &smm->cpu, sizeof(initsmm->cpu));
-memcpy(&initsmm->codeentry, &smm->codeentry, sizeof(initsmm->codeentry));
-
-// Setup code entry point.
-smm->codeentry = SMI_INSN;
 wbinvd();
+
+dprintf(3, "smm_relocate: after relocaten\n");
+dprintf(3, "smm_relocate: RAM codeentry %llx\n", initsmm->codeentry);
+dprintf(3, "smm_relocate: RAM  cpu.i64.smm_base  %lx\n", 
initsmm->cpu.i64.smm_base);
+dprintf(3, "smm_relocate: SMRAM  codeentry %llx\n", smm->codeentry);
+dprintf(3, "smm_relocate: SMRAM  cpu.i64.smm_base  %lx\n", 
smm->cpu.i64.smm_base);
 }
 
 // This code is hardcoded for PIIX4 Power Management device.
@@ -187,8 +186,6 @@ static void piix4_apmc_smm_setup(int isabdf, int i440_bdf)
 /* enable the SMM memory window */
 pci_config_writeb(i440_bdf, I440FX_SMRAM, 0x02 | 0x48);
 
-smm_save_and_copy();
-
 /* enable SMI generation when writing to the APMC register */
 pci_config_writel(isabdf, PIIX_DEVACTB, value | PIIX_DEVACTB_APMC_EN);
 
@@ -196,7 +193,7 @@ static void piix4_apmc_smm_setup(int isabdf, int i440_bdf)
 value = inl(acpi_pm_base + PIIX_PMIO_GLBCTL);
 outl(value | PIIX_PMIO_GLBCTL_SMI_EN, acpi_pm_base + PIIX_PMIO_GLBCTL);
 
-smm_relocate_and_restore();
+smm_relocate();
 
 /* close the SMM memory window and enable normal SMM */
 pci_config_writeb(i440_bdf, I440FX_SMRAM, 0x02 | 0x08);
@@ -213,8 +210,6 @@ void ich9_lpc_apmc_smm_setup(int isabdf, int mch_bdf)
 /* enable the SMM memory window */
 pci_config_writeb(mch_bdf, Q35_HOST_BRIDGE_SMRAM, 0x02 | 0x48);
 
-smm_save_and_copy();
-
 /* enable SMI generation when writing to the APMC register */
 outl(value | ICH9_PMIO_SMI_EN_APMC_EN | ICH9_PMIO_SMI_EN_GLB_SMI_EN,
  acpi_pm_base + ICH9_PMIO_SMI_EN);
@@ -224,7 +219,7 @@ void ich9_lpc_apmc_smm_setup(int isabdf, int mch_bdf)
 pci_config_writel(isabdf, ICH9_LPC_GEN_PMCON_1,
   value | ICH9_LPC_GEN_PMCON_1_SMI_LOCK);
 
-smm_relocate_and_restore();
+smm_relocate();
 
 /* close the SMM memory window and enable normal SMM */
 pci_config_writeb(mch_bdf, Q35_HOST_BRIDGE_SMRAM, 0x02 | 0x08);
-- 
2.18.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45824): https://edk2.groups.io/g/devel/message/45824
Mute This Topic: https://groups.io/mt/32899784/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscri

[edk2-devel] [POC QEMU PATCH 0/2] CPU hotplug: use dedicated SMRAM at 0x30000 in SMM address space

[Igor Mammedov]

It's just a quick hack together with Seabios to show
that normal RAM at 0x3 is not affected by SMM relocation
and dedicated SMRAM could be used for relocation without need to
care about untrusted RAM content at 0x3.


CC: "Chen,  Yingwen" 
CC: edk2-devel-groups-io 
CC: Phillip Goerl 
CC: qemu devel list 
CC: "Yao, Jiewen" 
CC: "Nakajima, Jun" 
CC: Boris Ostrovsky 
CC: edk2-rfc-groups-io 
CC: Laszlo Ersek 
CC: Joao Marcal Lemos Martins 
CC: pbonz...@redhat.com

 include/hw/pci-host/q35.h |  1 +
 hw/pci-host/q35.c | 10 ++
 2 files changed, 11 insertions(+)

-- 
2.18.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45822): https://edk2.groups.io/g/devel/message/45822
Mute This Topic: https://groups.io/mt/32899782/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH QEMU 1/1] q35: use dedicated SMRAM at default SMM_BASE

[Igor Mammedov]

it will allow us to hide sensetive SMM_BASE area from non SMM running env,
that will allow us to ensure that hotplugged CPU will run trusted
SMM BASE relocation code and we won't need to force all present CPUs
into SMM mode since we don not care about about 0x3 content
in normal RAM address space.

it's a obviously a hack only to demo approach. for easy SMI initialization
on SMI entry point SMRAM is aliased in to hajaked normal RAM address space
at a.
Patch should be used with supplied SMBIOS patch, that drops
save/restore sequence and just inits SMI entry point.

to test to run:
  qemu-system-x86_64 -M q35 -bios /path_to_seabios/out/bios.bin \
-nodefaults \
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

Signed-off-by: Igor Mammedov 
---
 include/hw/pci-host/q35.h |  1 +
 hw/pci-host/q35.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index 5ed77facd0..556ecb835a 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -55,6 +55,7 @@ typedef struct MCHPCIState {
 MemoryRegion smram_region, open_high_smram;
 MemoryRegion smram, low_smram, high_smram;
 MemoryRegion tseg_blackhole, tseg_window;
+MemoryRegion smbase, smram_alias;
 Range pci_hole;
 uint64_t below_4g_mem_size;
 uint64_t above_4g_mem_size;
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0a010be4cf..6c4c0f308c 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -574,6 +574,16 @@ static void mch_realize(PCIDevice *d, Error **errp)
 memory_region_set_enabled(&mch->tseg_window, false);
 memory_region_add_subregion(&mch->smram, mch->below_4g_mem_size,
 &mch->tseg_window);
+
+memory_region_init_ram(&mch->smm_base, OBJECT(mch), "SMM BASE", 
MCH_HOST_BRIDGE_SMRAM_C_SIZE, &error_fatal);
+memory_region_set_enabled(&mch->smm_base, true);
+memory_region_add_subregion(&mch->smram, 0x3, &mch->smm_base);
+
+memory_region_init_alias(&mch->smm_base_alias, OBJECT(mch), 
"smim_base_alias",
+ &mch->smm_base, 0, MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_set_enabled(&mch->smm_base_alias, true);
+memory_region_add_subregion_overlap(mch->system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE, &mch->smm_base_alias, 1);
+
 object_property_add_const_link(qdev_get_machine(), "smram",
OBJECT(&mch->smram), &error_abort);
 
-- 
2.18.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45823): https://edk2.groups.io/g/devel/message/45823
Mute This Topic: https://groups.io/mt/32899783/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update

[Liming Gao]

From: Mike Turner 

The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across
reboots, and then does an AllocatePage for that memory address.
If, on this boot, that memory comes from a Runtime memory bucket,
the MAT table is not updated. This causes Windows to boot into Recovery.

This patch blocks the memory manager from changing the page
from a special bucket to a different memory type.  Once the buckets are
allocated, we freeze the memory ranges for the OS, and fragmenting
the special buckets will cause errors resuming from hibernate (S4).

The references to S4 here are the use case that fails.  This
failure is root caused to an inconsistent behavior of the
core memory services themselves when type AllocateAddress is used.

The main issue is apparently with the UEFI memory map -- the UEFI memory
map reflects the pre-allocated bins, but the actual allocations at fixed
addresses may go out of sync with that. Everything else, such as:
- EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync,
- S4 failing
are just symptoms / consequences.

This patch is cherry pick from Project Mu:
https://github.com/microsoft/mu_basecore/commit/a9be767d9be96af94016ebd391ea6f340920735a
With the minor change,
1. Update commit message format to keep the message in 80 characters one line.
2. Remove // MU_CHANGE comments in source code.
3. Update comments style to follow edk2 style.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Dandan Bi 
Cc: Laszlo Ersek 
Signed-off-by: Liming Gao 
---
In v2, add more description for this issue. 

 MdeModulePkg/Core/Dxe/Mem/Page.c | 41 ++--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index bd9e116aa5..1f0e3d94b9 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1265,12 +1265,13 @@ CoreInternalAllocatePages (
   IN BOOLEANNeedGuard
   )
 {
-  EFI_STATUS  Status;
-  UINT64  Start;
-  UINT64  NumberOfBytes;
-  UINT64  End;
-  UINT64  MaxAddress;
-  UINTN   Alignment;
+  EFI_STATUS   Status;
+  UINT64   Start;
+  UINT64   NumberOfBytes;
+  UINT64   End;
+  UINT64   MaxAddress;
+  UINTNAlignment;
+  EFI_MEMORY_TYPE  CheckType;
 
   if ((UINT32)Type >= MaxAllocateType) {
 return EFI_INVALID_PARAMETER;
@@ -1321,6 +1322,7 @@ CoreInternalAllocatePages (
   // if (Start + NumberOfBytes) rolls over 0 or
   // if Start is above MAX_ALLOC_ADDRESS or
   // if End is above MAX_ALLOC_ADDRESS,
+  // if Start..End overlaps any tracked MemoryTypeStatistics range
   // return EFI_NOT_FOUND.
   //
   if (Type == AllocateAddress) {
@@ -1336,6 +1338,33 @@ CoreInternalAllocatePages (
 (End > MaxAddress)) {
   return EFI_NOT_FOUND;
 }
+
+//
+// A driver is allowed to call AllocatePages using an AllocateAddress 
type.  This type of
+// AllocatePage request the exact physical address if it is not used.  The 
existing code
+// will allow this request even in 'special' pages.  The problem with this 
is that the
+// reason to have 'special' pages for OS hibernate/resume is defeated as 
memory is
+// fragmented.
+//
+
+for (CheckType = (EFI_MEMORY_TYPE) 0; CheckType < EfiMaxMemoryType; 
CheckType++) {
+  if (MemoryType != CheckType &&
+  mMemoryTypeStatistics[CheckType].Special &&
+  mMemoryTypeStatistics[CheckType].NumberOfPages > 0) {
+if (Start >= mMemoryTypeStatistics[CheckType].BaseAddress &&
+Start <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
+  return EFI_NOT_FOUND;
+}
+if (End >= mMemoryTypeStatistics[CheckType].BaseAddress &&
+End <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
+  return EFI_NOT_FOUND;
+}
+if (Start < mMemoryTypeStatistics[CheckType].BaseAddress &&
+End   > mMemoryTypeStatistics[CheckType].MaximumAddress) {
+  return EFI_NOT_FOUND;
+}
+  }
+}
   }
 
   if (Type == AllocateMaxAddress) {
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45825): https://edk2.groups.io/g/devel/message/45825
Mute This Topic: https://groups.io/mt/32899946/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

[Laszlo Ersek]

On 08/15/19 06:02, Gao, Liming wrote:
> Donald: This change is a new feature. Now, it is not in edk2 feature
> planning list. If you want to catch it into 201908 stable tag, please
> get approve from Stewards first. I have cc this mail to all Stewards.
- I don't mind adding a new feature, as long as it gets properly
reviewed by package owners before we enter the soft feature freeze.

- Looking at the BZ
, a bit more
documentation would be nice.

- On the negative side, I'm very much *not* a fan of adding features to
the open source edk2 tree without actually *consuming* the feature in an
open source tree. Are the new library instances going to be put to use
in edk2-platforms, perhaps?

We discussed this topic earlier on some of the stewards' calls. On one
hand, it's not uncommon to see library instances from Intel enter core
edk2 packages without any dependent platform code, or even a detailed
problem statement / purpose description (see e.g. commit 5c9bb86f171c
and its surrounding commits). On the other hand, attempts in the past,
to add libraries with well demonstrated and direct in-tree use cases, to
edk2 core, have been rejected, from other submitters. (Here's one
example: .) I'm not
prying at proprietary platform information, but a new library added to
edk2 core *should* be well-justified.

The commit message on this patch is empty. It only references
. And if I open the
BZ, this is all I get:

Need a new TSC library to check the CPUID leaf (EAX=0x15) for TSC.
For new platform (start from SKL) can use CPUID and retire/remove
the current override from AcpiTimerLib.

Does this read like an actual feature request? (TimerLib is an MdePkg
library class, so not exactly "niche".)

Plus, the BZ isn't even marked as a feature request, to begin with (the
Product field is wrong, it says "EDK2", which is for bugs, not
features). Also, the patch is on the list, and the status is still
CONFIRMED, and not IN_PROGRESS.

Why are we making a joke of bug tracking? The purpose of a public
bugzilla instance on the web is not just more red tape, not just to have
one more administrative tool that we can abuse, ignore, and write off
with make-believe actions.

It's not like another issue tracker system (JIRA, Launchpad, GitHub,
GitLab, you name it) would properly work with this level of neglect, either.

In summary: I don't mind the feature, but the documentation around it
should be *much* better.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45826): https://edk2.groups.io/g/devel/message/45826
Mute This Topic: https://groups.io/mt/32839184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Laszlo Ersek]

On 08/14/19 18:22, vit9...@protonmail.com wrote:
> Michael, Liming, Laszlo,
> 
> Static assertions via _Static_assert are standard C11 functionality, thus any 
> at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support 
> the second argument with the diagnostic description.
> The notation without the message currently is only present in C++, not in C, 
> thus the two-argument notation is the only allowed notation for 
> _Static_assert for at least C17 (ISO/IEC 9899 2018) and below.
> In the bottom of this message I included a quote from C17 for the relevant 
> section (6.7.10).
> 
> GCC and CLANG (including Xcode) appear to be conforming to the standard for 
> this section, and MSVC compiler static_assert extension also supports the 
> diagnostic message argument. This is pretty much all we care about.
> 
> As for examples, I see little reason to clarify STATIC_ASSERT behaviour 
> outside of the standard reference in its description and actual usage in the 
> source code, but can do that just fine if you think that it may help somebody.

Edk2 targets C95, to my understanding. If features from more recent C
language standards happen to work on all toolchains that edk2 supports,
then I agree we can put those language features to use -- but we should
document them, in the appropriate header file. In my opinion.

> 
> I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
> and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
> This should be fairly costless, as apparently it is only used in Base.h and 
> MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in 
> the same patch set.

I disagree with introducing a new macro to a core header file without
putting it to use at once, in at least one very commonly built
translation unit in edk2 itself. I would suggest to single out a few
core uses of ASSERT (e.g. in MdePkg or MdeModulePkg), and to convert them.

If you can replace VERIFY_SIZE_OF with STATIC_ASSERT, that could be a
perfect first use. Of course I'd suggest that the patches be separate --
first, add the new macro, second, gradually convert VERIFY_SIZE_OF. So
this intro work should be done as a small series.

I think that can belong to a single BZ.

> As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
> great, as let us be honest, the use of ASSERT in EDK II codebase is very 
> questioning. In fact, this was one of the reasons we introduced our own 
> static assertions some time ago. However, fixing up all broken assertions is 
> unlikely a best place to fit into this patchset, but I can surely add a few 
> examples, in case somebody points them out. This will be useful for reference 
> purposes and may help the maintainers to get a better idea when static 
> assertions are to be used.

Wider ASSERT evaluation and conversion to STATIC_ASSERT should be done
later (separate BZs) if we ever have capacity for that.

Thanks
Laszlo


> 
> Looking forward to hearing your opinions.
> 
> Best regards,
> Vitaly
> 
> 
> 6.7.10 Static assertions
> 
> Syntax
> 1 static_assert-declaration:
> _Static_assert ( constant-expression , string-literal ) ;
> 
> Constraints
> 2 The constant expression shall compare unequal to 0.
> 
> Semantics
> 3 The constant expression shall be an integer constant expression. If the 
> value of the constant expression compares unequal to 0, the declaration has 
> no effect. Otherwise, the constraint is violated and the implementation shall 
> produce a diagnostic message that includes the text of the string literal, 
> except that characters not in the basic source character set are not required 
> to appear in the message.
> Forward references: diagnostics (7.2).
> 
> 7.2 Diagnostics 
> 
> 3 The macro
> static_assert
> expands to _Static_assert.
> 
> 
>> 14 авг. 2019 г., в 18:47, Kinney, Michael D  
>> написал(а):
>>
>>
>> Liming,
>>
>> I think a good candidate to demonstrate this
>> feature are the checks made in MdePkg/Include/Base.h.
>> The current implementation forces a divide by 0
>> in the C pre-processor to break the build.
>> STATIC_ASSERT() would be a better way to do this.
>> I would also remove unused externs from the builds.
>>
>> /**
>>  Verifies the storage size of a given data type.
>>
>>  This macro generates a divide by zero error or a zero size array 
>> declaration in
>>  the preprocessor if the size is incorrect.  These are declared as "extern" 
>> so
>>  the space for these arrays will not be in the modules.
>>
>>  @param  TYPE  The date type to determine the size of.
>>  @param  Size  The expected size for the TYPE.
>>
>> **/
>> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
>> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
>>
>> //
>> // Verify that ProcessorBind.h produced UEFI Data Types that are compliant 
>> with
>> // Section 2.3.1 of the UEFI 2.3 Specification.
>> //
>> VERIFY_SIZE_OF (BOOLEAN, 1);
>> VERIFY_SIZE_OF (INT8

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Laszlo Ersek]

On 08/15/19 03:59, Gao, Liming wrote:
> Vitaly:
>   As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose 
> this patch plan to catch this stable tag?
>  If yes, please ask the feedback from Tianocore Stewards. I have cc this 
> patch to all Stewards.

If a feature patch (or series) is fully reviewed before the soft feature
freeze (by the respective package maintainers), it can be merged during
the soft feature freeze.

However, I don't think this patch is mature enough for that. As I've
just said up-thread, I'd like to see STATIC_ASSERT being put to use at
once (in the same series, not in the same patch). In addition, the
documentation should be improved (the (constant-expression ,
string-literal) parameter list seems absent, or at least insufficiently
documented).

In turn, I doubt a v3 posting could be reviewed with enough care before
we enter the soft feature freeze. I'd suggest to submit the v3 series as
soon as we start the next development cycle.

Thanks
Laszlo

> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, 
> Jiewen
> Sent: Thursday, August 15, 2019 9:05 AM
> To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D 
> 
> Cc: Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
> 
> Good input.
> I think we should separate the work to convert all EDKII code to use 
> STATIC_ASSERT.
> We can do that work once we add STATIC_ASSERT.
> 
> I recommend:
> 
> 1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla
> 
> 2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
> VERIFY_SIZE_OF – the other patch and the other Bugzilla
> 
> 3)  Step 3: Scan the rest, if there is need. – Another patch and another 
> Bugzilla
> 
> Thank you
> Yao Jiewen
> 
> From: devel@edk2.groups.io 
> [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io
> Sent: Thursday, August 15, 2019 12:23 AM
> To: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>
> Cc: devel@edk2.groups.io; Laszlo Ersek 
> mailto:ler...@redhat.com>>
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
> 
> 
> Michael, Liming, Laszlo,
> 
> Static assertions via _Static_assert are standard C11 functionality, thus any 
> at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support 
> the second argument with the diagnostic description.
> 
> The notation without the message currently is only present in C++, not in C, 
> thus the two-argument notation is the only allowed notation for 
> _Static_assert for at least C17 (ISO/IEC 9899 2018) and below.
> 
> In the bottom of this message I included a quote from C17 for the relevant 
> section (6.7.10).
> 
> GCC and CLANG (including Xcode) appear to be conforming to the standard for 
> this section, and MSVC compiler static_assert extension also supports the 
> diagnostic message argument. This is pretty much all we care about.
> 
> As for examples, I see little reason to clarify STATIC_ASSERT behaviour 
> outside of the standard reference in its description and actual usage in the 
> source code, but can do that just fine if you think that it may help somebody.
> 
> I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
> and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
> This should be fairly costless, as apparently it is only used in Base.h and 
> MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in 
> the same patch set.
> 
> As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
> great, as let us be honest, the use of ASSERT in EDK II codebase is very 
> questioning. In fact, this was one of the reasons we introduced our own 
> static assertions some time ago. However, fixing up all broken assertions is 
> unlikely a best place to fit into this patchset, but I can surely add a few 
> examples, in case somebody points them out. This will be useful for reference 
> purposes and may help the maintainers to get a better idea when static 
> assertions are to be used.
> 
> Looking forward to hearing your opinions.
> 
> Best regards,
> Vitaly
> 
> 
> 6.7.10 Static assertions
> 
> Syntax
> 1 static_assert-declaration:
> _Static_assert ( constant-expression , string-literal ) ;
> 
> Constraints
> 2 The constant expression shall compare unequal to 0.
> 
> Semantics
> 3 The constant expression shall be an integer constant expression. If the 
> value of the constant expression compares unequal to 0, the declaration has 
> no effect. Otherwise, the constraint is violated and the implementation shall 
> produce a diagnostic message that includes the text of the string literal, 
> except that characters not in the basic source character set are not required 
> to appear in the message.
> 
> Forward references: diagnostics (7.2).
> 
> 7.2 Diagnostics 
> 
> 3 The macro
> static_assert
> expa

Re: [edk2-devel] [Patch v4 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

[Laszlo Ersek]

On 08/16/19 05:57, Eric Dong wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
> 
> Add below new micros which test the current value before write the new
> value. Only write new value when current value not same as new value.
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE32
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE64
>   CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
> 
> Also add below API:
>   CpuRegisterTableTestThenWrite
> 
> Signed-off-by: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Star Zeng 
> ---
>  UefiCpuPkg/Include/AcpiCpuData.h  |  3 +-
>  .../Include/Library/RegisterCpuFeaturesLib.h  | 91 +++
>  .../RegisterCpuFeaturesLib.c  | 44 -
>  3 files changed, 134 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/Include/AcpiCpuData.h 
> b/UefiCpuPkg/Include/AcpiCpuData.h
> index b963a2f592..77da5d4455 100644
> --- a/UefiCpuPkg/Include/AcpiCpuData.h
> +++ b/UefiCpuPkg/Include/AcpiCpuData.h
> @@ -78,7 +78,8 @@ typedef struct {
>UINT32 Index; // offset 4 - 7
>UINT8  ValidBitStart; // offset 8
>UINT8  ValidBitLength;// offset 9
> -  UINT16 Reserved;  // offset 10 - 11
> +  BOOLEANTestThenWrite; // offset 10
> +  UINT8  Reserved1; // offset 11
>UINT32 HighIndex; // offset 12-15, only valid for 
> MemoryMapped
>UINT64 Value; // offset 16-23
>  } CPU_REGISTER_TABLE_ENTRY;

Acked-by: Laszlo Ersek 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45829): https://edk2.groups.io/g/devel/message/45829
Mute This Topic: https://groups.io/mt/32894958/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 0/2] Platforms/RPi3: Device Tree driver improvements

[Leif Lindholm]

On Fri, Aug 16, 2019 at 11:00:07AM +0100, Pete Batard wrote:
> Changes from v1:
> - Break down DEBUB output embellishments from the other code changes.
> - Use GUIDs that are explicitly named after each platform/model rather than
>   generic ones.
> - Drop the use of a GUID table/index and use a single GUID variable instead.
> - Add additional fallback in case the required internal Device Tree cannot
>   be located (e.g. missing from the FDF).
> - Ensures that all of the Device Tree selection and fallback can be set up
>   in the .dec (FdtDxe reusability).
> - Add premilinary Raspberry Pi 4 support (FdtDxe reusability).
> 
> Note: Since the changes required to support the Raspberry Pi 4 are a direct
> byproduct of the changes required for multiple Device Tree support, I did
> not feel the need to break them down into a separate patch.

For the series,
Reviewed-by: Leif Lindholm 
Pushed as 591f0c39589c..7da906bfcd03.

Thanks!

> Pete Batard (2):
>   Platforms/RPi3: Improve debug output in FdtDxe
>   Platforms/RPi3: Add multiple embedded Device Tree selection
> 
>  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c   | 78 +++-
>  Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.inf |  5 +-
>  Platform/RaspberryPi/RPi3/RPi3.dec  |  8 +-
>  Platform/RaspberryPi/RPi3/RPi3.fdf  |  6 +-
>  4 files changed, 77 insertions(+), 20 deletions(-)
> 
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45830): https://edk2.groups.io/g/devel/message/45830
Mute This Topic: https://groups.io/mt/32896985/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] static data in dxe_runtime modules

[Roman Kagan]

On Wed, Aug 14, 2019 at 09:26:47AM -0700, Andrew Fish via Groups.Io wrote:
> Every runtime driver I've every seen usually works like this:
> 1) Loads as an EFI driver and uses EFI Boot Services in its constructor (gBS, 
> gDS, AllocatePool(), etc.)
> 2) You use the EFI Boot Service to register the ExitBootServices Event. 
> 3) SetVirtualAddressMap event fires and converts all the pointers 
> 4) After all the ExitBootServices events have been processed the DXE Runtime 
> driver re-relocates the Runtime Driver
> 5) The next code that runs is a call from the kernel virtual mapping, and the 
> system is at runtime 
> 
> It is important to remember that when gRT->SetVirtualAddressMap() is
> called by the OS Loader (or early kernel) that gBS->ExitBootServices()
> has already been called. So by the time you get 3) almost all of EFI
> is gone. The only services that remain are gRT. Note you find the
> location of gRT by using the gST passed into the entry point of the
> driver. So here is lies the problem the entry point is passed a Handle
> (EFI Boot Services concept) and a pointer to gST (another boot
> services table). So you can't really reload a module and expect it to
> work. 

Indeed.  My hope was that the particular VariableRuntimeDxe module was
just a bunch of self-contained code that accesses all the data it needs
through the arguments it's passed.  Having now looked at the code, this
assumption is certainly wrong: the module depends on a lot of private
data that is initialized at boot services time.

Thanks and sorry for the noise,
Roman.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45831): https://edk2.groups.io/g/devel/message/45831
Mute This Topic: https://groups.io/mt/32686575/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] BaseTools/BinWrappers question?

[Andrew Fish via Groups.Io]

Why does BaseTools/BinWrappers/WindowsLike only have wrappers for Python 
commands, while  BaseTools/BinWrappers/PosixLike has wrappers for C based tools 
too?

Thanks,

Andrew Fish
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45832): https://edk2.groups.io/g/devel/message/45832
Mute This Topic: https://groups.io/mt/32900805/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 01/10] Marvell/Armada7k8k: Fix 32-bit compilation

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:05AM +0200, Marcin Wojtas wrote:
> It turned out, that the recently added features broke
> ARM compilation. Fix all issues:
> * Use SIGNATURE_32 only
> * Do not shift address by 32-bit in ICU
> * Limit memory for ARM build to 1GB and stop using non-existent PCD
> 
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h   |  
> 2 +-
>  Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h   |  
> 2 +-
>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c  |  
> 4 
>  Silicon/Marvell/Library/IcuLib/IcuLib.c  |  
> 7 ++-
>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S | 
> 11 ---
>  5 files changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h 
> b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
> index a6f551b..7ecb4e1 100644
> --- a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
> +++ b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
> @@ -18,7 +18,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  #include 
>  
> -#define MV_BOARD_DESC_SIGNATURE SIGNATURE_64 ('M', 'V', 'B', 'R', 'D', 'D', 
> 'S', 'C')
> +#define MV_BOARD_DESC_SIGNATURE SIGNATURE_32 ('B', 'D', 'S', 'C')
>  
>  typedef struct {
>MARVELL_BOARD_DESC_PROTOCOL   BoardDescProtocol;
> diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h 
> b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
> index 1cb006a..600d5db 100644
> --- a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
> +++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
> @@ -23,7 +23,7 @@
>  
>  #include 
>  
> -#define MV_GPIO_SIGNATURESIGNATURE_64 ('M', 'V','_','G', 'P', 
> 'I','O',' ')
> +#define MV_GPIO_SIGNATURESIGNATURE_32 ('G', 'P', 'I', 'O')

Can you epxlain why you opted to change the size of the signature
instead of the signature field in the structs?

I'm not super happy about this, since we still have UINTN signature,
not UINT32. Since the signature is *not* architecture dependent, it
should have a fixed size.

>  
>  // Marvell MV_GPIO Controller Registers
>  #define MV_GPIO_DATA_OUT_REG (0x0)
> diff --git 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c 
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> index a735fe5..5ff6bb1 100644
> --- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> +++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> @@ -36,6 +36,7 @@ GetDramSize (
>IN OUT UINT64 *MemSize
>)
>  {
> +#if defined(MDE_CPU_AARCH64)
>ARM_SMC_ARGS SmcRegs = {0};
>EFI_STATUS Status;
>  
> @@ -48,6 +49,9 @@ GetDramSize (
>ArmCallSmc (&SmcRegs);
>  
>*MemSize = SmcRegs.Arg0;
> +#else
> +  *MemSize = FixedPcdGet64 (PcdSystemMemorySize);
> +#endif

Can you add a comment explaining why a 32-bit SMC call is not
possible?

>  
>return EFI_SUCCESS;
>  }
> diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.c 
> b/Silicon/Marvell/Library/IcuLib/IcuLib.c
> index 343c21b..422388c 100644
> --- a/Silicon/Marvell/Library/IcuLib/IcuLib.c
> +++ b/Silicon/Marvell/Library/IcuLib/IcuLib.c
> @@ -185,10 +185,15 @@ IcuConfigure (
>for (Index = 0; Index < IcuGroupMax; Index++, Msi++) {
>  MmioWrite32 (IcuBase + ICU_SET_SPI_AL (Msi->Group),
>Msi->SetSpiAddr & 0x);
> -MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), Msi->SetSpiAddr >> 
> 32);
>  MmioWrite32 (IcuBase + ICU_CLR_SPI_AL (Msi->Group),
>Msi->ClrSpiAddr & 0x);
> +#if defined(MDE_CPU_AARCH64)
> +MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), Msi->SetSpiAddr >> 
> 32);
>  MmioWrite32 (IcuBase + ICU_CLR_SPI_AH (Msi->Group), Msi->ClrSpiAddr >> 
> 32);
> +#else
> +MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), 0);
> +MmioWrite32 (IcuBase + ICU_CLR_SPI_AH (Msi->Group), 0);
> +#endif

I don't understand what's going on here - add a comment?

Best Regards,

Leif

>}
>  
>/* Mask all ICU interrupts */
> diff --git 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S 
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
> index 4416163..db43b0f 100644
> --- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
> +++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
> @@ -28,17 +28,6 @@ ASM_FUNC(ArmPlatformPeiBootAction)
>.err  PcdSystemMemoryBase should be 0x0 on this platform!
>.endif
>  
> -  .if   FixedPcdGet64 (PcdSystemMemorySize) > FixedPcdGet32 
> (PcdDramRemapTarget)
> -//
> -// Use the low range for UEFI itself. The remaining memory will be mapped
> -// and added to the GCD map later.
> -//
> -ADRL  (r0, mSystemMemoryEnd)
> -MOV32 (r2, FixedPcdGet32 (PcdDramRemapTarget) - 1)
> -mov   r3, #0
> -

Re: [edk2-devel] [edk2-platforms: PATCH v2 02/10] Marvell/Cn9130Db: Add ACPI tables

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:06AM +0200, Marcin Wojtas wrote:
> This patch adds ACPI tables and necessary headers,
> which are common for Cn913x SoCs and the CN9130 development board
> (variant A). Wiring up of support will be done in the follow-up
> commits.
> 
> Signed-off-by: Marcin Wojtas 

I'm not going to claim to have properly reviewed this, but:
Acked-by: Leif Lindholm 

> ---
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf   |  56 
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h|  37 +++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h|  20 ++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h |  36 +++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl  | 324 
> 
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc |  41 +++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc   |  80 +
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc   |  58 
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc   | 135 
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc   | 210 
> +
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc   |  49 +++
>  11 files changed, 1046 insertions(+)
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl
>  create mode 100644 
> Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45834): https://edk2.groups.io/g/devel/message/45834
Mute This Topic: https://groups.io/mt/32882734/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 03/10] Marvell/Cn9130Db: Add DeviceTree

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:07AM +0200, Marcin Wojtas wrote:
> This patch adds device tree sources which are common for Cn913x SoCs
> and the CN9130 development board (variant A). Wiring up of support
> will be done in the follow-up commits.
> 
> Signed-off-by: Marcin Wojtas 

Again, I've not reviewed the contents extensively, *but* this patch
cannot go into edk2-platforms - it has GPL licensed content.
Was it meant for edk2-non-osi? Because we could take it there.

Best Regards,

Leif

> ---
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf  |  22 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi |  43 ++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi  | 264 
> ++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi |  10 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi  | 552 
> 
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts| 185 +++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi | 168 ++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi| 126 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts|  29 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi | 173 ++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts|  76 +++
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi | 151 ++
>  12 files changed, 1799 insertions(+)
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
>  create mode 100644 
> Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45835): https://edk2.groups.io/g/devel/message/45835
Mute This Topic: https://groups.io/mt/32882735/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

Laszlo,

I have already mentioned that the documentation is sufficient as _Static_assert 
is C standard, so I do not plan to make a V3 for this patch. The patch is merge 
ready.

As for usage examples I have an opposing opinion to yours and believe it is 
based on very good reasons. Not using STATIC_ASSERT in the current release will 
make the feature optionally available and let people test it in their setups. 
In case they notice it does not work for them they will have 3 months grace 
period to report it to us and consider making a change. This will also give 
them 3 months grace period of VERIFY_SIZE_OF macro removal in favour of 
STATIC_ASSERT. Making the change now will let people do seamless transition to 
the new feature and will avoid obstacles you are currently trying to create. 
Thus STATIC_ASSERT usage and VERIFY_SIZE_OF removal must both be separate 
patchsets with potentially separate BZs.

Thanks for understanding,
Vitaly

> 16 авг. 2019 г., в 19:33, Laszlo Ersek  написал(а):
> 
> 
> On 08/15/19 03:59, Gao, Liming wrote:
>> Vitaly:
>>  As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose 
>> this patch plan to catch this stable tag?
>> If yes, please ask the feedback from Tianocore Stewards. I have cc this 
>> patch to all Stewards.
> 
> If a feature patch (or series) is fully reviewed before the soft feature
> freeze (by the respective package maintainers), it can be merged during
> the soft feature freeze.
> 
> However, I don't think this patch is mature enough for that. As I've
> just said up-thread, I'd like to see STATIC_ASSERT being put to use at
> once (in the same series, not in the same patch). In addition, the
> documentation should be improved (the (constant-expression ,
> string-literal) parameter list seems absent, or at least insufficiently
> documented).
> 
> In turn, I doubt a v3 posting could be reviewed with enough care before
> we enter the soft feature freeze. I'd suggest to submit the v3 series as
> soon as we start the next development cycle.
> 
> Thanks
> Laszlo
> 
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, 
>> Jiewen
>> Sent: Thursday, August 15, 2019 9:05 AM
>> To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D 
>> 
>> Cc: Laszlo Ersek 
>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
>> 
>> Good input.
>> I think we should separate the work to convert all EDKII code to use 
>> STATIC_ASSERT.
>> We can do that work once we add STATIC_ASSERT.
>> 
>> I recommend:
>> 
>> 1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla
>> 
>> 2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
>> VERIFY_SIZE_OF – the other patch and the other Bugzilla
>> 
>> 3)  Step 3: Scan the rest, if there is need. – Another patch and another 
>> Bugzilla
>> 
>> Thank you
>> Yao Jiewen
>> 
>> From: devel@edk2.groups.io 
>> [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io
>> Sent: Thursday, August 15, 2019 12:23 AM
>> To: Kinney, Michael D 
>> mailto:michael.d.kin...@intel.com>>
>> Cc: devel@edk2.groups.io; Laszlo Ersek 
>> mailto:ler...@redhat.com>>
>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
>> 
>> 
>> Michael, Liming, Laszlo,
>> 
>> Static assertions via _Static_assert are standard C11 functionality, thus 
>> any at least C11 (ISO/IEC 9899 2011) conforming compiler is required to 
>> support the second argument with the diagnostic description.
>> 
>> The notation without the message currently is only present in C++, not in C, 
>> thus the two-argument notation is the only allowed notation for 
>> _Static_assert for at least C17 (ISO/IEC 9899 2018) and below.
>> 
>> In the bottom of this message I included a quote from C17 for the relevant 
>> section (6.7.10).
>> 
>> GCC and CLANG (including Xcode) appear to be conforming to the standard for 
>> this section, and MSVC compiler static_assert extension also supports the 
>> diagnostic message argument. This is pretty much all we care about.
>> 
>> As for examples, I see little reason to clarify STATIC_ASSERT behaviour 
>> outside of the standard reference in its description and actual usage in the 
>> source code, but can do that just fine if you think that it may help 
>> somebody.
>> 
>> I fully agree that VERIFY_SIZE_OF usage should be converted to 
>> STATIC_ASSERT, and in fact I also suggest VERIFY_SIZE_OF to be entirely 
>> removed from Base.h. This should be fairly costless, as apparently it is 
>> only used in Base.h and MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, 
>> which I can replace in the same patch set.
>> 
>> As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
>> great, as let us be honest, the use of ASSERT in EDK II codebase is very 
>> questioning. In fact, this was one of the reasons we introduced our own 
>> static assertions some time ago. However, f

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

[Andrew Fish via Groups.Io]

Tested-by: Andrew Fish 

I tested the XCODE builds of the emulator and made sure that source level 
debugging worked probably for builds that generate symbols. 

Thanks,

Andrew Fish

> On Aug 16, 2019, at 8:09 AM, Michael D Kinney  
> wrote:
> 
> Jordan,
> 
> It is not a typo.
> 
> Andrew generated the XCODE specific changes, so they have 
> been tested by him.  I have also reviewed and tested the XCODE
> changes and verified that all 6 combinations build and boot
> to shell (IA32/X64 for RELEASE/DEBUG/NOOPT). Since they are
> all related to making EmulatorPkg work, we decided to fold
> them into the same patch set that was already being reviewed.
> 
> I also verified build and boot to shell for 6 combinations
> on GCC5 (IA32/X64 for RELEASE/DEBUG/NOOPT) and the 12
> combinations of VS2015/VS2017, IA323/X64, RELEASE/DEBUG/NOOPT.
> 
> I have been working on some CI experiments using Azure Pipelines.
> Here is a pointer to the build logs for all the combinations 
> listed above.
> 
> https://dev.azure.com/mikekinney/edk2-ci/_build/results?buildId=312
> 
> Mike
> 
>> -Original Message-
>> From: Justen, Jordan L
>> Sent: Friday, August 16, 2019 12:41 AM
>> To: Kinney, Michael D ;
>> devel@edk2.groups.io
>> Cc: Ni, Ray ; Andrew Fish
>> 
>> Subject: Re: [Patch V4 06/10] EmulatorPkg: Fix XCODE5
>> lldb issues
>> 
>> On 2019-08-15 19:14:33, Michael D Kinney wrote:
>>> Fix scripts to support lldb symbolic debugging when
>> using XCODE5 tool
>>> chain.
>>> 
>>> Cc: Jordan Justen 
>>> Cc: Ray Ni 
>>> Cc: Michael D Kinney 
>>> Signed-off-by: Andrew Fish 
>> 
>> Is this a Cc/Signed-off-by typo? (See also, patches 7-
>> 10).
>> 
>> This makes me wonder if you are taking advantage of the
>> git commit -s switch to add your Signed-off-by.
>> 
>> Also, I'm wondering if you are taking advantage of git-
>> send-email automatically Cc'ing the addresses you
>> listed in the commit message.
>> (I thought it Cc'd for the author and Cc tags, but I
>> wasn't sure about the Signed-off-by tag, and yet I see
>> Andrew was Cc'd.)
>> 
>> There's a couple long lines below. You could use \ at
>> the end of the line to split the .sh line. I think the
>> cd can be a separate command in a shell script. (Not in
>> make)
>> 
>> I hope someone that uses the XCODE toolchain could
>> review/check the XCODE patches.
>> 
>> -Jordan
>> 
>>> ---
>>> EmulatorPkg/Unix/lldbefi.py |  8 +---
>>> EmulatorPkg/build.sh| 17 ++---
>>> 2 files changed, 7 insertions(+), 18 deletions(-)
>>> 
>>> diff --git a/EmulatorPkg/Unix/lldbefi.py
>> b/EmulatorPkg/Unix/lldbefi.py
>>> index 218326b8cb..099192d8b5 100755
>>> --- a/EmulatorPkg/Unix/lldbefi.py
>>> +++ b/EmulatorPkg/Unix/lldbefi.py
>>> @@ -346,6 +346,7 @@ def TypePrintFormating(debugger):
>>> debugger.HandleCommand("type summary add CHAR8 -
>> -python-function lldbefi.CHAR8_TypeSummary")
>>> debugger.HandleCommand('type summary add --regex
>> "CHAR8
>>> \[[0-9]+\]" --python-function
>> lldbefi.CHAR8_TypeSummary')
>>> 
>>> +debugger.HandleCommand('setting set frame-format
>> "frame
>>> + #${frame.index}: ${frame.pc}{
>>> +
>> ${module.file.basename}{:${function.name}()${function.p
>> c-offset}}}{
>>> + at ${line.file.fullpath}:${line.number}}\n"')
>>> 
>>> gEmulatorBreakWorkaroundNeeded = True
>>> 
>>> @@ -381,15 +382,16 @@ def
>> LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
>>> Error = lldb.SBError()
>>> FileNamePtr = frame.FindVariable
>> ("FileName").GetValueAsUnsigned()
>>> FileNameLen = frame.FindVariable
>>> ("FileNameLength").GetValueAsUnsigned()
>>> +
>>> FileName =
>> frame.thread.process.ReadCStringFromMemory
>> (FileNamePtr, FileNameLen, Error)
>>> if not Error.Success():
>>> print "!ReadCStringFromMemory() did not find
>> a %d byte C string at %x" % (FileNameLen, FileNamePtr)
>>> # make breakpoint command contiue
>>> -frame.GetThread().GetProcess().Continue()
>>> +return False
>>> 
>>> debugger = frame.thread.process.target.debugger
>>> if frame.FindVariable
>> ("AddSymbolFlag").GetValueAsUnsigned() == 1:
>>> -LoadAddress = frame.FindVariable
>> ("LoadAddress").GetValueAsUnsigned()
>>> +LoadAddress = frame.FindVariable
>>> + ("LoadAddress").GetValueAsUnsigned() - 0x240
>>> 
>>> debugger.HandleCommand ("target modules add
>> %s" % FileName)
>>> print "target modules load --slid 0x%x %s" %
>> (LoadAddress,
>>> FileName) @@ -405,7 +407,7 @@ def
>> LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
>>> print "!lldb.target.RemoveModule
>> (%s) FAILED" %
>>> SBModule
>>> 
>>> # make breakpoint command contiue
>>> -frame.thread.process.Continue()
>>> +return False
>>> 
>>> def GuidToCStructStr (guid, Name=False):
>>>   #
>>> diff --git a/EmulatorPkg/build.sh
>> b/EmulatorPkg/build.sh index
>>> 60056e1b6c..35912a7775 100755
>>> --- a/EmulatorPkg/build.sh
>>> +++ b/EmulatorPkg/build.sh
>>> @@ -209,21 +209,8 @@ fi
>>> if [[ "$RUN_E

Re: [edk2-devel] [edk2-platforms: PATCH v2 04/10] Marvell/Cn9130Db: Introduce board support

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:08AM +0200, Marcin Wojtas wrote:
> This patch introduces all necessary components required
> for building EDK2 firmware for CN9130-DB setup A.
> Because the board is modular and can be extended to support
> also CN9131 and CN9132 SoC variants, extract common part into
> .dsc.inc file, which will be included by them.
> 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc 
> | 107 +++
>  Platform/Marvell/Cn913xDb/Cn913xDbA.dsc 
> |  46 +++
>  Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf 
> |  29 
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf 
> |  37 +
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h   
> |  19 +++
>  Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c   
> | 126 +
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c   
> | 144 
>  Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc 
> |  18 +++
>  8 files changed, 526 insertions(+)
>  create mode 100644 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
>  create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
>  create mode 100644 
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf
>  create mode 100644 
> Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
>  create mode 100644 
> Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h
>  create mode 100644 
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c
>  create mode 100644 
> Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c
>  create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc
> 
> diff --git a/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc 
> b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
> new file mode 100644
> index 000..33fb7cc
> --- /dev/null
> +++ b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
> @@ -0,0 +1,107 @@
> +## @file
> +#  Component description file for the CN9130 Development Board (variant A)
> +#
> +#  Copyright (c) 2019 Marvell International Ltd.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +
> +#
> +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
> +#
> +
> +[PcdsFixedAtBuild.common]
> +  # CP115 count
> +  gMarvellTokenSpaceGuid.PcdMaxCpCount|1
> +
> +  # MPP
> +  gMarvellTokenSpaceGuid.PcdMppChipCount|2
> +
> +  # APN807 MPP
> +  gMarvellTokenSpaceGuid.PcdChip0MppReverseFlag|FALSE
> +  gMarvellTokenSpaceGuid.PcdChip0MppBaseAddress|0xF06F4000
> +  gMarvellTokenSpaceGuid.PcdChip0MppPinCount|20
> +  gMarvellTokenSpaceGuid.PcdChip0MppSel0|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
> 0x1, 0x1, 0x1, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdChip0MppSel1|{ 0x1, 0x3, 0x1, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x3 }
> +
> +  # CP115 #0 MPP
> +  gMarvellTokenSpaceGuid.PcdChip1MppReverseFlag|FALSE
> +  gMarvellTokenSpaceGuid.PcdChip1MppBaseAddress|0xF244
> +  gMarvellTokenSpaceGuid.PcdChip1MppPinCount|64
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel0|{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, 
> 0x3, 0x3, 0x3, 0x3 }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel1|{ 0x3, 0x3, 0x0, 0x3, 0x3, 0x3, 
> 0x3, 0x1, 0x1, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel2|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
> 0x1, 0x1, 0x3, 0x9 }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel3|{ 0x9, 0x3, 0x7, 0x6, 0x7, 0x2, 
> 0x2, 0x2, 0x2, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel4|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
> 0x1, 0x1, 0x1, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel5|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
> 0xE, 0xE, 0xE, 0xE }
> +  gMarvellTokenSpaceGuid.PcdChip1MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +
> +  # I2C
> +  gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x21 }
> +  gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0 }
> +  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x0, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdI2cClockFrequency|25000
> +  gMarvellTokenSpaceGuid.PcdI2cBaudRate|10
> +
> +  # SPI
> +  gMarvellTokenSpaceGuid.PcdSpiRegBase|0xF2700680
> +  gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|1000
> +  gMarvellTokenSpaceGuid.PcdSpiClockFrequency|2
> +
> +  gMarvellTokenSpaceGuid.PcdSpiFlashMode|3
> +  gMarvellTokenSpaceGuid.PcdSpiFlashCs|0
> +
> +  # ComPhy
> +  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1 }
> +  # ComPhy0
> +  # 0: PCIE0 5 Gbps
> +  # 1: PCIE0 5 Gbps
> +  # 2: PCIE0 5 Gbps
> +  # 3: PCIE0 5 Gbps
> +  # 4: SFI   10.31 Gbps
> +  # 5: SATA1 5 Gbps
> +  gMarvellTokenSpaceGuid.PcdChip0ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
> $(CP_PCIE0)

Re: [edk2-devel] [edk2-platforms: PATCH v2 05/10] Marvell/Library: ArmadaSoCDescLib: Extend Xenon information

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:09AM +0200, Marcin Wojtas wrote:
> Hitherto SoC description library code assumed that there could
> be only two Xenon SdMmc controller instances in the SoC. Remove this
> limitation, so that to support CN913x SoCs, which may have up to 4 of
> such interfaces.
> 
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
>  |  5 +--
>  
> Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
>  | 34 +---
>  2 files changed, 25 insertions(+), 14 deletions(-)
> 
> diff --git 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
>  
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> index 0296d43..265b4f4 100644
> --- 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> +++ 
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> @@ -90,8 +90,9 @@
>  //
>  // Platform description of SDMMC controllers
>  //
> -#define MV_SOC_MAX_SDMMC_COUNT   2
> -#define MV_SOC_SDMMC_BASE(Index) ((Index) == 0 ? 0xF06E : 
> 0xF278)
> +#define MV_SOC_SDMMC_PER_CP_COUNT1
> +#define MV_SOC_AP80X_SDMMC_BASE  0xF06E
> +#define MV_SOC_CP_SDMMC_BASE(Cp) (MV_SOC_CP_BASE (Cp) + 0x78)
>  
>  //
>  // Platform description of UTMI PHY's
> diff --git 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
>  
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
> index 5947601..3ffd57e 100644
> --- 
> a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
> +++ 
> b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
> @@ -349,26 +349,36 @@ EFI_STATUS
>  EFIAPI
>  ArmadaSoCDescSdMmcGet (
>IN OUT MV_SOC_SDMMC_DESC  **SdMmcDesc,
> -  IN OUT UINTN   *DescCount
> +  IN OUT UINTN   *Count
>)
>  {
> -  MV_SOC_SDMMC_DESC *Desc;
> -  UINTN Index;
> +  MV_SOC_SDMMC_DESC *SdMmc;
> +  UINTN CpCount, CpIndex;
>  
> -  Desc = AllocateZeroPool (MV_SOC_MAX_SDMMC_COUNT * sizeof 
> (MV_SOC_SDMMC_DESC));
> -  if (Desc == NULL) {
> +  CpCount = FixedPcdGet8 (PcdMaxCpCount);
> +
> +  *Count = CpCount * MV_SOC_SDMMC_PER_CP_COUNT + MV_SOC_AP806_COUNT;
> +  SdMmc = AllocateZeroPool (*Count * sizeof (MV_SOC_SDMMC_DESC));
> +  if (SdMmc == NULL) {
>  DEBUG ((DEBUG_ERROR, "%a: Cannot allocate memory\n", __FUNCTION__));
>  return EFI_OUT_OF_RESOURCES;
>}
>  
> -  for (Index = 0; Index < MV_SOC_MAX_SDMMC_COUNT; Index++) {
> -Desc[Index].SdMmcBaseAddress = MV_SOC_SDMMC_BASE (Index);
> -Desc[Index].SdMmcMemSize = SIZE_1KB;
> -Desc[Index].SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
> -  }
> +  *SdMmcDesc = SdMmc;
> +
> +  /* AP80x controller */
> +  SdMmc->SdMmcBaseAddress = MV_SOC_AP80X_SDMMC_BASE;
> +  SdMmc->SdMmcMemSize = SIZE_1KB;
> +  SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
> +  SdMmc++;
>  
> -  *SdMmcDesc = Desc;
> -  *DescCount = MV_SOC_MAX_SDMMC_COUNT;
> +  /* CP11x controllers */
> +  for (CpIndex = 0; CpIndex < CpCount; CpIndex++) {
> +SdMmc->SdMmcBaseAddress = MV_SOC_CP_SDMMC_BASE (CpIndex);
> +SdMmc->SdMmcMemSize = SIZE_1KB;
> +SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
> +SdMmc++;
> +  }
>  
>return EFI_SUCCESS;
>  }
> -- 
> 2.7.4
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45839): https://edk2.groups.io/g/devel/message/45839
Mute This Topic: https://groups.io/mt/32882737/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 06/10] Marvell/Library: MppLib: Allow to configure more Xenon PHYs

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:10AM +0200, Marcin Wojtas wrote:
> Hitherto MppLib code assumed that there could be only two
> Xenon SdMmc controllers' PHYs. Remove this limitation, so that to
> support CN913x SoCs, which may have up to 4 of such interfaces.

Should this be merged with the preceding patch?

/
Leif

> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Library/MppLib/MppLib.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/Silicon/Marvell/Library/MppLib/MppLib.c 
> b/Silicon/Marvell/Library/MppLib/MppLib.c
> index 40d9077..f20668d 100644
> --- a/Silicon/Marvell/Library/MppLib/MppLib.c
> +++ b/Silicon/Marvell/Library/MppLib/MppLib.c
> @@ -139,11 +139,9 @@ SetSdMmcPhyMpp (
>case 0:
>  Offset = SD_MMC_PHY_AP_MPP_OFFSET;
>  break;
> -  case 1:
> +  default:
>  Offset = SD_MMC_PHY_CP0_MPP_OFFSET;
>  break;
> -  default:
> -return;
>}
>  
>/*
> -- 
> 2.7.4
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45840): https://edk2.groups.io/g/devel/message/45840
Mute This Topic: https://groups.io/mt/32882738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 07/10] Marvell/Library: IcuLib: Fix debug information

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:11AM +0200, Marcin Wojtas wrote:
> In case the number of CP11x components exceeded the maximum
> of currently supported, the user is informed with the information.
> It turned out that the print arguments were incorrect - fix it.

Whoops.

> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Marvell/Library/IcuLib/IcuLib.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.c 
> b/Silicon/Marvell/Library/IcuLib/IcuLib.c
> index 422388c..8d99409 100644
> --- a/Silicon/Marvell/Library/IcuLib/IcuLib.c
> +++ b/Silicon/Marvell/Library/IcuLib/IcuLib.c
> @@ -285,8 +285,8 @@ ArmadaIcuInitialize (
>if (CpCount > ICU_MAX_SUPPORTED_UNITS) {
>  DEBUG ((DEBUG_ERROR,
>"%a: Default ICU to GIC mapping is available for maximum %d CP110 
> units",
> -  ICU_MAX_SUPPORTED_UNITS,
> -  __FUNCTION__));
> +  __FUNCTION__,
> +  ICU_MAX_SUPPORTED_UNITS));
>  CpCount = ICU_MAX_SUPPORTED_UNITS;
>}
>  
> -- 
> 2.7.4
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45841): https://edk2.groups.io/g/devel/message/45841
Mute This Topic: https://groups.io/mt/32882740/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 08/10] Marvell/Cn9131Db: Introduce board support

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:12AM +0200, Marcin Wojtas wrote:
> This patch introduces all necessary components required
> for building EDK2 firmware for CN9131-DB setup A.
> 
> In order to build this variant, '-D CN9131' flag should be added.
> Otherwise the default (CN9130) will be compiled.

Yeah, see comment on the CN9130 .dsc - if you change that as
requested, don't forget to update this commit message.

> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc   | 
> 72 ++
>  Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  
> 7 ++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf | 
> 57 
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf | 
> 22 +
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |  
> 2 +
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h  |  
> 2 +
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 
> 29 ++
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl| 
> 98 
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi| 
> 26 +++---
>  9 files changed, 303 insertions(+), 12 deletions(-)
>  create mode 100644 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf
>  create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl
> 
> diff --git a/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc 
> b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
> new file mode 100644
> index 000..7235b9f
> --- /dev/null
> +++ b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
> @@ -0,0 +1,72 @@
> +## @file
> +#  Component description file for the CN9131 Development Board (variant A)
> +#
> +#  Copyright (c) 2019 Marvell International Ltd.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +
> +#
> +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
> +#
> +
> +[PcdsFixedAtBuild.common]
> +  # CP115 count
> +  gMarvellTokenSpaceGuid.PcdMaxCpCount|2
> +
> +  # MPP
> +  gMarvellTokenSpaceGuid.PcdMppChipCount|3
> +
> +  # CP115 #1 MPP
> +  gMarvellTokenSpaceGuid.PcdChip2MppReverseFlag|FALSE
> +  gMarvellTokenSpaceGuid.PcdChip2MppBaseAddress|0xF444
> +  gMarvellTokenSpaceGuid.PcdChip2MppPinCount|64
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel1|{ 0x0, 0x0, 0x0, 0x3, 0x3, 0x3, 
> 0x3, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x9, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel3|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x7, 
> 0x7, 0x2, 0x2, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip2MppSel6|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +
> +  # ComPhy
> +  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1 }
> +  # ComPhy1
> +  # 0: PCIE0 5 Gbps
> +  # 1: PCIE0 5 Gbps
> +  # 2: UNCONNECTED
> +  # 3: USB3_HOST15 Gbps
> +  # 4: SFI   10.31 Gbps
> +  # 5: SATA1 5 Gbps
> +  gMarvellTokenSpaceGuid.PcdChip1ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
> $(CP_UNCONNECTED), $(CP_USB3_HOST1), $(CP_SFI), $(CP_SATA1)}
> +  gMarvellTokenSpaceGuid.PcdChip1ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
> $(CP_DEFAULT), $(CP_5G), $(CP_10_3125G), $(CP_5G) }
> +
> +  # UtmiPhy
> +  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
> $(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1) }
> +
> +  # MDIO
> +  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
> +
> +  # PHY
> +  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
> +
> +  # NET
> +  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_SPEED_1), 
> $(PHY_SPEED_1000), $(PHY_SPEED_1000), $(PHY_SPEED_1) }
> +  gMarvellTokenSpaceGuid.PcdPp2PhyConnectionTypes|{ $(PHY_SFI), 
> $(PHY_RGMII), $(PHY_RGMII), $(PHY_SFI) }
> +  gMarvellTokenSpaceGuid.PcdPp2PhyIndexes|{ 0xFF, 0x0, 0x1, 0xFF }
> +  gMarvellTokenSpaceG

Re: [edk2-devel] [edk2-platforms: PATCH v2 09/10] Marvell/Cn9132Db: Introduce board support

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:13AM +0200, Marcin Wojtas wrote:
> This patch introduces all necessary components required
> for building EDK2 firmware for CN9132-DB setup A. Note
> the ACPI is not yet available for this variant, due to
> the current ICU (CP1xx interrupt controller) support
> implementation.
> 
> In order to build this variant, '-D CN9132' flag should be added.
> Otherwise the default (CN9130) will be compiled.

Same comment on commit message - don't forget to update if logic
changed.

> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc   |  
> 72 +++
>  Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  
> 15 ++-
>  Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf   |  
> 29 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf |  
> 22 
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |  
>  4 +
>  Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c | 
> 135 
>  Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c |  
> 42 ++
>  Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc   |  
>  2 +
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts   |  
>  6 -
>  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi|  
> 20 ++-
>  10 files changed, 333 insertions(+), 14 deletions(-)
>  create mode 100644 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
>  create mode 100644 
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf
>  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf
>  create mode 100644 
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c
> 
> diff --git a/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc 
> b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
> new file mode 100644
> index 000..a0b90fa
> --- /dev/null
> +++ b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
> @@ -0,0 +1,72 @@
> +## @file
> +#  Component description file for the CN9132 Development Board (variant A)
> +#
> +#  Copyright (c) 2019 Marvell International Ltd.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +
> +#
> +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
> +#
> +
> +[PcdsFixedAtBuild.common]
> +  # CP115 count
> +  gMarvellTokenSpaceGuid.PcdMaxCpCount|3
> +
> +  # MPP
> +  gMarvellTokenSpaceGuid.PcdMppChipCount|4
> +
> +  # CP115 #2 MPP
> +  gMarvellTokenSpaceGuid.PcdChip3MppReverseFlag|FALSE
> +  gMarvellTokenSpaceGuid.PcdChip3MppBaseAddress|0xF644
> +  gMarvellTokenSpaceGuid.PcdChip3MppPinCount|64
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel1|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x9, 0x9, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel3|{ 0x0, 0x0, 0x8, 0x0, 0x8, 0x0, 
> 0x0, 0x2, 0x2, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0xA, 0xB, 
> 0xE, 0xE, 0xE, 0xE }
> +  gMarvellTokenSpaceGuid.PcdChip3MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 
> 0x0, 0x0, 0x0, 0x0 }
> +
> +  # ComPhy
> +  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1, 0x1 }
> +  # ComPhy1
> +  # 0: PCIE0 5 Gbps
> +  # 1: PCIE0 5 Gbps
> +  # 2: SATA0 5 Gbps
> +  # 3: USB3_HOST15 Gbps
> +  # 4: SFI   10.31 Gbps
> +  # 5: PCIE2 5 Gbps
> +  gMarvellTokenSpaceGuid.PcdChip2ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
> $(CP_SATA0), $(CP_USB3_HOST1), $(CP_SFI), $(CP_PCIE2)}
> +  gMarvellTokenSpaceGuid.PcdChip2ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
> $(CP_5G), $(CP_5G), $(CP_10_3125G), $(CP_5G) }
> +
> +  # UtmiPhy
> +  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1, 
> 0x1, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
> $(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1), $(UTMI_USB_HOST0), 
> $(UTMI_USB_HOST1) }
> +
> +  # MDIO
> +  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
> +
> +  # PHY
> +  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
> +
> +  # NET
> +  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0, 0x0 }
> +  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_S

Re: [edk2-devel] [edk2-platforms: PATCH v2 10/10] Marvell/Drivers: SmbiosPlatformDxe: Use more generic board name

[Leif Lindholm]

On Thu, Aug 15, 2019 at 04:54:14AM +0200, Marcin Wojtas wrote:
> SmbiosPlatformDxe is used both by Armada 7k8k and CN913x platforms.
> Replace board name placeholder in order to avoid confusion.

Stupid/lazy question - do we already specify the actual platform name
elsewhere?

/
Leif

> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> index 08f4fa7..cdacd90 100644
> --- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> +++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> @@ -102,7 +102,7 @@ STATIC SMBIOS_TABLE_TYPE1 mArmadaDefaultType1 = {
>  
>  STATIC CHAR8 CONST *mArmadaDefaultType1Strings[] = {
>"Marvell\0",/* Manufacturer */
> -  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
> +  "Marvell Development Board  \0",/* Product Name placeholder*/
>"Revision unknown   \0",/* Version placeholder */
>"   \0",/* 32 character buffer */
>NULL
> @@ -130,7 +130,7 @@ STATIC SMBIOS_TABLE_TYPE2 mArmadaDefaultType2 = {
>  
>  STATIC CHAR8 CONST *mArmadaDefaultType2Strings[] = {
>"Marvell\0",/* Manufacturer */
> -  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
> +  "Marvell Development Board  \0",/* Product Name placeholder*/
>"Revision unknown   \0",/* Version placeholder */
>"Serial Not Set \0",/* Serial */
>"Base of Chassis\0",/* Board location */
> -- 
> 2.7.4
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45844): https://edk2.groups.io/g/devel/message/45844
Mute This Topic: https://groups.io/mt/32882743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

[Jordan Justen]

On 2019-08-16 08:09:55, Kinney, Michael D wrote:
> Jordan,
> 
> It is not a typo.
> 
> Andrew generated the XCODE specific changes, so they have 
> been tested by him.

In that case, is the git author for the patches set to Andrew? If it
was, I would expect to see a line inside the email body with:

From: Andrew Fish 

Git does that for patches where the sender doesn't match the patch
author.

You might want to rebase and run:

git commit --amend --author="Andrew Fish " --reset-author

to change the author.

I expect you might want to add Reviewed-by for yourself on these
patches to help speed things along. If Andrew authored the patch, you
reviewed it, and with a quick review it looked good to me, I would
probably add an Acked-by for some of the patches.

-Jordan

> I have also reviewed and tested the XCODE
> changes and verified that all 6 combinations build and boot
> to shell (IA32/X64 for RELEASE/DEBUG/NOOPT). Since they are
> all related to making EmulatorPkg work, we decided to fold
> them into the same patch set that was already being reviewed.
> 
> I also verified build and boot to shell for 6 combinations
> on GCC5 (IA32/X64 for RELEASE/DEBUG/NOOPT) and the 12
> combinations of VS2015/VS2017, IA323/X64, RELEASE/DEBUG/NOOPT.
> 
> I have been working on some CI experiments using Azure Pipelines.
> Here is a pointer to the build logs for all the combinations 
> listed above.
> 
> https://dev.azure.com/mikekinney/edk2-ci/_build/results?buildId=312
> 
> Mike
> 
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Friday, August 16, 2019 12:41 AM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io
> > Cc: Ni, Ray ; Andrew Fish
> > 
> > Subject: Re: [Patch V4 06/10] EmulatorPkg: Fix XCODE5
> > lldb issues
> > 
> > On 2019-08-15 19:14:33, Michael D Kinney wrote:
> > > Fix scripts to support lldb symbolic debugging when
> > using XCODE5 tool
> > > chain.
> > >
> > > Cc: Jordan Justen 
> > > Cc: Ray Ni 
> > > Cc: Michael D Kinney 
> > > Signed-off-by: Andrew Fish 
> > 
> > Is this a Cc/Signed-off-by typo? (See also, patches 7-
> > 10).
> > 
> > This makes me wonder if you are taking advantage of the
> > git commit -s switch to add your Signed-off-by.
> > 
> > Also, I'm wondering if you are taking advantage of git-
> > send-email automatically Cc'ing the addresses you
> > listed in the commit message.
> > (I thought it Cc'd for the author and Cc tags, but I
> > wasn't sure about the Signed-off-by tag, and yet I see
> > Andrew was Cc'd.)
> > 
> > There's a couple long lines below. You could use \ at
> > the end of the line to split the .sh line. I think the
> > cd can be a separate command in a shell script. (Not in
> > make)
> > 
> > I hope someone that uses the XCODE toolchain could
> > review/check the XCODE patches.
> > 
> > -Jordan
> > 
> > > ---
> > >  EmulatorPkg/Unix/lldbefi.py |  8 +---
> > >  EmulatorPkg/build.sh| 17 ++---
> > >  2 files changed, 7 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/EmulatorPkg/Unix/lldbefi.py
> > b/EmulatorPkg/Unix/lldbefi.py
> > > index 218326b8cb..099192d8b5 100755
> > > --- a/EmulatorPkg/Unix/lldbefi.py
> > > +++ b/EmulatorPkg/Unix/lldbefi.py
> > > @@ -346,6 +346,7 @@ def TypePrintFormating(debugger):
> > >  debugger.HandleCommand("type summary add CHAR8 -
> > -python-function lldbefi.CHAR8_TypeSummary")
> > >  debugger.HandleCommand('type summary add --regex
> > "CHAR8
> > > \[[0-9]+\]" --python-function
> > lldbefi.CHAR8_TypeSummary')
> > >
> > > +debugger.HandleCommand('setting set frame-format
> > "frame
> > > + #${frame.index}: ${frame.pc}{
> > > +
> > ${module.file.basename}{:${function.name}()${function.p
> > c-offset}}}{
> > > + at ${line.file.fullpath}:${line.number}}\n"')
> > >
> > >  gEmulatorBreakWorkaroundNeeded = True
> > >
> > > @@ -381,15 +382,16 @@ def
> > LoadEmulatorEfiSymbols(frame, bp_loc , internal_dict):
> > >  Error = lldb.SBError()
> > >  FileNamePtr = frame.FindVariable
> > ("FileName").GetValueAsUnsigned()
> > >  FileNameLen = frame.FindVariable
> > > ("FileNameLength").GetValueAsUnsigned()
> > > +
> > >  FileName =
> > frame.thread.process.ReadCStringFromMemory
> > (FileNamePtr, FileNameLen, Error)
> > >  if not Error.Success():
> > >  print "!ReadCStringFromMemory() did not find
> > a %d byte C string at %x" % (FileNameLen, FileNamePtr)
> > >  # make breakpoint command contiue
> > > -frame.GetThread().GetProcess().Continue()
> > > +return False
> > >
> > >  debugger = frame.thread.process.target.debugger
> > >  if frame.FindVariable
> > ("AddSymbolFlag").GetValueAsUnsigned() == 1:
> > > -LoadAddress = frame.FindVariable
> > ("LoadAddress").GetValueAsUnsigned()
> > > +LoadAddress = frame.FindVariable
> > > + ("LoadAddress").GetValueAsUnsigned() - 0x240
> > >
> > >  debugger.HandleCommand ("target modules add
> > %s" % FileName)
> > >  print "target modules load --slid 0x%x %s" %
> > (Load

Re: [edk2-devel] [Patch V4 09/10] EmulatorPkg/Sec: Change local variable scope for XCODE5

[Jordan Justen]

On 2019-08-15 19:14:36, Michael D Kinney wrote:
> The local variable PpiArray[10] is declared in middle
> of the SEC module _ModuleEntryPoint().  When building
> for XCODE5 with optimizations enabled, this results in
> corruption and an exception.

It looks like with old code, the scope containing PpiArray was closed,
but a dangling reference to had been made to it's location on the
stack. So, I think the change is good but we should add this extra
detail to the commit message.

-Jordan

> The fix is to move the
> declaration of PpiArray[10] to the standard location
> at the beginning of the function so the storage for
> this local variable is allocated for the entire
> lifetime of the function.
> 
> Cc: Jordan Justen 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Signed-off-by: Andrew Fish 
> ---
>  EmulatorPkg/Sec/Sec.c | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/EmulatorPkg/Sec/Sec.c b/EmulatorPkg/Sec/Sec.c
> index 701032233b..b734d2bb87 100644
> --- a/EmulatorPkg/Sec/Sec.c
> +++ b/EmulatorPkg/Sec/Sec.c
> @@ -75,6 +75,7 @@ _ModuleEntryPoint (
>EFI_PEI_PPI_DESCRIPTOR*SecPpiList;
>UINTN SecReseveredMemorySize;
>UINTN Index;
> +  EFI_PEI_PPI_DESCRIPTORPpiArray[10];
>
>EMU_MAGIC_PAGE()->PpiList = PpiList;
>ProcessLibraryConstructorList ();
> @@ -104,16 +105,13 @@ _ModuleEntryPoint (
>SecCoreData->PeiTemporaryRamBase = (VOID 
> *)((UINTN)SecCoreData->PeiTemporaryRamBase + SecReseveredMemorySize);
>SecCoreData->PeiTemporaryRamSize -= SecReseveredMemorySize;
>  #else
> -  {
> -//
> -// When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core 
> crashes? Either there is a bug
> -// or I don't understand temp RAM correctly?
> -//
> -EFI_PEI_PPI_DESCRIPTORPpiArray[10];
> +  //
> +  // When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core crashes? 
> Either there is a bug
> +  // or I don't understand temp RAM correctly?
> +  //
>
> -SecPpiList = &PpiArray[0];
> -ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize);
> -  }
> +  SecPpiList = &PpiArray[0];
> +  ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize);
>  #endif
>// Copy existing list, and append our entries.
>CopyMem (SecPpiList, PpiList, sizeof (EFI_PEI_PPI_DESCRIPTOR) * Index);
> -- 
> 2.21.0.windows.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45846): https://edk2.groups.io/g/devel/message/45846
Mute This Topic: https://groups.io/mt/32894354/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Determining TSC frequency programmatically

[Andrew Fish via Groups.Io]

Vitaly,

As Mike mentioned platforms can know more info about how they are constructed 
thus you may not want to have a lot of generic discovery code floating about if 
you don't really need it. 

One option could be to pass up the TSC Frequency/Period via some EFI mechanism 
so generic code can be told by platform specific code. 

The PI spec already has an abstraction for a CPU based timer that is 
architecture neutral. The CPU Architectural Protocol has a GetTimerValue() 
member function. 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Cpu.h#L220

For X86 it returns TSC
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuDxe.c#L289

EFI Systems are not required to implement PI so we usually don't encourage 
generic EFI code to go after PI APIs. 

I'd also point out that using TSC can break in things like the EmulatorPkg as 
you end up running in ring 0 and TSC access is blocked. 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/CpuRuntimeDxe/Cpu.c#L352
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/EmuThunk.c#L250


I would point that a library that did TSC frequency discovery would likely be 
useful for the UefiCpuPkg CpuDxe driver. 

Thanks,

Andrew Fish

> On Aug 15, 2019, at 2:10 PM, Vitaly Cheptsov via Groups.Io 
>  wrote:
> 
> Hello,
> 
> I initially raised this question in a new TimerLib patch[1], but as the 
> discussion was getting more distracted, I decided to create a separate thread 
> in hopes new people could join.
> 
> The issue is that our UEFI bootloader needs to obtain TSC frequency to pass 
> it to our specialised operating system that uses TSC for scheduling on x86.
> 
> For a while we went with ACPI power management timer to measure the 
> frequency, but as modern Intel CPUs support CPUID 15H leaf 
> (CPUID_TIME_STAMP_COUNTER) we try to use where possible for better accuracy. 
> The issue with this CPUID leaf is that the crystal clock frequency returned 
> in ECX register is optional and therefore can be 0. Intel SDM suggests to use 
> a static value in this case[2], but it is completely opaque on how to match 
> the running CPU with its static value from SDM.
> 
> Initially we went with CPUID model checking, but this failed badly for Xeon 
> Scalable and Xeon W, as they share the CPUID (06_55H) but have different 
> crystal clock frequencies (25 MHz vs 24 MHz accordingly). Donald Kuo gave a 
> good hint in the previous thread that client CPUs usually get 24 MHz crystal 
> clock, server CPUs have 25, and Atoms have 19.2. This, however, does not make 
> the situation easier as we do not see a way to determine CPU vertical segment 
> without e.g. parsing the CPUID brand string.
> 
> Apparently, we are not alone, and different open-source operating systems 
> have different workarounds to this issue. For example, Linux kernel went with 
> using marketing frequency from CPUID 16H leaf (CPUID_PROCESSOR_FREQUENCY)[3], 
> and BSD flavours fallback to older methods when neither crystal clock 
> frequency can be obtained through CPUID 15H, nor unambiguous CPUID models 
> exist to be able to use static values.
> 
> Another issue we see with EDK II TimerLib implementations for x86 is that 
> they are very model specific. As Michael Kinney said, the situation is not a 
> problem when you use TimerLib for BSP bringup, as you already know the CPU 
> family you target, however, it is not great for other uses, although they may 
> be discouraged. In our opinion, regardless of the use, this approach has a 
> number of design issues.
> 
> All modern Intel x86 CPUs have virtual TSC counter that has fixed frequency. 
> In fact, this is true for most, if not all, modern x86 CPUs by other vendors 
> as well. This makes us believe that EDK II should have generic TscTimerLib 
> for x86, which will work anywhere when given valid TSC frequency, and 
> TscFrequencyLib, which would determine TSC frequency in a vendor-specific 
> method. Ideally there exists GenericTscFrequencyLib that can do this for a 
> wide majority of CPUs through different methods at runtime, including CPUID 
> 15H, ACPI power management, vendor-specific extensions, etc.
> 
> To summarise:
> - We need to know how to match current running CPU with its crystal clock 
> frequency when CPUID 15H reports 0 ECX.
> - We would like to suggest to split TSC-based TimerLib in two libraries: 
> generic with timer implementation and platform-specific with TSC frequency 
> discovery.
> - We wonder whether a generic vendor-supported TSC frequency discovery 
> library working on a wide range of CPUs is feasible to have in EDK II 
> mainline.
> 
> Best regards,
> Vitaly
> 
> [1] 
> https://edk2.groups.io/g/devel/topic/patch_ueficpupkg_adding_a/32839184?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32839184
>  
> 
> [PATCH] UefiCpuPkg: Adding a new TSC libra

Re: [edk2-devel] Patch List for 201908 stable tag

[Laszlo Ersek]

On 08/16/19 10:00, Gao, Liming wrote:
> 
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Friday, August 16, 2019 3:59 PM
> To: Laszlo Ersek (ler...@redhat.com) ; 
> leif.lindh...@linaro.org; Kinney, Michael D ; 
> af...@apple.com; Cetola, Stephano 
> Cc: edk2-de...@lists.01.org
> Subject: Patch List for 201908 stable tag
> 
> Hi Stewards and all:
>   I collect current patch lists in devel mail list. Those patch contributors 
> request to add them for 201908 stable tag. Because the time is very close to 
> Soft Feature Freeze, I want to collect your feedback for below patches.
> 
> Feature List (those all have pass code review):
> https://edk2.groups.io/g/devel/message/45734 [PATCH v6 0/5] Build cache 
> enhancement

Seems to be well documented (both in commit messages and in the BZ), and
the series was approved by a BaseTools maintainer [1] before the soft
feature freeze [2].

[1] https://edk2.groups.io/g/devel/message/45783
[2] https://edk2.groups.io/g/devel/message/45806

The series can be pushed during the soft feature freeze, according to
the current SFF definition.

Some requests regarding the bugzilla:

- Comment 0 in the bugzilla says "redesign the platform hash algorithm".
I feel that would be better reflected if we changed the Product field to
TianoCore Feature Requests.

- Please capture the v1..v6 cover letters, with mailing list archive
links, in the bugzilla.

> https://edk2.groups.io/g/devel/message/45707 [PATCH] UefiCpuPkg: Adding a new 
> TSC library by using CPUID(0x15) TSC leaf

Accepted by a UefiCpuPkg maintainer [3] before the SFF [2].

[3] https://edk2.groups.io/g/devel/message/45787

Can be pushed during the soft feature freeze, according to the current
SFF definition.

According to my comments sent earlier today for this series, the
documentation and the bugzilla status are extremely lacking. I'm OK with
pushing the series, but those aspects should be fixed in the bugzilla.
Please see .

In addition, it appears multiple versions of the patch have been sent,
without using "vN" identifiers in the subject prefix. Please collect all
versions of the patch series from the mailing list archive, in
chronological order, and link them all into the bugzilla ticket.

> https://edk2.groups.io/g/devel/message/45503 [PATCH v2 1/1] MdePkg: Add 
> STATIC_ASSERT macro

I commented on this today, as well:


I disagree with the maintainer approval for this patch, from a reviewer
perspective. I think the submission isn't complete enough / mature
enough at this stage. The first version of the patch was posted on 12
Aug , as far as I can see.
Why are we in a mortal hurry to add a central macro without any call
sites in edk2 proper?

Anyway I'm not going to NACK the patch. If Mike is fine with the patch
as-is, I'll live with that, with my disagreement noted.

> Bug List:
> https://edk2.groups.io/g/devel/message/45794  [PATCH 1/1] CryptoPkg: Fix 
> coding style

Purely from the subject line, looks like a bugfix, so no conflict with
the *soft* feature freeze.

> https://edk2.groups.io/g/devel/message/45791 [PATCH v2 1/1] 
> ShellPkg/UefiShellAcpiViewCommandLib: Replace shift logical left

Clearly a bugfix, so ditto.

> https://edk2.groups.io/g/devel/message/45793 [Patch 1/1] BaseTools: Fixed 
> issue of incorrect Module Unique Name

Ditto.

> https://edk2.groups.io/g/devel/message/45773 [Patch v4 0/6] Add "test then 
> write" mechanism

Sigh, this is a messy question.

To my eyes, this introduces a feature. The cover letter says "add ...
mechanism". Even though it is used to fix a bug, it still introduces a
new facility, in my opinion. So here I disagree with
.

For UefiCpuPkg, Ray and Eric are Maintainers, and I'm a reviewer. The
submitter is Eric, and Ray is away. Eric asked me to review
.

I reviewed v2. Then v3 was posted (not sure in response to what, as I
can't see any comments under v2 that requested the v3 changes). V3
received a bunch of comments, so v4 was posted quickly afterwards.

The posting of v4 was still in time for the SFF, but I only arrived at
it after the SFF. (And Ray is still away.) Technically speaking, in my
book, this series has missed the stable tag. But that's not the
submitter's fault, arguably.

On this, I am undecided. I will defer to the other stewards. If they are
fine with the series going in, I'm OK too.

> https://edk2.groups.io/g/devel/message/45317 [Patch] MdeModulePkg DxeCore: 
> Fix for missing MAT update

This is a bugfix and therefore there is no conflict with the soft
feature freeze. Jian provided a maintainer R-b, and I asked for a
comment style cleanup and some documentation (commit message)
improvements. In addition, perhaps we should conditionalize the logic on
the gEfiMemoryTypeInformationGuid GUID HOB. (The discussion between

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

[Laszlo Ersek]

On 08/16/19 17:24, Gao, Liming wrote:
> Laszlo:
>
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, August 16, 2019 11:18 PM
>> To: Gao, Liming ; devel@edk2.groups.io; Kinney,
>> Michael D 
>> Cc: Mike Turner ; Wang, Jian J
>> ; Wu, Hao A ; Bi, Dandan
>> 
>> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for
>> missing MAT update
>>
>> On 08/14/19 17:55, Gao, Liming wrote:
>>
>>> If Platform PEIM doesn't build HOB, DxeIpl will not build HOB,
>>
>> My reading of the code is the opposite. If the platform PEIM does not
>> build the HOB, then the DXE IPL PEIM will attempt to build the HOB,
>> from the UEFI variable.
>>
>> At commit caa7d3a896f6, in file
>> "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c", function DxeLoadCore(), we
>> have:
>>
>>363if (GetFirstGuidHob ((CONST EFI_GUID 
>> *)&gEfiMemoryTypeInformationGuid) == NULL) {
>>364  //
>>365  // Don't build GuidHob if GuidHob has been installed.
>>366  //
>>367  Status = PeiServicesLocatePpi (
>>368 &gEfiPeiReadOnlyVariable2PpiGuid,
>>369 0,
>>370 NULL,
>>371 (VOID **)&Variable
>>372 );
>>373  if (!EFI_ERROR (Status)) {
>>374DataSize = sizeof (MemoryData);
>>375Status = Variable->GetVariable (
>>376 Variable,
>>377 EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
>>378 &gEfiMemoryTypeInformationGuid,
>>379 NULL,
>>380 &DataSize,
>>381 &MemoryData
>>382 );
>>383if (!EFI_ERROR (Status) && 
>> ValidateMemoryTypeInfoVariable(MemoryData, DataSize)) {
>
> Only when this variable exists, Hob will be built. But, if no PEIM
> builds Hob, BDS will not set the variable.
> So, there is still no HOB.

So how is a platform supposed to enable this feature?

If PlatformPei never builds the HOB, the variable will never be created,
so the DXE IPL PEIM will also not build the HOB, ever.

If PlatformPei builds the HOB with static data, then BDS will set
(update) the variable, yes, but the DXE IPL PEIM will ignore the
variable, because PlatformPei already built the HOB.

So... Is PlatformPei supposed to use the Variable PPI, check if the
variable exists, and create the static HOB only if the variable is
absent?

... Ugh, wait. I've actually implemented this for OVMF almost 2 years
ago! And the answer to my question is "yes":

  https://bugzilla.tianocore.org/show_bug.cgi?id=386
  https://lists.01.org/pipermail/edk2-devel/2017-November/018312.html

See the OnReadOnlyVariable2Available() function:

+  //
+  // Check if the "MemoryTypeInformation" variable exists, in the
+  // gEfiMemoryTypeInformationGuid namespace.
+  //
+  ReadOnlyVariable2 = Ppi;
+  DataSize = 0;
+  Status = ReadOnlyVariable2->GetVariable (
+ReadOnlyVariable2,
+EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
+&gEfiMemoryTypeInformationGuid,
+NULL,
+&DataSize,
+NULL
+);
+  if (Status == EFI_BUFFER_TOO_SMALL) {
+//
+// The variable exists; the DXE IPL PEIM will build the HOB from it.
+//
+return EFI_SUCCESS;
+  }
+  //
+  // Install the default memory type information HOB.
+  //
+  BuildMemTypeInfoHob ();

Apologies for forgetting about this; you are right.

Too bad my work for TianoCore#386 was rejected. :(

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45849): https://edk2.groups.io/g/devel/message/45849
Mute This Topic: https://groups.io/mt/32821535/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Laszlo Ersek]

On 08/16/19 19:23, vit9...@protonmail.com wrote:
> Laszlo,
>
> I have already mentioned that the documentation is sufficient as
> _Static_assert is C standard

Yes, in a release of the ISO C standard that edk2 does not target.

In addition, edk2 already has several restrictions in place against
standards-conformant code. (Such as bit-shifting of UINT64 values,
initialization of structures with automatic storage duration, structure
assignment, maybe more.)

> so I do not plan to make a V3 for this patch.

I find that regrettable.

> The patch is merge ready.

Such statements are usually made when people that comment on a patch
arrive at a consensus. The patch may be merge-ready from your
perspective and from Mike's. It is not merge-ready from my perspective.
I hope I'm allowed to comment (constructively) on patches that aren't
strictly aimed at the subsystems I co-maintain.

> As for usage examples I have an opposing opinion to yours and believe
> it is based on very good reasons. Not using STATIC_ASSERT in the
> current release will make the feature optionally available and let
> people test it in their setups.

Not using STATIC_ASSERT in the current stable release makes the
STATIC_ASSERT macro definition *dead code* in edk2 proper. I understand
that edk2 is a "kit", and quite explicitly caters to out-of-tree
platforms. That's not a positive trait of edk2 however; it's a negative
one, in my judgement. Whatever we add to the core of edk2, we should
exercise as diligently as we can *inside* of edk2.

> In case they notice it does not work for them they will have 3 months
> grace period to report it to us and consider making a change.

That is what the feature freezes are for. The feature is reviewed before
the soft feature freeze, merged (at the latest) during the soft feature
freeze, and bugs can still be fixed during the hard feature freeze. The
community is expected to test diligently during the hard feature freeze.
Perhaps we should extend the hard feature freeze.

My problem is not that the change is not "in your face". I'm all for
avoiding regressions. My problem is that the code is dead and untestable
without platform changes, even though it could be put to great use in
core code at once. If you think that's too risky, this close to the
stable tag, then one solution is to resubmit at the beginning of the
next development cycle (again with additional patches that utilize the
STATIC_ASSERT macro at once). Developers will then have close to three
months to report and fix issues.

Another solution would be to conditionally keep VERIFY_SIZE_OF, vs.
using STATIC_ASSERT, for expressing the build-time invariants. The
default would be STATIC_ASSERT. Should it break, people could
immediately switch back to VERIFY_SIZE_OF, without disruption to their
workflows.

We've done similar things in OvmfPkg in the past. For example:
- USE_LEGACY_ISA_STACK (commit a06810229618 / commit 562688707145),
- USE_OLD_BDS (commit 79c098b6d25d / commit dd43486577b3),
- USE_OLD_PCI_HOST (commit 4014885ffdfa / commit cef83a3050e5).

> This will also give them 3 months grace period of VERIFY_SIZE_OF macro
> removal in favour of STATIC_ASSERT. Making the change now will let
> people do seamless transition to the new feature and will avoid
> obstacles you are currently trying to create.

Please stop making claims in bad faith. I'm not trying to "create
obstacles". I'm a fan of STATIC_ASSERT. I'm not a fan of dead code.

> Thus STATIC_ASSERT usage and VERIFY_SIZE_OF removal must both be
> separate patchsets with potentially separate BZs.
>
> Thanks for understanding,

Why are you presenting this as a done deal? The v2 patch was submitted
three days ago, IIUC.

Also, I wish we could have this discussion without condescension.

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45850): https://edk2.groups.io/g/devel/message/45850
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Laszlo Ersek]

On 08/15/19 18:08, Michael D Kinney wrote:
> Reviewed-by: Michael D Kinney 

To summarize: personally, I disgree, but I can accept if the patch goes
in with Mike's R-b.

Thanks,
Laszlo

>> -Original Message-
>> From: devel@edk2.groups.io
>> [mailto:devel@edk2.groups.io] On Behalf Of vit9696 via
>> Groups.Io
>> Sent: Tuesday, August 13, 2019 1:17 AM
>> To: devel@edk2.groups.io
>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>> STATIC_ASSERT macro
>>
>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
>>
>> Provide a macro for compile time assertions.
>> Equivalent to C11 static_assert macro from assert.h.
>>
>> Signed-off-by: Vitaly Cheptsov 
>> ---
>>  MdePkg/Include/Base.h | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/MdePkg/Include/Base.h
>> b/MdePkg/Include/Base.h index
>> ce20b5f01dce..f85f7028a262 100644
>> --- a/MdePkg/Include/Base.h
>> +++ b/MdePkg/Include/Base.h
>> @@ -843,6 +843,17 @@ typedef UINTN  *BASE_LIST;
>> #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)-
>>> Field))  #endif
>>
>> +///
>> +/// Portable definition for compile time assertions.
>> +/// Equivalent to C11 static_assert macro from
>> assert.h.
>> +/// Takes condtion and error message as its arguments.
>> +///
>> +#ifdef _MSC_EXTENSIONS
>> +  #define STATIC_ASSERT static_assert
>> +#else
>> +  #define STATIC_ASSERT _Static_assert
>> +#endif
>> +
>>  /**
>>Macro that returns a pointer to the data structure
>> that contains a specified field of
>>that data structure.  This is a lightweight method
>> to hide information by placing a
>> --
>> 2.20.1 (Apple Git-117)
>>
>>
>> -=-=-=-=-=-=
>> Groups.io Links: You receive all messages sent to this
>> group.
>>
>> View/Reply Online (#45503):
>> https://edk2.groups.io/g/devel/message/45503
>> Mute This Topic: https://groups.io/mt/32850582/1643496
>> Group Owner: devel+ow...@edk2.groups.io
>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>> [michael.d.kin...@intel.com]
>> -=-=-=-=-=-=
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45851): https://edk2.groups.io/g/devel/message/45851
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update

[Laszlo Ersek]

On 08/16/19 17:39, Liming Gao wrote:
> From: Mike Turner 
> 
> The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across
> reboots, and then does an AllocatePage for that memory address.
> If, on this boot, that memory comes from a Runtime memory bucket,
> the MAT table is not updated. This causes Windows to boot into Recovery.
> 
> This patch blocks the memory manager from changing the page
> from a special bucket to a different memory type.  Once the buckets are
> allocated, we freeze the memory ranges for the OS, and fragmenting
> the special buckets will cause errors resuming from hibernate (S4).
> 
> The references to S4 here are the use case that fails.  This
> failure is root caused to an inconsistent behavior of the
> core memory services themselves when type AllocateAddress is used.
> 
> The main issue is apparently with the UEFI memory map -- the UEFI memory
> map reflects the pre-allocated bins, but the actual allocations at fixed
> addresses may go out of sync with that. Everything else, such as:
> - EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync,
> - S4 failing
> are just symptoms / consequences.
> 
> This patch is cherry pick from Project Mu:
> https://github.com/microsoft/mu_basecore/commit/a9be767d9be96af94016ebd391ea6f340920735a
> With the minor change,
> 1. Update commit message format to keep the message in 80 characters one line.
> 2. Remove // MU_CHANGE comments in source code.
> 3. Update comments style to follow edk2 style.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> Signed-off-by: Liming Gao 
> ---
> In v2, add more description for this issue. 
> 
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 41 
> ++--
>  1 file changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c 
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index bd9e116aa5..1f0e3d94b9 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1265,12 +1265,13 @@ CoreInternalAllocatePages (
>IN BOOLEANNeedGuard
>)
>  {
> -  EFI_STATUS  Status;
> -  UINT64  Start;
> -  UINT64  NumberOfBytes;
> -  UINT64  End;
> -  UINT64  MaxAddress;
> -  UINTN   Alignment;
> +  EFI_STATUS   Status;
> +  UINT64   Start;
> +  UINT64   NumberOfBytes;
> +  UINT64   End;
> +  UINT64   MaxAddress;
> +  UINTNAlignment;
> +  EFI_MEMORY_TYPE  CheckType;
>  
>if ((UINT32)Type >= MaxAllocateType) {
>  return EFI_INVALID_PARAMETER;
> @@ -1321,6 +1322,7 @@ CoreInternalAllocatePages (
>// if (Start + NumberOfBytes) rolls over 0 or
>// if Start is above MAX_ALLOC_ADDRESS or
>// if End is above MAX_ALLOC_ADDRESS,
> +  // if Start..End overlaps any tracked MemoryTypeStatistics range
>// return EFI_NOT_FOUND.
>//
>if (Type == AllocateAddress) {
> @@ -1336,6 +1338,33 @@ CoreInternalAllocatePages (
>  (End > MaxAddress)) {
>return EFI_NOT_FOUND;
>  }
> +
> +//
> +// A driver is allowed to call AllocatePages using an AllocateAddress 
> type.  This type of
> +// AllocatePage request the exact physical address if it is not used.  
> The existing code
> +// will allow this request even in 'special' pages.  The problem with 
> this is that the
> +// reason to have 'special' pages for OS hibernate/resume is defeated as 
> memory is
> +// fragmented.
> +//
> +
> +for (CheckType = (EFI_MEMORY_TYPE) 0; CheckType < EfiMaxMemoryType; 
> CheckType++) {
> +  if (MemoryType != CheckType &&
> +  mMemoryTypeStatistics[CheckType].Special &&
> +  mMemoryTypeStatistics[CheckType].NumberOfPages > 0) {
> +if (Start >= mMemoryTypeStatistics[CheckType].BaseAddress &&
> +Start <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
> +  return EFI_NOT_FOUND;
> +}
> +if (End >= mMemoryTypeStatistics[CheckType].BaseAddress &&
> +End <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
> +  return EFI_NOT_FOUND;
> +}
> +if (Start < mMemoryTypeStatistics[CheckType].BaseAddress &&
> +End   > mMemoryTypeStatistics[CheckType].MaximumAddress) {
> +  return EFI_NOT_FOUND;
> +}
> +  }
> +}
>}
>  
>if (Type == AllocateMaxAddress) {
> 

Acked-by: Laszlo Ersek 

Please wait for maintainer approval too.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45852): https://edk2.groups.io/g/devel/message/45852
Mute This Topic: https://groups.io/mt/32899946/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Laszlo Ersek]

On 08/15/19 18:21, Paolo Bonzini wrote:
> On 15/08/19 17:00, Laszlo Ersek wrote:
>> On 08/14/19 16:04, Paolo Bonzini wrote:
>>> On 14/08/19 15:20, Yao, Jiewen wrote:
> - Does this part require a new branch somewhere in the OVMF SEC code?
>   How do we determine whether the CPU executing SEC is BSP or
>   hot-plugged AP?
 [Jiewen] I think this is blocked from hardware perspective, since the 
 first instruction.
 There are some hardware specific registers can be used to determine if the 
 CPU is new added.
 I don’t think this must be same as the real hardware.
 You are free to invent some registers in device model to be used in OVMF 
 hot plug driver.
>>>
>>> Yes, this would be a new operation mode for QEMU, that only applies to
>>> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
>>> fact it doesn't reply to anything at all.
>>>
> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>   it should execute code at a particular pflash location.)
 [Jiewen] Same real mode reset vector at :FFF0.
>>>
>>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
>>> QEMU.  The AP does not start execution at all when it is unplugged, so
>>> no cache-as-RAM etc.
>>>
>>> We only need to modify QEMU so that hot-plugged APIs do not reply to
>>> INIT/SIPI/SMI.
>>>
 I don’t think there is problem for real hardware, who always has CAR.
 Can QEMU provide some CPU specific space, such as MMIO region?
>>>
>>> Why is a CPU-specific region needed if every other processor is in SMM
>>> and thus trusted.
>>
>> I was going through the steps Jiewen and Yingwen recommended.
>>
>> In step (02), the new CPU is expected to set up RAM access. In step
>> (03), the new CPU, executing code from flash, is expected to "send board
>> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
>> message." For that action, the new CPU may need a stack (minimally if we
>> want to use C function calls).
>>
>> Until step (03), there had been no word about any other (= pre-plugged)
>> CPUs (more precisely, Jiewen even confirmed "No impact to other
>> processors"), so I didn't assume that other CPUs had entered SMM.
>>
>> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
>> as I can. I'm still very confused. If you have a better understanding,
>> could you please write up the 15-step process from the thread starter
>> again, with all QEMU customizations applied? Such as, unnecessary steps
>> removed, and platform specifics filled in.
> 
> Sure.
> 
> (01a) QEMU: create new CPU.  The CPU already exists, but it does not
>  start running code until unparked by the CPU hotplug controller.
> 
> (01b) QEMU: trigger SCI
> 
> (02-03) no equivalent
> 
> (04) Host CPU: (OS) execute GPE handler from DSDT
> 
> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
>  will not enter CPU because SMI is disabled)
> 
> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>  rebase code.

(Could Intel open source code for this?)

> (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
>  new CPU
> 
> (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
> 
> (08a) New CPU: (Low RAM) Enter protected mode.

PCI DMA attack might be relevant (but yes, I see you've mentioned that
too, down-thread)

> 
> (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop.
> 
> (09) Host CPU: (SMM) Send SMI to the new CPU only.
> 
> (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to
>  TSEG.

I wish we could simply wake the new CPU -- after step 07a -- with an
SMI. IOW, if we could excise steps 07b, 08a, 08b.

Our CPU hotplug controller, and the initial parked state in 01a for the
new CPU, are going to be home-brewed anyway.

On the other hand...

> (11) Host CPU: (SMM) Restore 38000.
> 
> (12) Host CPU: (SMM) Update located data structure to add the new CPU
>  information. (This step will involve CPU_SERVICE protocol)
> 
> (13) New CPU: (Flash) do whatever other initialization is needed
> 
> (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.

basically step 08b is the environment to which the new CPU returns in
13/14, after the RSM.

Do we absolutely need low RAM for 08a (for entering protected mode)? we
could execute from pflash, no? OTOH we'd still need RAM for the stack,
and that could be attacked with PCI DMA similarly. I believe.

> (15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in..
> 
> 
> In other words, the cache-as-RAM phase of 02-03 is replaced by the
> INIT-SIPI-SIPI sequence of 07b-08a-08b.
> 
> 
>>> The QEMU DSDT could be modified (when secure boot is in effect) to OUT
>>> to 0xB2 when hotplug happens.  It could write a well-known value to
>>> 0xB2, to be read by an SMI handler in edk2.
>>
>> I dislike involving QEMU's generated DSDT in anything SMM (even
>> injecting the SMI), because the AML interpreter runs in the 

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

[Laszlo Ersek]

+Alex (direct question at the bottom)

On 08/16/19 09:49, Yao, Jiewen wrote:
> below
> 
>> -Original Message-
>> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
>> Sent: Friday, August 16, 2019 3:20 PM
>> To: Yao, Jiewen ; Laszlo Ersek
>> ; devel@edk2.groups.io
>> Cc: edk2-rfc-groups-io ; qemu devel list
>> ; Igor Mammedov ;
>> Chen, Yingwen ; Nakajima, Jun
>> ; Boris Ostrovsky ;
>> Joao Marcal Lemos Martins ; Phillip Goerl
>> 
>> Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
>>
>> On 16/08/19 04:46, Yao, Jiewen wrote:
>>> Comment below:
>>>
>>>
 -Original Message-
 From: Paolo Bonzini [mailto:pbonz...@redhat.com]
 Sent: Friday, August 16, 2019 12:21 AM
 To: Laszlo Ersek ; devel@edk2.groups.io; Yao,
>> Jiewen
 
 Cc: edk2-rfc-groups-io ; qemu devel list
 ; Igor Mammedov
>> ;
 Chen, Yingwen ; Nakajima, Jun
 ; Boris Ostrovsky
>> ;
 Joao Marcal Lemos Martins ; Phillip Goerl
 
 Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

 On 15/08/19 17:00, Laszlo Ersek wrote:
> On 08/14/19 16:04, Paolo Bonzini wrote:
>> On 14/08/19 15:20, Yao, Jiewen wrote:
 - Does this part require a new branch somewhere in the OVMF SEC
 code?
   How do we determine whether the CPU executing SEC is BSP or
   hot-plugged AP?
>>> [Jiewen] I think this is blocked from hardware perspective, since the
>> first
 instruction.
>>> There are some hardware specific registers can be used to determine
>> if
 the CPU is new added.
>>> I don’t think this must be same as the real hardware.
>>> You are free to invent some registers in device model to be used in
 OVMF hot plug driver.
>>
>> Yes, this would be a new operation mode for QEMU, that only applies
>> to
>> hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI,
>> in
>> fact it doesn't reply to anything at all.
>>
 - How do we tell the hot-plugged AP where to start execution? (I.e.
 that
   it should execute code at a particular pflash location.)
>>> [Jiewen] Same real mode reset vector at :FFF0.
>>
>> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
>> QEMU.  The AP does not start execution at all when it is unplugged,
>> so
>> no cache-as-RAM etc.
>>
>> We only need to modify QEMU so that hot-plugged APIs do not reply
>> to
>> INIT/SIPI/SMI.
>>
>>> I don’t think there is problem for real hardware, who always has CAR.
>>> Can QEMU provide some CPU specific space, such as MMIO region?
>>
>> Why is a CPU-specific region needed if every other processor is in SMM
>> and thus trusted.
>
> I was going through the steps Jiewen and Yingwen recommended.
>
> In step (02), the new CPU is expected to set up RAM access. In step
> (03), the new CPU, executing code from flash, is expected to "send
>> board
> message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add
> message." For that action, the new CPU may need a stack (minimally if
>> we
> want to use C function calls).
>
> Until step (03), there had been no word about any other (= pre-plugged)
> CPUs (more precisely, Jiewen even confirmed "No impact to other
> processors"), so I didn't assume that other CPUs had entered SMM.
>
> Paolo, I've attempted to read Jiewen's response, and yours, as carefully
> as I can. I'm still very confused. If you have a better understanding,
> could you please write up the 15-step process from the thread starter
> again, with all QEMU customizations applied? Such as, unnecessary
>> steps
> removed, and platform specifics filled in.

 Sure.

 (01a) QEMU: create new CPU.  The CPU already exists, but it does not
  start running code until unparked by the CPU hotplug controller.

 (01b) QEMU: trigger SCI

 (02-03) no equivalent

 (04) Host CPU: (OS) execute GPE handler from DSDT

 (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
  will not enter CPU because SMI is disabled)

 (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
  rebase code.

 (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable
  new CPU

 (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU.
>>> [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no
>>> restriction that INIT/SIPI/SIPI can only be sent in SMM.
>>
>> All of the CPUs are now in SMM, and INIT/SIPI/SIPI will be discarded
>> before 07a, so this is okay.
> [Jiewen] May I know why INIT/SIPI/SIPI is discarded before 07a but is 
> delivered at 07a?
> I don’t see any extra step between 06 and 07a.
> What is the magic here?

The magic is 07a itself, IIUC. The CPU hotplug controller would be
accessible only in SMM. And until 07a happens, the new CPU ignores
INIT/SIP

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Laszlo Ersek]

On 08/16/19 21:38, Laszlo Ersek wrote:

> I understand that edk2 is a "kit", and quite explicitly caters to
> out-of-tree platforms. That's not a positive trait of edk2 however;
> it's a negative one, in my judgement.

To clarify... I didn't mean that edk2 should willfully ignore dependent
platforms. Harmony between universal edk2 code and dependent platforms
is important. I meant that more platform code should live inside the
edk2 project. Again, this is a personal opinion.

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45855): https://edk2.groups.io/g/devel/message/45855
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

[Zurcher, Christopher J]

Hao,
Why will this cause CDROM devices to fail to be recognized? If they require a 
capacity read, I can change the MustReadCapacity flag to TRUE. On subsequent 
media change, the sense key parsing will set Action to ACTION_READ_CAPACITY so 
that case is covered as well. Is there a reason the MustReadCapacity flag was 
originally set to FALSE for CDROM devices? With the default action being to 
read capacity anyway, the existing implementation seems to make the flag mostly 
useless.

I have implemented the rest of the suggestions.

Thanks,
Christopher Zurcher

-Original Message-
From: Wu, Hao A 
Sent: Monday, June 17, 2019 19:12
To: devel@edk2.groups.io; Zurcher, Christopher J 

Cc: Kinney, Michael D ; Yao, Jiewen 
; Wang, Jian J ; Gao, Liming 

Subject: RE: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe: Support 
Storage Security Command Protocol

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Zurcher, Christopher J
> Sent: Thursday, June 13, 2019 10:05 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D; Yao, Jiewen; Wang, Jian J; Gao, Liming
> Subject: [edk2-devel] [PATCH v4 2/2] MdeModulePkg/ScsiDiskDxe: Support
> Storage Security Command Protocol
> 
> This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
> in the
> ScsiDiskDxe driver.
> 
> Support is currently limited to the RPMB Well-known LUN for UFS devices.


Hello,

Some general level comments:
1. CDROM device issue
This patch will bring an issue to the CDROM devices that CD/DVD will not
be recognized properly.

I think the cause of the issue is the relocation of the below logic:
  ScsiDiskDevice->BlkIo.Media->MediaPresent = TRUE;
from GetMediaInfo() to ScsiDiskTestUnitReady(). It will lead to the read
capacity command being skipped for CDROM devices, which results into the
LastBlock for the device equals to 0.

We may need to find out a better approach to handle the case for UFS RPMB.

2. Split this patch into three commits
Besides adding the Storage Security Command Protocol support in ScsiDisk
driver, the patch also:
* Updates the ScsiBus driver to recognize the Well known logical unit
* Updates the UfsPassThruDxe driver to expose the RPMB WLUN

Please help to split the patch into 3 separate commits.

3. Updates for the BlockIO(2) services
For functions ScsiDiskReadBlocks(Ex) & ScsiDiskWriteBlocks(Ex), below codes
are added for the dummy BlockIO(2) protocol instance on the UFS RPMB Lun:

  if (BlockSize == 0) {
Status = EFI_UNSUPPORTED;
goto Done;
  }

I suggest to use status 'EFI_DEVICE_ERROR' for such case, since
'EFI_UNSUPPORTED' is not listed as an expected return status in the UEFI
spec.

4. Reinstallation of the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
For the reinstallation of the SSC protocol to handle media change, I saw
this is only handled within ScsiDiskReceiveData() & ScsiDiskSendData().
The below functions should be considered as well:

ScsiDiskReadBlocks(Ex)
ScsiDiskWriteBlocks(Ex)
ScsiDiskFlushBlocksEx
ScsiDiskEraseBlocks


Some inline comments below:


> 
> Cc: Michael D Kinney 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Signed-off-by: Christopher J Zurcher 
> ---
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
>  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522
> +++-
>  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
>  5 files changed, 698 insertions(+), 22 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> index 5500d828e9..40818e669b 100644
> --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> @@ -3,7 +3,7 @@
>  #  It detects the SCSI disk media and installs Block I/O and Block I/O2 
> Protocol
> on
>  #  the device handle.
>  #
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -52,6 +52,7 @@
>gEfiBlockIoProtocolGuid   ## BY_START
>gEfiBlockIo2ProtocolGuid  ## BY_START
>gEfiEraseBlockProtocolGuid## BY_START
> +  gEfiStorageSecurityCommandProtocolGuid## BY_START
>gEfiScsiIoProtocolGuid## TO_START
>gEfiScsiPassThruProtocolGuid  ## TO_START
>gEfiExtScsiPassThruProtocolGuid   ## TO_START
> diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
> index 42c095..2d8679ec6f 100644
> --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
> +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
> @@ -1,7 +1,7 @@
>  /** @file
>Header file for SCSI Disk Driver.

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

[Laszlo Ersek]

On 08/16/19 18:16, Laszlo Ersek wrote:
> On 08/15/19 06:02, Gao, Liming wrote:
>> Donald: This change is a new feature. Now, it is not in edk2 feature
>> planning list. If you want to catch it into 201908 stable tag, please
>> get approve from Stewards first. I have cc this mail to all Stewards.
> - I don't mind adding a new feature, as long as it gets properly
> reviewed by package owners before we enter the soft feature freeze.
> 
> - Looking at the BZ
> , a bit more
> documentation would be nice.
> 
> - On the negative side, I'm very much *not* a fan of adding features to
> the open source edk2 tree without actually *consuming* the feature in an
> open source tree. Are the new library instances going to be put to use
> in edk2-platforms, perhaps?
> 
> We discussed this topic earlier on some of the stewards' calls. On one
> hand, it's not uncommon to see library instances from Intel enter core
> edk2 packages without any dependent platform code, or even a detailed
> problem statement / purpose description (see e.g. commit 5c9bb86f171c
> and its surrounding commits). On the other hand, attempts in the past,
> to add libraries with well demonstrated and direct in-tree use cases, to
> edk2 core, have been rejected, from other submitters. (Here's one
> example: .) I'm not
> prying at proprietary platform information, but a new library added to
> edk2 core *should* be well-justified.
> 
> The commit message on this patch is empty. It only references
> . And if I open the
> BZ, this is all I get:
> 
> Need a new TSC library to check the CPUID leaf (EAX=0x15) for TSC.
> For new platform (start from SKL) can use CPUID and retire/remove
> the current override from AcpiTimerLib.
> 
> Does this read like an actual feature request? (TimerLib is an MdePkg
> library class, so not exactly "niche".)

In comparison, the following email does read like a feature request:

[edk2-devel] Determining TSC frequency programmatically
https://edk2.groups.io/g/devel/message/45750
8EC14D0D-DFA5-412D-A4E1-4D641576D58E@protonmail.com">http://mid.mail-archive.com/8EC14D0D-DFA5-412D-A4E1-4D641576D58E@protonmail.com

If the posting is related to TianoCore#1909, then I urge the BZ assignee to 
please reference the message in the TianoCore BZ.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45857): https://edk2.groups.io/g/devel/message/45857
Mute This Topic: https://groups.io/mt/32839184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 10/10] Marvell/Drivers: SmbiosPlatformDxe: Use more generic board name

[Marcin Wojtas]

Hi Leif,

pt., 16 sie 2019 o 19:41 Leif Lindholm  napisał(a):
>
> On Thu, Aug 15, 2019 at 04:54:14AM +0200, Marcin Wojtas wrote:
> > SmbiosPlatformDxe is used both by Armada 7k8k and CN913x platforms.
> > Replace board name placeholder in order to avoid confusion.
>
> Stupid/lazy question - do we already specify the actual platform name
> elsewhere?

No. My plan is to enable SMBIOS customization via board description
library / protocol. I just came up on an easy idea to use PCD for
platform name. If that's ok for you, I'll refactor to it in v2.

Thanks,
Marcin

>
> /
> Leif
>
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> > b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > index 08f4fa7..cdacd90 100644
> > --- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > +++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > @@ -102,7 +102,7 @@ STATIC SMBIOS_TABLE_TYPE1 mArmadaDefaultType1 = {
> >
> >  STATIC CHAR8 CONST *mArmadaDefaultType1Strings[] = {
> >"Marvell\0",/* Manufacturer */
> > -  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
> > +  "Marvell Development Board  \0",/* Product Name placeholder*/
> >"Revision unknown   \0",/* Version placeholder */
> >"   \0",/* 32 character buffer */
> >NULL
> > @@ -130,7 +130,7 @@ STATIC SMBIOS_TABLE_TYPE2 mArmadaDefaultType2 = {
> >
> >  STATIC CHAR8 CONST *mArmadaDefaultType2Strings[] = {
> >"Marvell\0",/* Manufacturer */
> > -  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
> > +  "Marvell Development Board  \0",/* Product Name placeholder*/
> >"Revision unknown   \0",/* Version placeholder */
> >"Serial Not Set \0",/* Serial */
> >"Base of Chassis\0",/* Board location */
> > --
> > 2.7.4
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45858): https://edk2.groups.io/g/devel/message/45858
Mute This Topic: https://groups.io/mt/32882743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 03/10] Marvell/Cn9130Db: Add DeviceTree

[Marcin Wojtas]

Hi Leif,

pt., 16 sie 2019 o 19:10 Leif Lindholm  napisał(a):
>
> On Thu, Aug 15, 2019 at 04:54:07AM +0200, Marcin Wojtas wrote:
> > This patch adds device tree sources which are common for Cn913x SoCs
> > and the CN9130 development board (variant A). Wiring up of support
> > will be done in the follow-up commits.
> >
> > Signed-off-by: Marcin Wojtas 
>
> Again, I've not reviewed the contents extensively, *but* this patch
> cannot go into edk2-platforms - it has GPL licensed content.
> Was it meant for edk2-non-osi? Because we could take it there.
>

Thanks for catching this - my oversight. The top-level DT files should
also be dual licenced (GPL2.0/MIT), same as recently submitted to
Linux. So IMO no need to go for edk2-non-osi.

Best regards,
Marcin

> Best Regards,
>
> Leif
>
> > ---
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf  |  22 +
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi |  43 ++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi  | 264 
> > ++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi |  10 +
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi  | 552 
> > 
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts| 185 
> > +++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi | 168 ++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi| 126 +
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts|  29 +
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi | 173 ++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts|  76 +++
> >  Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi | 151 ++
> >  12 files changed, 1799 insertions(+)
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
> >  create mode 100644 
> > Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
> >  create mode 100644 
> > Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
> >  create mode 100644 
> > Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi
> >  create mode 100644 
> > Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
> >  create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45859): https://edk2.groups.io/g/devel/message/45859
Mute This Topic: https://groups.io/mt/32882735/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Michael D Kinney]

Laszlo,

I agree that better comments/documentation of STATIC_ASSERT()
for EDK II usages is required.  For example, EDK II defines
the ASSERT() macro which is based on the standard C function
assert(), but we still document it fully for EDK II usage.

/**
  Macro that calls DebugAssert() if an expression evaluates to FALSE.

  If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
  bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
  expression specified by Expression.  If Expression evaluates to FALSE, then
  DebugAssert() is called passing in the source filename, source line number,
  and Expression.

  @param  Expression  Boolean expression.

**/
#if !defined(MDEPKG_NDEBUG)
  #define ASSERT(Expression)\
do {\
  if (DebugAssertEnabled ()) {  \
if (!(Expression)) {\
  _ASSERT (Expression); \
  ANALYZER_UNREACHABLE ();  \
}   \
  } \
} while (FALSE)
#else
  #define ASSERT(Expression)
#endif

I would like to see the macro documentation for
STATIC_ASSERT() with the Doxygen style description of the
parameters.  The fact I asked if STATIC_ASSERT() supported
the 2nd message parameter should have been a trigger
for me to ask for the more complete macro comment block.
The fact that this macro can be directly mapped to 
built in compiler name makes the implementation simple,
but other implementations are possible for compilers
that do not support this feature directly.  This is why
the complete description of the EDK II version is required.

I would like to see a V3 with the complete description.

In general, I agree it is better if there is code that
uses a new feature in the code base, so the feature can
be tested.  A second option we can consider going forward
is for unit test code to be submitted with a new feature,
so even if there are no consumers from the EDK II repos,
the feature can still be tested as the EDK II repos are
maintained.  A third option is for community members to
provide Tested-by responses to the feature along with 
statements in the Bugzilla that clearly documents how the
the feature was tested.

Best regards,

Mike

> -Original Message-
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
> Sent: Friday, August 16, 2019 12:39 PM
> To: vit9...@protonmail.com
> Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
> af...@apple.com
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
> 
> On 08/16/19 19:23, vit9...@protonmail.com wrote:
> > Laszlo,
> >
> > I have already mentioned that the documentation is
> sufficient as
> > _Static_assert is C standard
> 
> Yes, in a release of the ISO C standard that edk2 does
> not target.
> 
> In addition, edk2 already has several restrictions in
> place against standards-conformant code. (Such as bit-
> shifting of UINT64 values, initialization of structures
> with automatic storage duration, structure assignment,
> maybe more.)
> 
> > so I do not plan to make a V3 for this patch.
> 
> I find that regrettable.
> 
> > The patch is merge ready.
> 
> Such statements are usually made when people that
> comment on a patch arrive at a consensus. The patch may
> be merge-ready from your perspective and from Mike's.
> It is not merge-ready from my perspective.
> I hope I'm allowed to comment (constructively) on
> patches that aren't strictly aimed at the subsystems I
> co-maintain.
> 
> > As for usage examples I have an opposing opinion to
> yours and believe
> > it is based on very good reasons. Not using
> STATIC_ASSERT in the
> > current release will make the feature optionally
> available and let
> > people test it in their setups.
> 
> Not using STATIC_ASSERT in the current stable release
> makes the STATIC_ASSERT macro definition *dead code* in
> edk2 proper. I understand that edk2 is a "kit", and
> quite explicitly caters to out-of-tree platforms.
> That's not a positive trait of edk2 however; it's a
> negative one, in my judgement. Whatever we add to the
> core of edk2, we should exercise as diligently as we
> can *inside* of edk2.
> 
> > In case they notice it does not work for them they
> will have 3 months
> > grace period to report it to us and consider making a
> change.
> 
> That is what the feature freezes are for. The feature
> is reviewed before the soft feature freeze, merged (at
> the latest) during the soft feature freeze, and bugs
> can still be fixed during the hard feature freeze. The
> community is expected to test diligently during the
> hard feature freeze.
> Perhaps we should extend the hard feature freeze.
> 
> My problem is not that the change is not "in your
> face". I'm all for avoiding regressions. My problem is
> that the code is dead and untestable without platform
> changes, even though it could be put to great use in
> core code at once. If you think that's too risky, this

Re: [edk2-devel] [edk2-platforms: PATCH v2 06/10] Marvell/Library: MppLib: Allow to configure more Xenon PHYs

[Marcin Wojtas]

Hi Leif,

pt., 16 sie 2019 o 19:36 Leif Lindholm  napisał(a):
>
> On Thu, Aug 15, 2019 at 04:54:10AM +0200, Marcin Wojtas wrote:
> > Hitherto MppLib code assumed that there could be only two
> > Xenon SdMmc controllers' PHYs. Remove this limitation, so that to
> > support CN913x SoCs, which may have up to 4 of such interfaces.
>
> Should this be merged with the preceding patch?
>

Yes it could - I will squash both patches.

Thanks,
Marcin

> /
> Leif
>
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  Silicon/Marvell/Library/MppLib/MppLib.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/Silicon/Marvell/Library/MppLib/MppLib.c 
> > b/Silicon/Marvell/Library/MppLib/MppLib.c
> > index 40d9077..f20668d 100644
> > --- a/Silicon/Marvell/Library/MppLib/MppLib.c
> > +++ b/Silicon/Marvell/Library/MppLib/MppLib.c
> > @@ -139,11 +139,9 @@ SetSdMmcPhyMpp (
> >case 0:
> >  Offset = SD_MMC_PHY_AP_MPP_OFFSET;
> >  break;
> > -  case 1:
> > +  default:
> >  Offset = SD_MMC_PHY_CP0_MPP_OFFSET;
> >  break;
> > -  default:
> > -return;
> >}
> >
> >/*
> > --
> > 2.7.4
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45861): https://edk2.groups.io/g/devel/message/45861
Mute This Topic: https://groups.io/mt/32882738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

[Michael D Kinney]

Jordan,

Thanks.  Yes.  Updating the Author sounds like the
right fix.  I will send an updated series soon.

Thanks,

Mike

> -Original Message-
> From: Justen, Jordan L
> Sent: Friday, August 16, 2019 11:21 AM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Ni, Ray ; Andrew Fish
> 
> Subject: RE: [Patch V4 06/10] EmulatorPkg: Fix XCODE5
> lldb issues
> 
> On 2019-08-16 08:09:55, Kinney, Michael D wrote:
> > Jordan,
> >
> > It is not a typo.
> >
> > Andrew generated the XCODE specific changes, so they
> have been tested
> > by him.
> 
> In that case, is the git author for the patches set to
> Andrew? If it was, I would expect to see a line inside
> the email body with:
> 
> From: Andrew Fish 
> 
> Git does that for patches where the sender doesn't
> match the patch author.
> 
> You might want to rebase and run:
> 
> git commit --amend --author="Andrew Fish
> " --reset-author
> 
> to change the author.
> 
> I expect you might want to add Reviewed-by for yourself
> on these patches to help speed things along. If Andrew
> authored the patch, you reviewed it, and with a quick
> review it looked good to me, I would probably add an
> Acked-by for some of the patches.
> 
> -Jordan
> 
> > I have also reviewed and tested the XCODE changes and
> verified that
> > all 6 combinations build and boot to shell (IA32/X64
> for
> > RELEASE/DEBUG/NOOPT). Since they are all related to
> making EmulatorPkg
> > work, we decided to fold them into the same patch set
> that was already
> > being reviewed.
> >
> > I also verified build and boot to shell for 6
> combinations on GCC5
> > (IA32/X64 for RELEASE/DEBUG/NOOPT) and the 12
> combinations of
> > VS2015/VS2017, IA323/X64, RELEASE/DEBUG/NOOPT.
> >
> > I have been working on some CI experiments using
> Azure Pipelines.
> > Here is a pointer to the build logs for all the
> combinations listed
> > above.
> >
> > https://dev.azure.com/mikekinney/edk2-
> ci/_build/results?buildId=312
> >
> > Mike
> >
> > > -Original Message-
> > > From: Justen, Jordan L
> > > Sent: Friday, August 16, 2019 12:41 AM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io
> > > Cc: Ni, Ray ; Andrew Fish
> 
> > > Subject: Re: [Patch V4 06/10] EmulatorPkg: Fix
> XCODE5 lldb issues
> > >
> > > On 2019-08-15 19:14:33, Michael D Kinney wrote:
> > > > Fix scripts to support lldb symbolic debugging
> when
> > > using XCODE5 tool
> > > > chain.
> > > >
> > > > Cc: Jordan Justen 
> > > > Cc: Ray Ni 
> > > > Cc: Michael D Kinney 
> > > > Signed-off-by: Andrew Fish 
> > >
> > > Is this a Cc/Signed-off-by typo? (See also, patches
> 7- 10).
> > >
> > > This makes me wonder if you are taking advantage of
> the git commit
> > > -s switch to add your Signed-off-by.
> > >
> > > Also, I'm wondering if you are taking advantage of
> git- send-email
> > > automatically Cc'ing the addresses you listed in
> the commit message.
> > > (I thought it Cc'd for the author and Cc tags, but
> I wasn't sure
> > > about the Signed-off-by tag, and yet I see Andrew
> was Cc'd.)
> > >
> > > There's a couple long lines below. You could use \
> at the end of the
> > > line to split the .sh line. I think the cd can be a
> separate command
> > > in a shell script. (Not in
> > > make)
> > >
> > > I hope someone that uses the XCODE toolchain could
> review/check the
> > > XCODE patches.
> > >
> > > -Jordan
> > >
> > > > ---
> > > >  EmulatorPkg/Unix/lldbefi.py |  8 +---
> > > >  EmulatorPkg/build.sh| 17 ++-
> --
> > > >  2 files changed, 7 insertions(+), 18 deletions(-
> )
> > > >
> > > > diff --git a/EmulatorPkg/Unix/lldbefi.py
> > > b/EmulatorPkg/Unix/lldbefi.py
> > > > index 218326b8cb..099192d8b5 100755
> > > > --- a/EmulatorPkg/Unix/lldbefi.py
> > > > +++ b/EmulatorPkg/Unix/lldbefi.py
> > > > @@ -346,6 +346,7 @@ def
> TypePrintFormating(debugger):
> > > >  debugger.HandleCommand("type summary add
> CHAR8 -
> > > -python-function lldbefi.CHAR8_TypeSummary")
> > > >  debugger.HandleCommand('type summary add --
> regex
> > > "CHAR8
> > > > \[[0-9]+\]" --python-function
> > > lldbefi.CHAR8_TypeSummary')
> > > >
> > > > +debugger.HandleCommand('setting set frame-
> format
> > > "frame
> > > > + #${frame.index}: ${frame.pc}{
> > > > +
> > >
> ${module.file.basename}{:${function.name}()${function.p
> > > c-offset}}}{
> > > > + at ${line.file.fullpath}:${line.number}}\n"')
> > > >
> > > >  gEmulatorBreakWorkaroundNeeded = True
> > > >
> > > > @@ -381,15 +382,16 @@ def
> > > LoadEmulatorEfiSymbols(frame, bp_loc ,
> internal_dict):
> > > >  Error = lldb.SBError()
> > > >  FileNamePtr = frame.FindVariable
> > > ("FileName").GetValueAsUnsigned()
> > > >  FileNameLen = frame.FindVariable
> > > > ("FileNameLength").GetValueAsUnsigned()
> > > > +
> > > >  FileName =
> > > frame.thread.process.ReadCStringFromMemory
> > > (FileNamePtr, FileNameLen, Error)
> > > >  if not Error.Success():
> > > >  print "!ReadCStringFromMemory() did not
> find
> > > a %d byte C string

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

Laszlo,

I am very glad to you for expressing a different opinion as this lets me view 
the situation from different angles.

I understand your concerns, and believe that most of them should actually be 
addressed in a way you explain. In fact, I plan to submit more patches myself 
for everyone's benefit.

The exact situation with static assertions is that they are not coming too 
early, but actually too late. We have been using static assertions in UEFI code 
for quite some time already, and I believe we are not alone. All of us will 
benefit from legacy code removal once this patch lands upstream.

For your claim that this code is not well tested I should mention that the 
patch is based on one of the open-source projects I maintain, which everyone 
can track, and which I believe have gotten reasonable attention from different 
people with different compilers.

For dead code I believe that in EDK II we do not have a good definition for 
that term as normally done in serious industrial projects like aerospace or 
military that have no dead code requirement in their SDL. Primarily because EDK 
II is a library for others to rely on, it is not a self contained system where 
dead code term is usually defined, standardised and verified against.

Whether it is liked or not, the fact EDK II gets continual development is only 
because different companies, academia, and individuals use its code. I feel bad 
for these people having to fork, and believe that most value in EDK is what it 
gives to the outside, not the inside. So supporting a new interface a number of 
projects use and need makes most sense to me.

I do not want to make more changes to core code for multiple reasons as you see 
above. One of them indeed being some necessary discussion for the use inside 
EDK II. But I do not believe this a good stopper from giving a working 
interface to others, which unlike EDK II, actually have defined compilers, 
infrastructure, and requirements.

Hopefully I pointed out to enough reasons to leave you with some doubts and 
permit this patch to land in as an exception from your personal standpoint. 
Thank you for understanding and being constructive.

Cheers,
Vitaly

On пт, авг. 16, 2019 at 22:38, Laszlo Ersek  wrote:

> On 08/16/19 19:23, vit9...@protonmail.com wrote:
>> Laszlo,
>>
>> I have already mentioned that the documentation is sufficient as
>> _Static_assert is C standard
>
> Yes, in a release of the ISO C standard that edk2 does not target.
>
> In addition, edk2 already has several restrictions in place against
> standards-conformant code. (Such as bit-shifting of UINT64 values,
> initialization of structures with automatic storage duration, structure
> assignment, maybe more.)
>
>> so I do not plan to make a V3 for this patch.
>
> I find that regrettable.
>
>> The patch is merge ready.
>
> Such statements are usually made when people that comment on a patch
> arrive at a consensus. The patch may be merge-ready from your
> perspective and from Mike's. It is not merge-ready from my perspective.
> I hope I'm allowed to comment (constructively) on patches that aren't
> strictly aimed at the subsystems I co-maintain.
>
>> As for usage examples I have an opposing opinion to yours and believe
>> it is based on very good reasons. Not using STATIC_ASSERT in the
>> current release will make the feature optionally available and let
>> people test it in their setups.
>
> Not using STATIC_ASSERT in the current stable release makes the
> STATIC_ASSERT macro definition *dead code* in edk2 proper. I understand
> that edk2 is a "kit", and quite explicitly caters to out-of-tree
> platforms. That's not a positive trait of edk2 however; it's a negative
> one, in my judgement. Whatever we add to the core of edk2, we should
> exercise as diligently as we can *inside* of edk2.
>
>> In case they notice it does not work for them they will have 3 months
>> grace period to report it to us and consider making a change.
>
> That is what the feature freezes are for. The feature is reviewed before
> the soft feature freeze, merged (at the latest) during the soft feature
> freeze, and bugs can still be fixed during the hard feature freeze. The
> community is expected to test diligently during the hard feature freeze.
> Perhaps we should extend the hard feature freeze.
>
> My problem is not that the change is not "in your face". I'm all for
> avoiding regressions. My problem is that the code is dead and untestable
> without platform changes, even though it could be put to great use in
> core code at once. If you think that's too risky, this close to the
> stable tag, then one solution is to resubmit at the beginning of the
> next development cycle (again with additional patches that utilize the
> STATIC_ASSERT macro at once). Developers will then have close to three
> months to report and fix issues.
>
> Another solution would be to conditionally keep VERIFY_SIZE_OF, vs.
> using STATIC_ASSERT, for expressing the build-time invariants. Th

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

Mike,

I missed your message while writing mine, but I am afraid I disagree with the 
functional macro usage for this feature.

I explicitly quoted C standard static_assert definition in one of my previous 
messages, and I want EDK II to be as close to standard C as possible.

This will avoid a lot of confusion for newcomers and will let us later adopt a 
more flexible single and double argument interface when it gets standardised.

For these reasons altogether, I am not positive the macro could get a doxygen 
documentation as it is not designed to have any arguments in the first place.

Best wishes,
Vitaly

On сб, авг. 17, 2019 at 00:04, Kinney, Michael D  
wrote:

> Laszlo,
>
> I agree that better comments/documentation of STATIC_ASSERT()
> for EDK II usages is required. For example, EDK II defines
> the ASSERT() macro which is based on the standard C function
> assert(), but we still document it fully for EDK II usage.
>
> /**
> Macro that calls DebugAssert() if an expression evaluates to FALSE.
>
> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
> bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
> expression specified by Expression. If Expression evaluates to FALSE, then
> DebugAssert() is called passing in the source filename, source line number,
> and Expression.
>
> @param Expression Boolean expression.
>
> **/
> #if !defined(MDEPKG_NDEBUG)
> #define ASSERT(Expression) \
> do { \
> if (DebugAssertEnabled ()) { \
> if (!(Expression)) { \
> _ASSERT (Expression); \
> ANALYZER_UNREACHABLE (); \
> } \
> } \
> } while (FALSE)
> #else
> #define ASSERT(Expression)
> #endif
>
> I would like to see the macro documentation for
> STATIC_ASSERT() with the Doxygen style description of the
> parameters. The fact I asked if STATIC_ASSERT() supported
> the 2nd message parameter should have been a trigger
> for me to ask for the more complete macro comment block.
> The fact that this macro can be directly mapped to
> built in compiler name makes the implementation simple,
> but other implementations are possible for compilers
> that do not support this feature directly. This is why
> the complete description of the EDK II version is required.
>
> I would like to see a V3 with the complete description.
>
> In general, I agree it is better if there is code that
> uses a new feature in the code base, so the feature can
> be tested. A second option we can consider going forward
> is for unit test code to be submitted with a new feature,
> so even if there are no consumers from the EDK II repos,
> the feature can still be tested as the EDK II repos are
> maintained. A third option is for community members to
> provide Tested-by responses to the feature along with
> statements in the Bugzilla that clearly documents how the
> the feature was tested.
>
> Best regards,
>
> Mike
>
>> -Original Message-
>> From: devel@edk2.groups.io
>> [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
>> Sent: Friday, August 16, 2019 12:39 PM
>> To: vit9...@protonmail.com
>> Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
>> af...@apple.com
>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>> STATIC_ASSERT macro
>>
>> On 08/16/19 19:23, vit9...@protonmail.com wrote:
>> > Laszlo,
>> >
>> > I have already mentioned that the documentation is
>> sufficient as
>> > _Static_assert is C standard
>>
>> Yes, in a release of the ISO C standard that edk2 does
>> not target.
>>
>> In addition, edk2 already has several restrictions in
>> place against standards-conformant code. (Such as bit-
>> shifting of UINT64 values, initialization of structures
>> with automatic storage duration, structure assignment,
>> maybe more.)
>>
>> > so I do not plan to make a V3 for this patch.
>>
>> I find that regrettable.
>>
>> > The patch is merge ready.
>>
>> Such statements are usually made when people that
>> comment on a patch arrive at a consensus. The patch may
>> be merge-ready from your perspective and from Mike's.
>> It is not merge-ready from my perspective.
>> I hope I'm allowed to comment (constructively) on
>> patches that aren't strictly aimed at the subsystems I
>> co-maintain.
>>
>> > As for usage examples I have an opposing opinion to
>> yours and believe
>> > it is based on very good reasons. Not using
>> STATIC_ASSERT in the
>> > current release will make the feature optionally
>> available and let
>> > people test it in their setups.
>>
>> Not using STATIC_ASSERT in the current stable release
>> makes the STATIC_ASSERT macro definition *dead code* in
>> edk2 proper. I understand that edk2 is a "kit", and
>> quite explicitly caters to out-of-tree platforms.
>> That's not a positive trait of edk2 however; it's a
>> negative one, in my judgement. Whatever we add to the
>> core of edk2, we should exercise as diligently as we
>> can *inside* of edk2.
>>
>> > In case they notice it does not work for them they
>> will have 3 months
>> > grace period to report it to us and consider maki

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[rebecca]

On 2019-08-16 15:40, Vitaly Cheptsov via Groups.Io wrote:
> I missed your message while writing mine, but I am afraid I disagree
> with the functional macro usage for this feature.
>
> I explicitly quoted C standard static_assert definition in one of my
> previous messages, and I want EDK II to be as close to standard C as
> possible.
>

Choosing a random message in this thread to comment.

We could also migrate the existing uses of __STATIC_ASSERT in BaseTools
to the new STATIC_ASSERT:


BaseTools/Source/C/Common/PcdValueCommon.h:22:#define __STATIC_ASSERT
static_assert
BaseTools/Source/C/Common/PcdValueCommon.h:24:#define __STATIC_ASSERT
_Static_assert
Binary file BaseTools/Source/Python/Workspace/DscBuildData.pyc matches
BaseTools/Source/Python/Workspace/DscBuildData.py:2037:   
CApp = CApp + '__STATIC_ASSERT(sizeof(%s_%s_INIT_Value) < %d *
sizeof(%s), "Pcd %s.%s Value in Dec exceed the array capability %s"); //
From  %s Line %s \n ' % (Pcd.TokenSpaceGuidCName,
Pcd.TokenCName,pcdarraysize,Pcd.BaseDatumType,Pcd.TokenSpaceGuidCName,
Pcd.TokenCName,Pcd.DatumType,Pcd.DefaultValueFromDecInfo[0],Pcd.DefaultValueFromDecInfo[1])
BaseTools/Source/Python/Workspace/DscBuildData.py:2042:   
CApp = CApp + '__STATIC_ASSERT(%d < %d * sizeof(%s), "Pcd %s.%s Value in
Dec exceed the array capability %s"); // From %s Line %s \n' %
(ValueSize,pcdarraysize,Pcd.BaseDatumType,Pcd.TokenSpaceGuidCName,
Pcd.TokenCName,Pcd.DatumType,Pcd.DefaultValueFromDecInfo[0],Pcd.DefaultValueFromDecInfo[1])



-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45865): https://edk2.groups.io/g/devel/message/45865
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Andrew Fish via Groups.Io]

> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io 
>  wrote:
> 
> Mike,
> 
> I missed your message while writing mine, but I am afraid I disagree with the 
> functional macro usage for this feature.
> 
> I explicitly quoted C standard static_assert definition in one of my previous 
> messages, and I want EDK II to be as close to standard C as possible.
> 
> This will avoid a lot of confusion for newcomers and will let us later adopt 
> a more flexible single and double argument interface when it gets 
> standardised.
> 
> For these reasons altogether, I am not positive the macro could get a doxygen 
> documentation as it is not designed to have any arguments in the first place.
> 

Vitaly,

I don't understand your logic? It is always possible to write a comment in C 
code?

In terms of the C standard and the EFI type system we kind of have a long 
history of how the code ended up like it is. The (U)EFI spec defined its own 
type system (and ABI) as a way of specifying interoperability so the code got 
built on top of that. 20 years ago we shied away from having and EFI code base 
produce definitions of standard C things as we wanted to make it easier to 
import chunks of code in OS loaders that needed to get ported to EFI from lots 
of different vendors. Also one of the early compilers that we standardized on 
was VC2003 and that does not even fully support C99. For some reason it seems 
VC2008 was also a popular target for some time. I don't think VC++ got around 
to C99 until 2013/2015. So that is kind how the edk2 ended up with its own type 
system. 

I'm all for modernization of the C code as long we are thoughtful about 
compatibility. For example I still see that VS2008 is a supported 
BaseTools/Conf/tools_def.template.

Thanks,

Andrew Fish


> Best wishes,
> Vitaly
> 
> On сб, авг. 17, 2019 at 00:04, Kinney, Michael D  > wrote:
>> 
>> Laszlo,
>> 
>> I agree that better comments/documentation of STATIC_ASSERT()
>> for EDK II usages is required. For example, EDK II defines
>> the ASSERT() macro which is based on the standard C function
>> assert(), but we still document it fully for EDK II usage.
>> 
>> /**
>> Macro that calls DebugAssert() if an expression evaluates to FALSE.
>> 
>> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
>> bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
>> expression specified by Expression. If Expression evaluates to FALSE, then
>> DebugAssert() is called passing in the source filename, source line number,
>> and Expression.
>> 
>> @param Expression Boolean expression.
>> 
>> **/
>> #if !defined(MDEPKG_NDEBUG)
>> #define ASSERT(Expression) \
>> do { \
>> if (DebugAssertEnabled ()) { \
>> if (!(Expression)) { \
>> _ASSERT (Expression); \
>> ANALYZER_UNREACHABLE (); \
>> } \
>> } \
>> } while (FALSE)
>> #else
>> #define ASSERT(Expression)
>> #endif
>> 
>> I would like to see the macro documentation for
>> STATIC_ASSERT() with the Doxygen style description of the
>> parameters. The fact I asked if STATIC_ASSERT() supported
>> the 2nd message parameter should have been a trigger
>> for me to ask for the more complete macro comment block.
>> The fact that this macro can be directly mapped to
>> built in compiler name makes the implementation simple,
>> but other implementations are possible for compilers
>> that do not support this feature directly. This is why
>> the complete description of the EDK II version is required.
>> 
>> I would like to see a V3 with the complete description.
>> 
>> In general, I agree it is better if there is code that
>> uses a new feature in the code base, so the feature can
>> be tested. A second option we can consider going forward
>> is for unit test code to be submitted with a new feature,
>> so even if there are no consumers from the EDK II repos,
>> the feature can still be tested as the EDK II repos are
>> maintained. A third option is for community members to
>> provide Tested-by responses to the feature along with
>> statements in the Bugzilla that clearly documents how the
>> the feature was tested.
>> 
>> Best regards,
>> 
>> Mike
>> 
>> > -Original Message-
>> > From: devel@edk2.groups.io
>> > [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
>> > Sent: Friday, August 16, 2019 12:39 PM
>> > To: vit9...@protonmail.com
>> > Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
>> > af...@apple.com
>> > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>> > STATIC_ASSERT macro
>> >
>> > On 08/16/19 19:23, vit9...@protonmail.com wrote:
>> > > Laszlo,
>> > >
>> > > I have already mentioned that the documentation is
>> > sufficient as
>> > > _Static_assert is C standard
>> >
>> > Yes, in a release of the ISO C standard that edk2 does
>> > not target.
>> >
>> > In addition, edk2 already has several restrictions in
>> > place against standards-conformant code. (Such as bit-
>> > shifting of UINT64 values, initialization of structu

[edk2-devel] [PATCH v3 0/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

Implements https://bugzilla.tianocore.org/show_bug.cgi?id=3D2048.

Things to note:
- _Static_assert is a standard C11 keyword and thus is available
on every modern compiler (including Apple Clang, Clang, and GCC).
See: https://en.cppreference.com/w/c/keyword/_Static_assert
- static_assert is a hack to support MSVC, which implements static
assertions with this vendor-specific keyword starting from at least
VS 2010 to date.
- V3 of the patch addresses the confusion with doxygen, which I
expected to not be able to handle @param for a macro with no arguments.
- The replacement of VERIFY_SIZE_OF will be submitted in a separate
patch series, and I request the colleagues to test this on their setups.
As for myself I can report that it works for me with CLANG38, GCC5,
VS2017, and XCODE5. 


Vitaly Cheptsov (1):
  MdePkg: Add STATIC_ASSERT macro

 MdePkg/Include/Base.h | 14 ++
 1 file changed, 14 insertions(+)

-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45867): https://edk2.groups.io/g/devel/message/45867
Mute This Topic: https://groups.io/mt/32917747/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signature

[edk2-devel] [PATCH v3 1/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048

Provide a macro for compile time assertions.
Equivalent to C11 static_assert macro from assert.h.

Signed-off-by: Vitaly Cheptsov 
---
 MdePkg/Include/Base.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index ce20b5f01d..ec096133ba 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -843,6 +843,20 @@ typedef UINTN  *BASE_LIST;
 #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
 #endif
 
+/**
+  Portable definition for compile time assertions.
+  Equivalent to C11 static_assert macro from assert.h.
+
+  @param  Expression  Boolean expression.
+  @param  Message Raised compiler diagnostic message when expression is 
false.
+
+**/
+#ifdef _MSC_EXTENSIONS
+  #define STATIC_ASSERT static_assert
+#else
+  #define STATIC_ASSERT _Static_assert
+#endif
+
 /**
   Macro that returns a pointer to the data structure that contains a specified 
field of
   that data structure.  This is a lightweight method to hide information by 
placing a
-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45868): https://edk2.groups.io/g/devel/message/45868
Mute This Topic: https://groups.io/mt/32917749/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signature

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

Andrew, Mike,

Actually thanks for making me recheck it. I have just installed doxygen, and 
can confirm that it can generate parameters for non-functional macros. This was 
my main reason for going with /// comment style, which is used for all other 
plain macros. I have just submitted V3 version with this fixed.

With C language modernisation I fully agree that it needs to be done 
reasonably, and that is why I also try to be very realistic on what people 
actually use. For instance, one of the issues that caused several problems is 
the use of 1-sized arrays instead of flexible array members. A couple years ago 
that was still there just because there still existed some compilers that did 
not support [] syntax.

Best wishes,
Vitaly

> 17 авг. 2019 г., в 1:58, Andrew Fish  написал(а):
> 
> 
> 
>> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io 
>> mailto:vit9696=protonmail@groups.io>> 
>> wrote:
>> 
>> Mike,
>> 
>> I missed your message while writing mine, but I am afraid I disagree with 
>> the functional macro usage for this feature.
>> 
>> I explicitly quoted C standard static_assert definition in one of my 
>> previous messages, and I want EDK II to be as close to standard C as 
>> possible.
>> 
>> This will avoid a lot of confusion for newcomers and will let us later adopt 
>> a more flexible single and double argument interface when it gets 
>> standardised.
>> 
>> For these reasons altogether, I am not positive the macro could get a 
>> doxygen documentation as it is not designed to have any arguments in the 
>> first place.
>> 
> 
> Vitaly,
> 
> I don't understand your logic? It is always possible to write a comment in C 
> code?
> 
> In terms of the C standard and the EFI type system we kind of have a long 
> history of how the code ended up like it is. The (U)EFI spec defined its own 
> type system (and ABI) as a way of specifying interoperability so the code got 
> built on top of that. 20 years ago we shied away from having and EFI code 
> base produce definitions of standard C things as we wanted to make it easier 
> to import chunks of code in OS loaders that needed to get ported to EFI from 
> lots of different vendors. Also one of the early compilers that we 
> standardized on was VC2003 and that does not even fully support C99. For some 
> reason it seems VC2008 was also a popular target for some time. I don't think 
> VC++ got around to C99 until 2013/2015. So that is kind how the edk2 ended up 
> with its own type system. 
> 
> I'm all for modernization of the C code as long we are thoughtful about 
> compatibility. For example I still see that VS2008 is a supported 
> BaseTools/Conf/tools_def.template.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
>> Best wishes,
>> Vitaly
>> 
>> On сб, авг. 17, 2019 at 00:04, Kinney, Michael D > > wrote:
>>> 
>>> Laszlo,
>>> 
>>> I agree that better comments/documentation of STATIC_ASSERT()
>>> for EDK II usages is required. For example, EDK II defines
>>> the ASSERT() macro which is based on the standard C function
>>> assert(), but we still document it fully for EDK II usage.
>>> 
>>> /**
>>> Macro that calls DebugAssert() if an expression evaluates to FALSE.
>>> 
>>> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
>>> bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
>>> expression specified by Expression. If Expression evaluates to FALSE, then
>>> DebugAssert() is called passing in the source filename, source line number,
>>> and Expression.
>>> 
>>> @param Expression Boolean expression.
>>> 
>>> **/
>>> #if !defined(MDEPKG_NDEBUG)
>>> #define ASSERT(Expression) \
>>> do { \
>>> if (DebugAssertEnabled ()) { \
>>> if (!(Expression)) { \
>>> _ASSERT (Expression); \
>>> ANALYZER_UNREACHABLE (); \
>>> } \
>>> } \
>>> } while (FALSE)
>>> #else
>>> #define ASSERT(Expression)
>>> #endif
>>> 
>>> I would like to see the macro documentation for
>>> STATIC_ASSERT() with the Doxygen style description of the
>>> parameters. The fact I asked if STATIC_ASSERT() supported
>>> the 2nd message parameter should have been a trigger
>>> for me to ask for the more complete macro comment block.
>>> The fact that this macro can be directly mapped to
>>> built in compiler name makes the implementation simple,
>>> but other implementations are possible for compilers
>>> that do not support this feature directly. This is why
>>> the complete description of the EDK II version is required.
>>> 
>>> I would like to see a V3 with the complete description.
>>> 
>>> In general, I agree it is better if there is code that
>>> uses a new feature in the code base, so the feature can
>>> be tested. A second option we can consider going forward
>>> is for unit test code to be submitted with a new feature,
>>> so even if there are no consumers from the EDK II repos,
>>> the feature can still be tested as the EDK II repos are
>>> maintained. A third option is for community members to
>>> provide

[edk2-devel] [PATCH v1 1/3] MdeModulePkg/ResetUtilityLib: Use STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048

Use new STATIC_ASSERT macro instead of VERIFY_SIZE_OF.

Signed-off-by: Vitaly Cheptsov 
---
 MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c 
b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
index 2b5af4b95a..bb151d0331 100644
--- a/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
+++ b/MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c
@@ -20,7 +20,10 @@ typedef struct {
 } RESET_UTILITY_GUID_SPECIFIC_RESET_DATA;
 #pragma pack()
 
-VERIFY_SIZE_OF (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA, 18);
+STATIC_ASSERT (
+  sizeof (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA) == 18,
+  "sizeof (RESET_UTILITY_GUID_SPECIFIC_RESET_DATA) is expected to be 18 bytes"
+  );
 
 /**
   This is a shorthand helper function to reset with reset type and a subtype
-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45870): https://edk2.groups.io/g/devel/message/45870
Mute This Topic: https://groups.io/mt/32918009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signature

[edk2-devel] [PATCH v1 2/3] MdePkg: Use STATIC_ASSERT macro

[Vitaly Cheptsov via Groups.Io]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048

Use new STATIC_ASSERT macro instead of VERIFY_SIZE_OF.

Signed-off-by: Vitaly Cheptsov 
---
 MdePkg/Include/Base.h | 79 ++--
 1 file changed, 40 insertions(+), 39 deletions(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index ec096133ba..d871422cd6 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -41,45 +41,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
 #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
_VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
 
-//
-// Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
-// Section 2.3.1 of the UEFI 2.3 Specification.
-//
-VERIFY_SIZE_OF (BOOLEAN, 1);
-VERIFY_SIZE_OF (INT8, 1);
-VERIFY_SIZE_OF (UINT8, 1);
-VERIFY_SIZE_OF (INT16, 2);
-VERIFY_SIZE_OF (UINT16, 2);
-VERIFY_SIZE_OF (INT32, 4);
-VERIFY_SIZE_OF (UINT32, 4);
-VERIFY_SIZE_OF (INT64, 8);
-VERIFY_SIZE_OF (UINT64, 8);
-VERIFY_SIZE_OF (CHAR8, 1);
-VERIFY_SIZE_OF (CHAR16, 2);
-
-//
-// The following three enum types are used to verify that the compiler
-// configuration for enum types is compliant with Section 2.3.1 of the
-// UEFI 2.3 Specification. These enum types and enum values are not
-// intended to be used. A prefix of '__' is used avoid conflicts with
-// other types.
-//
-typedef enum {
-  __VerifyUint8EnumValue = 0xff
-} __VERIFY_UINT8_ENUM_SIZE;
-
-typedef enum {
-  __VerifyUint16EnumValue = 0x
-} __VERIFY_UINT16_ENUM_SIZE;
-
-typedef enum {
-  __VerifyUint32EnumValue = 0x
-} __VERIFY_UINT32_ENUM_SIZE;
-
-VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
-VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
-VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
-
 //
 // The Microsoft* C compiler can removed references to unreferenced data items
 //  if the /OPT:REF linker option is used. We defined a macro as this is a
@@ -857,6 +818,46 @@ typedef UINTN  *BASE_LIST;
   #define STATIC_ASSERT _Static_assert
 #endif
 
+//
+// Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
+// Section 2.3.1 of the UEFI 2.3 Specification.
+//
+
+STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (INT8)== 1, "sizeof (INT8) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (UINT8)   == 1, "sizeof (UINT8) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (INT16)   == 2, "sizeof (INT16) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (UINT16)  == 2, "sizeof (UINT16) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (INT32)   == 4, "sizeof (INT32) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (UINT32)  == 4, "sizeof (UINT32) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (INT64)   == 8, "sizeof (INT64) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (UINT64)  == 8, "sizeof (UINT64) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (CHAR8)   == 1, "sizeof (CHAR8) does not meet UEFI 
Specification Data Type requirements");
+STATIC_ASSERT (sizeof (CHAR16)  == 2, "sizeof (CHAR16) does not meet UEFI 
Specification Data Type requirements");
+
+//
+// The following three enum types are used to verify that the compiler
+// configuration for enum types is compliant with Section 2.3.1 of the
+// UEFI 2.3 Specification. These enum types and enum values are not
+// intended to be used. A prefix of '__' is used avoid conflicts with
+// other types.
+//
+typedef enum {
+  __VerifyUint8EnumValue = 0xff
+} __VERIFY_UINT8_ENUM_SIZE;
+
+typedef enum {
+  __VerifyUint16EnumValue = 0x
+} __VERIFY_UINT16_ENUM_SIZE;
+
+typedef enum {
+  __VerifyUint32EnumValue = 0x
+} __VERIFY_UINT32_ENUM_SIZE;
+
+STATIC_ASSERT (sizeof (__VERIFY_UINT8_ENUM_SIZE) == 4, "Size of enum does not 
meet UEFI Specification Data Type requirements");
+STATIC_ASSERT (sizeof (__VERIFY_UINT16_ENUM_SIZE) == 4, "Size of enum does not 
meet UEFI Specification Data Type requirements");
+STATIC_ASSERT (sizeof (__VERIFY_UINT32_ENUM_SIZE) == 4, "Size of enum does not 
meet UEFI Specification Data Type requirements");
+
 /**
   Macro that returns a pointer to the data structure that contains a specified 
field of
   that data structure.  This is a lightweight method to hide information by 
placing a
-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45873): https://edk2.groups.io/g/devel/message/45873
Mute This Topic: https://groups.io/mt/32918012/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signatu

[edk2-devel] [PATCH v1 3/3] MdePkg: Drop VERIFY_SIZE_OF in favour of STATIC_ASSERT

[Vitaly Cheptsov via Groups.Io]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048

New STATIC_ASSERT macro supersedes VERIFY_SIZE_OF as being more functional.

Signed-off-by: Vitaly Cheptsov 
---
 MdePkg/Include/Base.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index d871422cd6..ed85b98318 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -28,19 +28,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #pragma warning ( disable : 4200 )
 #endif
 
-/**
-  Verifies the storage size of a given data type.
-
-  This macro generates a divide by zero error or a zero size array declaration 
in
-  the preprocessor if the size is incorrect.  These are declared as "extern" so
-  the space for these arrays will not be in the modules.
-
-  @param  TYPE  The date type to determine the size of.
-  @param  Size  The expected size for the TYPE.
-
-**/
-#define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
_VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
-
 //
 // The Microsoft* C compiler can removed references to unreferenced data items
 //  if the /OPT:REF linker option is used. We defined a macro as this is a
-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45872): https://edk2.groups.io/g/devel/message/45872
Mute This Topic: https://groups.io/mt/32918011/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signature

[edk2-devel] [PATCH v1 0/3] Replace VERIFY_SIZE_OF with STATIC_ASSERT

[Vitaly Cheptsov via Groups.Io]

Things to note:

- This patchset should go after STATIC_ASSERT implementation:
  https://edk2.groups.io/g/devel/topic/32917749
- It is suggested that unlike the previous patch, which in my
  opinion should appear in edk2-stable201908, this patchset should
  land in edk2-stable2019011. This will let more people to comment
  whether they are ready to use it as is.

Vitaly Cheptsov (3):
  MdeModulePkg/ResetUtilityLib: Use STATIC_ASSERT macro
  MdePkg: Use STATIC_ASSERT macro
  MdePkg: Drop VERIFY_SIZE_OF in favour of STATIC_ASSERT

 MdePkg/Include/Base.h   | 92 +---
 MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c |  5 +-
 2 files changed, 44 insertions(+), 53 deletions(-)

-- 
2.20.1 (Apple Git-117)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45871): https://edk2.groups.io/g/devel/message/45871
Mute This Topic: https://groups.io/mt/32918010/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: OpenPGP digital signature

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[rebecca]

On 2019-08-16 16:58, Andrew Fish via Groups.Io wrote:
>
> I'm all for modernization of the C code as long we are thoughtful
> about compatibility. For example I still see that VS2008 is a
> supported BaseTools/Conf/tools_def.template.


It would be interesting to see who's using the older toolchains against
current/newer revisions of the edk2.

For example at work we build a UEFI driver using VS2012, but it's
against the UDK2014.SP1 branch, and being for a legacy product we'll
never migrate to a newer UDK release or master tag.


-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45874): https://edk2.groups.io/g/devel/message/45874
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[Andrew Fish via Groups.Io]

> On Aug 16, 2019, at 5:01 PM, Rebecca Cran  wrote:
> 
> On 2019-08-16 16:58, Andrew Fish via Groups.Io wrote:
>> 
>> I'm all for modernization of the C code as long we are thoughtful
>> about compatibility. For example I still see that VS2008 is a
>> supported BaseTools/Conf/tools_def.template.
> 
> 
> It would be interesting to see who's using the older toolchains against
> current/newer revisions of the edk2.
> 
> For example at work we build a UEFI driver using VS2012, but it's
> against the UDK2014.SP1 branch, and being for a legacy product we'll
> never migrate to a newer UDK release or master tag.
> 

Rebecca,

It is also interesting in the context of our CI as we could pick oldest and 
newest version from every compiler family for the CI build test. 

Thanks,

Andrew Fish


> 
> -- 
> Rebecca Cran
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45875): https://edk2.groups.io/g/devel/message/45875
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

[rebecca]

On 2019-08-16 18:03, Andrew Fish wrote:
> It is also interesting in the context of our CI as we could pick oldest and 
> newest version from every compiler family for the CI build test. 


Yes, that's going to be important. Given
https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015?view=vs-2019,
I suspect support for VS2008 might already have been broken, since it
reports that "static_assert" was introduced in Visual Studio 2010 - and
we use it in BaseTools/Source/C/Common/PcdValueCommon.h (the
_STATIC_ASSERT was added in September 2018):


#if defined(_MSC_EXTENSIONS)
#define __STATIC_ASSERT static_assert
#else
#define __STATIC_ASSERT _Static_assert
#endif


-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45876): https://edk2.groups.io/g/devel/message/45876
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH V1 05/37] CoffeelakeSiliconPkg/Pch: Add ConfigBlock headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds header files to Pch/Include/ConfigBlock.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/CnviConfig.h
|  69 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/DciConfig.h 
|  56 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/DmiConfig.h 
|  43 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/EspiConfig.h
|  40 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/FlashProtectionConfig.h
 |  54 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/GpioDevConfig.h 
|  39 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/HdAudioConfig.h 
| 178 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/HsioConfig.h
|  57 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/HsioPcieConfig.h
|  58 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/HsioSataConfig.h
|  66 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/InterruptConfig.h   
|  58 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/IoApicConfig.h  
|  68 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/IshConfig.h 
|  57 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/LanConfig.h 
|  35 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/LockDownConfig.h
|  70 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/LpcConfig.h 
|  34 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/P2sbConfig.h
|  49 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/PchGeneralConfig.h  
|  71 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/PchTraceHubConfig.h 
|  36 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/PcieRpConfig.h  
| 429 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/PmConfig.h  
| 311 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/SataConfig.h
| 230 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/ScsConfig.h 
|  63 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/SerialIoConfig.h
|  96 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/SerialIrqConfig.h   
|  43 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/SmbusConfig.h   
|  52 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/ThermalConfig.h 
| 139 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/WatchDogConfig.h
|  33 ++
 28 files changed, 2534 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/CnviConfig.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/CnviConfig.h
new file mode 100644
index 00..35fa125ba3
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/ConfigBlock/CnviConfig.h
@@ -0,0 +1,69 @@
+/** @file
+  CNVI policy
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _CNVI_CONFIG_H_
+#define _CNVI_CONFIG_H_
+
+#define CNVI_CONFIG_REVISION 2
+extern EFI_GUID gCnviConfigGuid;
+
+#pragma pack (push,1)
+
+/**
+  CNVi Mode options
+**/
+typedef enum {
+  CnviModeDisabled = 0,
+  CnviModeAuto
+} CNVI_MODE;
+
+/**
+  CNVi MfUart1 connection options
+**/
+typedef enum {
+  CnviMfUart1Ish = 0,
+  CnviMfUart1SerialIo,
+  CnviBtUart1ExtPads,
+  CnviBtUart1NotConnected
+} CNVI_MFUART1_TYPE;
+
+
+/**
+  Revision 1:
+  - Initial version.
+  Revision 2:
+  - Remove BtInterface and BtUartType.
+
+**/
+typedef struct {
+  CONFIG_BLOCK_HEADER   Header;   ///< Config Block Header
+  /**
+This option allows for automatic detection of Connectivity Solution.
+Auto Detection assumes that CNVi will be enabled when available;
+Disable allows for disabling CNVi.
+CnviModeDisabled = Disabled,
+CnviModeAuto = Auto Detection
+  **/
+  UINT32 Mode  :  1;
+  /**
+(Test) This option configures Uart type which connects to MfUart1
+For production configuration ISH is the default, for tests SerialIO Uart0 
or external pads can be used
+Use CNVI_MFUART1_TYPE enum for selection
+CnviMfUart1Ish = MfUart1 over ISH Uart0,
+CnviMfUart1SerialIo = MfUart1 over SerialIO Uart2,
+CnviBtUart1ExtPads = MfUart1 over exteranl pads,
+CnviBtUart1NotConnected = MfUart1 not connected
+  **/
+  UINT32 MfUart1Type   :  2;
+  UINT32 RsvdBits  : 29;
+} PCH_CNVI_CONFIG;
+
+#pragma pack (pop)
+
+#endif // _CNVI_CONFIG_H_
+
diff --gi

[edk2-devel] [edk2-platforms][PATCH V1 15/37] CoffeelakeSiliconPkg/Cpu: Add library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds CPU library class instances.

* BaseCpuMailboxLibNull - Generic CPU mailbox interaction services.
* PeiCpuPolicyLib - CPU policy configuration services.
* PeiCpuPolicyLibPreMem - CPU policy pre-memory configuration services.
* PeiDxeSmmCpuPlatformLib - CPU platform services.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/BaseCpuMailboxLibNull/BaseCpuMailboxLibNull.inf
 |  22 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLib.inf
 |  65 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLibPreMem.inf
   |  43 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/PeiDxeSmmCpuPlatformLib.inf
 |  39 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLibrary.h
   |  30 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/CpuPlatformLibrary.h
|  28 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/BaseCpuMailboxLibNull/BaseCpuMailboxLibNull.c
   |  90 
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c 
   | 293 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicyPreMem.c
  | 108 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLib.c
   | 434 
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLibPreMem.c
 | 160 
 
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiDxeSmmCpuPlatformLib/CpuPlatformLibrary.c
| 415 +++
 12 files changed, 1727 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/BaseCpuMailboxLibNull/BaseCpuMailboxLibNull.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/BaseCpuMailboxLibNull/BaseCpuMailboxLibNull.inf
new file mode 100644
index 00..4fcfca4670
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/BaseCpuMailboxLibNull/BaseCpuMailboxLibNull.inf
@@ -0,0 +1,22 @@
+## @file
+# Component description file for Cpu Mailbox Null Lib
+#
+# Copyright (c) 2017 - 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseCpuMailboxLibNull
+FILE_GUID = 74F470BC-1769-4732-B9C0-EE9AB0B12411
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = CpuMailboxLib
+
+[Packages]
+MdePkg/MdePkg.dec
+
+[Sources]
+BaseCpuMailboxLibNull.c
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLib.inf
new file mode 100644
index 00..c986e35360
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLib.inf
@@ -0,0 +1,65 @@
+## @file
+# Component description file for the PeiCpuPolicyLib library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = PeiCpuPolicyLib
+FILE_GUID = 5baafc8f-25c6-4d19-b141-585757509372
+VERSION_STRING = 1.0
+MODULE_TYPE = PEIM
+LIBRARY_CLASS = CpuPolicyLib
+
+
+[LibraryClasses]
+DebugLib
+IoLib
+PeiServicesLib
+BaseMemoryLib
+MemoryAllocationLib
+CpuPlatformLib
+PciSegmentLib
+SaPlatformLib
+SiConfigBlockLib
+PostCodeLib
+PcdLib
+
+[Packages]
+MdePkg/MdePkg.dec
+UefiCpuPkg/UefiCpuPkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+PeiCpuPolicyLib.c
+PeiCpuPolicyLibrary.h
+CpuPrintPolicy.c
+PeiCpuPolicyLibPreMem.c
+CpuPrintPolicyPreMem.c
+
+[Ppis]
+gSiPolicyPpiGuid## CONSUMES
+gSiPreMemPolicyPpiGuid  ## CONSUMES
+
+[FixedPcd]
+gSiPkgTokenSpaceGuid.PcdFlashMicrocodeFvBase
+gSiPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize
+
+[Pcd]
+gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode  ## Produces
+
+[Guids]
+gCpuConfigGuid  ## PRODUCES
+gCpuSgxConfigGuid   ## PRODUCES
+gCpuPowerMgmtBasicConfigGuid## PRODUCES
+gCpuPowerMgmtCustomConfigGuid   ## PRODUCES
+gCpuTestConfigGuid  ## PRODUCES
+gCpuPidTestConfigGuid   ## PRODUCES
+gCpuPowerMgmtTestConfigGuid ## PRODUCES
+gCpuConfigLibPreMemConfigGuid   ## PRODUCES
+gCpuSecurityPreMemConfigGuid## PRODUCES
+gCpuOverclockingPreMemConfigGuid## CONSUMES
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLibPreMem.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/PeiCpuPolicyLibPreMem.inf
new file mode 100644
index 00..52dc989f74
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCp

[edk2-devel] [edk2-platforms][PATCH V1 10/37] CoffeelakeSiliconPkg/Pch: Add Private/Library include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds the following header files:
 * Pch/Include/Private/Library

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/DxePchHdaNhlt.h 
  |  134 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/GpioHelpersLib.h 
 |   97 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/GpioNameBufferLib.h
   |   25 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/GpioPrivateLib.h 
 | 1061 
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/I2cMasterCommonLib.h
  |  288 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchDmiLib.h 
  |  344 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchHdaLib.h 
  |   56 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchInitCommonLib.h
|  100 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchPciExpressHelpersLib.h
 |  371 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchPsfPrivateLib.h
|  578 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchSmbusCommonLib.h
   |   98 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PchSpiCommonLib.h
 |  366 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PeiPchDmiLib.h  
  |   25 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/PmcPrivateLib.h 
  |  706 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/SiScheduleResetLib.h
  |   48 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/SmmPchPrivateLib.h
|   28 +
 16 files changed, 4325 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/DxePchHdaNhlt.h
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/DxePchHdaNhlt.h
new file mode 100644
index 00..9d8e34eb0d
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Library/DxePchHdaNhlt.h
@@ -0,0 +1,134 @@
+/** @file
+  Header file for DxePchHdaLib - NHLT structure definitions.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _DXE_PCH_HDA_NHLT_H_
+#define _DXE_PCH_HDA_NHLT_H_
+
+#include 
+
+//
+// ACPI support protocol instance signature definition.
+//
+#define NHLT_ACPI_TABLE_SIGNATURE  SIGNATURE_32 ('N', 'H', 'L', 'T')
+
+// MSFT defined structures
+#define SPEAKER_FRONT_LEFT  0x1
+#define SPEAKER_FRONT_RIGHT 0x2
+#define SPEAKER_FRONT_CENTER0x4
+#define SPEAKER_BACK_LEFT   0x10
+#define SPEAKER_BACK_RIGHT  0x20
+
+#define KSAUDIO_SPEAKER_MONO   (SPEAKER_FRONT_CENTER)
+#define KSAUDIO_SPEAKER_STEREO (SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT)
+#define KSAUDIO_SPEAKER_QUAD   (SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | 
SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT)
+
+#define WAVE_FORMAT_EXTENSIBLE0xFFFE /* Microsoft */
+#define KSDATAFORMAT_SUBTYPE_PCM \
+{0x0001, 0x, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 
0x9b, 0x71}}
+
+#pragma pack (push, 1)
+
+typedef struct {
+  UINT16  wFormatTag;
+  UINT16  nChannels;
+  UINT32  nSamplesPerSec;
+  UINT32  nAvgBytesPerSec;
+  UINT16  nBlockAlign;
+  UINT16  wBitsPerSample;
+  UINT16  cbSize;
+} WAVEFORMATEX;
+
+typedef struct {
+  WAVEFORMATEX Format;
+  union {
+UINT16 wValidBitsPerSample;
+UINT16 wSamplesPerBlock;
+UINT16 wReserved;
+  } Samples;
+  UINT32   dwChannelMask;
+  GUID SubFormat;
+} WAVEFORMATEXTENSIBLE;
+
+//
+// List of supported link type.
+//
+enum NHLT_LINK_TYPE
+{
+  HdaNhltLinkHd   = 0,
+  HdaNhltLinkDsp  = 1,
+  HdaNhltLinkDmic = 2,
+  HdaNhltLinkSsp  = 3,
+  HdaNhltLinkInvalid
+};
+
+//
+// List of supported device type.
+//
+enum NHLT_DEVICE_TYPE
+{
+  HdaNhltDeviceBt   = 0,
+  HdaNhltDeviceDmic = 1,
+  HdaNhltDeviceI2s  = 4,
+  HdaNhltDeviceInvalid
+};
+
+typedef struct {
+  UINT32CapabilitiesSize;
+  UINT8 Capabilities[1];
+} SPECIFIC_CONFIG;
+
+typedef struct {
+  WAVEFORMATEXTENSIBLE Format;
+  SPECIFIC_CONFIG  FormatConfiguration;
+} FORMAT_CONFIG;
+
+typedef struct {
+  UINT8   FormatsCount;
+  FORMAT_CONFIG   FormatsConfiguration[1];
+} FORMATS_CONFIG;
+
+typedef struct {
+  UINT8   DeviceId[16];
+  UINT8   DeviceInstanceId;
+  UINT8   DevicePortId;
+} DEVICE_INFO;
+
+typedef struct {
+  UINT8   DeviceInfoCount;
+  DEVICE_INFO DeviceInformation[1];
+} DEVICES_INFO;
+
+typedef struct {
+  UINT32  EndpointDescriptorLength;
+  UINT8   LinkType;
+  UINT8   InstanceId;
+  UINT16  HwVendorId;
+  UINT16  HwDeviceId;
+  

[edk2-devel] [edk2-platforms][PATCH V1 17/37] CoffeelakeSiliconPkg/Pch: Add Base library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds PCH Base library class instances.

* BaseResetSystemLib
* BaseSmbusLib

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.inf
 |  38 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseSmbusLib/BaseSmbusLib.inf   
  |  39 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.c
   | 153 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseSmbusLib/BaseSmbusLib.c 
  | 993 
 4 files changed, 1223 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.inf
new file mode 100644
index 00..8d68f2dd83
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.inf
@@ -0,0 +1,38 @@
+## @file
+# Component description file for Intel Ich7 Reset System Library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseResetSystemLib
+FILE_GUID = D4FF05AA-3C7D-4B8A-A1EE-AA5EFA0B1732
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+UEFI_SPECIFICATION_VERSION = 2.00
+LIBRARY_CLASS = ResetSystemLib
+CONSTRUCTOR = BaseResetSystemLibConstructor
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF
+#
+
+[LibraryClasses]
+IoLib
+DebugLib
+PmcLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+BaseResetSystemLib.c
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseSmbusLib/BaseSmbusLib.inf 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseSmbusLib/BaseSmbusLib.inf
new file mode 100644
index 00..f3388a2624
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseSmbusLib/BaseSmbusLib.inf
@@ -0,0 +1,39 @@
+## @file
+# Component description file for PCH Smbus Library.
+#
+# SMBUS Library that layers on top of the I/O Library to directly
+# access a standard SMBUS host controller.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseSmbusLib
+FILE_GUID = 5C4D0430-F81B-42D3-BB88-4A6CD2796FF8
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = SmbusLib
+CONSTRUCTOR = BaseSmbusLibConstructor
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF EBC
+#
+
+[LibraryClasses]
+BaseLib
+DebugLib
+IoLib
+PciSegmentLib
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+BaseSmbusLib.c
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.c
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.c
new file mode 100644
index 00..a603f5e794
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/BaseResetSystemLib/BaseResetSystemLib.c
@@ -0,0 +1,153 @@
+/** @file
+  System reset library services.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+GLOBAL_REMOVE_IF_UNREFERENCED UINT16   mBaseResetSystemABase;
+
+/**
+  Calling this function causes a system-wide reset. This sets
+  all circuitry within the system to its initial state. This type of reset
+  is asynchronous to system operation and operates without regard to
+  cycle boundaries.
+
+  System reset should not return, if it returns, it means the system does
+  not support cold reset.
+**/
+VOID
+EFIAPI
+ResetCold (
+  VOID
+  )
+{
+  IoWrite8 (R_PCH_IO_RST_CNT, V_PCH_IO_RST_CNT_FULLRESET);
+}
+
+/**
+  Calling this function causes a system-wide initialization. The processors
+  are set to their initial state, and pending cycles are not corrupted.
+
+  System reset should not return, if it returns, it means the system does
+  not support warm reset.
+**/
+VOID
+EFIAPI
+ResetWarm (
+  VOID
+  )
+{
+  IoWrite8 (R_PCH_IO_RST_CNT, V_PCH_IO_RST_CNT_HARDRESET);
+}
+
+/**
+  Calling this function causes the system to enter a power state equivalent
+  to the ACPI G2/S5 or G3 states.
+
+  System shutdown should not return, if it returns, it means the system does
+  not support shut down reset.
+**/
+VOID
+EFIAPI
+ResetShutdown (
+  VOID
+  )
+{
+  UINT16 ABase;
+  UINT32 Data32;
+
+  ABase = mBaseResetSystemABase;
+  if (ABase == 0) {
+ABase = PmcGetAcpiBase ();
+  }
+  ///
+  /// Firstly, GPE0_EN sho

[edk2-devel] [edk2-platforms][PATCH V1 07/37] CoffeelakeSiliconPkg/Pch: Add PPI and Protocol include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds the following header files:
 * Pch/Include/Ppi
 * Pch/Include/Protocol

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/PchReset.h  
  |  42 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Spi.h   
  |  27 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Wdt.h   
  |  28 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/IoTrapExDispatch.h 
  | 186 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchAcpiSmiDispatch.h   
  | 136 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchEmmcTuning.h
  |  68 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchEspiSmiDispatch.h   
  | 146 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchPcieSmiDispatch.h   
  | 132 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchPolicy.h
  |  42 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchReset.h 
  |  42 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchSmiDispatch.h   
  | 134 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchSmmIoTrapControl.h  
  |  67 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchSmmPeriodicTimerControl.h
 |  67 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/PchTcoSmiDispatch.h
  | 152 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/SmmSmbus.h 
  |  15 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/Spi.h  
  | 295 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Protocol/Wdt.h  
  | 113 
 17 files changed, 1692 insertions(+)

diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/PchReset.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/PchReset.h
new file mode 100644
index 00..840a2355f1
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/PchReset.h
@@ -0,0 +1,42 @@
+/** @file
+  PCH Reset PPI
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PCH_RESET_PPI_H_
+#define _PCH_RESET_PPI_H_
+
+//
+// Member functions
+//
+/**
+  Execute call back function for Pch Reset.
+
+  @param[in] ResetTypeReset Types which includes GlobalReset.
+  @param[in] ResetTypeGuidPointer to an EFI_GUID, which is the Reset 
Type Guid.
+
+  @retval EFI_SUCCESS The callback function has been done 
successfully
+  @retval EFI_NOT_FOUND   Failed to find Pch Reset Callback ppi. Or, 
none of
+  callback ppi is installed.
+  @retval Others  Do not do any reset from PCH
+**/
+typedef
+EFI_STATUS
+(EFIAPI *PCH_RESET_CALLBACK) (
+  IN  EFI_RESET_TYPEResetType,
+  IN  EFI_GUID  *ResetTypeGuid
+  );
+
+/**
+  This ppi is used to execute PCH Reset from the host controller.
+  If drivers need to run their callback function right before issuing the PCH 
Reset,
+  they can install PCH Reset Callback PPI before PCH Reset PEI driver to 
achieve that.
+**/
+typedef struct {
+  PCH_RESET_CALLBACK  ResetCallback;
+} PCH_RESET_CALLBACK_PPI;
+
+#endif
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Spi.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Spi.h
new file mode 100644
index 00..d3ff152742
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Spi.h
@@ -0,0 +1,27 @@
+/** @file
+  This file defines the PCH SPI PPI which implements the
+  Intel(R) PCH SPI Host Controller Compatibility Interface.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PCH_SPI_PPI_H_
+#define _PCH_SPI_PPI_H_
+
+#include 
+
+//
+// Extern the GUID for PPI users.
+//
+extern EFI_GUID   gPchSpiPpiGuid;
+
+/**
+  Reuse the PCH_SPI_PROTOCOL definitions
+  This is possible becaues the PPI implementation does not rely on a 
PeiService pointer,
+  as it uses EDKII Glue Lib to do IO accesses
+**/
+typedef PCH_SPI_PROTOCOL PCH_SPI_PPI;
+
+#endif
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Wdt.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Wdt.h
new file mode 100644
index 00..59a9f0f251
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Ppi/Wdt.h
@@ -0,0 +1,28 @@
+/** @file
+  Watchdog Timer PPI
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PEI_WDT_H_
+#define _PEI_WDT_H_
+
+#include 
+//
+// MRC takes a lot of time to 

[edk2-devel] [edk2-platforms][PATCH V1 04/37] CoffeelakeSiliconPkg/Pch: Add include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds Pch/Include headers.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/DxeHdaNhlt.h   | 
135 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/GpioConfig.h   | 
326 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/GpioPinsCnlH.h | 
381 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/GpioPinsCnlLp.h| 
340 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/GpioPinsSklH.h | 
241 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/GpioPinsSklLp.h| 
200 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchAccess.h|  
54 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchHda.h   |  
38 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchInfoHob.h   |  
80 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchLimits.h|  
53 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchPcieStorageDetectHob.h  |  
47 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchPolicyCommon.h  |  
47 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchPreMemPolicyCommon.h|  
59 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchReservedResources.h |  
53 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/PchResetPlatformSpecific.h |  
23 ++
 15 files changed, 2077 insertions(+)

diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/DxeHdaNhlt.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/DxeHdaNhlt.h
new file mode 100644
index 00..91222fd54d
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/DxeHdaNhlt.h
@@ -0,0 +1,135 @@
+/** @file
+  Header file for DxePchHdaNhltLib - NHLT structure definitions.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _DXE_HDA_NHLT_H_
+#define _DXE_HDA_NHLT_H_
+
+#include 
+
+//
+// ACPI support protocol instance signature definition.
+//
+#define NHLT_ACPI_TABLE_SIGNATURE  SIGNATURE_32 ('N', 'H', 'L', 'T')
+
+// MSFT defined structures
+#define SPEAKER_FRONT_LEFT  0x1
+#define SPEAKER_FRONT_RIGHT 0x2
+#define SPEAKER_FRONT_CENTER0x4
+#define SPEAKER_BACK_LEFT   0x10
+#define SPEAKER_BACK_RIGHT  0x20
+
+#define KSAUDIO_SPEAKER_MONO   (SPEAKER_FRONT_CENTER)
+#define KSAUDIO_SPEAKER_STEREO (SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT)
+#define KSAUDIO_SPEAKER_QUAD   (SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | 
SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT)
+
+#define WAVE_FORMAT_EXTENSIBLE0xFFFE
+#define KSDATAFORMAT_SUBTYPE_PCM \
+{0x0001, 0x, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 
0x9b, 0x71}}
+
+#pragma pack (push, 1)
+
+typedef struct {
+  UINT16  wFormatTag;
+  UINT16  nChannels;
+  UINT32  nSamplesPerSec;
+  UINT32  nAvgBytesPerSec;
+  UINT16  nBlockAlign;
+  UINT16  wBitsPerSample;
+  UINT16  cbSize;
+} WAVEFORMATEX;
+
+typedef struct {
+  WAVEFORMATEX Format;
+  union {
+UINT16 wValidBitsPerSample;
+UINT16 wSamplesPerBlock;
+UINT16 wReserved;
+  } Samples;
+  UINT32   dwChannelMask;
+  GUID SubFormat;
+} WAVEFORMATEXTENSIBLE;
+
+//
+// List of supported link type.
+//
+enum NHLT_LINK_TYPE
+{
+  HdaNhltLinkHd   = 0,
+  HdaNhltLinkDsp  = 1,
+  HdaNhltLinkDmic = 2,
+  HdaNhltLinkSsp  = 3,
+  HdaNhltLinkInvalid
+};
+
+//
+// List of supported device type.
+//
+enum NHLT_DEVICE_TYPE
+{
+  HdaNhltDeviceBt   = 0,
+  HdaNhltDeviceDmic = 1,
+  HdaNhltDeviceI2s  = 4,
+  HdaNhltDeviceInvalid
+};
+
+typedef struct {
+  UINT32CapabilitiesSize;
+  UINT8 Capabilities[1];
+} SPECIFIC_CONFIG;
+
+typedef struct {
+  WAVEFORMATEXTENSIBLE Format;
+  SPECIFIC_CONFIG  FormatConfiguration;
+} FORMAT_CONFIG;
+
+typedef struct {
+  UINT8   FormatsCount;
+  FORMAT_CONFIG   FormatsConfiguration[1];
+} FORMATS_CONFIG;
+
+typedef struct {
+  UINT8   DeviceId[16];
+  UINT8   DeviceInstanceId;
+  UINT8   DevicePortId;
+} DEVICE_INFO;
+
+typedef struct {
+  UINT8   DeviceInfoCount;
+  DEVICE_INFO DeviceInformation[1];
+} DEVICES_INFO;
+
+typedef struct {
+  UINT32  EndpointDescriptorLength;
+  UINT8   LinkType;
+  UINT8   InstanceId;
+  UINT16  HwVendorId;
+  UINT16  HwDeviceId;
+  UINT16  HwRevisionId;
+  UINT32  HwSubsystemId;
+  UINT8   DeviceType;
+  UINT8   Direction;
+  UINT8   VirtualBusId;
+  SPECIFIC_CONFIG EndpointConfig;
+  FORMATS_CONFIG  FormatsConfig;
+  DEVICES_INFODevicesInformation;
+} ENDPOINT_DESCRIPTOR;
+
+//
+// High Level Table structure
+//
+typedef struct {
+  EFI_ACPI_DESCRIPTION_HEADER Header; //{'N', 'H', 'L', 'T'}
+  UINT8   En

[edk2-devel] [edk2-platforms][PATCH V1 06/37] CoffeelakeSiliconPkg/Pch: Add Library include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds the following header files:
 * Pch/Include/library

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/BiosLockLib.h | 
 27 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/CnviLib.h | 
 24 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/DxePchPolicyLib.h | 
 58 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/GbeMdiLib.h   | 
265 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/GpioLib.h | 
788 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/GpioNativeLib.h   | 
166 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/OcWdtLib.h| 
 33 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchCycleDecodingLib.h | 
371 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchEspiLib.h  | 
141 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchGbeLib.h   | 
 36 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchHsioLib.h  | 
109 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchInfoLib.h  | 
407 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchPcieRpLib.h| 
105 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchPcrLib.h   | 
226 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchPmcLib.h   | 
 45 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchPolicyLib.h| 
114 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchResetLib.h | 
 24 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchSbiAccessLib.h | 
116 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchSerialIoLib.h  | 
240 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchSerialIoUartLib.h  | 
111 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchSmmControlLib.h| 
 23 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PchWdtCommonLib.h | 
121 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/PmcLib.h  | 
207 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/SataLib.h | 
 76 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/SecPchLib.h   | 
 22 +
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/SpiFlashCommonLib.h   | 
 98 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/SpiLib.h  | 
 23 +
 27 files changed, 3976 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/BiosLockLib.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/BiosLockLib.h
new file mode 100644
index 00..ee77334ecb
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/BiosLockLib.h
@@ -0,0 +1,27 @@
+/** @file
+  Header file for BiosLockLib.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _BIOSLOCK_LIB_H_
+#define _BIOSLOCK_LIB_H_
+
+/**
+  Enable BIOS lock. This will set the LE (Lock Enable) and EISS (Enable In 
SMM.STS).
+  When this is set, attempts to write the WPD (Write Protect Disable) bit in 
PCH
+  will cause a SMI which will allow the BIOS to verify that the write is from 
a valid source.
+
+  Bios should always enable LockDownConfig.BiosLock policy to set Bios Lock 
bit in FRC.
+  If capsule udpate is enabled, it's expected to not do BiosLock by setting 
BiosLock policy disable
+  so it can udpate BIOS region.
+  After flash update, it should utilize this lib to do BiosLock for security.
+**/
+VOID
+BiosLockEnable (
+  VOID
+  );
+
+#endif // _BIOSLOCK_LIB_H_
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/CnviLib.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/CnviLib.h
new file mode 100644
index 00..f406e0d929
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/CnviLib.h
@@ -0,0 +1,24 @@
+/** @file
+  Header file for CnviLib.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _CNVI_LIB_H_
+#define _CNVI_LIB_H_
+
+/**
+  Check if CNVi is present.
+
+  @retval TRUECNVi is enabled
+  @retval FALSE   CNVi is disabled
+
+**/
+BOOLEAN
+CnviIsPresent (
+  VOID
+  );
+
+#endif // _CNVI_LIB_H_
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/DxePchPolicyLib.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/DxePchPolicyLib.h
new file mode 100644
index 00..4d1ed91f7e
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Library/DxePchPolicyLib.h
@@ -0,0 +1,58 @@
+/** @file
+  Prototype of the DxePchPolicyLib libra

[edk2-devel] [edk2-platforms][PATCH V1 01/37] CoffeelakeSiliconPkg: Add package and Include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Create the CoffeelakeSiliconPkg to provide an initial package for
silicon initialization code for Coffee Lake (CFL) and Whiskey Lake
(WHL) generation products.

* Major areas of functionality are categorized into CPU, Management
  Engine (ME), Platform Controller Hub (PCH), and System Agent
  subdirectories.
* Common libraries and headers are kept at the root of the package.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec  | 
714 
 Silicon/Intel/CoffeelakeSiliconPkg/Include/ConfigBlock.h  |  
53 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/ConfigBlock/SiConfig.h |  
89 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/ConfigBlock/UsbConfig.h| 
291 
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/AslUpdateLib.h | 
157 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/ConfigBlockLib.h   |  
64 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/MmPciLib.h |  
28 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/PeiSiPolicyUpdateLib.h | 
123 
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/SiConfigBlockLib.h |  
58 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/SiPolicyLib.h  | 
110 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/StallPpiLib.h  |  
22 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Library/UsbLib.h   |  
34 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/PcieRegs.h | 
319 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Ppi/SiPolicy.h |  
29 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Private/Library/PcieInitLib.h  |  
26 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Private/Library/UsbInitLib.h   |  
71 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Protocol/SiPolicyProtocol.h|  
60 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/Register/RegsUsb.h |  
55 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/SiConfigHob.h  |  
19 +
 Silicon/Intel/CoffeelakeSiliconPkg/Include/SiPolicyStruct.h   |  
65 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Include/TraceHubCommonConfig.h |  
23 +
 21 files changed, 2410 insertions(+)

diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec 
b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
new file mode 100644
index 00..fa8c11e93d
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/SiPkg.dec
@@ -0,0 +1,714 @@
+## @file
+# Component description file for the Silicon Reference Code.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+DEC_SPECIFICATION = 0x00010017
+PACKAGE_NAME  = SiPkg
+PACKAGE_VERSION   = 0.1
+PACKAGE_GUID  = F245E276-44A0-46b3-AEB5-9898BBCF008D
+
+[Includes]
+  Include
+  SampleCode/Include
+  SampleCode/MdeModulePkg/Include
+  SampleCode/IntelFrameworkPkg/Include
+  #
+  # SystemAgent
+  #
+  SystemAgent/Include
+  SystemAgent/MemoryInit/Include
+  SystemAgent/AcpiTables
+  #
+  # Cpu
+  #
+  Cpu/Include
+  #
+  # Me
+  #
+  Me/Include
+  #
+  # Pch
+  #
+  Pch/Include
+
+[Guids.common.Private]
+  #
+  # PCH
+  #
+  gPchDeviceTableHobGuid   = { 0xb3e123d0, 0x7a1e, 0x4db4, { 0xaf, 0x66, 
0xbe, 0xd4, 0x1e, 0x9c, 0x66, 0x38 }}
+  gPchConfigHobGuid= { 0x524ed3ca, 0xb250, 0x49f5, { 0x94, 0xd9, 
0xa2, 0xba, 0xff, 0xc7, 0x0e, 0x14 }}
+  gGpioLibUnlockHobGuid= { 0xA7892E49, 0x0F9F, 0x4166, { 0xB8, 0xD6, 
0x8A, 0x9B, 0xD9, 0x8B, 0x17, 0x38 }}
+  gSiScheduleResetHobGuid  = { 0xEA0597FF, 0x8858, 0x41CA, { 0xBB, 0xC1, 
0xFE, 0x18, 0xFC, 0xD2, 0x8E, 0x22 }}
+
+[Guids]
+##
+## MdeModulePkg
+##
+gEfiMemoryTypeInformationGuid  =  {0x4c19049f, 0x4137, 0x4dd3, {0x9c, 0x10, 
0x8b, 0x97, 0xa8, 0x3f, 0xfd, 0xfa}}
+gEfiCapsuleVendorGuid  =  {0x711c703f, 0xc285, 0x4b10, {0xa3, 0xb0, 0x36, 
0xec, 0xbd, 0x3c, 0x8b, 0xe2}}
+gEfiConsoleOutDeviceGuid = { 0xd3b36f2c, 0xd551, 0x11d4, { 0x9a, 0x46, 0x0, 
0x90, 0x27, 0x3f, 0xc1, 0x4d}}
+
+##
+## IntelFrameworkPkg
+##
+gEfiSmmPeiSmramMemoryReserveGuid =  {0x6dadf1d1, 0xd4cc, 0x4910, {0xbb, 0x6e, 
0x82, 0xb1, 0xfd, 0x80, 0xff, 0x3d}}
+
+##
+## Common
+##
+## Include/ConfigBlock/SiConfig.h
+gSiConfigGuid = {0x4ed6d282, 0x22f3, 0x4fe1, {0xa6, 0x61, 0x6, 0x1a, 0x97, 
0x38, 0x59, 0xd8 }}
+gSiPkgTokenSpaceGuid  =  {0x977c97c1, 0x47e1, 0x4b6b, {0x96, 0x69, 0x43, 0x66, 
0x99, 0xcb, 0xe4, 0x5b}}
+
+## Include/SiConfigHob.h
+gSiConfigHobGuid = {0xb3903068, 0x7482, 0x4424, {0xba, 0x4b, 0x40, 0x5f, 0x8f, 
0xd7, 0x65, 0x4e}}
+
+##
+## System Agent
+##
+gSaAcpiTableStorageGuid  =  {0x3c0ed5e2, 0x91ea, 0x4b94, { 0x82, 0xd, 0x9d, 
0xaf, 0x9a, 0x3b, 0xb4, 0xa2}}
+gSaDataHobGuid  =  {0xe07d0bda, 0xbf90, 0x46a9, { 0xb0, 0x0e, 0xb2, 0xc4, 
0x4a, 0x0e, 0

[edk2-devel] [edk2-platforms][PATCH V1 21/37] CoffeelakeSiliconPkg/Pch: Add Base library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds Pch/Library/Private Base library class instances.

* BaseGpioHelpersLibNull
* BasePchSpiCommonlib
* BaseSiScheduleResetLib
* BaseSiScheduleResetLibFsp

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseGpioHelpersLibNull/BaseGpioHelpersLibNull.inf
 |   26 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BasePchSpiCommonLib/BasePchSpiCommonLib.inf
   |   28 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLib.inf
 |   40 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLibFsp.inf
  |   40 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseGpioHelpersLibNull/BaseGpioHelpersLibNull.c
   |  108 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BasePchSpiCommonLib/SpiCommon.c
   | 1081 
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLib.c
   |   70 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLibCommon.c
 |  125 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLibFsp.c
|   61 ++
 9 files changed, 1579 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseGpioHelpersLibNull/BaseGpioHelpersLibNull.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseGpioHelpersLibNull/BaseGpioHelpersLibNull.inf
new file mode 100644
index 00..5502af824f
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseGpioHelpersLibNull/BaseGpioHelpersLibNull.inf
@@ -0,0 +1,26 @@
+## @file
+# Component description file for the NULL GpioHelpersLib
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseGpioHelpersLib
+FILE_GUID = AB282608-2A50-4AE3-9242-64064ECF40D4
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = GpioHelpersLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+BaseGpioHelpersLibNull.c
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BasePchSpiCommonLib/BasePchSpiCommonLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BasePchSpiCommonLib/BasePchSpiCommonLib.inf
new file mode 100644
index 00..ea23e628c8
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BasePchSpiCommonLib/BasePchSpiCommonLib.inf
@@ -0,0 +1,28 @@
+## @file
+#  Component description file for the PchSpiCommonLib
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BasePchSpiCommonLib
+  FILE_GUID  = A37CB67E-7D85-45B3-B07E-BF65BDB603E8
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PchSpiCommonLib
+
+[Sources]
+  SpiCommon.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  CoffeelakeSiliconPkg/SiPkg.dec
+
+[LibraryClasses]
+  IoLib
+  DebugLib
+  PmcLib
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLib.inf
new file mode 100644
index 00..de7f6eeb73
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLib.inf
@@ -0,0 +1,40 @@
+## @file
+# Component description file for Si Reset Schedule Library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseSiScheduleResetLib
+FILE_GUID = E6F3D551-36C0-4737-80C7-47FC57593163
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = SiScheduleResetLib
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF
+#
+
+[LibraryClasses]
+BaseLib
+IoLib
+DebugLib
+HobLib
+ResetSystemLib
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Guids]
+gSiScheduleResetHobGuid
+gPchConfigHobGuid
+
+[Sources]
+BaseSiScheduleResetLibCommon.c
+BaseSiScheduleResetLib.c
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLibFsp.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/BaseSiScheduleResetLib/BaseSiScheduleResetLibFsp.inf
new file mode 100644
index 00..c8fe9e6079
--- /dev/

[edk2-devel] [edk2-platforms][PATCH V1 14/37] CoffeelakeSiliconPkg: Add package common library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds package-level library class instances.

* BaseConfigBlockLib - Library functions for config block management.
* BaseSiConfigBlockLib - Library functions for managing component
  config blocks.
* DxeAslUpdateLib - Services to update ACPI tables.
* PeiDxeSmmMmPciLib - Services to manage PCI Express addresses.
* PeiStallPpiLib - Installs an instance of EFI_PEI_STALL_PPI.
* PeiSiPolicyLib - Installs an instance of the Silicon Policy PPI.
  Prints the Silicon Policy PPI values when DEBUG prints are enabled.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlockLib.inf
 |  29 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.inf
 |  33 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLib/DxeAslUpdateLib.inf 
  |  40 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLibNull/DxeAslUpdateLibNull.inf
   |  30 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.inf
   |  35 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiInstallStallPpiLib/PeiStallPpiLib.inf
  |  31 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiSiPolicyLib/PeiSiPolicyLib.inf   
  |  51 +++
 Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiSiPolicyLib/PeiSiPolicyLibrary.h 
  |  35 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlockLib.c
   | 146 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.c
   |  87 +
 Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLib/DxeAslUpdateLib.c   
  | 403 
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLibNull/DxeAslUpdateLibNull.c
 | 126 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiDxeSmmMmPciLib/PeiDxeSmmMmPciLib.c
 |  32 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiInstallStallPpiLib/PeiStallPpiLib.c
|  78 
 Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiSiPolicyLib/PeiSiPolicyLib.c 
  | 214 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiSiPolicyLib/PeiSiPolicyLibPreMem.c
 | 122 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Library/PeiSiPolicyLib/SiPrintPolicy.c  
  |  36 ++
 17 files changed, 1528 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlockLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlockLib.inf
new file mode 100644
index 00..a7def2481d
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseConfigBlockLib/BaseConfigBlockLib.inf
@@ -0,0 +1,29 @@
+## @file
+# Component INF file for the BaseConfigBlock library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseConfigBlockLib
+FILE_GUID = 1EC07EA8-7808-4e06-9D79-309AE331D2D5
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = ConfigBlockLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+BaseConfigBlockLib.c
+
+[LibraryClasses]
+DebugLib
+BaseMemoryLib
+MemoryAllocationLib
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.inf
new file mode 100644
index 00..b04dc3cfa4
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/BaseSiConfigBlockLib/BaseSiConfigBlockLib.inf
@@ -0,0 +1,33 @@
+## @file
+# Component description file for the BaseSiConfigBlockLib library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = BaseSiConfigBlockLib
+FILE_GUID = 6C068D0F-F48E-48CB-B369-433E507AF4A2
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = SiConfigBlockLib
+
+
+[LibraryClasses]
+DebugLib
+IoLib
+ConfigBlockLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+BaseSiConfigBlockLib.c
+
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLib/DxeAslUpdateLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLib/DxeAslUpdateLib.inf
new file mode 100644
index 00..658caccb43
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Library/DxeAslUpdateLib/DxeAslUpdateLib.inf
@@ -0,0 +1,40 @@
+## @file
+# Provides services to update ASL tables.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxeAslUpdateLib
+FILE_GUID = 8621697D-4E3A-4bf2-ADB0-3E2FF06559

[edk2-devel] [edk2-platforms][PATCH V1 11/37] CoffeelakeSiliconPkg/Pch: Add Private/Protocol include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds the following header files:
 * Pch/Include/Private/Protocol

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PchNvsArea.h | 
31 
 Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PcieIoTrap.h | 
37 
 2 files changed, 68 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PchNvsArea.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PchNvsArea.h
new file mode 100644
index 00..75003c82ad
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PchNvsArea.h
@@ -0,0 +1,31 @@
+/** @file
+  This file defines the PCH NVS Area Protocol.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PCH_NVS_AREA_H_
+#define _PCH_NVS_AREA_H_
+
+//
+// PCH NVS Area definition
+//
+#include 
+
+//
+// Extern the GUID for protocol users.
+//
+extern EFI_GUID gPchNvsAreaProtocolGuid;
+
+/**
+  This protocol is used to sync PCH information from POST to runtime ASL.
+  This protocol exposes the pointer of PCH NVS Area only. Please refer to
+  ASL definition for PCH NVS AREA.
+**/
+typedef struct {
+  PCH_NVS_AREA  *Area;
+} PCH_NVS_AREA_PROTOCOL;
+
+#endif // _PCH_NVS_AREA_H_
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PcieIoTrap.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PcieIoTrap.h
new file mode 100644
index 00..2cd6b85d29
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Private/Protocol/PcieIoTrap.h
@@ -0,0 +1,37 @@
+/** @file
+  This file defines the PCH PCIE IoTrap Protocol.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PCH_PCIE_IOTRAP_H_
+#define _PCH_PCIE_IOTRAP_H_
+
+//
+// Extern the GUID for protocol users.
+//
+extern EFI_GUID   gPchPcieIoTrapProtocolGuid;
+
+//
+// Forward reference for ANSI C compatibility
+//
+typedef struct _PCH_PCIE_IOTRAP_PROTOCOL PCH_PCIE_IOTRAP_PROTOCOL;
+
+///
+/// Pcie Trap valid types
+///
+typedef enum {
+  PciePmTrap,
+  PcieTrapTypeMaximum
+} PCH_PCIE_TRAP_TYPE;
+
+/**
+ This protocol is used to provide the IoTrap address to trigger PCH PCIE call 
back events
+**/
+struct _PCH_PCIE_IOTRAP_PROTOCOL {
+  UINT16  PcieTrapAddress;
+};
+
+#endif
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45887): https://edk2.groups.io/g/devel/message/45887
Mute This Topic: https://groups.io/mt/32918179/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH V1 36/37] WhiskeylakeOpenBoardPkg/WhiskeylakeURvp: Add DSC and build files

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2083

Adds the DSC and build files necessary to build the
WhiskeylakeURvp board instance.

Key files
=
* build_config.cfg - Board-specific build configuration file.
* OpenBoardPkg.dsc - The WhiskeylakeURvp board description file.
* OpenBoardPkgConfig.dsc - Used for feature-related PCD
  customization.
* OpenBoardPkgPcd.dsc - Used for other PCD customization.
* OpenBoardPkg.fdf - The WhiskeylakeURvp board flash file.
* FlashMapInclude.fdf - The WhiskeylakeURvp board flash map.
* OpenBoardPkgBuildOption.dsc - Sets build options Based
  on PCD values.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Liming Gao 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkg.dsc
| 385 +++
 
Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgBuildOption.dsc
 | 154 +
 Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgConfig.dsc  
| 128 
 Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgPcd.dsc 
| 245 +++
 
Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/Include/Fdf/FlashMapInclude.fdf
 |  49 ++
 Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkg.fdf
| 706 
 Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
|  33 +
 7 files changed, 1700 insertions(+)

diff --git 
a/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkg.dsc 
b/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkg.dsc
new file mode 100644
index 00..eea809140c
--- /dev/null
+++ b/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkg.dsc
@@ -0,0 +1,385 @@
+## @file
+#  Platform description.
+#
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+  #
+  # Set platform specific package/folder name, same as passed from PREBUILD 
script.
+  # PLATFORM_PACKAGE would be the same as PLATFORM_NAME as well as package 
build folder
+  # DEFINE only takes effect at R9 DSC and FDF.
+  #
+  DEFINE  PLATFORM_PACKAGE  = MinPlatformPkg
+  DEFINE  PLATFORM_SI_PACKAGE   = CoffeelakeSiliconPkg
+  DEFINE  PLATFORM_SI_BIN_PACKAGE   = CoffeelakeSiliconBinPkg
+  DEFINE  PLATFORM_FSP_BIN_PACKAGE  = CoffeeLakeFspBinPkg
+  DEFINE  PLATFORM_BOARD_PACKAGE= WhiskeylakeOpenBoardPkg
+  DEFINE  BOARD = WhiskeylakeURvp
+  DEFINE  PROJECT   = $(PLATFORM_BOARD_PACKAGE)/$(BOARD)
+
+  #
+  # Platform On/Off features are defined here
+  #
+  !include OpenBoardPkgConfig.dsc
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME   = $(PLATFORM_PACKAGE)
+  PLATFORM_GUID   = 84D0F5BD-0EF3-4CC0-9B09-F2D0F2AA5C5E
+  PLATFORM_VERSION= 0.1
+  DSC_SPECIFICATION   = 0x00010005
+  OUTPUT_DIRECTORY= Build/$(PROJECT)
+  SUPPORTED_ARCHITECTURES = IA32|X64
+  BUILD_TARGETS   = DEBUG|RELEASE
+  SKUID_IDENTIFIER= ALL
+
+
+  FLASH_DEFINITION= $(PROJECT)/OpenBoardPkg.fdf
+
+  FIX_LOAD_TOP_MEMORY_ADDRESS = 0x0
+  DEFINE   TOP_MEMORY_ADDRESS = 0x0
+
+  #
+  # Default value for OpenBoardPkg.fdf use
+  #
+  DEFINE BIOS_SIZE_OPTION = SIZE_70
+
+
+#
+# SKU Identification section - list of all SKU IDs supported by this
+#  Platform.
+#
+
+[SkuIds]
+  0|DEFAULT  # The entry: 0|DEFAULT is reserved and always 
required.
+  0x60|WhiskeylakeURvp
+
+
+#
+# Library Class section - list of all Library Classes needed by this Platform.
+#
+
+
+  !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc
+  !include $(PLATFORM_PACKAGE)/Include/Dsc/CorePeiLib.dsc
+  !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreDxeLib.dsc
+
+[LibraryClasses.common]
+
+  PeiLib|$(PLATFORM_PACKAGE)/Library/PeiLib/PeiLib.inf
+  
ReportFvLib|$(PLATFORM_PACKAGE)/PlatformInit/Library/PeiReportFvLib/PeiReportFvLib.inf
+
+  
PciHostBridgeLib|$(PLATFORM_PACKAGE)/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.inf
+  
PciSegmentInfoLib|$(PLATFORM_PACKAGE)/Pci/Library/PciSegmentInfoLibSimple/PciSegmentInfoLibSimple.inf
+  
Pl

[edk2-devel] [edk2-platforms][PATCH V1 12/37] CoffeelakeSiliconPkg/SampleCode: Add Include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds header files common to silicon Sample Code.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha >
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/Include/Library/SecPlatformLib.h 
|   82 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h
  |   51 +
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
  | 1513 
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Protocol/LegacyInterrupt.h
 |  118 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Guid/AcpiS3Context.h
|   65 +
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Guid/ConsoleOutDevice.h
 |   17 +
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Guid/MemoryTypeInformation.h
|   30 +
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Library/ResetSystemLib.h
|   80 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Ppi/SmmAccess.h
 |  137 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Ppi/SmmControl.h
|   87 ++
 
Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/MdeModulePkg/Include/Protocol/SmmVariable.h
  |   33 +
 11 files changed, 2213 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/Include/Library/SecPlatformLib.h
 
b/Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/Include/Library/SecPlatformLib.h
new file mode 100644
index 00..829d1190fc
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/Include/Library/SecPlatformLib.h
@@ -0,0 +1,82 @@
+/** @file
+  Prototype of SEC Platform hook library.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef  _SEC_PLATFORM_LIB_H_
+#define  _SEC_PLATFORM_LIB_H_
+
+#include 
+#include 
+
+/**
+  A developer supplied function to perform platform specific operations.
+
+  It's a developer supplied function to perform any operations appropriate to a
+  given platform. It's invoked just before passing control to PEI core by SEC
+  core. Platform developer may modify the SecCoreData passed to PEI Core.
+  It returns a platform specific PPI list that platform wishes to pass to PEI 
core.
+  The Generic SEC core module will merge this list to join the final list 
passed to
+  PEI core.
+
+  @param  SecCoreData   The same parameter as passing to PEI core. It
+could be overridden by this function.
+
+  @return The platform specific PPI list to be passed to PEI core or
+  NULL if there is no need of such platform specific PPI list.
+
+**/
+EFI_PEI_PPI_DESCRIPTOR *
+EFIAPI
+SecPlatformMain (
+  IN OUT   EFI_SEC_PEI_HAND_OFF*SecCoreData
+  );
+
+
+/**
+  This interface conveys state information out of the Security (SEC) phase 
into PEI.
+
+  @param  PeiServices   Pointer to the PEI Services Table.
+  @param  StructureSize Pointer to the variable describing size of 
the input buffer.
+  @param  PlatformInformationRecord Pointer to the 
EFI_SEC_PLATFORM_INFORMATION_RECORD.
+
+  @retval EFI_SUCCESS   The data was successfully returned.
+  @retval EFI_BUFFER_TOO_SMALL  The buffer was too small.
+
+**/
+EFI_STATUS
+EFIAPI
+SecPlatformInformation (
+  IN CONST EFI_PEI_SERVICES **PeiServices,
+  IN OUT   UINT64   *StructureSize,
+ OUT   EFI_SEC_PLATFORM_INFORMATION_RECORD  *PlatformInformationRecord
+  );
+
+/**
+  This interface conveys performance information out of the Security (SEC) 
phase into PEI.
+
+  This service is published by the SEC phase. The SEC phase handoff has an 
optional
+  EFI_PEI_PPI_DESCRIPTOR list as its final argument when control is passed 
from SEC into the
+  PEI Foundation. As such, if the platform supports collecting performance 
data in SEC,
+  this information is encapsulated into the data structure abstracted by this 
service.
+  This information is collected for the boot-strap processor (BSP) on IA-32.
+
+  @param[in]  PeiServices  The pointer to the PEI Services Table.
+  @param[in]  This The pointer to this instance of the 
PEI_SEC_PERFORMANCE_PPI.
+  @param[out] Performance  The pointer to performance data collected in SEC 
phase.
+
+  @retval EFI_SUCCESS  The data was successfully returned.
+**/
+EFI_STATUS
+EFIAPI
+SecGetPerformance (
+  IN CONST EFI_PEI_SERVICES  **PeiServices,
+  IN   PEI_SEC_PERFORMANCE_PPI   *This,
+  OUT  FIRMWARE_SEC_PERFORMANCE  *Performance
+  );
+
+#endif
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/SampleCode/IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h
 
b/Silicon/

[edk2-devel] [edk2-platforms][PATCH V1 16/37] CoffeelakeSiliconPkg/Me: Add library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds ME library class instances.

* PeiMePolicyLib - PEI ME policy configuration services.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.inf 
  |  44 
 
Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLibrary.h
 |  25 ++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.c  
   | 251 
 3 files changed, 320 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.inf
new file mode 100644
index 00..85a227f950
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.inf
@@ -0,0 +1,44 @@
+## @file
+# Component description file for the PeiMePolicyLib libbrary.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = PeiMePolicyLib
+FILE_GUID = 2655FA94-4559-F393-B0B1-85A8E79C1532
+VERSION_STRING = 1.0
+MODULE_TYPE = PEIM
+LIBRARY_CLASS = PeiMePolicyLib
+
+
+[LibraryClasses]
+DebugLib
+IoLib
+PeiServicesLib
+BaseMemoryLib
+MemoryAllocationLib
+ConfigBlockLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+PeiMePolicyLib.c
+PeiMePolicyLibrary.h
+
+
+[Ppis]
+gSiPolicyPpiGuid   ## PRODUCES
+gSiPreMemPolicyPpiGuid ## PRODUCES
+
+
+[Guids]
+gMePeiPreMemConfigGuid
+gMePeiConfigGuid
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLibrary.h
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLibrary.h
new file mode 100644
index 00..3ac6a639e9
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLibrary.h
@@ -0,0 +1,25 @@
+/** @file
+  Header file for the PeiMePolicy library.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _PEI_ME_POLICY_LIBRARY_H_
+#define _PEI_ME_POLICY_LIBRARY_H_
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#endif // _PEI_ME_POLICY_LIBRARY_H_
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.c 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.c
new file mode 100644
index 00..6f3d70b841
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Library/PeiMePolicyLib/PeiMePolicyLib.c
@@ -0,0 +1,251 @@
+/** @file
+  This file is PeiMePolicy library.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "PeiMePolicyLibrary.h"
+
+/**
+  Load default settings for ME config block in pre-mem phase.
+
+  @param[in] ConfigBlockPointer The pointer to the config block
+**/
+VOID
+LoadMePeiPreMemDefault (
+  IN VOID   *ConfigBlockPointer
+  );
+
+/**
+  Load default settings for ME config block in PEI phase.
+
+  @param[in] ConfigBlockPointer The pointer to the config block
+**/
+VOID
+LoadMePeiDefault (
+  IN VOID   *ConfigBlockPointer
+  );
+
+STATIC COMPONENT_BLOCK_ENTRY  mMeCompontBlockPreMemBlocks [] = {
+  {&gMePeiPreMemConfigGuid, sizeof (ME_PEI_PREMEM_CONFIG),  
ME_PEI_PREMEM_CONFIG_REVISION,  LoadMePeiPreMemDefault}
+};
+
+STATIC COMPONENT_BLOCK_ENTRY  mMeCompontBlockBlocks [] = {
+  {&gMePeiConfigGuid,   sizeof (ME_PEI_CONFIG), 
ME_PEI_CONFIG_REVISION, LoadMePeiDefault}
+};
+
+/**
+  Load default settings for ME config block in pre-mem phase.
+
+  @param[in] ConfigBlockPointer The pointer to the config block
+**/
+VOID
+LoadMePeiPreMemDefault (
+  IN VOID   *ConfigBlockPointer
+  )
+{
+  ME_PEI_PREMEM_CONFIG *MePeiPreMemConfig;
+  MePeiPreMemConfig = ConfigBlockPointer;
+
+  MePeiPreMemConfig->HeciTimeouts  = 1;
+
+  MePeiPreMemConfig->Heci1BarAddress   = 0xFED1A000;
+  MePeiPreMemConfig->Heci2BarAddress   = 0xFED1B000;
+  MePeiPreMemConfig->Heci3BarAddress   = 0xFED1C000;
+
+  //
+  // Test policies
+  //
+  MePeiPreMemConfig->SendDidMsg= 1;
+
+  MePeiPreMemConfig->KtDeviceEnable= 1;
+}
+
+/**
+  Load default settings for ME config block in PEI phase.
+
+  @param[in] ConfigBlockPointer The pointer to the config block
+**/
+VOID
+LoadMePeiDefault (
+  IN VOID   *ConfigBlockPointer
+  )
+{
+  ME_PEI_CONFIG *MePeiConfig;
+  MePeiConfig = ConfigBlockPointer;
+
+  MePeiConfig->End

[edk2-devel] [edk2-platforms][PATCH V1 03/37] CoffeelakeSiliconPkg/Me: Add Include headers

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds header files common to ME modules.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/ConfigBlock/MePeiConfig.h | 124 
++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/Library/DxeMePolicyLib.h  |  59 
+++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/Library/PeiMePolicyLib.h  |  87 
++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/MeChipset.h   | 172 

 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/MePolicyHob.h |  17 
++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/MkhiMsgs.h|  19 
+++
 Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/Protocol/MePolicy.h   |  41 
+
 7 files changed, 519 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/ConfigBlock/MePeiConfig.h 
b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/ConfigBlock/MePeiConfig.h
new file mode 100644
index 00..102fb43bd1
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Me/Include/ConfigBlock/MePeiConfig.h
@@ -0,0 +1,124 @@
+/** @file
+  ME config block for PEI phase
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _ME_PEI_CONFIG_H_
+#define _ME_PEI_CONFIG_H_
+
+#include 
+
+#define ME_PEI_PREMEM_CONFIG_REVISION 2
+extern EFI_GUID gMePeiPreMemConfigGuid;
+
+#ifndef PLATFORM_POR
+#define PLATFORM_POR  0
+#endif
+#ifndef FORCE_ENABLE
+#define FORCE_ENABLE  1
+#endif
+#ifndef FORCE_DISABLE
+#define FORCE_DISABLE 2
+#endif
+
+#pragma pack (push,1)
+
+/**
+  ME Pei Pre-Memory Configuration Structure.
+
+  Revision 1:
+  - Initial version.
+  Revision 2:
+  - Change DidInitStat bit width.
+**/
+typedef struct {
+  CONFIG_BLOCK_HEADER   Header; ///< Config Block Header
+  UINT32 HeciTimeouts : 1;  ///< 0: Disable; 1: 
Enable - HECI Send/Receive Timeouts.
+  /**
+(Test)
+0: Disabled
+   1: ME DID init stat 0 - Success
+   2: ME DID init stat 1 - No Memory in Channels
+   3: ME DID init stat 2 - Memory Init Error
+  **/
+  UINT32 DidInitStat  : 2;
+  /**
+(Test)
+0: Set to 0 to enable polling for CPU replacement
+   1: Set to 1 will disable polling for CPU replacement
+  **/
+  UINT32 DisableCpuReplacedPolling: 1;
+  UINT32 SendDidMsg   : 1;  ///< (Test) 0: Disable; 
1: Enable - Enable/Disable to send DID message.
+  /**
+(Test)
+0: Set to 0 to enable retry mechanism for HECI APIs
+   1: Set to 1 will disable retry mechanism for HECI APIs
+  **/
+  UINT32 DisableHeciRetry : 1;
+  /**
+(Test)
+0: ME BIOS will check each messages before sending
+   1: ME BIOS always sends messages without checking
+  **/
+  UINT32 DisableMessageCheck  : 1;
+  /**
+(Test)
+The SkipMbpHob policy determines whether ME BIOS Payload data will be 
requested during boot
+in a MBP message. If set to 1, BIOS will send the MBP message with SkipMbp 
flag
+set causing CSME to respond with MKHI header only and no MBP data
+0: ME BIOS will keep MBP and create HOB for MBP data
+   1: ME BIOS will skip MBP data
+  **/
+  UINT32 SkipMbpHob   : 1;
+  UINT32 HeciCommunication2   : 1;  ///< (Test) 0: 
Disable; 1: Enable - Enable/Disable HECI2.
+  UINT32 KtDeviceEnable   : 1;  ///< (Test) 0: Disable; 
1: Enable - Enable/Disable Kt Device.
+  UINT32 RsvdBits : 22; ///< Reserved for future use & 
Config block alignment
+  UINT32 Heci1BarAddress;   ///< HECI1 BAR address.
+  UINT32 Heci2BarAddress;   ///< HECI2 BAR address.
+  UINT32 Heci3BarAddress;   ///< HECI3 BAR address.
+} ME_PEI_PREMEM_CONFIG;
+#pragma pack (pop)
+
+
+#define ME_PEI_CONFIG_REVISION 2
+extern EFI_GUID gMePeiConfigGuid;
+
+#pragma pack (push,1)
+
+/**
+  ME Pei Post-Memory Configuration Structure.
+
+  Revision 1:
+  - Initial version.
+  Revision 2:
+  - Add MctpBroadcastCycle test setting.
+**/
+typedef struct {
+  CONFIG_BLOCK_HEADER   Header; ///< Config Block Header
+
+  UINT32 EndOfPostMessage : 2;  ///< 0: Disabled; 1: Send in 
PEI; 2: Send in DXE - Send EOP at specific phase.
+  /**
+HECI3 state from Mbp for reference in S3 path only
+0: Disabled; 1: Enabled
+  **/
+  UINT32 Heci3Enabled : 1;
+  UINT32 DisableD0I3SettingForHeci: 1;  ///< (Test) 0: 
Disable; 1: Enable - Enable/Disable D0i3 for HECI.
+  /**
+Enable/Disable Me Unconfig On Rtc Clear. If enabled, BIOS will send 
MeUnconfigOnRtcClearDisable Msg with parameter 0.
+It will cause ME to unconfig if RTC is cleared.
+-0: Disable
+- 1: Enable
+-2

[edk2-devel] [edk2-platforms][PATCH V1 29/37] CoffeelakeSiliconPkg: Add package DSC files

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 Silicon/Intel/CoffeelakeSiliconPkg/CoffeelakeSiliconPkg.dsc | 215 

 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgBuildOption.dsc | 130 
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgCommonLib.dsc   |  69 +++
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgDxe.dsc |  33 +++
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgDxeLib.dsc  |  37 
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgPei.dsc |  21 ++
 Silicon/Intel/CoffeelakeSiliconPkg/SiPkgPeiLib.dsc  |  44 
 7 files changed, 549 insertions(+)

diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/CoffeelakeSiliconPkg.dsc 
b/Silicon/Intel/CoffeelakeSiliconPkg/CoffeelakeSiliconPkg.dsc
new file mode 100644
index 00..37c77d8f63
--- /dev/null
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/CoffeelakeSiliconPkg.dsc
@@ -0,0 +1,215 @@
+## @file
+#  Component description file for the Coffee Lake silicon package DSC file.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[PcdsFeatureFlag]
+gSiPkgTokenSpaceGuid.PcdTraceHubEnable   |FALSE
+gSiPkgTokenSpaceGuid.PcdSmmVariableEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdAtaEnable|FALSE
+gSiPkgTokenSpaceGuid.PcdSiCsmEnable  |FALSE
+gSiPkgTokenSpaceGuid.PcdUseHpetTimer |TRUE
+gSiPkgTokenSpaceGuid.PcdSgEnable |TRUE
+gSiPkgTokenSpaceGuid.PcdAcpiEnable   |FALSE
+gSiPkgTokenSpaceGuid.PcdSourceDebugEnable|FALSE
+gSiPkgTokenSpaceGuid.PcdPpmEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdIntegratedTouchEnable|FALSE
+gSiPkgTokenSpaceGuid.PcdPttEnable|FALSE
+gSiPkgTokenSpaceGuid.PcdJhiEnable|FALSE
+gSiPkgTokenSpaceGuid.PcdSmbiosEnable |TRUE
+gSiPkgTokenSpaceGuid.PcdS3Enable |TRUE
+gSiPkgTokenSpaceGuid.PcdOverclockEnable  |FALSE
+gSiPkgTokenSpaceGuid.PcdCpuPowerOnConfigEnable   |FALSE
+gSiPkgTokenSpaceGuid.PcdBdatEnable   |TRUE
+gSiPkgTokenSpaceGuid.PcdIgdEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdPegEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdSaDmiEnable  |TRUE
+gSiPkgTokenSpaceGuid.PcdIpuEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdGnaEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdSaOcEnable   |TRUE
+gSiPkgTokenSpaceGuid.PcdVtdEnable|TRUE
+gSiPkgTokenSpaceGuid.PcdOptimizeCompilerEnable   |TRUE
+gSiPkgTokenSpaceGuid.PcdPeiDisplayEnable |TRUE
+gSiPkgTokenSpaceGuid.PcdCflCpuEnable |FALSE
+gSiPkgTokenSpaceGuid.PcdOcWdtEnable  |TRUE
+gSiPkgTokenSpaceGuid.PcdSerialIoUartEnable   |TRUE
+gSiPkgTokenSpaceGuid.PcdSiCatalogDebugEnable |FALSE
+
+[PcdsFixedAtBuild.common]
+gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress   |0xE000
+gSiPkgTokenSpaceGuid.PcdTemporaryPciExpressRegionLength |0x1000
+
+  gSiPkgTokenSpaceGuid.PcdSiliconInitTempPciBusMin|10
+  gSiPkgTokenSpaceGuid.PcdSiliconInitTempPciBusMax|18
+
+[PcdsDynamicDefault.common]
+gSiPkgTokenSpaceGuid.PcdPciExpressRegionLength  |0x1000
+
+## Specifies the AP wait loop state during POST phase.
+#  The value is defined as below.
+#  1: Place AP in the Hlt-Loop state.
+#  2: Place AP in the Mwait-Loop state.
+#  3: Place AP in the Run-Loop state.
+# @Prompt The AP wait loop state.
+gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode|2
+## Specifies the AP target C-state for Mwait during POST phase.
+#  The default value 0 means C1 state.
+#  The value is defined as below.
+# @Prompt The specified AP target C-state for Mwait.
+gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0
+
+[Defines]
+  PLATFORM_NAME = CoffeelakeSiliconPkg
+  PLATFORM_GUID = A45CA44C-AB04-4932-A77C-5A7179F66A22
+  PLATFORM_VERSION = 0.4
+  DSC_SPECIFICATION = 0x00010005
+  OUTPUT_DIRECTORY = Build/CoffeelakeSiliconPkg
+  SUPPORTED_ARCHITECTURES = IA32|X64
+  BUILD_TARGETS = DEBUG|RELEASE
+  SKUID_IDENTIFIER = DEFAULT
+
+  DEFINE   PLATFORM_SI_PACKAGE= CoffeelakeSiliconPkg
+
+  #
+  # Definition for Build Flag
+  #
+  !include $(PLATFORM_SI_PACKAGE)/SiPkgBuildOption.dsc
+
+[LibraryClasses.common]
+  #
+  # Entry point
+  #
+  PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
+  PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
+  DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
+  
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+  
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+  
PeCoffExtraActionLib|MdeP

[edk2-devel] [edk2-platforms][PATCH V1 18/37] CoffeelakeSiliconPkg/Pch: Add DXE library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds PCH DXE library class instances.

* DxePchPolicyLib
* DxeResetSystemLib
* DxeRuntimeResetSystemLib

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.inf
   |  41 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeResetSystemLib/DxeResetSystemLib.inf
   |  49 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeRuntimeResetSystemLib/DxeRuntimeResetSystemLib.inf
 |  52 
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.c
 | 218 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeResetSystemLib/DxeResetSystemLib.c
 | 310 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeRuntimeResetSystemLib/DxeRuntimeResetSystemLib.c
   | 323 
 6 files changed, 993 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.inf
new file mode 100644
index 00..8845ab796c
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.inf
@@ -0,0 +1,41 @@
+## @file
+# Component description file for the PeiPchPolicy library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxePchPolicyLib
+FILE_GUID = E2179D04-7026-48A5-9475-309CEA2F21A3
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = DxePchPolicyLib
+
+
+[LibraryClasses]
+BaseMemoryLib
+UefiBootServicesTableLib
+DebugLib
+ConfigBlockLib
+SiConfigBlockLib
+PchInfoLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+DxePchPolicyLib.c
+
+
+[Guids]
+gHdAudioDxeConfigGuid
+gGpioDxeConfigGuid
+
+[Protocols]
+gPchPolicyProtocolGuid ## PRODUCES
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeResetSystemLib/DxeResetSystemLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeResetSystemLib/DxeResetSystemLib.inf
new file mode 100644
index 00..0bb2d6e247
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeResetSystemLib/DxeResetSystemLib.inf
@@ -0,0 +1,49 @@
+## @file
+# Component description file for Intel Ich7 Reset System Library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxeResetSystemLib
+FILE_GUID = 239383BC-499E-4DC5-8CDC-F85AF27B1BC4
+VERSION_STRING = 1.0
+MODULE_TYPE = DXE_DRIVER
+UEFI_SPECIFICATION_VERSION = 2.00
+LIBRARY_CLASS = ResetSystemLib
+CONSTRUCTOR = DxeResetSystemLibConstructor
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF
+#
+
+[LibraryClasses]
+IoLib
+BaseLib
+DebugLib
+TimerLib
+BaseMemoryLib
+UefiBootServicesTableLib
+PmcLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+DxeResetSystemLib.c
+
+
+[Protocols]
+gPchResetCallbackProtocolGuid ## CONSUMES
+
+
+[Guids]
+gPchGlobalResetGuid
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeRuntimeResetSystemLib/DxeRuntimeResetSystemLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeRuntimeResetSystemLib/DxeRuntimeResetSystemLib.inf
new file mode 100644
index 00..a1777293ab
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxeRuntimeResetSystemLib/DxeRuntimeResetSystemLib.inf
@@ -0,0 +1,52 @@
+## @file
+# Component description file for Intel Ich7 Reset System Library.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxeRuntimeResetSystemLib
+FILE_GUID = 1026813A-E46F-43D1-B709-FF1F996F2E72
+VERSION_STRING = 1.0
+MODULE_TYPE = DXE_RUNTIME_DRIVER
+UEFI_SPECIFICATION_VERSION = 2.00
+LIBRARY_CLASS = ResetSystemLib
+CONSTRUCTOR = DxeRuntimeResetSystemLibConstructor
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF
+#
+
+[LibraryClasses]
+IoLib
+BaseLib
+DebugLib
+TimerLib
+BaseMemoryLib
+UefiRuntimeLib
+DxeServicesTableLib
+UefiBootServicesTableLib
+PmcLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+DxeRuntimeResetSystemLib.c
+
+
+[Protocols]
+gPchResetCallbackProtocolGuid ## CONSUMES
+
+
+[Guids]
+gPchGlobalResetGuid
+gEfiEventVirtualAddressChangeGuid
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/DxePchPolicyLib/DxePchPolicyLib.c
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/D

[edk2-devel] [edk2-platforms][PATCH V1 24/37] CoffeelakeSiliconPkg/Pch: Add SMM private library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds PCH SMM private library class instances.

* SmmPchPrivateLib

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.inf
 | 32 +++
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.c
   | 58 
 2 files changed, 90 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.inf
new file mode 100644
index 00..5cbad21fa5
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.inf
@@ -0,0 +1,32 @@
+## @file
+#  PCH SMM private lib.
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = SmmPchPrivateLib
+FILE_GUID = FE6495FB-7AA9-4A24-BF3E-4698F7BCE0EE
+VERSION_STRING = 1.0
+MODULE_TYPE = DXE_SMM_DRIVER
+LIBRARY_CLASS = SmmPchPrivateLib
+
+
+[LibraryClasses]
+BaseLib
+IoLib
+DebugLib
+CpuPlatformLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Sources]
+SmmPchPrivateLib.c
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.c
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.c
new file mode 100644
index 00..85a3086874
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/SmmPchPrivateLib/SmmPchPrivateLib.c
@@ -0,0 +1,58 @@
+/** @file
+  PCH SMM private lib.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  Set InSmm.Sts bit
+**/
+VOID
+PchSetInSmmSts (
+  VOID
+  )
+{
+  UINT32  Data32;
+
+  ///
+  /// Read memory location FED30880h OR with 0001h, place the result in 
EAX,
+  /// and write data to lower 32 bits of MSR 1FEh (sample code available)
+  ///
+  Data32 = MmioRead32 (0xFED30880);
+  AsmWriteMsr32 (MSR_SPCL_CHIPSET_USAGE_ADDR, Data32 | BIT0);
+  ///
+  /// Read FED30880h back to ensure the setting went through.
+  ///
+  Data32 = MmioRead32 (0xFED30880);
+}
+
+/**
+  Clear InSmm.Sts bit
+**/
+VOID
+PchClearInSmmSts (
+  VOID
+  )
+{
+  UINT32  Data32;
+
+  ///
+  /// Read memory location FED30880h AND with FFFEh, place the result in 
EAX,
+  /// and write data to lower 32 bits of MSR 1FEh (sample code available)
+  ///
+  Data32 = MmioRead32 (0xFED30880);
+  AsmWriteMsr32 (MSR_SPCL_CHIPSET_USAGE_ADDR, Data32 & (UINT32) (~BIT0));
+  ///
+  /// Read FED30880h back to ensure the setting went through.
+  ///
+  Data32 = MmioRead32 (0xFED30880);
+}
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#45901): https://edk2.groups.io/g/devel/message/45901
Mute This Topic: https://groups.io/mt/32918194/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH V1 22/37] CoffeelakeSiliconPkg/Pch: Add DXE private library instances

[Kubacki, Michael A]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2082

Adds PCH DXE private library class instances.

* DxeGpioNameBufferLib
* DxePchHdaLib

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Ankit Sinha 
Signed-off-by: Michael Kubacki 
---
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/DxeGpioNameBufferLib.inf
 |  32 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/DxePchHdaLib.inf
 |  43 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/GpioNameBufferDxe.c
  |  20 +
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaEndpoints.c
| 333 
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaLib.c 
 | 886 
 
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaNhltConfig.c
   | 439 ++
 6 files changed, 1753 insertions(+)

diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/DxeGpioNameBufferLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/DxeGpioNameBufferLib.inf
new file mode 100644
index 00..0dc8f9749d
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/DxeGpioNameBufferLib.inf
@@ -0,0 +1,32 @@
+## @file
+# Component description file for the DxeGpioMemLib
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxeGpioNameBufferLib
+FILE_GUID = 16EC6AA8-81D5-4847-B6CB-662CDAB863F2
+VERSION_STRING = 1.0
+MODULE_TYPE = DXE_DRIVER
+LIBRARY_CLASS = GpioNameBufferLib
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+# VALID_ARCHITECTURES = IA32 X64 IPF EBC
+#
+
+[LibraryClasses]
+BaseLib
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+[Sources]
+GpioNameBufferDxe.c
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/DxePchHdaLib.inf
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/DxePchHdaLib.inf
new file mode 100644
index 00..a8a3f60b53
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/DxePchHdaLib.inf
@@ -0,0 +1,43 @@
+## @file
+# Component information file for PCH HD Audio Library
+#
+# Copyright (c) 2019 Intel Corporation. All rights reserved. 
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME = DxePchHdaLib
+FILE_GUID = DA915B7F-EE08-4C1D-B3D0-DE7C52AB155A
+VERSION_STRING = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS = PchHdaLib
+
+
+[LibraryClasses]
+BaseLib
+DebugLib
+MemoryAllocationLib
+BaseMemoryLib
+PchInfoLib
+
+
+[Packages]
+MdePkg/MdePkg.dec
+CoffeelakeSiliconPkg/SiPkg.dec
+
+
+[Pcd]
+  gSiPkgTokenSpaceGuid.PcdAcpiDefaultOemId
+  gSiPkgTokenSpaceGuid.PcdAcpiDefaultOemTableId
+  gSiPkgTokenSpaceGuid.PcdAcpiDefaultOemRevision
+  gSiPkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
+  gSiPkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision
+
+
+[Sources]
+PchHdaLib.c
+PchHdaEndpoints.c
+PchHdaNhltConfig.c
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/GpioNameBufferDxe.c
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/GpioNameBufferDxe.c
new file mode 100644
index 00..af53387faf
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxeGpioNameBufferLib/GpioNameBufferDxe.c
@@ -0,0 +1,20 @@
+/** @file
+  This file contains implementation of the GpioMemLib for DXE phase
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+STATIC CHAR8 mGpioNameBuffer[GPIO_NAME_LENGTH_MAX];
+
+CHAR8*
+GpioGetStaticNameBuffer (
+  VOID
+  )
+{
+  return mGpioNameBuffer;
+}
+
diff --git 
a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaEndpoints.c
 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaEndpoints.c
new file mode 100644
index 00..ea04512501
--- /dev/null
+++ 
b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/DxePchHdaLib/PchHdaEndpoints.c
@@ -0,0 +1,333 @@
+/** @file
+  This file contains HD Audio NHLT Endpoints definitions
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+CONST WAVEFORMATEXTENSIBLE Ch1_48kHz16bitFormat =
+{
+  {
+WAVE_FORMAT_EXTENSIBLE,
+1,
+48000,
+96000,
+2,
+16,
+sizeof (WAVEFORMATEXTENSIBLE) - sizeof (WAVEFORMATEX)
+  },
+  {16},
+  KSAUDIO_SPEAKER_MONO,
+  KSDATAFORMAT_SUBTYPE_PCM
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+CONST WAVEFORMATEXTENSIBLE Ch2_48