date:20180125

Re: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module

2018-01-25 Thread Ni, Ruiyu

Mike,
Should all code use BSD licenses?

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Friday, January 26, 2018 7:08 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Dong, Eric ; Yao,
> Jiewen ; Kinney, Michael D
> ; Zeng, Star 
> Subject: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe
> module
> 
> From: Michael D Kinney 
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=802
> 
> Based on content from the following branch/commits:
> https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
> 
> The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that
> produces ESRT entries based only on FMP Protocol instances.
> 
> Cc: Sean Brogan 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Michael D Kinney 
> ---
>  MdeModulePkg/MdeModulePkg.dsc  |   1 +
>  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484
> +
>  .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c   | 161 +++
>  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf   |  68 +++
>  4 files changed, 714 insertions(+)
>  create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
>  create mode 100644
> MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c
>  create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5988..c7dd76b774 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -417,6 +417,7 @@
> 
>MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
>MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
> +  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
> 
> 
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxe.inf
>MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf  { diff --git
> a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> new file mode 100644
> index 00..9fb281c666
> --- /dev/null
> +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> @@ -0,0 +1,484 @@
> +/** @file
> +  Publishes ESRT table from Firmware Management Protocol instances
> +
> +  Copyright (c) 2016, Microsoft Corporation  Copyright (c) 2018, Intel
> + Corporation. All rights reserved.
> +
> +  All rights reserved.
> +  Redistribution and use in source and binary forms, with or without
> + modification, are permitted provided that the following conditions are met:
> +  1. Redistributions of source code must retain the above copyright
> + notice,  this list of conditions and the following disclaimer.
> +  2. Redistributions in binary form must reproduce the above copyright
> + notice,  this list of conditions and the following disclaimer in the
> + documentation  and/or other materials provided with the distribution.
> +
> +  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + "AS IS" AND  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + LIMITED TO, THE IMPLIED  WARRANTIES OF MERCHANTABILITY AND FITNESS
> FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> +  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
> FOR
> + ANY DIRECT,  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + CONSEQUENTIAL DAMAGES (INCLUDING,  BUT NOT LIMITED TO,
> PROCUREMENT OF
> + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,  DATA, OR PROFITS; OR
> + BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> LIABILITY,
> + WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE
> + OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
> EVEN IF  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include  #include
> +
> +#include 
> +#include 
> +#include 
> +#include  #include 
> +#include 
> +
> +/*
> +  Print ESRT to debug console
> +*/
> +VOID
> +EFIAPI
> +PrintTable (
> +  IN EFI_SYSTEM_RESOURCE_TABLE  *Table
> +  );
> +
> +//
> +// Number of ESRT entries to grow by each time we run out of room //
> +#define GROWTH_STEP  10
> +
> +//
> +// Module globals.
> +//
> +EFI_EVENT  mEsrtReadyToBootEvent;
> +EFI_SYSTEM_RESOURCE_TABLE  *mTable = NULL;
> +BOOLEANmEsrtInstalled = FALSE;
> +EFI_EVENT  mFmpInstallEvent;
> +VOID   *mFmpInstallEventRegistration = NULL;
> +
> +/**
> +  Install EFI System Resource Table into the UEFI Configuration Table
> +
> +  @return  Status code.
> +
> +**/
> +EFI_STATUS
>

Re: [edk2] [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase

2018-01-25 Thread Gao, Liming

Laszlo:
  Here is PERF macro PERF_START_EX(Handle, Token, Module, TimeStamp, 
Identifier). 

  Handle is the image handle or device handle. PerfLib can base on Handle to 
get its FILE guid. 
  Token is the measured token name. 
  Module is the measured module name. PERF_START macro is added before 
gEfiCallerBaseName is supported. Some old PERF_START uses Token only. This 
patch just copies one and add it. So, it doesn't use gEfiCallerBaseName. I 
agree to use gEfiCallerBaseName better.
  TimeStamp is current tick. 
  Identifier will be mapped into progressId in edk2 extended FPDT record from 
new performance 
https://lists.01.org/pipermail/edk2-devel/2018-January/020345.html. New 
performance will save each PERF into one record. It means START PERF entry is 
one record, END PERF entry is another record. When DP or OS tool parses record, 
they need to know the record is Start or End. Then, the different ProgressId 
will be used for Start and End. 

Thanks
Liming
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Thursday, January 25, 2018 8:44 PM
>To: Bi, Dandan ; edk2-devel@lists.01.org
>Cc: Dong, Eric ; Gao, Liming 
>Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase
>
>On 01/25/18 05:56, Bi, Dandan wrote:
>> Hi Laszlo,
>>
>> Thank you for your comments.
>>
>> Yes. The PERF_INMODULE_START_ID macro is from
>"ExtendedFirmwarePerformance.h" which is added in the new performance
>infrastructure patches([ mail subject: patch 0/8] Update EDKII Performance
>infrastructure based on ACPI FPDT table). That is the dependency I mean.
>>
>> I will send V2 of this patch and the patch which remove Pref code after "new
>performance infrastructure" patches have been committed . Then I will refine
>the commit message of these two patches, add commit  hash value of "new
>performance infrastructure" patches if I need to reference it.
>
>Thank you.
>
>I had some other questions lower down, about the PERF_START_EX()
>arguments. Can you please help me understand those better?
>
>Thanks!
>Laszlo
>
>>
>> Thanks,
>> Dandan
>>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, January 24, 2018 11:45 PM
>> To: Bi, Dandan ; edk2-devel@lists.01.org
>> Cc: Dong, Eric ; Gao, Liming 
>> Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3
>phase
>>
>> On 01/24/18 08:59, Dandan Bi wrote:
>>> Add more perf entry to hook BootScriptDonePpi/EndOfPeiPpi/
>>> EndOfS3Resume.
>>>
>>> Notes: This patch depends on the new performance infrastructure.
>>
>> Since this statement is going into the commit log, please be more specific
>about the "new performance infrastructure" (TianoCore BZ or commit hashes
>etc).
>>
>> Also, how is the dependency established? For example, OVMF uses
>BasePerformanceLibNull; so I think it will see no changes.
>>
>> Do you mean the PERF_INMODULE_START_ID macro, from
>"ExtendedFirmwarePerformance.h"? Ah, that's not committed yet. In this
>case, please add a reference to the mailing list message (subject and archive
>URL) that adds it.
>>
>> (Actually, the best solution is to reference the TianoCore BZ, and then add
>the mailing list URL for each patch set submission to the TianoCore BZ.)
>>
>>>
>>> Cc: Eric Dong 
>>> Cc: Laszlo Ersek 
>>> Cc: Liming Gao 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Dandan Bi 
>>> ---
>>>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 15
>>> ++-
>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> index b597ac7..d7d2a4d 100644
>>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>>> @@ -2,11 +2,11 @@
>>>This module produces the EFI_PEI_S3_RESUME2_PPI.
>>>This module works with StandAloneBootScriptExecutor to S3 resume to
>OS.
>>>This module will execute the boot script saved during last boot and after
>that,
>>>control is passed to OS waking up handler.
>>>
>>> -  Copyright (c) 2006 - 2017, Intel Corporation. All rights
>>> reserved.
>>> +  Copyright (c) 2006 - 2018, Intel Corporation. All rights
>>> + reserved.
>>>Copyright (c) 2017, AMD Incorporated. All rights reserved.
>>>
>>>This program and the accompanying materials
>>>are licensed and made available under the terms and conditions
>>>of the BSD License which accompanies this distribution.  The @@
>>> -21,10 +21,11 @@  #include 
>>>
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -551,13 +552,17 @@ S3ResumeBootOs (
>>>PERF_END (NULL,

Re: [edk2] [PATCH v2] PcAtChipsetPkg: Add PeiAcpiTimerLib to save PerformanceCounterFrequency in HOB

2018-01-25 Thread Zeng, Star

Hi Liming,

Reviewed-by: Star Zeng 

Two minor comments. Just for your information.
1. Notice the title, it may be too long.
2. In PeiAcpiTimerLib.c, you may need to add ASSERT 
(PerformanceCounterFrequency != NULL) after BuildGuidHob.
And you can move " PerformanceCounterFrequency = (UINT64*)GET_GUID_HOB_DATA 
(GuidHob); " to the else condition, then only one "return" is needed.

+  PerformanceCounterFrequency = NULL;
+  GuidHob = GetFirstGuidHob ();
+  if (GuidHob == NULL) {
+PerformanceCounterFrequency  = (UINT64*)BuildGuidHob(, 
sizeof (*PerformanceCounterFrequency));
+*PerformanceCounterFrequency = InternalCalculateTscFrequency ();
+return *PerformanceCounterFrequency;
+  }
+  PerformanceCounterFrequency = (UINT64*)GET_GUID_HOB_DATA (GuidHob);
+
+  return  *PerformanceCounterFrequency;
+}


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, January 23, 2018 10:24 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [edk2] [PATCH v2] PcAtChipsetPkg: Add PeiAcpiTimerLib to save 
PerformanceCounterFrequency in HOB

In V2:
1) Update PeiAcpiTimerLib base name to PeiAcpiTimerLib
2) Update PeiAcpiTimerLib to add the missing constructor to enable ACPI IO space
3) Update DxeAcpiTimerLib to cache frequency in constructor.

PeiAcpiTimerLib caches PerformanceCounterFrequency in HOB, then Pei and Dxe
AcpiTimerLib can share the same PerformanceCounterFrequency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Star Zeng 
---
 PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c |  4 +-
 .../Library/AcpiTimerLib/DxeAcpiTimerLib.c | 57 +-
 .../Library/AcpiTimerLib/DxeAcpiTimerLib.inf   |  7 ++-
 .../Library/AcpiTimerLib/PeiAcpiTimerLib.c | 68 ++
 .../Library/AcpiTimerLib/PeiAcpiTimerLib.inf   | 56 ++
 .../Library/AcpiTimerLib/PeiAcpiTimerLib.uni   | 23 
 PcAtChipsetPkg/PcAtChipsetPkg.dsc  |  4 +-
 7 files changed, 211 insertions(+), 8 deletions(-)
 create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.c
 create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf
 create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.uni

diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
index 792781a33f..2f3cb4bca4 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI Timer implements one instance of Timer Library.
 
-  Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+GUID mFrequencyHobGuid = { 0x3fca54f6, 0xe1a2, 0x4b20, { 0xbe, 0x76, 0x92, 
0x6b, 0x4b, 0x48, 0xbf, 0xaa }};
+
 /**
   Internal function to retrieves the 64-bit frequency in Hz.
 
diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c 
b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c
index b141c680fb..67e18a1360 100644
--- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c
+++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c
@@ -12,9 +12,27 @@
 
 **/
 
-#include 
+#include 
 #include 
 #include 
+#include 
+
+extern GUID mFrequencyHobGuid;
+
+/**
+  The constructor function enables ACPI IO space.
+
+  If ACPI I/O space not enabled, this function will enable it.
+  It will always return RETURN_SUCCESS.
+
+  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+
+**/
+RETURN_STATUS
+EFIAPI
+AcpiTimerLibConstructor (
+  VOID
+  );
 
 /**
   Calculate TSC frequency.
@@ -54,8 +72,41 @@ InternalGetPerformanceCounterFrequency (
   VOID
   ) 
 {
-  if (mPerformanceCounterFrequency == 0) {
+  return  mPerformanceCounterFrequency;
+}
+
+/**
+  The constructor function enables ACPI IO space, and caches 
PerformanceCounterFrequency. 
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns RETURN_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+DxeAcpiTimerLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_HOB_GUID_TYPE   *GuidHob;
+
+  //
+  // Enable ACPI IO space.
+  //
+  AcpiTimerLibConstructor ();
+
+  //
+  // Initialize PerformanceCounterFrequency
+  //
+  GuidHob = GetFirstGuidHob ();
+  if (GuidHob != NULL) {
+mPerformanceCounterFrequency =

Re: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module

2018-01-25 Thread Zeng, Star

Hi Mike,

Some MINOR comments at my first sight.

1. Should *.uni and *Extra.uni be added for this module?
2. Could EfiCreateEventReadyToBootEx() be used instead of below code? Then 
gEfiEventReadyToBootGuid reference in *.inf could be also removed.

+  Status = gBS->CreateEventEx (
+  EVT_NOTIFY_SIGNAL,
+  TPL_CALLBACK,
+  EsrtReadyToBootEventNotify,
+  NULL,
+  ,
+  
+  );

3. Is it better to have the MODULE_TYPE to be DXE_DRIVER?

+  MODULE_TYPE= UEFI_DRIVER


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Friday, January 26, 2018 7:08 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Dong, Eric ; Yao, 
Jiewen ; Kinney, Michael D ; 
Zeng, Star 
Subject: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that 
produces ESRT entries based only on FMP Protocol instances.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 +
 .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c   | 161 +++
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf   |  68 +++
 4 files changed, 714 insertions(+)
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index dd7e9d5988..c7dd76b774 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -417,6 +417,7 @@
 
   MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
   MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
   
   
MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf
   MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf  { diff --git 
a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c 
b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
new file mode 100644
index 00..9fb281c666
--- /dev/null
+++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
@@ -0,0 +1,484 @@
+/** @file
+  Publishes ESRT table from Firmware Management Protocol instances
+
+  Copyright (c) 2016, Microsoft Corporation  Copyright (c) 2018, Intel 
+ Corporation. All rights reserved.
+
+  All rights reserved.
+  Redistribution and use in source and binary forms, with or without  
+ modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright 
+ notice,  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright 
+ notice,  this list of conditions and the following disclaimer in the 
+ documentation  and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
+ "AS IS" AND  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
+ LIMITED TO, THE IMPLIED  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
PARTICULAR PURPOSE ARE DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR 
+ ANY DIRECT,  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
+ CONSEQUENTIAL DAMAGES (INCLUDING,  BUT NOT LIMITED TO, PROCUREMENT OF 
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,  DATA, OR PROFITS; OR 
+ BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF  LIABILITY, 
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE  
+ OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF  
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include 
+#include 
+#include 
+#include  #include 
+
+#include 
+#include 
+#include 
+#include  #include  
+#include 
+
+/*
+  Print ESRT to debug console
+*/
+VOID
+EFIAPI
+PrintTable (
+  IN EFI_SYSTEM_RESOURCE_TABLE  *Table
+  );
+
+//
+// Number of ESRT entries to grow by each time we run out of room // 
+#define GROWTH_STEP  10
+
+//
+// Module globals.
+//
+EFI_EVENT  mEsrtReadyToBootEvent;
+EFI_SYSTEM_RESOURCE_TABLE  *mTable = NULL;
+BOOLEAN

Re: [edk2] [PATCH] IntelSiliconPkg MicrocodeUpdateDxe: TotalSize must be multiples of 1KB

2018-01-25 Thread Yao, Jiewen

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Friday, January 26, 2018 11:50 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ;
> Chaganty, Rangasai V 
> Subject: [PATCH] IntelSiliconPkg MicrocodeUpdateDxe: TotalSize must be
> multiples of 1KB
> 
> TotalSize must be multiples of 1024 bytes (1 KBytes) according to SDM.
> 
> Also enhance the debug message for DataSize that must be
> multiples of DWORDs.
> 
> Cc: Jiewen Yao 
> Cc: Rangasai V Chaganty 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c  | 19
> +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git
> a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> index 11a51106fdd2..46b55088285f 100644
> --- a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> +++
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> @@ -8,7 +8,7 @@
> 
>MicrocodeWrite() and VerifyMicrocode() will receive untrusted input and do
> basic validation.
> 
> -  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -421,7 +421,7 @@ VerifyMicrocode (
>  return EFI_INCOMPATIBLE_VERSION;
>}
>//
> -  // Check Size
> +  // Check TotalSize
>//
>if (MicrocodeEntryPoint->DataSize == 0) {
>  TotalSize = 2048;
> @@ -436,6 +436,14 @@ VerifyMicrocode (
>  }
>  return EFI_VOLUME_CORRUPTED;
>}
> +  if ((TotalSize & (SIZE_1KB - 1)) != 0) {
> +DEBUG((DEBUG_ERROR, "VerifyMicrocode - TotalSize is not multiples of
> 1024 bytes (1 KBytes)\n"));
> +*LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT;
> +if (AbortReason != NULL) {
> +  *AbortReason = AllocateCopyPool(sizeof(L"InvalidTotalSize"),
> L"InvalidTotalSize");
> +}
> +return EFI_VOLUME_CORRUPTED;
> +  }
>if (TotalSize != ImageSize) {
>  DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on TotalSize\n"));
>  *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT;
> @@ -445,7 +453,7 @@ VerifyMicrocode (
>  return EFI_VOLUME_CORRUPTED;
>}
>//
> -  // Check CheckSum32
> +  // Check DataSize
>//
>if (MicrocodeEntryPoint->DataSize == 0) {
>  DataSize = 2048 - sizeof(CPU_MICROCODE_HEADER);
> @@ -461,13 +469,16 @@ VerifyMicrocode (
>  return EFI_VOLUME_CORRUPTED;
>}
>if ((DataSize & 0x3) != 0) {
> -DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize not aligned\n"));
> +DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize is not multiples of
> DWORDs\n"));
>  *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT;
>  if (AbortReason != NULL) {
>*AbortReason = AllocateCopyPool(sizeof(L"InvalidDataSize"),
> L"InvalidDataSize");
>  }
>  return EFI_VOLUME_CORRUPTED;
>}
> +  //
> +  // Check CheckSum32
> +  //
>CheckSum32 = CalculateSum32((UINT32 *)MicrocodeEntryPoint, DataSize +
> sizeof(CPU_MICROCODE_HEADER));
>if (CheckSum32 != 0) {
>  DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on CheckSum32\n"));
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 2/3] QuarkPlatformPkg: Switch from EsrtDxe to EsrtFmpDxe

2018-01-25 Thread Kinney, Michael D

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

The EsrtFmpDxe module is a lightweight version of the EsrtDxe
module that produces ESRT entries based only on FMP Protocol
instances.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 QuarkPlatformPkg/Quark.dsc | 4 ++--
 QuarkPlatformPkg/Quark.fdf | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc
index 5624451e12..2176c8c9db 100644
--- a/QuarkPlatformPkg/Quark.dsc
+++ b/QuarkPlatformPkg/Quark.dsc
@@ -2,7 +2,7 @@
 # Clanton Peak CRB platform with 32-bit DXE for 4MB/8MB flash devices.
 #
 # This package provides Clanton Peak CRB platform specific modules.
-# Copyright (c) 2013 - 2017 Intel Corporation.
+# Copyright (c) 2013 - 2018 Intel Corporation.
 #
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
@@ -921,7 +921,7 @@
   }
 
 !if $(CAPSULE_ENABLE)
-  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
 
   SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf {
 
diff --git a/QuarkPlatformPkg/Quark.fdf b/QuarkPlatformPkg/Quark.fdf
index ab0f84b860..609f6e9b35 100644
--- a/QuarkPlatformPkg/Quark.fdf
+++ b/QuarkPlatformPkg/Quark.fdf
@@ -2,7 +2,7 @@
 # FDF file of Clanton Peak CRB platform with 32-bit DXE
 #
 # This package provides QuarkNcSocId platform specific modules.
-# Copyright (c) 2013 - 2017 Intel Corporation.
+# Copyright (c) 2013 - 2018 Intel Corporation.
 #
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
@@ -598,7 +598,7 @@ INF  RuleOverride = DRIVER_ACPITABLE 
SecurityPkg/Tcg/TcgSmm/TcgSmm.inf
 !endif
 
 !if $(CAPSULE_ENABLE)
-INF  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+INF  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
 INF  
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
 !endif
 
-- 
2.14.2.windows.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module

2018-01-25 Thread Kinney, Michael D

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

The EsrtFmpDxe module is a lightweight version of the EsrtDxe
module that produces ESRT entries based only on FMP Protocol
instances.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 +
 .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c   | 161 +++
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf   |  68 +++
 4 files changed, 714 insertions(+)
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index dd7e9d5988..c7dd76b774 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -417,6 +417,7 @@
 
   MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
   MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
   
   
MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf
   MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf  {
diff --git a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c 
b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
new file mode 100644
index 00..9fb281c666
--- /dev/null
+++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
@@ -0,0 +1,484 @@
+/** @file
+  Publishes ESRT table from Firmware Management Protocol instances
+
+  Copyright (c) 2016, Microsoft Corporation
+  Copyright (c) 2018, Intel Corporation. All rights reserved.
+
+  All rights reserved.
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  1. Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  2. Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND
+  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED.
+  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT,
+  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING,
+  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY 
OF
+  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE
+  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+  Print ESRT to debug console
+*/
+VOID
+EFIAPI
+PrintTable (
+  IN EFI_SYSTEM_RESOURCE_TABLE  *Table
+  );
+
+//
+// Number of ESRT entries to grow by each time we run out of room
+//
+#define GROWTH_STEP  10
+
+//
+// Module globals.
+//
+EFI_EVENT  mEsrtReadyToBootEvent;
+EFI_SYSTEM_RESOURCE_TABLE  *mTable = NULL;
+BOOLEANmEsrtInstalled = FALSE;
+EFI_EVENT  mFmpInstallEvent;
+VOID   *mFmpInstallEventRegistration = NULL;
+
+/**
+  Install EFI System Resource Table into the UEFI Configuration Table
+
+  @return  Status code.
+
+**/
+EFI_STATUS
+InstallEfiSystemResourceTableInUefiConfigurationTable (
+   VOID
+  )
+{
+  EFI_STATUS Status;
+
+  Status = EFI_SUCCESS;
+  if (!mEsrtInstalled) {
+if (mTable == NULL) {
+  DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table because it is 
NULL. \n"));
+  Status = EFI_OUT_OF_RESOURCES;
+} else if (mTable->FwResourceCount == 0) {
+  DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table because it 
has zero Entries. \n"));
+  Status = EFI_UNSUPPORTED;
+} else {
+  //
+  // Install the pointer into config table
+  //
+  Status = gBS->InstallConfigurationTable (, 
mTable);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table.  Status: 
%r. \n", Status));
+  } else {

[edk2] [Patch 3/3] Vlv2TbltDevicePkg: Switch from EsrtDxe to EsrtFmpDxe

2018-01-25 Thread Kinney, Michael D

From: Michael D Kinney 

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

The EsrtFmpDxe module is a lightweight version of the EsrtDxe
module that produces ESRT entries based only on FMP Protocol
instances.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 Vlv2TbltDevicePkg/PlatformPkg.fdf   | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 4 ++--
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf 
b/Vlv2TbltDevicePkg/PlatformPkg.fdf
index 5ed85f4dee..148553828c 100644
--- a/Vlv2TbltDevicePkg/PlatformPkg.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf
@@ -1,7 +1,7 @@
 #/** @file
 # FDF file of Platform.
 #
-# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -773,7 +773,7 @@ FILE FREEFORM = 878AC2CC-5343-46F2-B563-51F89DAF56BA {
 !endif
 
 !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE)
-INF  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+INF  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
 !endif
 !if $(CAPSULE_ENABLE)
 INF  
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf 
b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
index a02a4f6286..d208871ae6 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
+++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf
@@ -1,7 +1,7 @@
 #/** @file
 # FDF file of Platform.
 #
-# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
+# Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -730,7 +730,7 @@ FILE FREEFORM = 878AC2CC-5343-46F2-B563-51F89DAF56BA {
 !endif
 
 !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE)
-INF  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+INF  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
 !endif
 !if $(CAPSULE_ENABLE)
 INF  
SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index f98263d8a5..7a431130a3 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -1,7 +1,7 @@
 #/** @file
 # Platform description.
 #
-# Copyright (c) 2012  - 2017, Intel Corporation. All rights reserved.
+# Copyright (c) 2012  - 2018, Intel Corporation. All rights reserved.
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -1567,7 +1567,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf
 
 !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE)
-  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
   MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf
 !endif
 
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index c755df2fe2..d27fc49df7 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1,7 +1,7 @@
 #/** @file
 # Platform description.
 #
-# Copyright (c) 2012  - 2017, Intel Corporation. All rights reserved.
+# Copyright (c) 2012  - 2018, Intel Corporation. All rights reserved.
 #
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -1555,7 +1555,7 @@ 
$(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf
   Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf
 
 !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE)
-  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
+  MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
   MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf
 !endif
 
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index dda8216e6a..ca68928b23 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@

[edk2] [Patch 0/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module

2018-01-25 Thread Kinney, Michael D

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

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport

The EsrtFmpDxe module is a lightweight version of the EsrtDxe
module that produces ESRT entries based only on FMP Protocol
instances.

Update Quark and Vlv2 platforms to use EsrtFmpDxe.

Cc: Sean Brogan 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 

Michael D Kinney (3):
  MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module
  QuarkPlatformPkg: Switch from EsrtDxe to EsrtFmpDxe
  Vlv2TbltDevicePkg: Switch from EsrtDxe to EsrtFmpDxe

 MdeModulePkg/MdeModulePkg.dsc  |   1 +
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 +
 .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c   | 161 +++
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf   |  68 +++
 QuarkPlatformPkg/Quark.dsc |   4 +-
 QuarkPlatformPkg/Quark.fdf |   4 +-
 Vlv2TbltDevicePkg/PlatformPkg.fdf  |   4 +-
 Vlv2TbltDevicePkg/PlatformPkgGcc.fdf   |   4 +-
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|   4 +-
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc  |   4 +-
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc   |   4 +-
 11 files changed, 728 insertions(+), 14 deletions(-)
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c
 create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf

-- 
2.14.2.windows.3

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.

2018-01-25 Thread Supreeth Venkatesh

Marvin/Tim,

Thanks.
Apologies, if I didn't mention that this patch was just addition of new values
EFI_FV_FILETYPE_MM_STANDALONE
EFI_FV_FILETYPE_MM_CORE_STANDALONE
and
EFI_SECTION_MM_DEPEX

No other changes.
In existing code, EFI_FV_FILETYPE_SMM  and EFI_FV_FILETYPE_MM are same already.

Supreeth
-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Thursday, January 25, 2018 12:32 PM
To: edk2-devel@lists.01.org; tim.le...@insyde.com; Supreeth Venkatesh 

Cc: michael.d.kin...@intel.com; liming@intel.com
Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file 
type and depex.

Hey Tim and Supreeth,

Sorry, 0x0C was a typo, 0x0D is the correct one.
The values of the SMM and MM constants are identical, this is just a naming 
update plus the introduction of the new value, MM Standalone Core, so 
backwards-compatibility is given.
Regarding the traditional MM Core, I just assumed it was an oversight as MdePkg 
is generic. If it wasn't, sorry.

Thanks,
Marvin

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Thursday, January 25, 2018 6:53 PM
> To: 'Supreeth Venkatesh' ; 'Marvin H?user'
> ; edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV file type and depex.
>
> Supreeth --
>
> Doesn't Appendix A of the PI 1.6 define this as:
>
> #define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM #define
> EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE
>
> Thanks,
>
> Tim
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Thursday, January 25, 2018 9:45 AM
> To: Marvin H?user ; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV file type and depex.
>
> Marvin,
>
> Thanks for your comments.
> As per PI v1.6 specification,
> EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM
> Traditional Mode.)
>
> This is traditional MM mode, which ARM is not supporting at this
> point. We are more interested in MM_CORE_STANDALONE mode.
> However, I have no issues in adding this in the patch, but would
> prefer if this is added when MM traditional mode is supported in ARM.
>
> Further,
> w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't
> want to break backwards compatibility with existing SMM traditional
> mode implementations.
> I will be happy to let folks who have migrated to _MM_ definitions
> from _SMM_ definitions to send the patch across.
>
> Thanks,
> Supreeth
>
> -Original Message-
> From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
> Sent: Tuesday, January 23, 2018 6:34 PM
> To: edk2-devel@lists.01.org
> Cc: Supreeth Venkatesh ;
> michael.d.kin...@intel.com; liming@intel.com
> Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV file type and depex.
>
> Good day,
>
> I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE"
> (0x0C).
> Furthermore, may I suggest changing the *_SMM_* definitions to be
> defined via the *_MM_* definitions?
>
> Best regards,
> Marvin.
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > Of Supreeth Venkatesh
> > Sent: Tuesday, January 23, 2018 9:03 PM
> > To: edk2-devel@lists.01.org
> > Cc: michael.d.kin...@intel.com; liming@intel.com
> > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV
> > file type and depex.
> >
> > As per PI specification v1.6,
> > The following new file types are added:
> > EFI_FV_FILETYPE_MM_STANDALONE
> > EFI_FV_FILETYPE_MM_CORE_STANDALONE
> >
> > The following new section type is added:
> > EFI_SECTION_MM_DEPEX
> >
> > This patch adds the management mode FV file type and depex.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
> > Reviewed-by: Jiewen Yao 
> > ---
> >  MdePkg/Include/Pi/PiFirmwareFile.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
> > b/MdePkg/Include/Pi/PiFirmwareFile.h
> > index b982c9eda3..6086d1bb2f 100644
> > --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE;  #define
> > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER  0x08
> >  #define EFI_FV_FILETYPE_APPLICATION   0x09
> >  #define EFI_FV_FILETYPE_SMM   0x0A
> > +#define EFI_FV_FILETYPE_MM0x0A
> >  #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
> >  #define

Re: [edk2] DMA Buffer write operation not persisted

2018-01-25 Thread Paulo Alcantara



On January 25, 2018 4:53:06 PM GMT-02:00, Rafael Machado 
 wrote:
>Hi everyone.
>
>I'm currently work on a task, and I need to write some data at a DMA
>buffer.
>At the UEFI Driver Writer's guide, at page 359 there is a sample code
>of
>how to do that.
>
>Considering that code and adapting to my scenario I got the following
>function (some debug prints are present for clarification):
>
>EFI_STATUS
>EFIAPI
>DoBusMasterWrite (
>  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
>  IN UINT8 *HostAddress,
>  IN UINTN *Length,
>  IN UINT32 Value
>)
>{
>  EFI_STATUS Status;
>  UINTN NumberOfBytes;
>  EFI_PHYSICAL_ADDRESS DeviceAddress;
>  VOID *Mapping;
>  UINT64 ReadValue;
>
>  //
>  // Call Map() to retrieve the DeviceAddress to use for the bus
>  // master write operation. The Map() function may not support
>  // performing a DMA operation for the entire length, so it may
>  // be broken up into smaller DMA operations.
>  //
>  NumberOfBytes = *Length;
>  Status = PciIo->Map (PciIo, // This
>
> EfiPciIoOperationBusMasterCommonBuffer, // Operation
>(VOID *)HostAddress, // HostAddress
> , // NumberOfBytes
> , //DeviceAddress
>  //Mapping);
>
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>
>  //
>  // Write the data to the desired address
>  // This write operation also starts the DMA transaction
>  //
>  Status = PciIo->Mem.Write (PciIo, // This
>  EfiPciIoWidthUint32, // Width
>   *HostAddress,
>   1, // Count
>// Buffer
>   );

I'm not sure, but I think you're passing the wrong value to the 3rd parameter 
(Address). Shouldn't that be "(UINT64)(UINTN)HostAddress"?

Paulo

>
>  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
>  Print(L"address: 0x%x\r\n", HostAddress);
>  Print(L"Value: 0x%x\r\n", Value);
>  Print(L"Status: %r\r\n", Status);
>
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>
>  //
>  // The operations performed by PollMem() also flush all posted
>  // writes from the PCI bus master and through PCI-to-PCI bridges.
>  //
>  Status = PciIo->PollMem (PciIo, // This
>  EfiPciIoWidthUint32, // Width
>   *HostAddress, // Offset
>   0x,// Mask
>   Value,// Value
>   EFI_TIMER_PERIOD_SECONDS
>(1), // Timeout
>// Result
>   );
>  Print(L"Status2: %r\r\n", Status);
>
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>
>  //
>  // Call Flush() to flush all write transactions to system memory
>  //
>  Status = PciIo->Flush (PciIo);
>  Print(L"Status3: %r\r\n", Status);
>
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>
>  //
>  // Call Unmap() to complete the bus master write operation
>  //
>  Status = PciIo->Unmap (PciIo, Mapping);
>  Print(L"Status4: %r\r\n", Status);
>
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
>  return Status;
>}
>
>The output of this function is this:
>  NumberOfBytes: 4
>  address: 0xCCCAC000
>  Value: 0xA
>  Status: Success
>  Status2: Success
>  Status3: Success
>  Status4: Success
>
>The problem is that when I try to read this memory content using the
>dmem
>command at the efiShell the value 0xA cannot be found. Seems
>something
>is locking the DMA trasaction.
>Can someone give me some light?
>
>Thanks and Regard
>Rafael R. Machado
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SecurityPkg/DxePhysicalPresenceLib: Reject illegal PCR bank allocation

2018-01-25 Thread Bill Paul

Of all the gin joints in all the towns in all the world, Zhang, Chao B had to 
walk into mine at 20:53 on Wednesday 24 January 2018 and say:

> According to TCG PP1.3 spec, error PCR bank allocation input should be
> rejected by Physical Presence. Firmware has to ensure that at least one
> PCR banks is active.
> 
> Cc: Long Qin 
> Cc: Yao Jiewen 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> ---
>  .../DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c  | 12
>  1 file changed, 12 insertions(+)
> 
> diff --git
> a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi
> b.c
> b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi
> b.c index 5bf95a1..830266b 100644
> ---
> a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi
> b.c +++
> b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi
> b.c @@ -186,6 +186,18 @@ Tcg2ExecutePhysicalPresence (
>  case TCG2_PHYSICAL_PRESENCE_SET_PCR_BANKS:
>Status = Tpm2GetCapabilitySupportedAndActivePcrs
> (, ); ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // PP spec requirements:
> +  //Firmware should check that all requested (set) hashing
> algorithms are supported with respective PCR banks. +  //Firmware
> has to ensure that at least one PCR banks is active +  // If not, an
> error is returned and no action is taken
> +  //
> +  if (CommandParameter == 0 || (CommandParameter &
> (~TpmHashAlgorithmBitmap)) != 0) { +DEBUG((DEBUG_ERROR, "PCR banks
> %x to allocate are not supported by TPM. Skip operation\n",
> CommandParameter)); +return TCG_PP_OPERATION_RESPONSE_BIOS_FAILURE
> +  }
> +  DEBUG((DEBUG_ERROR, "zhangchao TpmHashAlgorithmBitmap %x

Was it your intention to have the debug error message string identify you by 
name? :)

-Bill

> CommandParameter %x\n", TpmHashAlgorithmBitmap, CommandParameter)); Status
> = Tpm2PcrAllocateBanks (PlatformAuth, TpmHashAlgorithmBitmap,
> CommandParameter); if (EFI_ERROR (Status)) {
>  return TCG_PP_OPERATION_RESPONSE_BIOS_FAILURE;
-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] DMA Buffer write operation not persisted

2018-01-25 Thread Rafael Machado

Hi Andrew

Thanks for the answer.

The allocation was done at other part of the code. But yet, I used the
PciI->AllocateBuffer() function.

One question, about the topics retrieved from the spec.
When the spec says "• The common buffer can now be accessed equally by the
processor and the DMA bus master."

Does this means that I can write some data using a simple pointer, like for
example copying some data using MemCopy? Or should I still use the
PciIo->Mem.Write...?

I'll really this part of the spec carefully.

Thanks and Regards
Rafael R. Machado

Em qui, 25 de jan de 2018 às 17:04, Andrew Fish  escreveu:

> Rafeal,
>
> There are some good summaries in the UEFI Spec that really help.
>
> DMA Bus Master Common Buffer Operation
> • Call AllocateBuffer() to allocate a common buffer.
> • Call Map() for EfiPciOperationBusMasterCommonBuffer or
> EfiPciOperationBusMasterCommonBuffer64.
> • Program the DMA Bus Master with the DeviceAddress returned by Map().
> • The common buffer can now be accessed equally by the processor and the
> DMA bus master.
> • Call Unmap().
> • Call FreeBuffer().
>
> Did you miss the PciIo->AllocateBuffer() call?
>
> For x86 it can abstract things like DMA only supported < 4GB.
> For ARM it may need to change the cacheability of the region etc.
>
> Thanks,
>
> Andrew Fish
>
> > On Jan 25, 2018, at 10:53 AM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
> >
> > Hi everyone.
> >
> > I'm currently work on a task, and I need to write some data at a DMA
> buffer.
> > At the UEFI Driver Writer's guide, at page 359 there is a sample code of
> > how to do that.
> >
> > Considering that code and adapting to my scenario I got the following
> > function (some debug prints are present for clarification):
> >
> > EFI_STATUS
> > EFIAPI
> > DoBusMasterWrite (
> >  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
> >  IN UINT8 *HostAddress,
> >  IN UINTN *Length,
> >  IN UINT32 Value
> > )
> > {
> >  EFI_STATUS Status;
> >  UINTN NumberOfBytes;
> >  EFI_PHYSICAL_ADDRESS DeviceAddress;
> >  VOID *Mapping;
> >  UINT64 ReadValue;
> >
> >  //
> >  // Call Map() to retrieve the DeviceAddress to use for the bus
> >  // master write operation. The Map() function may not support
> >  // performing a DMA operation for the entire length, so it may
> >  // be broken up into smaller DMA operations.
> >  //
> >  NumberOfBytes = *Length;
> >  Status = PciIo->Map (PciIo, // This
> >
> > EfiPciIoOperationBusMasterCommonBuffer, // Operation
> > (VOID *)HostAddress, // HostAddress
> > , // NumberOfBytes
> > , //DeviceAddress
> >  //Mapping);
> >
> >  if (EFI_ERROR (Status)) {
> >return Status;
> >  }
> >
> >  //
> >  // Write the data to the desired address
> >  // This write operation also starts the DMA transaction
> >  //
> >  Status = PciIo->Mem.Write (PciIo, // This
> >   EfiPciIoWidthUint32, //
> Width
> >   *HostAddress,
> >   1, // Count
> >// Buffer
> >   );
> >
> >  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
> >  Print(L"address: 0x%x\r\n", HostAddress);
> >  Print(L"Value: 0x%x\r\n", Value);
> >  Print(L"Status: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
> > return Status;
> >  }
> >
> >  //
> >  // The operations performed by PollMem() also flush all posted
> >  // writes from the PCI bus master and through PCI-to-PCI bridges.
> >  //
> >  Status = PciIo->PollMem (PciIo, // This
> >   EfiPciIoWidthUint32, //
> Width
> >   *HostAddress, // Offset
> >   0x,// Mask
> >   Value,// Value
> >   EFI_TIMER_PERIOD_SECONDS
> > (1), // Timeout
> >// Result
> >   );
> >  Print(L"Status2: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
> > return Status;
> >  }
> >
> >  //
> >  // Call Flush() to flush all write transactions to system memory
> >  //
> >  Status = PciIo->Flush (PciIo);
> >  Print(L"Status3: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
> > return Status;
> >  }
> >
> >  //
> >  // Call Unmap() to complete the bus master write operation
> >  //
> >  Status = PciIo->Unmap (PciIo, Mapping);
> >  Print(L"Status4: %r\r\n", Status);
> >
> >  if (EFI_ERROR (Status)) {
> > return Status;
> >  }
> >  return Status;
> > }
> >
> > The output of this function is this:
> >  NumberOfBytes: 4
> >  address: 0xCCCAC000
> >  Value: 0xA
> >  Status: Success
> >  Status2: Success
> >

Re: [edk2] DMA Buffer write operation not persisted

2018-01-25 Thread Andrew Fish

Rafeal,

There are some good summaries in the UEFI Spec that really help. 

DMA Bus Master Common Buffer Operation
• Call AllocateBuffer() to allocate a common buffer.
• Call Map() for EfiPciOperationBusMasterCommonBuffer or 
EfiPciOperationBusMasterCommonBuffer64.
• Program the DMA Bus Master with the DeviceAddress returned by Map().
• The common buffer can now be accessed equally by the processor and the DMA 
bus master.
• Call Unmap().
• Call FreeBuffer().

Did you miss the PciIo->AllocateBuffer() call?

For x86 it can abstract things like DMA only supported < 4GB. 
For ARM it may need to change the cacheability of the region etc. 

Thanks,

Andrew Fish

> On Jan 25, 2018, at 10:53 AM, Rafael Machado 
>  wrote:
> 
> Hi everyone.
> 
> I'm currently work on a task, and I need to write some data at a DMA buffer.
> At the UEFI Driver Writer's guide, at page 359 there is a sample code of
> how to do that.
> 
> Considering that code and adapting to my scenario I got the following
> function (some debug prints are present for clarification):
> 
> EFI_STATUS
> EFIAPI
> DoBusMasterWrite (
>  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
>  IN UINT8 *HostAddress,
>  IN UINTN *Length,
>  IN UINT32 Value
> )
> {
>  EFI_STATUS Status;
>  UINTN NumberOfBytes;
>  EFI_PHYSICAL_ADDRESS DeviceAddress;
>  VOID *Mapping;
>  UINT64 ReadValue;
> 
>  //
>  // Call Map() to retrieve the DeviceAddress to use for the bus
>  // master write operation. The Map() function may not support
>  // performing a DMA operation for the entire length, so it may
>  // be broken up into smaller DMA operations.
>  //
>  NumberOfBytes = *Length;
>  Status = PciIo->Map (PciIo, // This
> 
> EfiPciIoOperationBusMasterCommonBuffer, // Operation
> (VOID *)HostAddress, // HostAddress
> , // NumberOfBytes
> , //DeviceAddress
>  //Mapping);
> 
>  if (EFI_ERROR (Status)) {
>return Status;
>  }
> 
>  //
>  // Write the data to the desired address
>  // This write operation also starts the DMA transaction
>  //
>  Status = PciIo->Mem.Write (PciIo, // This
>   EfiPciIoWidthUint32, // Width
>   *HostAddress,
>   1, // Count
>// Buffer
>   );
> 
>  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
>  Print(L"address: 0x%x\r\n", HostAddress);
>  Print(L"Value: 0x%x\r\n", Value);
>  Print(L"Status: %r\r\n", Status);
> 
>  if (EFI_ERROR (Status)) {
> return Status;
>  }
> 
>  //
>  // The operations performed by PollMem() also flush all posted
>  // writes from the PCI bus master and through PCI-to-PCI bridges.
>  //
>  Status = PciIo->PollMem (PciIo, // This
>   EfiPciIoWidthUint32, // Width
>   *HostAddress, // Offset
>   0x,// Mask
>   Value,// Value
>   EFI_TIMER_PERIOD_SECONDS
> (1), // Timeout
>// Result
>   );
>  Print(L"Status2: %r\r\n", Status);
> 
>  if (EFI_ERROR (Status)) {
> return Status;
>  }
> 
>  //
>  // Call Flush() to flush all write transactions to system memory
>  //
>  Status = PciIo->Flush (PciIo);
>  Print(L"Status3: %r\r\n", Status);
> 
>  if (EFI_ERROR (Status)) {
> return Status;
>  }
> 
>  //
>  // Call Unmap() to complete the bus master write operation
>  //
>  Status = PciIo->Unmap (PciIo, Mapping);
>  Print(L"Status4: %r\r\n", Status);
> 
>  if (EFI_ERROR (Status)) {
> return Status;
>  }
>  return Status;
> }
> 
> The output of this function is this:
>  NumberOfBytes: 4
>  address: 0xCCCAC000
>  Value: 0xA
>  Status: Success
>  Status2: Success
>  Status3: Success
>  Status4: Success
> 
> The problem is that when I try to read this memory content using the dmem
> command at the efiShell the value 0xA cannot be found. Seems something
> is locking the DMA trasaction.
> Can someone give me some light?
> 
> Thanks and Regard
> Rafael R. Machado
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] DMA Buffer write operation not persisted

2018-01-25 Thread Rafael Machado

Hi everyone.

I'm currently work on a task, and I need to write some data at a DMA buffer.
At the UEFI Driver Writer's guide, at page 359 there is a sample code of
how to do that.

Considering that code and adapting to my scenario I got the following
function (some debug prints are present for clarification):

EFI_STATUS
EFIAPI
DoBusMasterWrite (
  IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo,
  IN UINT8 *HostAddress,
  IN UINTN *Length,
  IN UINT32 Value
)
{
  EFI_STATUS Status;
  UINTN NumberOfBytes;
  EFI_PHYSICAL_ADDRESS DeviceAddress;
  VOID *Mapping;
  UINT64 ReadValue;

  //
  // Call Map() to retrieve the DeviceAddress to use for the bus
  // master write operation. The Map() function may not support
  // performing a DMA operation for the entire length, so it may
  // be broken up into smaller DMA operations.
  //
  NumberOfBytes = *Length;
  Status = PciIo->Map (PciIo, // This

 EfiPciIoOperationBusMasterCommonBuffer, // Operation
 (VOID *)HostAddress, // HostAddress
 , // NumberOfBytes
 , //DeviceAddress
  //Mapping);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Write the data to the desired address
  // This write operation also starts the DMA transaction
  //
  Status = PciIo->Mem.Write (PciIo, // This
   EfiPciIoWidthUint32, // Width
   *HostAddress,
   1, // Count
// Buffer
   );

  Print(L"NumberOfBytes: %d\r\n", NumberOfBytes);
  Print(L"address: 0x%x\r\n", HostAddress);
  Print(L"Value: 0x%x\r\n", Value);
  Print(L"Status: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // The operations performed by PollMem() also flush all posted
  // writes from the PCI bus master and through PCI-to-PCI bridges.
  //
  Status = PciIo->PollMem (PciIo, // This
   EfiPciIoWidthUint32, // Width
   *HostAddress, // Offset
   0x,// Mask
   Value,// Value
   EFI_TIMER_PERIOD_SECONDS
(1), // Timeout
// Result
   );
  Print(L"Status2: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Call Flush() to flush all write transactions to system memory
  //
  Status = PciIo->Flush (PciIo);
  Print(L"Status3: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }

  //
  // Call Unmap() to complete the bus master write operation
  //
  Status = PciIo->Unmap (PciIo, Mapping);
  Print(L"Status4: %r\r\n", Status);

  if (EFI_ERROR (Status)) {
return Status;
  }
  return Status;
}

The output of this function is this:
  NumberOfBytes: 4
  address: 0xCCCAC000
  Value: 0xA
  Status: Success
  Status2: Success
  Status3: Success
  Status4: Success

The problem is that when I try to read this memory content using the dmem
command at the efiShell the value 0xA cannot be found. Seems something
is locking the DMA trasaction.
Can someone give me some light?

Thanks and Regard
Rafael R. Machado
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 0/8] Socionext SynQuacer updates

2018-01-25 Thread Ard Biesheuvel

On 25 January 2018 at 12:27, Ard Biesheuvel  wrote:
> Some stuff I have collected over the past 2 months or so. Note that this
> includes the SATA spread spectrum patch I sent out yesterday: I had forgotten
> all about this backlog, and I only remembered when attempting to apply it to
> the master branch.
>
> Ard Biesheuvel (8):
>   Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061
> SATA
>   Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid
>   Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol
>   Silicon/SynQuacerI2cDxe: remove spurious format specifier
>   Silicon/SynQuacer: load I2C driver before platform DXE driver
>   Silicon/SynQuacer/DeviceTree: align uart DT nodes
>   Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding
>   Silicon/Socionext/SynQuacer: implement menu option to set max PCIe
> speed
>

All pushed. Thanks.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v3] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 05:13:17PM +, Ard Biesheuvel wrote:
> Add menu options to the SynQuacer Platform menu screen to limit the
> maximum PCIe link speed for each slot individually. This may be useful
> to work around potential PCIe issues.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v3:
> deobfuscate the slot speed limit check, using a switch rather than a
> convoluted if(), and a comment that describes what goes on

Thanks for this.
Reviewed-by: Leif Lindholm 

> v2:
> Make the speed limit per-slot instead of per-RC. That does make this
> implementation more specific to DeveloperBox than it was before, but
> given the special knowledge about the on-board ASM1184e switch and the
> need for enabling spread-spectrum on the ASM1061, we're already past the
> point where PlatformDxe is a generic SynQuacer driver, and we may need to
> move it into Platform/Socionext (and clone it for each platform) in the
> future.
> 
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> |   2 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> |   2 +
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> |  35 ++-
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> | 107 
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h
> |  13 +++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf  
> |  11 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni   
> |  29 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr   
> |  69 +
>  Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h  
> |  23 +
>  Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h  
> |   5 +
>  Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h  
> |  29 ++
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
>   |   2 +
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>  |  40 +++-
>  Silicon/Socionext/SynQuacer/SynQuacer.dec
> |   5 +
>  14 files changed, 365 insertions(+), 7 deletions(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index 86685d1dec3b..2d46b4515749 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
>  [PcdsDynamicHii]
>
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
>  
> +  
> gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
> +
>  [PcdsDynamicDefault]
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index b4b9239143bc..263b6454ff72 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
>  [PcdsDynamicHii]
>
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
>  
> +  
> gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
> +
>  [PcdsDynamicDefault]
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> index 9af3dd942cdd..7c69a8051a56 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort (
>EFI_STATUSStatus;
>PCIE_CAP  Cap;
>PCI_REG_PCIE_LINK_CONTROL LinkControl;
> +  UINTN SegmentNumber;
> +  UINTN BusNumber;
> +  UINTN DeviceNumber;
> +  UINTN FunctionNumber;
> +  UINT8 MaxSpeed;
>  
>//
>

Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.

2018-01-25 Thread Marvin H?user

Hey Tim and Supreeth,

Sorry, 0x0C was a typo, 0x0D is the correct one.
The values of the SMM and MM constants are identical, this is just a naming 
update plus the introduction of the new value, MM Standalone Core, so 
backwards-compatibility is given.
Regarding the traditional MM Core, I just assumed it was an oversight as MdePkg 
is generic. If it wasn't, sorry.

Thanks,
Marvin

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Thursday, January 25, 2018 6:53 PM
> To: 'Supreeth Venkatesh' ; 'Marvin H?user'
> ; edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV file type and depex.
> 
> Supreeth --
> 
> Doesn't Appendix A of the PI 1.6 define this as:
> 
> #define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM #define
> EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE
> 
> Thanks,
> 
> Tim
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Thursday, January 25, 2018 9:45 AM
> To: Marvin H?user ; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management
> mode FV file type and depex.
> 
> Marvin,
> 
> Thanks for your comments.
> As per PI v1.6 specification,
> EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support
> MM Traditional Mode.)
> 
> This is traditional MM mode, which ARM is not supporting at this point. We
> are more interested in MM_CORE_STANDALONE mode.
> However, I have no issues in adding this in the patch, but would prefer if 
> this
> is added when MM traditional mode is supported in ARM.
> 
> Further,
> w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't
> want to break backwards compatibility with existing SMM traditional mode
> implementations.
> I will be happy to let folks who have migrated to _MM_ definitions from
> _SMM_ definitions to send the patch across.
> 
> Thanks,
> Supreeth
> 
> -Original Message-
> From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
> Sent: Tuesday, January 23, 2018 6:34 PM
> To: edk2-devel@lists.01.org
> Cc: Supreeth Venkatesh ;
> michael.d.kin...@intel.com; liming@intel.com
> Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV file type and depex.
> 
> Good day,
> 
> I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE"
> (0x0C).
> Furthermore, may I suggest changing the *_SMM_* definitions to be
> defined via the *_MM_* definitions?
> 
> Best regards,
> Marvin.
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Supreeth Venkatesh
> > Sent: Tuesday, January 23, 2018 9:03 PM
> > To: edk2-devel@lists.01.org
> > Cc: michael.d.kin...@intel.com; liming@intel.com
> > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode
> FV
> > file type and depex.
> >
> > As per PI specification v1.6,
> > The following new file types are added:
> > EFI_FV_FILETYPE_MM_STANDALONE
> > EFI_FV_FILETYPE_MM_CORE_STANDALONE
> >
> > The following new section type is added:
> > EFI_SECTION_MM_DEPEX
> >
> > This patch adds the management mode FV file type and depex.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
> > Reviewed-by: Jiewen Yao 
> > ---
> >  MdePkg/Include/Pi/PiFirmwareFile.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
> > b/MdePkg/Include/Pi/PiFirmwareFile.h
> > index b982c9eda3..6086d1bb2f 100644
> > --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE;  #define
> > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER  0x08
> >  #define EFI_FV_FILETYPE_APPLICATION   0x09
> >  #define EFI_FV_FILETYPE_SMM   0x0A
> > +#define EFI_FV_FILETYPE_MM0x0A
> >  #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
> >  #define EFI_FV_FILETYPE_COMBINED_SMM_DXE  0x0C
> > +#define EFI_FV_FILETYPE_COMBINED_MM_DXE   0x0C
> >  #define EFI_FV_FILETYPE_SMM_CORE  0x0D
> > +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E
> >  #define EFI_FV_FILETYPE_OEM_MIN   0xc0
> >  #define EFI_FV_FILETYPE_OEM_MAX   0xdf
> >  #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
> > @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE;
> >  #define EFI_SECTION_RAW   0x19
> >  #define EFI_SECTION_PEI_DEPEX 0x1B
> >  #define EFI_SECTION_SMM_DEPEX 0x1C
> > +#define EFI_SECTION_MM_DEPEX  0x1C
> >
> >  ///
> >  /// Common

Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.

2018-01-25 Thread Tim Lewis

Supreeth --

Doesn't Appendix A of the PI 1.6 define this as:

#define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM
#define EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE

Thanks,

Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Supreeth Venkatesh
Sent: Thursday, January 25, 2018 9:45 AM
To: Marvin H?user ; edk2-devel@lists.01.org
Cc: michael.d.kin...@intel.com; liming@intel.com
Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV
file type and depex.

Marvin,

Thanks for your comments.
As per PI v1.6 specification,
EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM
Traditional Mode.)

This is traditional MM mode, which ARM is not supporting at this point. We
are more interested in MM_CORE_STANDALONE mode.
However, I have no issues in adding this in the patch, but would prefer if
this is added when MM traditional mode is supported in ARM.

Further,
w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't want
to break backwards compatibility with existing SMM traditional mode
implementations.
I will be happy to let folks who have migrated to _MM_ definitions from
_SMM_ definitions to send the patch across.

Thanks,
Supreeth

-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Tuesday, January 23, 2018 6:34 PM
To: edk2-devel@lists.01.org
Cc: Supreeth Venkatesh ;
michael.d.kin...@intel.com; liming@intel.com
Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV
file type and depex.

Good day,

I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE"
(0x0C).
Furthermore, may I suggest changing the *_SMM_* definitions to be defined
via the *_MM_* definitions?

Best regards,
Marvin.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Supreeth Venkatesh
> Sent: Tuesday, January 23, 2018 9:03 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV 
> file type and depex.
>
> As per PI specification v1.6,
> The following new file types are added:
> EFI_FV_FILETYPE_MM_STANDALONE
> EFI_FV_FILETYPE_MM_CORE_STANDALONE
>
> The following new section type is added:
> EFI_SECTION_MM_DEPEX
>
> This patch adds the management mode FV file type and depex.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Reviewed-by: Jiewen Yao 
> ---
>  MdePkg/Include/Pi/PiFirmwareFile.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index b982c9eda3..6086d1bb2f 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE;  #define 
> EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER  0x08
>  #define EFI_FV_FILETYPE_APPLICATION   0x09
>  #define EFI_FV_FILETYPE_SMM   0x0A
> +#define EFI_FV_FILETYPE_MM0x0A
>  #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
>  #define EFI_FV_FILETYPE_COMBINED_SMM_DXE  0x0C
> +#define EFI_FV_FILETYPE_COMBINED_MM_DXE   0x0C
>  #define EFI_FV_FILETYPE_SMM_CORE  0x0D
> +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E
>  #define EFI_FV_FILETYPE_OEM_MIN   0xc0
>  #define EFI_FV_FILETYPE_OEM_MAX   0xdf
>  #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
> @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE;
>  #define EFI_SECTION_RAW   0x19
>  #define EFI_SECTION_PEI_DEPEX 0x1B
>  #define EFI_SECTION_SMM_DEPEX 0x1C
> +#define EFI_SECTION_MM_DEPEX  0x1C
>
>  ///
>  /// Common section header.
> --
> 2.14.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.

2018-01-25 Thread Supreeth Venkatesh

Marvin,

Thanks for your comments.
As per PI v1.6 specification,
EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM 
Traditional Mode.)

This is traditional MM mode, which ARM is not supporting at this point. We are 
more interested in MM_CORE_STANDALONE mode.
However, I have no issues in adding this in the patch, but would prefer if this 
is added when MM traditional mode is supported in ARM.

Further,
w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't want to 
break backwards compatibility with existing SMM traditional mode 
implementations.
I will be happy to let folks who have migrated to _MM_ definitions from _SMM_ 
definitions to send the patch across.

Thanks,
Supreeth

-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Tuesday, January 23, 2018 6:34 PM
To: edk2-devel@lists.01.org
Cc: Supreeth Venkatesh ; 
michael.d.kin...@intel.com; liming@intel.com
Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file 
type and depex.

Good day,

I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE" (0x0C).
Furthermore, may I suggest changing the *_SMM_* definitions to be defined via 
the *_MM_* definitions?

Best regards,
Marvin.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Supreeth Venkatesh
> Sent: Tuesday, January 23, 2018 9:03 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV
> file type and depex.
>
> As per PI specification v1.6,
> The following new file types are added:
> EFI_FV_FILETYPE_MM_STANDALONE
> EFI_FV_FILETYPE_MM_CORE_STANDALONE
>
> The following new section type is added:
> EFI_SECTION_MM_DEPEX
>
> This patch adds the management mode FV file type and depex.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta 
> Signed-off-by: Supreeth Venkatesh 
> Reviewed-by: Jiewen Yao 
> ---
>  MdePkg/Include/Pi/PiFirmwareFile.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h
> b/MdePkg/Include/Pi/PiFirmwareFile.h
> index b982c9eda3..6086d1bb2f 100644
> --- a/MdePkg/Include/Pi/PiFirmwareFile.h
> +++ b/MdePkg/Include/Pi/PiFirmwareFile.h
> @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE;  #define
> EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER  0x08
>  #define EFI_FV_FILETYPE_APPLICATION   0x09
>  #define EFI_FV_FILETYPE_SMM   0x0A
> +#define EFI_FV_FILETYPE_MM0x0A
>  #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
>  #define EFI_FV_FILETYPE_COMBINED_SMM_DXE  0x0C
> +#define EFI_FV_FILETYPE_COMBINED_MM_DXE   0x0C
>  #define EFI_FV_FILETYPE_SMM_CORE  0x0D
> +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E
>  #define EFI_FV_FILETYPE_OEM_MIN   0xc0
>  #define EFI_FV_FILETYPE_OEM_MAX   0xdf
>  #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
> @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE;
>  #define EFI_SECTION_RAW   0x19
>  #define EFI_SECTION_PEI_DEPEX 0x1B
>  #define EFI_SECTION_SMM_DEPEX 0x1C
> +#define EFI_SECTION_MM_DEPEX  0x1C
>
>  ///
>  /// Common section header.
> --
> 2.14.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v3] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed

2018-01-25 Thread Ard Biesheuvel

Add menu options to the SynQuacer Platform menu screen to limit the
maximum PCIe link speed for each slot individually. This may be useful
to work around potential PCIe issues.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
v3:
deobfuscate the slot speed limit check, using a switch rather than a
convoluted if(), and a comment that describes what goes on

v2:
Make the speed limit per-slot instead of per-RC. That does make this
implementation more specific to DeveloperBox than it was before, but
given the special knowledge about the on-board ASM1184e switch and the
need for enabling spread-spectrum on the ASM1061, we're already past the
point where PlatformDxe is a generic SynQuacer driver, and we may need to
move it into Platform/Socionext (and clone it for each platform) in the
future.

 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   
  |   2 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   
  |   2 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c  
  |  35 ++-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c  
  | 107 
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h  
  |  13 +++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
  |  11 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni 
  |  29 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
  |  69 +
 Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h
  |  23 +
 Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
  |   5 +
 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
  |  29 ++
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
  |   2 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
 |  40 +++-
 Silicon/Socionext/SynQuacer/SynQuacer.dec  
  |   5 +
 14 files changed, 365 insertions(+), 7 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 86685d1dec3b..2d46b4515749 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index b4b9239143bc..263b6454ff72 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
index 9af3dd942cdd..7c69a8051a56 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
@@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort (
   EFI_STATUSStatus;
   PCIE_CAP  Cap;
   PCI_REG_PCIE_LINK_CONTROL LinkControl;
+  UINTN SegmentNumber;
+  UINTN BusNumber;
+  UINTN DeviceNumber;
+  UINTN FunctionNumber;
+  UINT8 MaxSpeed;
 
   //
   // The upstream and downstream ports share the same PID/VID, so check
@@ -64,8 +69,34 @@ RetrainAsm1184eDownstreamPort (
 return;
   }
 
-  DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream PCIe port\n",
-__FUNCTION__));
+  Status = PciIo->GetLocation (PciIo, , , 
,
+);
+  ASSERT_EFI_ERROR (Status);

Re: [edk2] [PATCH edk2-platforms v2] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 03:31:19PM +, Ard Biesheuvel wrote:
> Add menu options to the SynQuacer Platform menu screen to limit the
> maximum PCIe link speed for each slot individually. This may be useful
> to work around potential PCIe issues.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v2:
> Make the speed limit per-slot instead of per-RC. That does make this
> implementation more specific to DeveloperBox than it was before, but
> given the special knowledge about the on-board ASM1184e switch and the
> need for enabling spread-spectrum on the ASM1061, we're already past the
> point where PlatformDxe is a generic SynQuacer driver, and we may need to
> move it into Platform/Socionext (and clone it for each platform) in the
> future.
> 
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> |   2 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> |   2 +
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> |  24 -
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> | 107 
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h
> |  13 +++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf  
> |  11 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni   
> |  29 ++
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr   
> |  69 +
>  Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h  
> |  23 +
>  Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h  
> |   5 +
>  Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h  
> |  29 ++
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
>   |   2 +
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>  |  35 ++-
>  Silicon/Socionext/SynQuacer/SynQuacer.dec
> |   5 +
>  14 files changed, 349 insertions(+), 7 deletions(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index 86685d1dec3b..2d46b4515749 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
>  [PcdsDynamicHii]
>
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
>  
> +  
> gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
> +
>  [PcdsDynamicDefault]
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index b4b9239143bc..263b6454ff72 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
>  [PcdsDynamicHii]
>
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
>  
> +  
> gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
> +
>  [PcdsDynamicDefault]
>gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
>gArmTokenSpaceGuid.PcdSystemMemorySize|0x
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> index 9af3dd942cdd..4e1b4a6f9080 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
> @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort (
>EFI_STATUSStatus;
>PCIE_CAP  Cap;
>PCI_REG_PCIE_LINK_CONTROL LinkControl;
> +  UINTN SegmentNumber;
> +  UINTN BusNumber;
> +  UINTN DeviceNumber;
> +  UINTN FunctionNumber;
> +  UINTN Location;
>  
>//
>// The upstream and downstream ports share the same PID/VID, so check
> @@ -64,8 +69,23 @@ RetrainAsm1184eDownstreamPort (
>  return;
>}
>  
> -  DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream

[edk2] [PATCH edk2-platforms v2] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed

2018-01-25 Thread Ard Biesheuvel

Add menu options to the SynQuacer Platform menu screen to limit the
maximum PCIe link speed for each slot individually. This may be useful
to work around potential PCIe issues.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
v2:
Make the speed limit per-slot instead of per-RC. That does make this
implementation more specific to DeveloperBox than it was before, but
given the special knowledge about the on-board ASM1184e switch and the
need for enabling spread-spectrum on the ASM1061, we're already past the
point where PlatformDxe is a generic SynQuacer driver, and we may need to
move it into Platform/Socionext (and clone it for each platform) in the
future.

 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   
  |   2 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   
  |   2 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c  
  |  24 -
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c  
  | 107 
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h  
  |  13 +++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
  |  11 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni 
  |  29 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
  |  69 +
 Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h
  |  23 +
 Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
  |   5 +
 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
  |  29 ++
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
  |   2 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
 |  35 ++-
 Silicon/Socionext/SynQuacer/SynQuacer.dec  
  |   5 +
 14 files changed, 349 insertions(+), 7 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 86685d1dec3b..2d46b4515749 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index b4b9239143bc..263b6454ff72 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
index 9af3dd942cdd..4e1b4a6f9080 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
@@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort (
   EFI_STATUSStatus;
   PCIE_CAP  Cap;
   PCI_REG_PCIE_LINK_CONTROL LinkControl;
+  UINTN SegmentNumber;
+  UINTN BusNumber;
+  UINTN DeviceNumber;
+  UINTN FunctionNumber;
+  UINTN Location;
 
   //
   // The upstream and downstream ports share the same PID/VID, so check
@@ -64,8 +69,23 @@ RetrainAsm1184eDownstreamPort (
 return;
   }
 
-  DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream PCIe port\n",
-__FUNCTION__));
+  Status = PciIo->GetLocation (PciIo, , , 
,
+);
+  ASSERT_EFI_ERROR (Status);
+
+  Location = SYNQUACER_PCI_LOCATION (SegmentNumber, BusNumber, DeviceNumber);
+  if ((Location == SYNQUACER_PCI_SLOT0_LOCATION &&
+

Re: [edk2] [PATCH edk2-platforms v1 01/14] Hisilicon/D05: Add PPTT support

2018-01-25 Thread Jeremy Linton


Hi,

On 01/24/2018 11:56 PM, Huangming (Mark) wrote:



On 2018/1/24 5:29, Jeremy Linton wrote:

Hi,


On 01/18/2018 09:01 AM, Ming Huang wrote:

From: Jason Zhang 

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jason Zhang 
Signed-off-by: Ming Huang 
Signed-off-by: Heyi Guo 
---
   Platform/Hisilicon/D05/D05.dsc  |   1 +
   Platform/Hisilicon/D05/D05.fdf  |   1 +
   Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h |  27 ++
   Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc  |  31 +-
   Silicon/Hisilicon/Hi1616/Pptt/Pptt.c| 447 

   Silicon/Hisilicon/Hi1616/Pptt/Pptt.h| 142 +++
   Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf  |  55 +++
   7 files changed, 677 insertions(+), 27 deletions(-)

diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index 77a89fd..710339c 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -506,6 +506,7 @@
 MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
   Silicon/Hisilicon/Hi1616/D05AcpiTables/AcpiTablesHi1616.inf
+  Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf
 Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
   #
diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf
index 78ab0c8..97de4d2 100644
--- a/Platform/Hisilicon/D05/D05.fdf
+++ b/Platform/Hisilicon/D05/D05.fdf
@@ -241,6 +241,7 @@ READ_LOCK_STATUS   = TRUE
 INF Silicon/Hisilicon/Drivers/HisiAcpiPlatformDxe/AcpiPlatformDxe.inf
   INF RuleOverride=ACPITABLE 
Silicon/Hisilicon/Hi1616/D05AcpiTables/AcpiTablesHi1616.inf
+  INF Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf
 INF Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
   #
diff --git a/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h 
b/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h
index 808219a..f1927e8 100644
--- a/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h
+++ b/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h
@@ -19,6 +19,7 @@
 #ifndef _HI1610_PLATFORM_H_
   #define _HI1610_PLATFORM_H_
+#include 
 //
   // ACPI table information used to initialize tables.
@@ -44,5 +45,31 @@
 }
 #define HI1616_WATCHDOG_COUNT  2
+#define HI1616_GIC_STRUCTURE_COUNT  64
+
+#define HI1616_MPID_TA_BASE  0x1
+#define HI1616_MPID_TB_BASE  0x3
+#define HI1616_MPID_TA_2_BASE  0x5
+#define HI1616_MPID_TB_2_BASE  0x7
+
+// Differs from Juno, we have another affinity level beyond cluster and core
+#define PLATFORM_GET_MPID_TA(ClusterId, CoreId)   (HI1616_MPID_TA_BASE | 
((ClusterId) << 8) | (CoreId))
+#define PLATFORM_GET_MPID_TB(ClusterId, CoreId)   (HI1616_MPID_TB_BASE | 
((ClusterId) << 8) | (CoreId))
+#define PLATFORM_GET_MPID_TA_2(ClusterId, CoreId)   (HI1616_MPID_TA_2_BASE | 
((ClusterId) << 8) | (CoreId))
+#define PLATFORM_GET_MPID_TB_2(ClusterId, CoreId)   (HI1616_MPID_TB_2_BASE | 
((ClusterId) << 8) | (CoreId))
+
+//
+// Multiple APIC Description Table
+//
+#pragma pack (1)
+
+typedef struct {
+  EFI_ACPI_6_1_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
+  EFI_ACPI_6_1_GIC_STRUCTURE
GicInterfaces[HI1616_GIC_STRUCTURE_COUNT];
+  EFI_ACPI_6_1_GIC_DISTRIBUTOR_STRUCTUREGicDistributor;
+  EFI_ACPI_6_1_GIC_ITS_STRUCTUREGicITS[8];
+} EFI_ACPI_6_1_MULTIPLE_APIC_DESCRIPTION_TABLE;
+
+#pragma pack ()
 #endif
diff --git a/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc 
b/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc
index 169ee72..33dca03 100644
--- a/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc
+++ b/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc
@@ -1,9 +1,9 @@
   /** @file
   *  Multiple APIC Description Table (MADT)
   *
-*  Copyright (c) 2012 - 2014, ARM Limited. All rights reserved.
-*  Copyright (c) 2015 - 2016, Hisilicon Limited. All rights reserved.
-*  Copyright (c) 2015 - 2016, Linaro Limited. All rights reserved.
+*  Copyright (c) 2012 - 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2015 - 2018, Hisilicon Limited. All rights reserved.
+*  Copyright (c) 2015 - 2018, Linaro Limited. All rights reserved.
   *
   *  This program and the accompanying materials
   *
@@ -19,34 +19,11 @@
   *
   **/
   -
-#include 
+#include "Hi1616Platform.h"
   #include 
   #include 
   #include 
   #include 
-#include "Hi1616Platform.h"
-
-// Differs from Juno, we have another affinity level beyond cluster and core
-// 0x2 is only for socket 0
-#define PLATFORM_GET_MPID_TA(ClusterId, CoreId)   (0x1 | ((ClusterId) << 
8) | (CoreId))
-#define PLATFORM_GET_MPID_TB(ClusterId, CoreId)   (0x3 | ((ClusterId) << 
8) | (CoreId))
-#define PLATFORM_GET_MPID_TA_2(ClusterId, CoreId)   (0x5 | ((ClusterId) << 
8) | (CoreId))

Re: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to 1.02

2018-01-25 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, January 25, 2018 1:54 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: RE: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01
> to 1.02
> Importance: High
> 
> Reviewed-by: Liming Gao 
> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Ruiyu Ni
> >Sent: Wednesday, January 24, 2018 1:56 PM
> >To: edk2-devel@lists.01.org
> >Cc: Carsey, Jaben 
> >Subject: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to
> >1.02
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Ruiyu Ni 
> >Cc: Jaben Carsey 
> >---
> > ShellPkg/ShellPkg.dec | 4 ++--
> > ShellPkg/ShellPkg.dsc | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec
> >index 48d50b87b3..0c4f74ff41 100644
> >--- a/ShellPkg/ShellPkg.dec
> >+++ b/ShellPkg/ShellPkg.dec
> >@@ -2,7 +2,7 @@
> > # This Package provides all definitions for EFI and UEFI Shell
> > #
> > # (C) Copyright 2013-2014 Hewlett-Packard Development Company,
> L.P.
> >-# Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
> >+# Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> > #
> > # This program and the accompanying materials are licensed and made
> >available under
> > # the terms and conditions of the BSD License which accompanies this
> >distribution.
> >@@ -18,7 +18,7 @@ [Defines]
> >   DEC_SPECIFICATION  = 0x00010005
> >   PACKAGE_NAME   = ShellPkg
> >   PACKAGE_GUID   = C1014BB7-4092-43D4-984F-0738EB424DBF
> >-  PACKAGE_VERSION= 1.01
> >+  PACKAGE_VERSION= 1.02
> >
> > [Includes]
> >   Include
> >diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
> >index 86382139a5..29f5376412 100644
> >--- a/ShellPkg/ShellPkg.dsc
> >+++ b/ShellPkg/ShellPkg.dsc
> >@@ -1,7 +1,7 @@
> > ##  @file
> > # Shell Package
> > #
> >-# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
> >+# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> > #
> > #This program and the accompanying materials
> > #are licensed and made available under the terms and conditions of the
> >BSD License
> >@@ -16,7 +16,7 @@
> > [Defines]
> >   PLATFORM_NAME  = Shell
> >   PLATFORM_GUID  = E1DC9BF8-7013-4c99-9437-795DAA45F3BD
> >-  PLATFORM_VERSION   = 1.01
> >+  PLATFORM_VERSION   = 1.02
> >   DSC_SPECIFICATION  = 0x00010006
> >   OUTPUT_DIRECTORY   = Build/Shell
> >   SUPPORTED_ARCHITECTURES= IA32|IPF|X64|EBC|ARM|AARCH64
> >--
> >2.15.1.windows.2
> >
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/15] BaseTools: One step toward python3

2018-01-25 Thread Zhu, Yonghong

Hi Gary,

Thanks for your patches. I am still in evaluating these changes and do some 
verification for it.
I still need some more days to give you comment. Thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Gary Lin [mailto:g...@suse.com] 
Sent: Friday, January 19, 2018 12:43 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming 
Subject: [PATCH 00/15] BaseTools: One step toward python3

Since python2 will be EOF in 2020, we start to evaluate the impact of the 
python2 removal. As expected, OMVF building failed the test. It's actually a 
task noted in the wiki page:

https://github.com/tianocore/tianocore.github.io/wiki/Tasks-BaseTools-Python3-Support

Maybe it's time to convert the python scripts gradully.

This patchset doesn't make the python scripts in BaseTools compatible with 
python3 immediately. It aims to do the trivial and safe conversion and 
replacement to make some statements compatible with both python2 and python3, 
so we can deal with the difficult cases later.

With the help of "futurize" from python-future, it's easier to refactor the 
statements. This patchset is basically equivalent to "futurize -1"
plus "StringIO.StringIO => io.BytesIO" and minus "fix_absolute_import".
The reason to skip "fix_absolute_import" is that python2 failed to find some 
modules after converting to absolute import, and it might take time to figure 
out a proper fix.

For the "io.BytesIO" change, it MIGHT introduce slow down to the build time 
since io.BytesIO is slower than StringIO.StringIO in python2(*).
For a quick test, I built OVMF with the following command based on
8ab0bd2397c9d3922e0c7dbb1aa6f7e08799079f:

$ rm -rf Build && make -C BaseTools/ clean $ time ./OvmfPkg/build.sh -D 
SECURE_BOOT_ENABLE \
  -D NETWORK_IP6_ENABLE \
  -D HTTP_BOOT_ENABLE \
  -D TLS_ENABLE

Before io.BytesIO:

  Build total time: 00:03:56
  real4m22.991s
  user3m55.874s
  sys 0m27.250s

After io.BytesIO:

  Build total time: 00:03:57
  real4m23.953s
  user3m57.526s
  sys 0m27.192s

The difference is only 1 second, and I would say the impact is subtle. 

The next step will be fixing relative import and maybe applying more futurize 
fixes. We won't get there soon but at least we are moving... 

(*) 
https://stackoverflow.com/questions/37462075/confusing-about-stringio-cstringio-and-byteio

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Yonghong Zhu 
Cc: Liming Gao 
Signed-off-by: Gary Lin 

Gary Lin (15):
  BaseTools: Refactor python except statements
  BaseTools: Refactor python print statements
  BaseTools: Remove the old python "not-equal"
  BaseTools: Use the python3-range functions
  BaseTools: Remove tuple parameter in python scripts
  BaseTools: Remove the deprecated hash_key()
  BaseTools: Import reduce() from functools
  BaseTools: Replace StandardError with Expression
  BaseTools: Remove types.TypeType
  BaseTools: Refactor python raise statement
  BaseTools: Adjust the spaces around commas and colons
  BaseTools: Migrate to the new octal literal
  BaseTools: Unify long int and int in python scripts
  BaseTools: Adjust old python2 idioms
  BaseTools: Replace StringIO.StringIO with io.BytesIO

 BaseTools/Bin/CYGWIN_NT-5.1-i686/armcc_wrapper.py  |   5 +-
 BaseTools/Scripts/BinToPcd.py  |  46 
+++---
 BaseTools/Scripts/ConvertMasmToNasm.py |   1 +
 BaseTools/Scripts/ConvertUni.py|   5 -
 BaseTools/Scripts/MemoryProfileSymbolGen.py|  22 
+--
 BaseTools/Scripts/PatchCheck.py|   7 +-
 BaseTools/Scripts/RunMakefile.py   |   2 +-
 BaseTools/Scripts/SmiHandlerProfileSymbolGen.py|  20 
+--
 BaseTools/Scripts/UpdateBuildVersions.py   |  18 +-
 BaseTools/Source/Python/AutoGen/AutoGen.py |  91 
+-
 BaseTools/Source/Python/AutoGen/BuildEngine.py |  38 
+++--
 BaseTools/Source/Python/AutoGen/GenC.py|   5 +-
 BaseTools/Source/Python/AutoGen/GenDepex.py|   8 +-
 BaseTools/Source/Python/AutoGen/GenMake.py |   8 +-
 BaseTools/Source/Python/AutoGen/GenPcdDb.py| 142 

 BaseTools/Source/Python/AutoGen/GenVar.py  | 165 
+--
 BaseTools/Source/Python/AutoGen/IdfClassObject.py  |   1 -
 BaseTools/Source/Python/AutoGen/InfSectionParser.py|   1 +
 BaseTools/Source/Python/AutoGen/StrGather.py   |   5 +-

Re: [edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol

2018-01-25 Thread Ard Biesheuvel

On 25 January 2018 at 12:54, Leif Lindholm  wrote:
> On Thu, Jan 25, 2018 at 12:27:31PM +, Ard Biesheuvel wrote:
>> Instead of registering a notification callback on the driver binding
>> protocol, and attempting to connect our I2C master handle each time
>> a new driver is registered, switch to the more obvious approach of
>> registering a notification callback on the I2C master protocol directly.
>>
>> The original code was written under the assumption that it would make
>> the RTC available at an earlier time, but given that all handles that
>> are created during the execution of a driver entry point are connected
>> by DXE core right away (i.e., before StartImage() returns), this is not
>> really necessary, and in fact, may result in the driver already having
>> been connected by the time we attempt to connect it.
>>
>> Note that it is now up to the platform to ensure that ConnectController()
>> is called for the handle if DXE core does not call it by itself, or does
>> call it but at a time when no I2C master protocol driver is available
>> yet.
>
> Presumably the platforms in edk2-platforms using this library already
> follow these constraints?
>

There aren't any. But I did CC the NXP guys on this patch when I sent
it the first time around, to give them the head's up that they
probably shouldn't copy the original pattern.

> If so:
> Reviewed-by: Leif Lindholm 
>

Thanks.

>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   | 
>> 31 
>>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf |  
>> 1 -
>>  2 files changed, 13 insertions(+), 19 deletions(-)
>>
>> diff --git 
>> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c 
>> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
>> index 6bc4aef28849..fb58e1feb424 100644
>> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
>> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
>> @@ -41,7 +41,7 @@
>>  #define EPOCH_BASE2000
>>
>>  STATIC EFI_HANDLE mI2cMasterHandle;
>> -STATIC VOID   *mDriverEventRegistration;
>> +STATIC VOID   *mI2cMasterEventRegistration;
>>  STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
>>  STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
>>
>> @@ -263,12 +263,12 @@ LibSetWakeupTime (
>>
>>  STATIC
>>  VOID
>> -DriverRegistrationEvent (
>> +I2cMasterRegistrationEvent (
>>IN  EFI_EVENT   Event,
>>IN  VOID*Context
>>)
>>  {
>> -  EFI_HANDLEHandle[2];
>> +  EFI_HANDLEHandle;
>>UINTN BufferSize;
>>EFI_STATUSStatus;
>>EFI_I2C_MASTER_PROTOCOL   *I2cMaster;
>> @@ -280,10 +280,10 @@ DriverRegistrationEvent (
>>do {
>>  BufferSize = sizeof (EFI_HANDLE);
>>  Status = gBS->LocateHandle (ByRegisterNotify,
>> -,
>> -mDriverEventRegistration,
>> +,
>> +mI2cMasterEventRegistration,
>>  ,
>> -Handle);
>> +);
>>  if (EFI_ERROR (Status)) {
>>if (Status != EFI_NOT_FOUND) {
>>  DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n",
>> @@ -292,12 +292,7 @@ DriverRegistrationEvent (
>>break;
>>  }
>>
>> -//
>> -// Check if we can connect our handle to this driver.
>> -//
>> -Handle[1] = NULL;
>> -Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE);
>> -if (EFI_ERROR (Status)) {
>> +if (Handle != mI2cMasterHandle) {
>>continue;
>>  }
>>
>> @@ -378,16 +373,16 @@ LibRtcInitialize (
>>ASSERT_EFI_ERROR (Status);
>>
>>//
>> -  // Register a protocol registration notification callback on the driver
>> -  // binding protocol so we can attempt to connect our I2C master to it
>> -  // as soon as it appears.
>> +  // Register a protocol registration notification callback on the I2C 
>> master
>> +  // protocol. This will notify us even if the protocol instance we are 
>> looking
>> +  // for has already been installed.
>>//
>>EfiCreateProtocolNotifyEvent (
>> -,
>> +,
>>  TPL_CALLBACK,
>> -DriverRegistrationEvent,
>> +I2cMasterRegistrationEvent,
>>  NULL,
>> -);
>> +);
>>
>>//
>>// Register for the virtual address change event
>> diff --git 
>> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf 
>> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
>> index 1a9a6f6c9cf3..e232902c6b5d 100644
>> ---

Re: [edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding

2018-01-25 Thread Ard Biesheuvel

On 25 January 2018 at 13:00, Leif Lindholm  wrote:
> On Thu, Jan 25, 2018 at 12:27:35PM +, Ard Biesheuvel wrote:
>> The upstream version of the Linux NETSEC driver expects the PHY DT
>> node to appear under a MDIO subnode, so fix this in the device tree.
>> Fix the node name as well, this should be 'ethernet' not 'netsec',
>> and add a clock-names property describing the single clock reference
>> as 'phy_ref_clk'.
>>
>> Also, move the PHY subnode into the per-platform .dts file so we can
>> set the unit address in the node name. This is necessary because recent
>> versions of the DT compiler are more finicky about this.
>
> Presumably the only kernels this may break are using non-upstream code?

Yes. The upstream version is not quite upstream yet - it is now
[finally] queued, for inclusion in v4.16

> If so:
> Reviewed-by: Leif Lindholm 
>

Thanks

>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts   |  7 +
>>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 
>> +---
>>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts |  7 +
>>  3 files changed, 28 insertions(+), 16 deletions(-)
>>
>> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts 
>> b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
>> index d2cd7ef90e6f..488c51a0f793 100644
>> --- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
>> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
>> @@ -44,3 +44,10 @@
>>"GPIO-K", "GPIO-L", "PEC-PD26", 
>> "PEC-PD27",
>>"PEC-PD28",   "PEC-PD29",   "PEC-PD30", 
>> "PEC-PD31";
>>  };
>> +
>> +_netsec {
>> +phy_netsec: ethernet-phy@7 {
>> +compatible = "ethernet-phy-ieee802.3-c22";
>> +reg = <7>;
>> +};
>> +};
>> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
>> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
>> index 7c3518facb98..6ee7a0b7ccb4 100644
>> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
>> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
>> @@ -457,25 +457,23 @@
>>  #clock-cells = <0>;
>>  };
>>
>> -eth0: netsec@522D {
>> -compatible = "socionext,synquacer-netsec";
>> -reg = <0 0x522d 0x0 0x1>,
>> -  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
>> -interrupts = ;
>> -clocks = <_netsec>;
>> -phy-mode = "rgmii";
>> -max-speed = <1000>;
>> -max-frame-size = <9000>;
>> -phy-handle = <>;
>> -dma-coherent;
>> +ethernet@522d {
>> +compatible = "socionext,synquacer-netsec";
>> +reg = <0 0x522d 0x0 0x1>,
>> +  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
>> +interrupts = ;
>> +clocks = <_netsec>;
>> +clock-names = "phy_ref_clk";
>> +phy-mode = "rgmii";
>> +max-speed = <1000>;
>> +max-frame-size = <9000>;
>> +phy-handle = <_netsec>;
>> +dma-coherent;
>>
>> +mdio_netsec: mdio {
>>  #address-cells = <1>;
>>  #size-cells = <0>;
>> -
>> -ethphy0: ethernet-phy {
>> -compatible = "ethernet-phy-ieee802.3-c22";
>> -reg = ;
>> -};
>> +};
>>  };
>>
>>  smmu: iommu@582c {
>> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts 
>> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
>> index 132fd370a71b..97fddfedcb46 100644
>> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
>> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
>> @@ -34,3 +34,10 @@
>>   {
>>  status = "okay";
>>  };
>> +
>> +_netsec {
>> +phy_netsec: ethernet-phy@1 {
>> +compatible = "ethernet-phy-ieee802.3-c22";
>> +reg = <1>;
>> +};
>> +};
>> --
>> 2.11.0
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:35PM +, Ard Biesheuvel wrote:
> The upstream version of the Linux NETSEC driver expects the PHY DT
> node to appear under a MDIO subnode, so fix this in the device tree.
> Fix the node name as well, this should be 'ethernet' not 'netsec',
> and add a clock-names property describing the single clock reference
> as 'phy_ref_clk'.
> 
> Also, move the PHY subnode into the per-platform .dts file so we can
> set the unit address in the node name. This is necessary because recent
> versions of the DT compiler are more finicky about this.

Presumably the only kernels this may break are using non-upstream code?
If so:
Reviewed-by: Leif Lindholm 

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts   |  7 +
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 
> +---
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts |  7 +
>  3 files changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts 
> b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
> index d2cd7ef90e6f..488c51a0f793 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
> @@ -44,3 +44,10 @@
>"GPIO-K", "GPIO-L", "PEC-PD26", "PEC-PD27",
>"PEC-PD28",   "PEC-PD29",   "PEC-PD30", "PEC-PD31";
>  };
> +
> +_netsec {
> +phy_netsec: ethernet-phy@7 {
> +compatible = "ethernet-phy-ieee802.3-c22";
> +reg = <7>;
> +};
> +};
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> index 7c3518facb98..6ee7a0b7ccb4 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> @@ -457,25 +457,23 @@
>  #clock-cells = <0>;
>  };
>  
> -eth0: netsec@522D {
> -compatible = "socionext,synquacer-netsec";
> -reg = <0 0x522d 0x0 0x1>,
> -  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
> -interrupts = ;
> -clocks = <_netsec>;
> -phy-mode = "rgmii";
> -max-speed = <1000>;
> -max-frame-size = <9000>;
> -phy-handle = <>;
> -dma-coherent;
> +ethernet@522d {
> +compatible = "socionext,synquacer-netsec";
> +reg = <0 0x522d 0x0 0x1>,
> +  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
> +interrupts = ;
> +clocks = <_netsec>;
> +clock-names = "phy_ref_clk";
> +phy-mode = "rgmii";
> +max-speed = <1000>;
> +max-frame-size = <9000>;
> +phy-handle = <_netsec>;
> +dma-coherent;
>  
> +mdio_netsec: mdio {
>  #address-cells = <1>;
>  #size-cells = <0>;
> -
> -ethphy0: ethernet-phy {
> -compatible = "ethernet-phy-ieee802.3-c22";
> -reg = ;
> -};
> +};
>  };
>  
>  smmu: iommu@582c {
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts 
> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
> index 132fd370a71b..97fddfedcb46 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
> @@ -34,3 +34,10 @@
>   {
>  status = "okay";
>  };
> +
> +_netsec {
> +phy_netsec: ethernet-phy@1 {
> +compatible = "ethernet-phy-ieee802.3-c22";
> +reg = <1>;
> +};
> +};
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/DeviceTree: align uart DT nodes

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:34PM +, Ard Biesheuvel wrote:
> Align the UART DT nodes:
> - use 'uart' not 'fuart' as node name for the second serial port
> - create an alias 'serial1' for the second serial port
> - use UART clock reference instead of hardcoded frequency
> - split 'clocks' property into 1 cell per phandle
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> index 37a3981f0360..7c3518facb98 100644
> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
> @@ -32,6 +32,7 @@
>  
>  aliases {
>  serial0 = _uart0;
> +serial1 = 
>  };
>  
>  chosen {
> @@ -436,15 +437,16 @@
>  compatible = "arm,pl011", "arm,primecell";
>  reg = <0x0 0x2a40 0x0 0x1000>;
>  interrupts = ;
> -clocks = <_uart _apb>;
> +clocks = <_uart>, <_apb>;
>  clock-names = "uartclk", "apb_pclk";
>  };
>  
> -fuart: fuart@5104 {
> +fuart: uart@5104 {
>  compatible = "snps,dw-apb-uart";
>  reg = <0x0 0x5104 0x0 0x1000>;
>  interrupts = ;
> -clock-frequency = <6250>;
> +clocks = <_uart>, <_apb>;
> +clock-names = "baudclk", "apb_pclk";
>  reg-io-width = <4>;
>  reg-shift = <2>;
>  };
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 5/8] Silicon/SynQuacer: load I2C driver before platform DXE driver

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:33PM +, Ard Biesheuvel wrote:
> To ensure that the I2C master protocol is installed immediately onto
> the handles created by PlatformDxe in its entry point, force the
> SynQuacerI2cDxe driver to be loaded before PlatformDxe. These handles
> are recursively connected by the DXE core as soon as they appear, and
> so ensuring that the I2C master protocol driver is available at this
> time will ensure that these handles will be connected to it right away.
> 
> This is useful when implementations of architectural protocols such as
> RTC or the EFI variable store, which should become available long before
> the ordinary dispatch of UEFI driver model drivers is started at the end
> of DXE, are based on I2C.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 
> +-
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf | 2 
> +-
>  Silicon/Socionext/SynQuacer/SynQuacer.dec   | 2 
> ++
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> index 4d6a1d637922..f075957d7456 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> @@ -17,7 +17,7 @@
>  [Defines]
>INF_VERSION= 0x0001001A
>BASE_NAME  = PlatformDxe
> -  FILE_GUID  = ac422cc1-d916-489a-b165-536fdfc633c2
> +  FILE_GUID  = ac422cc1-d916-489a-b165-536fdfc633c2 # 
> gSynQuacerPlatformDxeFileGuid
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>ENTRY_POINT= PlatformDxeEntryPoint
> diff --git 
> a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf 
> b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
> index fa715366878c..325816ba0b88 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
> +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
> @@ -56,4 +56,4 @@ [FixedPcd]
>gSynQuacerTokenSpaceGuid.PcdI2cReferenceClock
>  
>  [Depex]
> -  TRUE
> +  BEFORE gSynQuacerPlatformDxeFileGuid
> diff --git a/Silicon/Socionext/SynQuacer/SynQuacer.dec 
> b/Silicon/Socionext/SynQuacer/SynQuacer.dec
> index a21f12b5bc32..76529e3c2164 100644
> --- a/Silicon/Socionext/SynQuacer/SynQuacer.dec
> +++ b/Silicon/Socionext/SynQuacer/SynQuacer.dec
> @@ -25,6 +25,8 @@ [Guids]
>gSynQuacerNonDiscoverableI2cMasterGuid = { 0x364ee675, 0x9e44, 0x42b7, { 
> 0xa5, 0xe4, 0x92, 0x84, 0xdb, 0x85, 0xda, 0x09 } }
>gSynQuacerNonDiscoverableRuntimeI2cMasterGuid = { 0x5f35aa9b, 0x8c6f, 
> 0x4828, { 0xbd, 0x44, 0x7c, 0xc0, 0xeb, 0x2d, 0xfe, 0xb9 } }
>  
> +  gSynQuacerPlatformDxeFileGuid = { 0xac422cc1, 0xd916, 0x489a, { 0xb1, 
> 0x65, 0x53, 0x6f, 0xdf, 0xc6, 0x33, 0xc2 } }
> +
>  [Ppis]
>gSynQuacerDramInfoPpiGuid = { 0x3e1d7356, 0xdda4, 0x4b1a, { 0x93, 0x46, 
> 0xbf, 0x89, 0x1c, 0x86, 0x46, 0xcc } }
>  
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 4/8] Silicon/SynQuacerI2cDxe: remove spurious format specifier

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:32PM +, Ard Biesheuvel wrote:
> Remove a %r without an associated parameter.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c 
> b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
> index c3703dfb6c33..46c512a20151 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
> @@ -335,7 +335,7 @@ SynQuacerI2cStartRequest (
>  }
>  
>  if (MmioRead8 (I2c->MmioBase + F_I2C_REG_BSR) & F_I2C_BSR_LRB) {
> -  BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received - %r\n", 
> __FUNCTION__));
> +  BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received\n", __FUNCTION__));
>Status = EFI_DEVICE_ERROR;
>break;
>  }
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:31PM +, Ard Biesheuvel wrote:
> Instead of registering a notification callback on the driver binding
> protocol, and attempting to connect our I2C master handle each time
> a new driver is registered, switch to the more obvious approach of
> registering a notification callback on the I2C master protocol directly.
> 
> The original code was written under the assumption that it would make
> the RTC available at an earlier time, but given that all handles that
> are created during the execution of a driver entry point are connected
> by DXE core right away (i.e., before StartImage() returns), this is not
> really necessary, and in fact, may result in the driver already having
> been connected by the time we attempt to connect it.
> 
> Note that it is now up to the platform to ensure that ConnectController()
> is called for the handle if DXE core does not call it by itself, or does
> call it but at a time when no I2C master protocol driver is available
> yet.

Presumably the platforms in edk2-platforms using this library already
follow these constraints?

If so:
Reviewed-by: Leif Lindholm 

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   | 31 
> 
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf |  1 
> -
>  2 files changed, 13 insertions(+), 19 deletions(-)
> 
> diff --git 
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c 
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> index 6bc4aef28849..fb58e1feb424 100644
> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> @@ -41,7 +41,7 @@
>  #define EPOCH_BASE2000
>  
>  STATIC EFI_HANDLE mI2cMasterHandle;
> -STATIC VOID   *mDriverEventRegistration;
> +STATIC VOID   *mI2cMasterEventRegistration;
>  STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
>  STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
>  
> @@ -263,12 +263,12 @@ LibSetWakeupTime (
>  
>  STATIC
>  VOID
> -DriverRegistrationEvent (
> +I2cMasterRegistrationEvent (
>IN  EFI_EVENT   Event,
>IN  VOID*Context
>)
>  {
> -  EFI_HANDLEHandle[2];
> +  EFI_HANDLEHandle;
>UINTN BufferSize;
>EFI_STATUSStatus;
>EFI_I2C_MASTER_PROTOCOL   *I2cMaster;
> @@ -280,10 +280,10 @@ DriverRegistrationEvent (
>do {
>  BufferSize = sizeof (EFI_HANDLE);
>  Status = gBS->LocateHandle (ByRegisterNotify,
> -,
> -mDriverEventRegistration,
> +,
> +mI2cMasterEventRegistration,
>  ,
> -Handle);
> +);
>  if (EFI_ERROR (Status)) {
>if (Status != EFI_NOT_FOUND) {
>  DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n",
> @@ -292,12 +292,7 @@ DriverRegistrationEvent (
>break;
>  }
>  
> -//
> -// Check if we can connect our handle to this driver.
> -//
> -Handle[1] = NULL;
> -Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE);
> -if (EFI_ERROR (Status)) {
> +if (Handle != mI2cMasterHandle) {
>continue;
>  }
>  
> @@ -378,16 +373,16 @@ LibRtcInitialize (
>ASSERT_EFI_ERROR (Status);
>  
>//
> -  // Register a protocol registration notification callback on the driver
> -  // binding protocol so we can attempt to connect our I2C master to it
> -  // as soon as it appears.
> +  // Register a protocol registration notification callback on the I2C master
> +  // protocol. This will notify us even if the protocol instance we are 
> looking
> +  // for has already been installed.
>//
>EfiCreateProtocolNotifyEvent (
> -,
> +,
>  TPL_CALLBACK,
> -DriverRegistrationEvent,
> +I2cMasterRegistrationEvent,
>  NULL,
> -);
> +);
>  
>//
>// Register for the virtual address change event
> diff --git 
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf 
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> index 1a9a6f6c9cf3..e232902c6b5d 100644
> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> @@ -40,7 +40,6 @@ [Guids]
>gEfiEventVirtualAddressChangeGuid
>  
>  [Protocols]
> -  gEfiDriverBindingProtocolGuid   ## CONSUMES
>gEfiI2cMasterProtocolGuid   ## CONSUMES
>

Re: [edk2] [PATCH edk2-platforms 2/8] Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid

2018-01-25 Thread Leif Lindholm

On Thu, Jan 25, 2018 at 12:27:30PM +, Ard Biesheuvel wrote:
> Do a global replace of gPcf8563RealTimeClockLibI2cMasterProtolGuid with
> gPcf8563RealTimeClockLibI2cMasterProtocolGuid.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   | 2 
> +-
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec | 2 
> +-
>  Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 4 
> ++--
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c   | 2 
> +-
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 
> +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git 
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c 
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> index 67f8e7de4025..6bc4aef28849 100644
> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
> @@ -373,7 +373,7 @@ LibRtcInitialize (
>//
>BufferSize = sizeof (EFI_HANDLE);
>Status = gBS->LocateHandle (ByProtocol,
> -  , NULL,
> +  , NULL,
>, );
>ASSERT_EFI_ERROR (Status);
>  
> diff --git 
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec 
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
> index 3849056f164a..94c4a3f1ef4c 100644
> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
> @@ -22,7 +22,7 @@ [Guids]
>gPcf8563RealTimeClockLibTokenSpaceGuid = { 0xaaf5b169, 0x93a0, 0x4d60, { 
> 0xba, 0xe4, 0x06, 0x07, 0x92, 0x8e, 0x63, 0xdd }}
>  
>  [Protocols]
> -  gPcf8563RealTimeClockLibI2cMasterProtolGuid = { 0xa6af18ae, 0x3bd5, 
> 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }}
> +  gPcf8563RealTimeClockLibI2cMasterProtocolGuid = { 0xa6af18ae, 0x3bd5, 
> 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }}
>  
>  [PcdsFixedAtBuild]
>
> gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress|0x51|UINT8|0x0001
> diff --git 
> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf 
> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> index 9907e343ba78..1a9a6f6c9cf3 100644
> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
> @@ -42,11 +42,11 @@ [Guids]
>  [Protocols]
>gEfiDriverBindingProtocolGuid   ## CONSUMES
>gEfiI2cMasterProtocolGuid   ## CONSUMES
> -  gPcf8563RealTimeClockLibI2cMasterProtolGuid ## CONSUMES
> +  gPcf8563RealTimeClockLibI2cMasterProtocolGuid   ## CONSUMES
>  
>  [FixedPcd]
>gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress
>gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cBusFrequency
>  
>  [Depex]
> -  gPcf8563RealTimeClockLibI2cMasterProtolGuid
> +  gPcf8563RealTimeClockLibI2cMasterProtocolGuid
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> index 098a4dbd324e..91c1b66ea1f8 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
> @@ -183,7 +183,7 @@ PlatformDxeEntryPoint (
>// through the I2C driver stack (which cannot be used at runtime)
>//
>Status = gBS->InstallProtocolInterface (,
> -  ,
> +  ,
>EFI_NATIVE_INTERFACE, NULL);
>ASSERT_EFI_ERROR (Status);
>  
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> index 766f4041c826..4d6a1d637922 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
> @@ -53,7 +53,7 @@ [Guids]
>  [Protocols]
>gEdkiiNonDiscoverableDeviceProtocolGuid ## PRODUCES
>gEfiPciIoProtocolGuid   ## CONSUMES
> -  gPcf8563RealTimeClockLibI2cMasterProtolGuid ## PRODUCES
> +  gPcf8563RealTimeClockLibI2cMasterProtocolGuid   ## PRODUCES
>  
>  [FixedPcd]
>gSynQuacerTokenSpaceGuid.PcdNetsecEepromBase
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase

2018-01-25 Thread Laszlo Ersek

On 01/25/18 05:56, Bi, Dandan wrote:
> Hi Laszlo,
> 
> Thank you for your comments.
> 
> Yes. The PERF_INMODULE_START_ID macro is from "ExtendedFirmwarePerformance.h" 
> which is added in the new performance infrastructure patches([ mail subject: 
> patch 0/8] Update EDKII Performance infrastructure based on ACPI FPDT table). 
> That is the dependency I mean.
> 
> I will send V2 of this patch and the patch which remove Pref code after "new 
> performance infrastructure" patches have been committed . Then I will refine 
> the commit message of these two patches, add commit  hash value of "new 
> performance infrastructure" patches if I need to reference it. 

Thank you.

I had some other questions lower down, about the PERF_START_EX()
arguments. Can you please help me understand those better?

Thanks!
Laszlo

> 
> Thanks,
> Dandan
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Wednesday, January 24, 2018 11:45 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Gao, Liming 
> Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase
> 
> On 01/24/18 08:59, Dandan Bi wrote:
>> Add more perf entry to hook BootScriptDonePpi/EndOfPeiPpi/ 
>> EndOfS3Resume.
>>
>> Notes: This patch depends on the new performance infrastructure.
> 
> Since this statement is going into the commit log, please be more specific 
> about the "new performance infrastructure" (TianoCore BZ or commit hashes 
> etc).
> 
> Also, how is the dependency established? For example, OVMF uses 
> BasePerformanceLibNull; so I think it will see no changes.
> 
> Do you mean the PERF_INMODULE_START_ID macro, from 
> "ExtendedFirmwarePerformance.h"? Ah, that's not committed yet. In this case, 
> please add a reference to the mailing list message (subject and archive URL) 
> that adds it.
> 
> (Actually, the best solution is to reference the TianoCore BZ, and then add 
> the mailing list URL for each patch set submission to the TianoCore BZ.)
> 
>>
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Cc: Liming Gao 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Dandan Bi 
>> ---
>>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 15 
>> ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> index b597ac7..d7d2a4d 100644
>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
>> @@ -2,11 +2,11 @@
>>This module produces the EFI_PEI_S3_RESUME2_PPI.
>>This module works with StandAloneBootScriptExecutor to S3 resume to OS.
>>This module will execute the boot script saved during last boot and after 
>> that,
>>control is passed to OS waking up handler.
>>  
>> -  Copyright (c) 2006 - 2017, Intel Corporation. All rights 
>> reserved.
>> +  Copyright (c) 2006 - 2018, Intel Corporation. All rights 
>> + reserved.
>>Copyright (c) 2017, AMD Incorporated. All rights reserved.
>>  
>>This program and the accompanying materials
>>are licensed and made available under the terms and conditions
>>of the BSD License which accompanies this distribution.  The @@ 
>> -21,10 +21,11 @@  #include 
>>  
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -551,13 +552,17 @@ S3ResumeBootOs (
>>PERF_END (NULL, "ScriptExec", NULL, 0);
>>  
>>//
>>// Install BootScriptDonePpi
>>//
>> +  PERF_START_EX (NULL, "BootScriptDonePpi", NULL, 0, 
>> + PERF_INMODULE_START_ID);
>> +
> 
> My question here is not really specific to this patch, but I guess asking it 
> this time is just as good as any other time:
> 
> - Why do we pass NULL for Module, rather than gEfiCallerBaseName?
> 
> - We already have START and END calls for the performance measurement; why do 
> we use different Identifier values for the records added?
> 
> (These questions are more for my education than about possible issues in the 
> patch.)
> 
> Thanks!
> Laszlo
> 
> 
>>Status = PeiServicesInstallPpi ();
>>ASSERT_EFI_ERROR (Status);
>>  
>> +  PERF_END_EX (NULL, "BootScriptDonePpi", NULL, 0, 
>> + PERF_INMODULE_END_ID);
>> +
>>//
>>// Get ACPI Table Address
>>//
>>Facs = (EFI_ACPI_4_0_FIRMWARE_ACPI_CONTROL_STRUCTURE *) ((UINTN) 
>> (AcpiS3Context->AcpiFacsTable));
>>  
>> @@ -576,18 +581,26 @@ S3ResumeBootOs (
>>}
>>  
>>//
>>// Install EndOfPeiPpi
>>//
>> +  PERF_START_EX (NULL, "EndOfPeiPpi", NULL, 0, 
>> + PERF_INMODULE_START_ID);
>> +
>>Status = PeiServicesInstallPpi ();
>>ASSERT_EFI_ERROR (Status);
>>  
>> +  PERF_END_EX (NULL, "EndOfPeiPpi", NULL, 0, PERF_INMODULE_END_ID);
>> +
>>//
>>// Signal

Re: [edk2] setting the TLS cipher list for HTTPS booting

2018-01-25 Thread Laszlo Ersek

On 01/25/18 05:52, Wu, Jiaxin wrote:
> Hi Laszlo,
> 
> The HttpDxe driver needs to install the Driver Binding Protocol so as
> to check if a specific controller is supported by HttpDxe. HttpDxe
> can only be started if the TcpServiceBindingProtocol existed. So, it
> has to follow the UEFI Driver Model.
> 
> For the PCD usage, I think it should be fine to cover the
> configuration of UEFI Drivers through the PCD settings. The
> requirement of *.inf needs to include the PcdLib and the section of
> [Pcd]. We already have the similar pattern for this usage, for
> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
> MdeModulePkg. Besides, there are some advantages by using PCD
> compared to the variable. First, PCD is one kind of interface that
> more formal than a private variable, the setting by PCD is more
> acceptable by the consumer. Secondly, from a *security* standpoint,
> variable can be dumped easily from the flash region. Here, even
> though it's no security impact towards the cipher list storage
> because it will be public shared to remote server, but we need to
> think and *align* with other configurations for TLS in HTTPS level.
> For example, in the future, we might support the HTTPS mutual
> authentication, than the host PrivateKey/Password
> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
> due to its confidentiality, while PCD is good choice. At that time,
> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
> which is currently setting by the variable (TlsCaCertificate), so as
> to align all the configuration setting on one line, which can reduce
> the complexity of platform usage. Finally, we can also save the
> variable space.
> 
> From the above, the dynamic PCD is a solution I still preferred.

OK, it works for me. Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/DeviceTree: align uart DT nodes

2018-01-25 Thread Ard Biesheuvel

Align the UART DT nodes:
- use 'uart' not 'fuart' as node name for the second serial port
- create an alias 'serial1' for the second serial port
- use UART clock reference instead of hardcoded frequency
- split 'clocks' property into 1 cell per phandle

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
index 37a3981f0360..7c3518facb98 100644
--- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
+++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
@@ -32,6 +32,7 @@
 
 aliases {
 serial0 = _uart0;
+serial1 = 
 };
 
 chosen {
@@ -436,15 +437,16 @@
 compatible = "arm,pl011", "arm,primecell";
 reg = <0x0 0x2a40 0x0 0x1000>;
 interrupts = ;
-clocks = <_uart _apb>;
+clocks = <_uart>, <_apb>;
 clock-names = "uartclk", "apb_pclk";
 };
 
-fuart: fuart@5104 {
+fuart: uart@5104 {
 compatible = "snps,dw-apb-uart";
 reg = <0x0 0x5104 0x0 0x1000>;
 interrupts = ;
-clock-frequency = <6250>;
+clocks = <_uart>, <_apb>;
+clock-names = "baudclk", "apb_pclk";
 reg-io-width = <4>;
 reg-shift = <2>;
 };
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 4/8] Silicon/SynQuacerI2cDxe: remove spurious format specifier

2018-01-25 Thread Ard Biesheuvel

Remove a %r without an associated parameter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c 
b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
index c3703dfb6c33..46c512a20151 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c
@@ -335,7 +335,7 @@ SynQuacerI2cStartRequest (
 }
 
 if (MmioRead8 (I2c->MmioBase + F_I2C_REG_BSR) & F_I2C_BSR_LRB) {
-  BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received - %r\n", 
__FUNCTION__));
+  BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received\n", __FUNCTION__));
   Status = EFI_DEVICE_ERROR;
   break;
 }
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding

2018-01-25 Thread Ard Biesheuvel

The upstream version of the Linux NETSEC driver expects the PHY DT
node to appear under a MDIO subnode, so fix this in the device tree.
Fix the node name as well, this should be 'ethernet' not 'netsec',
and add a clock-names property describing the single clock reference
as 'phy_ref_clk'.

Also, move the PHY subnode into the per-platform .dts file so we can
set the unit address in the node name. This is necessary because recent
versions of the DT compiler are more finicky about this.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts   |  7 +
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 
+---
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts |  7 +
 3 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts 
b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
index d2cd7ef90e6f..488c51a0f793 100644
--- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
+++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
@@ -44,3 +44,10 @@
   "GPIO-K", "GPIO-L", "PEC-PD26", "PEC-PD27",
   "PEC-PD28",   "PEC-PD29",   "PEC-PD30", "PEC-PD31";
 };
+
+_netsec {
+phy_netsec: ethernet-phy@7 {
+compatible = "ethernet-phy-ieee802.3-c22";
+reg = <7>;
+};
+};
diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi 
b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
index 7c3518facb98..6ee7a0b7ccb4 100644
--- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
+++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi
@@ -457,25 +457,23 @@
 #clock-cells = <0>;
 };
 
-eth0: netsec@522D {
-compatible = "socionext,synquacer-netsec";
-reg = <0 0x522d 0x0 0x1>,
-  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
-interrupts = ;
-clocks = <_netsec>;
-phy-mode = "rgmii";
-max-speed = <1000>;
-max-frame-size = <9000>;
-phy-handle = <>;
-dma-coherent;
+ethernet@522d {
+compatible = "socionext,synquacer-netsec";
+reg = <0 0x522d 0x0 0x1>,
+  <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>;
+interrupts = ;
+clocks = <_netsec>;
+clock-names = "phy_ref_clk";
+phy-mode = "rgmii";
+max-speed = <1000>;
+max-frame-size = <9000>;
+phy-handle = <_netsec>;
+dma-coherent;
 
+mdio_netsec: mdio {
 #address-cells = <1>;
 #size-cells = <0>;
-
-ethphy0: ethernet-phy {
-compatible = "ethernet-phy-ieee802.3-c22";
-reg = ;
-};
+};
 };
 
 smmu: iommu@582c {
diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts 
b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
index 132fd370a71b..97fddfedcb46 100644
--- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
+++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts
@@ -34,3 +34,10 @@
  {
 status = "okay";
 };
+
+_netsec {
+phy_netsec: ethernet-phy@1 {
+compatible = "ethernet-phy-ieee802.3-c22";
+reg = <1>;
+};
+};
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 2/8] Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid

2018-01-25 Thread Ard Biesheuvel

Do a global replace of gPcf8563RealTimeClockLibI2cMasterProtolGuid with
gPcf8563RealTimeClockLibI2cMasterProtocolGuid.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   | 2 +-
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec | 2 +-
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 4 
++--
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c   | 2 +-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c 
b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
index 67f8e7de4025..6bc4aef28849 100644
--- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
+++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
@@ -373,7 +373,7 @@ LibRtcInitialize (
   //
   BufferSize = sizeof (EFI_HANDLE);
   Status = gBS->LocateHandle (ByProtocol,
-  , NULL,
+  , NULL,
   , );
   ASSERT_EFI_ERROR (Status);
 
diff --git 
a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec 
b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
index 3849056f164a..94c4a3f1ef4c 100644
--- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
+++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
@@ -22,7 +22,7 @@ [Guids]
   gPcf8563RealTimeClockLibTokenSpaceGuid = { 0xaaf5b169, 0x93a0, 0x4d60, { 
0xba, 0xe4, 0x06, 0x07, 0x92, 0x8e, 0x63, 0xdd }}
 
 [Protocols]
-  gPcf8563RealTimeClockLibI2cMasterProtolGuid = { 0xa6af18ae, 0x3bd5, 0x4af9, 
{ 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }}
+  gPcf8563RealTimeClockLibI2cMasterProtocolGuid = { 0xa6af18ae, 0x3bd5, 
0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }}
 
 [PcdsFixedAtBuild]
   
gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress|0x51|UINT8|0x0001
diff --git 
a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf 
b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
index 9907e343ba78..1a9a6f6c9cf3 100644
--- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
+++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
@@ -42,11 +42,11 @@ [Guids]
 [Protocols]
   gEfiDriverBindingProtocolGuid   ## CONSUMES
   gEfiI2cMasterProtocolGuid   ## CONSUMES
-  gPcf8563RealTimeClockLibI2cMasterProtolGuid ## CONSUMES
+  gPcf8563RealTimeClockLibI2cMasterProtocolGuid   ## CONSUMES
 
 [FixedPcd]
   gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress
   gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cBusFrequency
 
 [Depex]
-  gPcf8563RealTimeClockLibI2cMasterProtolGuid
+  gPcf8563RealTimeClockLibI2cMasterProtocolGuid
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
index 098a4dbd324e..91c1b66ea1f8 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
@@ -183,7 +183,7 @@ PlatformDxeEntryPoint (
   // through the I2C driver stack (which cannot be used at runtime)
   //
   Status = gBS->InstallProtocolInterface (,
-  ,
+  ,
   EFI_NATIVE_INTERFACE, NULL);
   ASSERT_EFI_ERROR (Status);
 
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
index 766f4041c826..4d6a1d637922 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
@@ -53,7 +53,7 @@ [Guids]
 [Protocols]
   gEdkiiNonDiscoverableDeviceProtocolGuid ## PRODUCES
   gEfiPciIoProtocolGuid   ## CONSUMES
-  gPcf8563RealTimeClockLibI2cMasterProtolGuid ## PRODUCES
+  gPcf8563RealTimeClockLibI2cMasterProtocolGuid   ## PRODUCES
 
 [FixedPcd]
   gSynQuacerTokenSpaceGuid.PcdNetsecEepromBase
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 0/8] Socionext SynQuacer updates

2018-01-25 Thread Ard Biesheuvel

Some stuff I have collected over the past 2 months or so. Note that this
includes the SATA spread spectrum patch I sent out yesterday: I had forgotten
all about this backlog, and I only remembered when attempting to apply it to
the master branch.

Ard Biesheuvel (8):
  Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061
SATA
  Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid
  Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol
  Silicon/SynQuacerI2cDxe: remove spurious format specifier
  Silicon/SynQuacer: load I2C driver before platform DXE driver
  Silicon/SynQuacer/DeviceTree: align uart DT nodes
  Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding
  Silicon/Socionext/SynQuacer: implement menu option to set max PCIe
speed

 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   
  |   2 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   
  |   2 +
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c  
  |  33 +++---
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec
  |   2 +-
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
  |   5 +-
 Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts
  |   7 ++
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi  
  |  38 +++
 Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts  
  |   7 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => Pci.c}   
  |  85 +++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c  
  | 109 +++-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h  
  |  12 +++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
  |  17 ++-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni 
  |  28 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
  |  61 +++
 Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c  
  |   2 +-
 Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
  |   2 +-
 Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h
  |  23 +
 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
  |  28 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
  |   2 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
 |  25 -
 Silicon/Socionext/SynQuacer/SynQuacer.dec  
  |   7 ++
 21 files changed, 424 insertions(+), 73 deletions(-)
 rename Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => 
Pci.c} (63%)
 create mode 100644 
Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni
 create mode 100644 
Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
 create mode 100644 
Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h
 create mode 100644 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h

-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms 8/8] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed

2018-01-25 Thread Ard Biesheuvel

Add menu options to the SynQuacer Platform menu screen to limit the
maximum PCIe link speed for each RC individually. This may be useful
to work around potential PCIe issues.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc   
  |   2 +
 Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   
  |   2 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c  
  |   4 +-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c  
  | 107 
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h  
  |  12 +++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf
  |  11 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni 
  |  28 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
  |  61 +++
 Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h
  |  23 +
 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
  |  28 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
  |   2 +
 
Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
 |  25 -
 Silicon/Socionext/SynQuacer/SynQuacer.dec  
  |   5 +
 13 files changed, 304 insertions(+), 6 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 86685d1dec3b..2d46b4515749 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
index b4b9239143bc..263b6454ff72 100644
--- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
+++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
@@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT]
 [PcdsDynamicHii]
   
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30
 
+  
gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS
+
 [PcdsDynamicDefault]
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
index 9af3dd942cdd..2a0fefbd423f 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
@@ -160,7 +160,9 @@ OnPciIoProtocolNotify (
   // 2-port sibling of which samples were used in development) needs a
   // little nudge to get it to train the downstream links at Gen2 speed.
   //
-  RetrainAsm1184eDownstreamPort (PciIo);
+  if (mHiiSettings->Pcie0MaxSpeed != PCIE_MAX_SPEED_GEN1) {
+RetrainAsm1184eDownstreamPort (PciIo);
+  }
   break;
 }
   }
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
index 91c1b66ea1f8..b60607d05861 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
@@ -14,6 +14,36 @@
 
 #include "PlatformDxe.h"
 
+UINT64mHiiSettingsVal;
+SYNQUACER_PLATFORM_VARSTORE_DATA  *mHiiSettings;
+
+typedef struct {
+  VENDOR_DEVICE_PATH  VendorDevicePath;
+  EFI_DEVICE_PATH_PROTOCOLEnd;
+} HII_VENDOR_DEVICE_PATH;
+
+STATIC HII_VENDOR_DEVICE_PATH mPlatformDxeHiiVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+SYNQUACER_PLATFORM_FORMSET_GUID
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{
+  (UINT8)

[edk2] [PATCH edk2-platforms 1/8] Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061 SATA

2018-01-25 Thread Ard Biesheuvel

The ASM1061 SATA controller integrated into the DeveloperBox board
emits too much electromagnetic radiation, so it needs spread spectrum
mode enabled.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 
---
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => Pci.c} | 83 
+++-
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf  |  2 
+-
 2 files changed, 64 insertions(+), 21 deletions(-)

diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
similarity index 64%
rename from Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c
rename to Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
index 874e83a649b5..9af3dd942cdd 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c
@@ -15,9 +15,12 @@
 #include "PlatformDxe.h"
 
 #define ASMEDIA_VID 0x1b21
+#define ASM1061_PID 0x0612
 #define ASM1182E_PID0x1182
 #define ASM1184E_PID0x1184
 
+#define ASM1061_SSC_OFFSET  0xA10
+
 #define ASM118x_PCIE_CAPABILITY_OFFSET  0x80
 #define ASM118x_PCIE_LINK_CONTROL_OFFSET(ASM118x_PCIE_CAPABILITY_OFFSET + \
  OFFSET_OF (PCI_CAPABILITY_PCIEXP, 
\
@@ -39,24 +42,10 @@ RetrainAsm1184eDownstreamPort (
   IN  EFI_PCI_IO_PROTOCOL   *PciIo
   )
 {
-  UINT16PciVidPid[2];
   EFI_STATUSStatus;
   PCIE_CAP  Cap;
   PCI_REG_PCIE_LINK_CONTROL LinkControl;
 
-  Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET,
-ARRAY_SIZE (PciVidPid), );
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_WARN, "%a: failed to read PCI vendor/product ID - %r\n",
-  __FUNCTION__, Status));
-return;
-  }
-
-  if (PciVidPid[0] != ASMEDIA_VID ||
-  (PciVidPid[1] != ASM1182E_PID && PciVidPid[1] != ASM1184E_PID)) {
-return;
-  }
-
   //
   // The upstream and downstream ports share the same PID/VID, so check
   // the port type. This assumes the PCIe Express capability block lives
@@ -91,6 +80,34 @@ RetrainAsm1184eDownstreamPort (
 
 STATIC
 VOID
+EnableAsm1061SpreadSpectrum (
+  IN  EFI_PCI_IO_PROTOCOL   *PciIo
+  )
+{
+  EFI_STATUS  Status;
+  UINT8   SscVal;
+
+  DEBUG ((DEBUG_INFO, "%a: enabling spread spectrum mode 0 for ASM1061\n",
+__FUNCTION__));
+
+  // SSC mode 0~-4000 ppm, 1:1 modulation
+
+  SscVal = 0;
+  Status = PciIo->Pci.Write (PciIo, EfiPciIoWidthUint8, ASM1061_SSC_OFFSET, 1,
+);
+  ASSERT_EFI_ERROR (Status);
+
+  MemoryFence ();
+  gBS->Stall (1); // delay at least 100 ns between writes of the same register
+
+  SscVal = 1;
+  Status = PciIo->Pci.Write (PciIo, EfiPciIoWidthUint8, ASM1061_SSC_OFFSET, 1,
+);
+  ASSERT_EFI_ERROR (Status);
+}
+
+STATIC
+VOID
 EFIAPI
 OnPciIoProtocolNotify (
   IN EFI_EVENT  Event,
@@ -101,6 +118,7 @@ OnPciIoProtocolNotify (
   EFI_STATUSStatus;
   EFI_HANDLEHandleBuffer;
   UINTN BufferSize;
+  UINT16PciVidPid[2];
 
   while (TRUE) {
 BufferSize = sizeof (EFI_HANDLE);
@@ -114,12 +132,37 @@ OnPciIoProtocolNotify (
 (VOID **));
 ASSERT_EFI_ERROR (Status);
 
-//
-// The ASM1184E 4-port PCIe switch on the DeveloperBox board (and its
-// 2-port sibling of which samples were used in development) needs a
-// little nudge to get it to train the downstream links at Gen2 speed.
-//
-RetrainAsm1184eDownstreamPort (PciIo);
+Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET,
+  ARRAY_SIZE (PciVidPid), );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_WARN, "%a: failed to read PCI vendor/product ID - %r\n",
+__FUNCTION__, Status));
+  continue;
+}
+
+if (PciVidPid[0] != ASMEDIA_VID) {
+  continue;
+}
+
+switch (PciVidPid[1]) {
+case ASM1061_PID:
+  //
+  // The ASM1061 SATA controller as integrated into the DeveloperBox design
+  // emits too much electromagnetic radiation. So enable spread spectrum
+  // mode.
+  //
+  EnableAsm1061SpreadSpectrum (PciIo);
+  break;
+case ASM1182E_PID:
+case ASM1184E_PID:
+  //
+  // The ASM1184E 4-port PCIe switch on the DeveloperBox board (and its
+  // 2-port sibling of which samples were used in development) needs a
+  // little nudge to get it to train the downstream links at Gen2 speed.
+  //
+  RetrainAsm1184eDownstreamPort (PciIo);
+  break;
+}
   }
 }
 
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf

[edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol

2018-01-25 Thread Ard Biesheuvel

Instead of registering a notification callback on the driver binding
protocol, and attempting to connect our I2C master handle each time
a new driver is registered, switch to the more obvious approach of
registering a notification callback on the I2C master protocol directly.

The original code was written under the assumption that it would make
the RTC available at an earlier time, but given that all handles that
are created during the execution of a driver entry point are connected
by DXE core right away (i.e., before StartImage() returns), this is not
really necessary, and in fact, may result in the driver already having
been connected by the time we attempt to connect it.

Note that it is now up to the platform to ensure that ConnectController()
is called for the handle if DXE core does not call it by itself, or does
call it but at a time when no I2C master protocol driver is available
yet.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c   | 31 

 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf |  1 -
 2 files changed, 13 insertions(+), 19 deletions(-)

diff --git 
a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c 
b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
index 6bc4aef28849..fb58e1feb424 100644
--- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
+++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c
@@ -41,7 +41,7 @@
 #define EPOCH_BASE2000
 
 STATIC EFI_HANDLE mI2cMasterHandle;
-STATIC VOID   *mDriverEventRegistration;
+STATIC VOID   *mI2cMasterEventRegistration;
 STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
 STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
 
@@ -263,12 +263,12 @@ LibSetWakeupTime (
 
 STATIC
 VOID
-DriverRegistrationEvent (
+I2cMasterRegistrationEvent (
   IN  EFI_EVENT   Event,
   IN  VOID*Context
   )
 {
-  EFI_HANDLEHandle[2];
+  EFI_HANDLEHandle;
   UINTN BufferSize;
   EFI_STATUSStatus;
   EFI_I2C_MASTER_PROTOCOL   *I2cMaster;
@@ -280,10 +280,10 @@ DriverRegistrationEvent (
   do {
 BufferSize = sizeof (EFI_HANDLE);
 Status = gBS->LocateHandle (ByRegisterNotify,
-,
-mDriverEventRegistration,
+,
+mI2cMasterEventRegistration,
 ,
-Handle);
+);
 if (EFI_ERROR (Status)) {
   if (Status != EFI_NOT_FOUND) {
 DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n",
@@ -292,12 +292,7 @@ DriverRegistrationEvent (
   break;
 }
 
-//
-// Check if we can connect our handle to this driver.
-//
-Handle[1] = NULL;
-Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE);
-if (EFI_ERROR (Status)) {
+if (Handle != mI2cMasterHandle) {
   continue;
 }
 
@@ -378,16 +373,16 @@ LibRtcInitialize (
   ASSERT_EFI_ERROR (Status);
 
   //
-  // Register a protocol registration notification callback on the driver
-  // binding protocol so we can attempt to connect our I2C master to it
-  // as soon as it appears.
+  // Register a protocol registration notification callback on the I2C master
+  // protocol. This will notify us even if the protocol instance we are looking
+  // for has already been installed.
   //
   EfiCreateProtocolNotifyEvent (
-,
+,
 TPL_CALLBACK,
-DriverRegistrationEvent,
+I2cMasterRegistrationEvent,
 NULL,
-);
+);
 
   //
   // Register for the virtual address change event
diff --git 
a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf 
b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
index 1a9a6f6c9cf3..e232902c6b5d 100644
--- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
+++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf
@@ -40,7 +40,6 @@ [Guids]
   gEfiEventVirtualAddressChangeGuid
 
 [Protocols]
-  gEfiDriverBindingProtocolGuid   ## CONSUMES
   gEfiI2cMasterProtocolGuid   ## CONSUMES
   gPcf8563RealTimeClockLibI2cMasterProtocolGuid   ## CONSUMES
 
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 0/6] Add ARM support for VS2017

2018-01-25 Thread Pete Batard


Thanks Liming.

From the way you framed your comment, I'm not completely sure if 
there's action still needed on my side...


Do I actually need to resubmit a patch set with "Reviewed By"?
Or, now that each patch should have flagged as reviewed, are we simply 
supposed to wait for formal integration?


Regards,

/Pete

On 2018.01.25 10:27, Gao, Liming wrote:

Pete:
   The changes in BaseTools and MdePkg are good to me. You can add my R-B.


-Original Message-
From: Pete Batard [mailto:p...@akeo.ie]
Sent: Friday, January 12, 2018 9:33 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; ard.biesheu...@linaro.org;
eug...@hp.com
Subject: [PATCH v5 0/6] Add ARM support for VS2017

(Same as v4, except for the AREA names where we replaced the RVCT macros,
in
patch 4/6, so that it matches what would have been produced with the
macros)


The following series adds ARM compilation support for the VS2017 toolchain.
* PATCH 1 targets the disabling of VS Level 4 warnings. The disabled warnings
  for ARM are now aligned with IA32 and X64.
* PATCH 2 adds a NULL handler for the base stack check, since this is a GCC
  functionality.
* PATCH 3 updates MdePkg/Library/BaseLib so that the RVCT assembly
sources
  are also used for MSFT.
* PATCH 4 adds the required compiler intrinsics replacements for division,
  shift, by reusing the RVCT code, as well as memset/memcpy.
* PATCH 5 adds variable argument handlers for print output. Note that this
  is done without relying on any external headers, with the VA_ARG macro
  having been reverse engineered from MSFT ARM assembly output.
* PATCH 6 enables the selection of ARM in the conf templates.

With these patches, VS2017 toolchain users should be able to compile
regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support,
ARM support does not require a specific update of Visual Studio 2017, as
the ARM toolchain has been available from the very first release.

Additional notes:

We tested compiling and running the full UEFI Shell with this series, as
well as a small set of applications and drivers, and found no issues.
With an additional patch [1], it is also possible to use this proposal to
compile a complete QEMU ARM firmware. As the patch shows, the changes
that
need to be applied to the EDK2 sources to achieve this are actually very
minimal.

However, the generated firmware does not currently boot, possibly because
of the following warnings being generated by the MS compiler:
- ArmCpuDxe.dll : warning LNK4072: section count 118 exceeds max (96);
image may not run
- UiApp.dll : warning LNK4072: section count 113 exceeds max (96); image may
not run

As far as I could see, the section count max is hardcoded so a workaround
would be needed to address those.

Also, because the VS2017 ARM compiler forces a section alignment of 4096
bytes (which in turn forces use to use /FILEALIGN:4096 as a linker option
for the firmware generation), the generated firmware exceeds 2MB and we
had to double its size to 4MB.

At this stage, since the goal of this series is to allow users to compile
regular ARM UEFI applications using the VS2017 toolchain, I have no plans
to spend more time on the QEMU firmware issues, especially as I suspect
that reducing the firmware size back to 2 MB may not be achievable without
Microsoft altering their compiler. I am however hopeful that ARM
specialists can take this matter over eventually...

Regards,

/Pete

[1]
https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a906048
13f037b13

Pete Batard (6):
  MdePkg: Disable some Level 4 warnings for VS2017/ARM
  MdePkg/Library/BaseStackCheckLib: Add Null handler for VS2017/ARM
  MdePkg/Library/BaseLib: Enable VS2017/ARM builds
  ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds
  MdePkg/Include: Add VA list support for VS2017/ARM
  BaseTools/Conf: Add VS2017/ARM support

ArmPkg/Library/CompilerIntrinsicsLib/Arm/div.asm   | 43 +++--
ArmPkg/Library/CompilerIntrinsicsLib/Arm/ldivmod.asm   | 40 ++--
ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm  | 22 +++--
ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm | 29 +-
ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf | 16 +++-
ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c   | 34 +++
ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c   | 33 +++
BaseTools/Conf/build_rule.template | 31 ++-
BaseTools/Conf/tools_def.template  | 31 +++
MdePkg/Include/Arm/ProcessorBind.h | 96
+++-
MdePkg/Include/Base.h  | 13 +++
MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm   |  5 +-
MdePkg/Library/BaseLib/BaseLib.inf | 16 +++-
MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf |  5 +-

Re: [edk2] [PATCH] MdeModulePkg/Partition: Fix media probe

2018-01-25 Thread Wang, Jian J

Tested-by/Reviewed-by: Jian J Wang 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, January 25, 2018 5:45 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J 
> Subject: [PATCH] MdeModulePkg/Partition: Fix media probe
> 
> The call in ProbeMediaStatusEx() to the ReadDisk() function of the
> EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c
> crashed in DiskIo2ReadWriteDisk() because of the NULL value of
> the destination buffer pointer.
> 
> Pass the address of a buffer in the stack instead of a NULL
> pointer.
> 
> The similar fix was applied to ProbeMediaStatus in commit
> df473cc1fc9acd1a623ec7e05276f2f0635c19d2
> * MdeModulePkg/PartitionDxe: Fix media probe
> 
> Somehow ProbeMediaStatusEx() wasn't changed together.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jian J Wang 
> ---
>  MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> index bb9d0b70ce..46c0877cee 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> @@ -4,7 +4,7 @@
>of the raw block devices media. Currently "El Torito CD-ROM", UDF, Legacy
>MBR, and GPT partition schemes are supported.
> 
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -777,11 +777,15 @@ ProbeMediaStatusEx (
>)
>  {
>EFI_STATUS Status;
> +  UINT8  Buffer[1];
> 
>//
> -  // Read 1 byte from offset 0 but passing NULL as buffer pointer
> +  // Read 1 byte from offset 0 to check if the MediaId is still valid.
> +  // The reading operation is synchronious thus it is not worth it to
> +  // allocate a buffer from the pool. The destination buffer for the
> +  // data is in the stack.
>//
> -  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, NULL);
> +  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, (VOID*)Buffer);
>if ((Status == EFI_NO_MEDIA) || (Status == EFI_MEDIA_CHANGED)) {
>  return Status;
>}
> --
> 2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v5 0/6] Add ARM support for VS2017

2018-01-25 Thread Gao, Liming

Pete:
  The changes in BaseTools and MdePkg are good to me. You can add my R-B.

>-Original Message-
>From: Pete Batard [mailto:p...@akeo.ie]
>Sent: Friday, January 12, 2018 9:33 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; ard.biesheu...@linaro.org;
>eug...@hp.com
>Subject: [PATCH v5 0/6] Add ARM support for VS2017
>
>(Same as v4, except for the AREA names where we replaced the RVCT macros,
>in
>patch 4/6, so that it matches what would have been produced with the
>macros)
>
>
>The following series adds ARM compilation support for the VS2017 toolchain.
>* PATCH 1 targets the disabling of VS Level 4 warnings. The disabled warnings
>  for ARM are now aligned with IA32 and X64.
>* PATCH 2 adds a NULL handler for the base stack check, since this is a GCC
>  functionality.
>* PATCH 3 updates MdePkg/Library/BaseLib so that the RVCT assembly
>sources
>  are also used for MSFT.
>* PATCH 4 adds the required compiler intrinsics replacements for division,
>  shift, by reusing the RVCT code, as well as memset/memcpy.
>* PATCH 5 adds variable argument handlers for print output. Note that this
>  is done without relying on any external headers, with the VA_ARG macro
>  having been reverse engineered from MSFT ARM assembly output.
>* PATCH 6 enables the selection of ARM in the conf templates.
>
>With these patches, VS2017 toolchain users should be able to compile
>regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support,
>ARM support does not require a specific update of Visual Studio 2017, as
>the ARM toolchain has been available from the very first release.
>
>Additional notes:
>
>We tested compiling and running the full UEFI Shell with this series, as
>well as a small set of applications and drivers, and found no issues.
>With an additional patch [1], it is also possible to use this proposal to
>compile a complete QEMU ARM firmware. As the patch shows, the changes
>that
>need to be applied to the EDK2 sources to achieve this are actually very
>minimal.
>
>However, the generated firmware does not currently boot, possibly because
>of the following warnings being generated by the MS compiler:
>- ArmCpuDxe.dll : warning LNK4072: section count 118 exceeds max (96);
>image may not run
>- UiApp.dll : warning LNK4072: section count 113 exceeds max (96); image may
>not run
>
>As far as I could see, the section count max is hardcoded so a workaround
>would be needed to address those.
>
>Also, because the VS2017 ARM compiler forces a section alignment of 4096
>bytes (which in turn forces use to use /FILEALIGN:4096 as a linker option
>for the firmware generation), the generated firmware exceeds 2MB and we
>had to double its size to 4MB.
>
>At this stage, since the goal of this series is to allow users to compile
>regular ARM UEFI applications using the VS2017 toolchain, I have no plans
>to spend more time on the QEMU firmware issues, especially as I suspect
>that reducing the firmware size back to 2 MB may not be achievable without
>Microsoft altering their compiler. I am however hopeful that ARM
>specialists can take this matter over eventually...
>
>Regards,
>
>/Pete
>
>[1]
>https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a906048
>13f037b13
>
>Pete Batard (6):
>  MdePkg: Disable some Level 4 warnings for VS2017/ARM
>  MdePkg/Library/BaseStackCheckLib: Add Null handler for VS2017/ARM
>  MdePkg/Library/BaseLib: Enable VS2017/ARM builds
>  ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds
>  MdePkg/Include: Add VA list support for VS2017/ARM
>  BaseTools/Conf: Add VS2017/ARM support
>
> ArmPkg/Library/CompilerIntrinsicsLib/Arm/div.asm   | 43 +++--
> ArmPkg/Library/CompilerIntrinsicsLib/Arm/ldivmod.asm   | 40 ++--
> ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm  | 22 +++--
> ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm | 29 +-
> ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf | 16 +++-
> ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c   | 34 +++
> ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c   | 33 +++
> BaseTools/Conf/build_rule.template | 31 ++-
> BaseTools/Conf/tools_def.template  | 31 +++
> MdePkg/Include/Arm/ProcessorBind.h | 96
>+++-
> MdePkg/Include/Base.h  | 13 +++
> MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm   |  5 +-
> MdePkg/Library/BaseLib/BaseLib.inf | 16 +++-
> MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf |  5 +-
> MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c  | 18 
> 15 files changed, 372 insertions(+), 60 deletions(-)
> create mode 100644 ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c
> create mode 100644 ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c
> create mode 100644

Re: [edk2] [Patch] BaseTool: Fixed the StructurePcd incorrect value.

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Thursday, January 25, 2018 3:42 PM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch] BaseTool: Fixed the StructurePcd incorrect value.
>
>If user not set Structure overall value in Dsc,
>Structure Pcd value would be incorrect.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/Workspace/BuildClassObject.py | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>index e5f1f01556..947ac1f466 100644
>--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>@@ -65,11 +65,11 @@ class PcdClassObject(object):
> self.validlists = validlists
> self.expressions = expressions
> self.DscDefaultValue = None
> if IsDsc:
> self.DscDefaultValue = Value
>-
>+
> ## Convert the class to a string
> #
> #  Convert each member of the class to string
> #  Organize to a signle line format string
> #
>@@ -107,11 +107,15 @@ class PcdClassObject(object):
> #
> def __hash__(self):
> return hash((self.TokenCName, self.TokenSpaceGuidCName))
>
> class StructurePcd(PcdClassObject):
>-def __init__(self, StructuredPcdIncludeFile="", Packages=None,
>Name=None, Guid=None, Type=None, DatumType=None, Value=None,
>Token=None, MaxDatumSize=None, SkuInfoList={}, IsOverrided=False,
>GuidValue=None, validateranges=[], validlists=[],
>expressions=[],default_store = TAB_DEFAULT_STORES_DEFAULT):
>+def __init__(self, StructuredPcdIncludeFile=None, Packages=None,
>Name=None, Guid=None, Type=None, DatumType=None, Value=None,
>Token=None, MaxDatumSize=None, SkuInfoList=None, IsOverrided=False,
>GuidValue=None, validateranges=None, validlists=None,
>expressions=None,default_store = TAB_DEFAULT_STORES_DEFAULT):
>+if SkuInfoList is None: SkuInfoList={}
>+if validateranges is None: validateranges=[]
>+if validlists is None: validlists=[]
>+if expressions is None : expressions=[]
> super(StructurePcd, self).__init__(Name, Guid, Type, DatumType, Value,
>Token, MaxDatumSize, SkuInfoList, IsOverrided, GuidValue, validateranges,
>validlists, expressions)
> self.StructuredPcdIncludeFile = StructuredPcdIncludeFile
> self.PackageDecs = Packages
> self.DefaultStoreName = [default_store]
> self.DefaultValues = collections.OrderedDict({})
>@@ -435,6 +439,5 @@ class PlatformBuildClassObject(object):
> #
> # @retval string Key for hash table
> #
> def __hash__(self):
> return hash(self.MetaFile)
>-
>--
>2.14.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fixed incorrect VPD size.

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>BobCF
>Sent: Tuesday, January 23, 2018 4:01 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Fixed incorrect VPD size.
>
>The VPD size is incorrect if that VPD is not used in Module.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Feng Bob C 
>Reviewed-by: Liming Gao 
>---
> BaseTools/Source/Python/AutoGen/AutoGen.py | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>b/BaseTools/Source/Python/AutoGen/AutoGen.py
>index ce8bc64ca5..848378f3d4 100644
>--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>@@ -1744,18 +1744,16 @@ class PlatformAutoGen(AutoGen):
>
> # Not found, it should be signature
> if not FoundFlag :
> # just pick the a value to determine whether is 
> unicode string
>type
> SkuValueMap = {}
>+SkuObjList = DscPcdEntry.SkuInfoList.items()
> DefaultSku = 
> DscPcdEntry.SkuInfoList.get('DEFAULT')
> if DefaultSku:
>-PcdValue = DefaultSku.DefaultValue
>-if PcdValue not in SkuValueMap:
>-SkuValueMap[PcdValue] = []
>-VpdFile.Add(DscPcdEntry, 
>'DEFAULT',DefaultSku.VpdOffset)
>-SkuValueMap[PcdValue].append(DefaultSku)
>-for (SkuName,Sku) in 
>DscPcdEntry.SkuInfoList.items():
>+defaultindex = 
>SkuObjList.index(('DEFAULT',DefaultSku))
>+SkuObjList[0],SkuObjList[defaultindex] =
>SkuObjList[defaultindex],SkuObjList[0]
>+for (SkuName,Sku) in SkuObjList:
> Sku.VpdOffset = Sku.VpdOffset.strip()
>
> # Need to iterate DEC pcd information to get 
> the value &
>datumtype
> for eachDec in self.PackageList:
> for DecPcd in eachDec.Pcds:
>--
>2.14.3.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Add comments for the Structure Pcd definition in PcdValueInit.c file

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Tuesday, January 23, 2018 11:03 AM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch] BaseTools: Add comments for the Structure Pcd definition in
>PcdValueInit.c file
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/Workspace/BuildClassObject.py | 4 
> BaseTools/Source/Python/Workspace/DecBuildData.py | 2 ++
> BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>index 0e3081cfc5..8d02e78b27 100644
>--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>@@ -117,10 +117,12 @@ class StructurePcd(PcdClassObject):
> self.DefaultValues = collections.OrderedDict({})
> self.PcdMode = None
> self.SkuOverrideValues = collections.OrderedDict({})
> self.FlexibleFieldName = None
> self.StructName = None
>+self.PcdDefineLineNo = 0
>+self.PkgPath = ""
> def __repr__(self):
> return self.TypeName
>
> def AddDefaultValue (self, FieldName, Value, FileName="", LineNo=0):
> if FieldName in self.DefaultValues:
>@@ -169,10 +171,12 @@ class StructurePcd(PcdClassObject):
> self.PcdMode = PcdObject.PcdMode if PcdObject.PcdMode else
>self.PcdMode
> self.DefaultFromDSC=None
> self.SkuOverrideValues = PcdObject.SkuOverrideValues if
>PcdObject.SkuOverrideValues else self.SkuOverrideValues
> self.FlexibleFieldName = PcdObject.FlexibleFieldName if
>PcdObject.FlexibleFieldName else self.FlexibleFieldName
> self.StructName = PcdObject.DatumType if PcdObject.DatumType else
>self.StructName
>+self.PcdDefineLineNo = PcdObject.PcdDefineLineNo if
>PcdObject.PcdDefineLineNo else self.PcdDefineLineNo
>+self.PkgPath = PcdObject.PkgPath if PcdObject.PkgPath else
>self.PkgPath
>
> ## LibraryClassObject
> #
> # This Class defines LibraryClassObject used in BuildDatabase
> #
>diff --git a/BaseTools/Source/Python/Workspace/DecBuildData.py
>b/BaseTools/Source/Python/Workspace/DecBuildData.py
>index 13fb8686b6..2fd3820dcc 100644
>--- a/BaseTools/Source/Python/Workspace/DecBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DecBuildData.py
>@@ -381,10 +381,12 @@ class DecBuildData(PackageBuildClassObject):
> dep_pkgs.append(item.DefaultValue)
> elif item.DatumType == item.TokenCName:
> struct_pcd.copy(item)
> struct_pcd.TokenValue = 
> struct_pcd.TokenValue.strip("{").strip()
> struct_pcd.TokenSpaceGuidCName, struct_pcd.TokenCName =
>pcdname.split(".")
>+struct_pcd.PcdDefineLineNo = LineNo
>+struct_pcd.PkgPath = self.MetaFile.File
> else:
> struct_pcd.AddDefaultValue(item.TokenCName,
>item.DefaultValue,self.MetaFile.File,LineNo)
>
> struct_pcd.PackageDecs = dep_pkgs
>
>diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
>b/BaseTools/Source/Python/Workspace/DscBuildData.py
>index b042c4306a..60aa4868ed 100644
>--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
>@@ -1284,11 +1284,11 @@ class DscBuildData(PlatformBuildClassObject):
> CApp = CApp + '  UINT32  Size;\n'
> CApp = CApp + '  UINT32  FieldSize;\n'
> CApp = CApp + '  CHAR8   *Value;\n'
> CApp = CApp + '  UINT32  OriginalSize;\n'
> CApp = CApp + '  VOID*OriginalPcd;\n'
>-CApp = CApp + '  %s  *Pcd;\n' % (Pcd.DatumType)
>+CApp = CApp + '  %s  *Pcd;  // From %s Line %d \n' %
>(Pcd.DatumType, Pcd.PkgPath, Pcd.PcdDefineLineNo)
> CApp = CApp + '\n'
>
> Pcd.DefaultValue = Pcd.DefaultValue.strip()
> PcdDefaultValue = StringToArray(Pcd.DefaultValue)
>
>--
>2.14.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fixed build failure for the case that A pcd is initialized under one SKU but is uninitialized under another SKU.

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Tuesday, January 23, 2018 9:39 AM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch] BaseTools: Fixed build failure for the case that A pcd is
>initialized under one SKU but is uninitialized under another SKU.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/AutoGen/GenPcdDb.py | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/GenPcdDb.py
>b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
>index 22283ef7fe..82360ae57d 100644
>--- a/BaseTools/Source/Python/AutoGen/GenPcdDb.py
>+++ b/BaseTools/Source/Python/AutoGen/GenPcdDb.py
>@@ -1022,10 +1022,23 @@ def CreateAutoGen(PcdDriverAutoGenData):
> return (PcdDriverAutoGenData[(skuname,skuid)][0],autogenC)
> def NewCreatePcdDatabasePhaseSpecificAutoGen(Platform,Phase):
> def prune_sku(pcd,skuname):
> new_pcd = copy.deepcopy(pcd)
> new_pcd.SkuInfoList = {skuname:pcd.SkuInfoList[skuname]}
>+new_pcd.isinit = 'INIT'
>+if new_pcd.DatumType in ['UINT8','UINT16','UINT32','UINT64']:
>+for skuobj in pcd.SkuInfoList.values():
>+if skuobj.DefaultValue:
>+defaultvalue = int(skuobj.DefaultValue,16) if
>skuobj.DefaultValue.upper().startswith("0X") else int(skuobj.DefaultValue,10)
>+if defaultvalue  != 0:
>+new_pcd.isinit = "INIT"
>+break
>+elif skuobj.VariableName:
>+new_pcd.isinit = "INIT"
>+break
>+else:
>+new_pcd.isinit = "UNINIT"
> return new_pcd
> DynamicPcds = Platform.DynamicPcdList
> DynamicPcdSet_Sku = {(SkuName,skuobj.SkuId):[] for pcd in DynamicPcds
>for (SkuName,skuobj) in pcd.SkuInfoList.items() }
> for skuname,skuid in DynamicPcdSet_Sku:
> DynamicPcdSet_Sku[(skuname,skuid)] = [prune_sku(pcd,skuname) for
>pcd in DynamicPcds]
>@@ -1399,12 +1412,11 @@ def CreatePcdDatabasePhaseSpecificAutoGen
>(Platform, DynamicPcdList, Phase):
> if "PCD_TYPE_HII" not in Pcd.TokenTypeList:
> Pcd.TokenTypeList += ['PCD_TYPE_DATA']
> if Sku.DefaultValue == 'TRUE':
> Pcd.InitString = 'INIT'
> else:
>-if int(Sku.DefaultValue, 0) != 0:
>-Pcd.InitString = 'INIT'
>+Pcd.InitString = Pcd.isinit
> #
> # For UNIT64 type PCD's value, ULL should be append to avoid
> # warning under linux building environment.
> #
> if Pcd.DatumType == "UINT64":
>--
>2.14.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTool: Combine the HiiPcd value if they link to same Variable

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Tuesday, January 23, 2018 10:19 AM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch] BaseTool: Combine the HiiPcd value if they link to same
>Variable
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/AutoGen/AutoGen.py |  2 +-
> BaseTools/Source/Python/AutoGen/GenVar.py  | 36
>--
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>b/BaseTools/Source/Python/AutoGen/AutoGen.py
>index 0f7454f55a..604d38a4d6 100644
>--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>@@ -1404,11 +1404,11 @@ class PlatformAutoGen(AutoGen):
> continue
> if len(Sku.VariableName) > 0:
> VariableGuidStructure = Sku.VariableGuidValue
> VariableGuid =
>GuidStructureStringToGuidString(VariableGuidStructure)
> for StorageName in Sku.DefaultStoreDict:
>-
>VariableInfo.append_variable(var_info(Index,pcdname,StorageName,SkuNa
>me, StringToArray(Sku.VariableName),VariableGuid, Sku.VariableAttribute ,
>Sku.HiiDefaultValue,Sku.DefaultStoreDict[StorageName],Pcd.DatumType))
>+
>VariableInfo.append_variable(var_info(Index,pcdname,StorageName,SkuNa
>me, StringToArray(Sku.VariableName),VariableGuid, Sku.VariableOffset,
>Sku.VariableAttribute ,
>Sku.HiiDefaultValue,Sku.DefaultStoreDict[StorageName],Pcd.DatumType))
> Index += 1
> return VariableInfo
>
> def UpdateNVStoreMaxSize(self,OrgVpdFile):
> if self.VariableInfo:
>diff --git a/BaseTools/Source/Python/AutoGen/GenVar.py
>b/BaseTools/Source/Python/AutoGen/GenVar.py
>index 65d0bea36c..1389d7ff62 100644
>--- a/BaseTools/Source/Python/AutoGen/GenVar.py
>+++ b/BaseTools/Source/Python/AutoGen/GenVar.py
>@@ -19,11 +19,11 @@ import collections
> import copy
> from Common.VariableAttributes import VariableAttributes
> from Common.Misc import *
> import collections
>
>-var_info = collections.namedtuple("uefi_var",
>"pcdindex,pcdname,defaultstoragename,skuname,var_name, var_guid,
>var_attribute,pcd_default_value, default_value, data_type")
>+var_info = collections.namedtuple("uefi_var",
>"pcdindex,pcdname,defaultstoragename,skuname,var_name, var_guid,
>var_offset,var_attribute,pcd_default_value, default_value, data_type")
> NvStorageHeaderSize = 28
> VariableHeaderSize = 32
>
> def StringArrayToList(StringArray):
> StringArray = StringArray[1:-1]
>@@ -74,11 +74,42 @@ class VariableMgr(object):
> value_str = "{"
> default_var_bin_strip = [ data.strip("""'""") for data in 
> default_var_bin]
> value_str += ",".join(default_var_bin_strip)
> value_str += "}"
> return value_str
>-
>+def combine_variable(self):
>+indexedvarinfo = collections.OrderedDict()
>+for item in self.VarInfo:
>+if (item.skuname,item.defaultstoragename,
>item.var_name,item.var_guid) not in indexedvarinfo:
>+indexedvarinfo[(item.skuname,item.defaultstoragename,
>item.var_name,item.var_guid) ] = []
>+indexedvarinfo[(item.skuname,item.defaultstoragename,
>item.var_name,item.var_guid)].append(item)
>+for key in indexedvarinfo:
>+sku_var_info_offset_list = indexedvarinfo[key]
>+if len(sku_var_info_offset_list) == 1:
>+continue
>+newvalue = {}
>+for item in sku_var_info_offset_list:
>+data_type = item.data_type
>+value_list = 
>item.default_value.strip("{").strip("}").split(",")
>+if data_type in 
>["BOOLEAN","UINT8","UINT16","UINT32","UINT64"]:
>+if data_type == ["BOOLEAN","UINT8"]:
>+data_flag = "=B"
>+elif data_type == "UINT16":
>+data_flag = "=H"
>+elif data_type == "UINT32":
>+data_flag = "=L"
>+elif data_type == "UINT64":
>+data_flag = "=Q"
>+data = value_list[0]
>+value_list = []
>+for data_byte in pack(data_flag,int(data,16) if
>data.upper().startswith('0X') else int(data)):
>+value_list += [hex(unpack("B",data_byte)[0])]
>+newvalue[int(item.var_offset,16) if
>item.var_offset.upper().startswith("0X") else int(item.var_offset)] =
>value_list
>+newvaluestr = "{" + ",".join(reduce(lambda x,y: x+y, [newvalue[k] 
>for k
>in sorted(newvalue.keys())] )) +"}"
>+n = sku_var_info_offset_list[0]
>+indexedvarinfo[key] =

Re: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to 1.02

2018-01-25 Thread Gao, Liming

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Ruiyu Ni
>Sent: Wednesday, January 24, 2018 1:56 PM
>To: edk2-devel@lists.01.org
>Cc: Carsey, Jaben 
>Subject: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to
>1.02
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Ruiyu Ni 
>Cc: Jaben Carsey 
>---
> ShellPkg/ShellPkg.dec | 4 ++--
> ShellPkg/ShellPkg.dsc | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec
>index 48d50b87b3..0c4f74ff41 100644
>--- a/ShellPkg/ShellPkg.dec
>+++ b/ShellPkg/ShellPkg.dec
>@@ -2,7 +2,7 @@
> # This Package provides all definitions for EFI and UEFI Shell
> #
> # (C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P.
>-# Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
>+# Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> #
> # This program and the accompanying materials are licensed and made
>available under
> # the terms and conditions of the BSD License which accompanies this
>distribution.
>@@ -18,7 +18,7 @@ [Defines]
>   DEC_SPECIFICATION  = 0x00010005
>   PACKAGE_NAME   = ShellPkg
>   PACKAGE_GUID   = C1014BB7-4092-43D4-984F-0738EB424DBF
>-  PACKAGE_VERSION= 1.01
>+  PACKAGE_VERSION= 1.02
>
> [Includes]
>   Include
>diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
>index 86382139a5..29f5376412 100644
>--- a/ShellPkg/ShellPkg.dsc
>+++ b/ShellPkg/ShellPkg.dsc
>@@ -1,7 +1,7 @@
> ##  @file
> # Shell Package
> #
>-# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
>+# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> #
> #This program and the accompanying materials
> #are licensed and made available under the terms and conditions of the
>BSD License
>@@ -16,7 +16,7 @@
> [Defines]
>   PLATFORM_NAME  = Shell
>   PLATFORM_GUID  = E1DC9BF8-7013-4c99-9437-795DAA45F3BD
>-  PLATFORM_VERSION   = 1.01
>+  PLATFORM_VERSION   = 1.02
>   DSC_SPECIFICATION  = 0x00010006
>   OUTPUT_DIRECTORY   = Build/Shell
>   SUPPORTED_ARCHITECTURES= IA32|IPF|X64|EBC|ARM|AARCH64
>--
>2.15.1.windows.2
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/Partition: Fix media probe

2018-01-25 Thread Ruiyu Ni

The call in ProbeMediaStatusEx() to the ReadDisk() function of the
EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c
crashed in DiskIo2ReadWriteDisk() because of the NULL value of
the destination buffer pointer.

Pass the address of a buffer in the stack instead of a NULL
pointer.

The similar fix was applied to ProbeMediaStatus in commit
df473cc1fc9acd1a623ec7e05276f2f0635c19d2
* MdeModulePkg/PartitionDxe: Fix media probe

Somehow ProbeMediaStatusEx() wasn't changed together.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jian J Wang 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
index bb9d0b70ce..46c0877cee 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
@@ -4,7 +4,7 @@
   of the raw block devices media. Currently "El Torito CD-ROM", UDF, Legacy
   MBR, and GPT partition schemes are supported.
 
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -777,11 +777,15 @@ ProbeMediaStatusEx (
   )
 {
   EFI_STATUS Status;
+  UINT8  Buffer[1];
 
   //
-  // Read 1 byte from offset 0 but passing NULL as buffer pointer
+  // Read 1 byte from offset 0 to check if the MediaId is still valid.
+  // The reading operation is synchronious thus it is not worth it to
+  // allocate a buffer from the pool. The destination buffer for the
+  // data is in the stack.
   //
-  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, NULL);
+  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, (VOID*)Buffer);
   if ((Status == EFI_NO_MEDIA) || (Status == EFI_MEDIA_CHANGED)) {
 return Status;
   }
-- 
2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine

2018-01-25 Thread Arthur Heymans

"You, Benjamin"  writes:

> Hi Arthur,
>
> Could you please give more details about your case that 
> HorizontalResolution * (BitsPerPixel / 8) and pFbInfo->BytesPerScanLine 
> don't match?
>

On many devices, notably Intel hardware, the STRIDE needs to be 64 byte
aligned when used in linear memory mode, which coreboot does. STRIDE is
value that used to determine the line to line increment for the
display. So what coreboot does when initializing the hardware to align
(HorizontalResolution * (BitsPerPixel / 8)), 64 bytes up.

> I did a brief search in Coreboot source and found following comments in 
> coreboot-4.6\src\lib\edid.c:
>
>   /* In the case of (e.g.) 24 framebuffer bits per pixel, the convention
>* nowadays seems to be to round it up to the nearest reasonable
>* boundary, because otherwise the byte-packing is hideous.
>
> So it appears framebuffer BitsPerPixel will likely be 16 or 32, and the 
> following statement in the same file calculates:
>
>   edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8);
>
> which results in bytes_per_line (already rounded up to be 32 or 64 byte 
> aligned) matching x_resolution * (fb_bpp / 8).
>
> There are cases that even if panel bits_per_pixel is 24, the framebuffer 
> bits_per_pixel is still 32, as shown in 
> coreboot-4.6\src\drivers\emulation\qemu\bochs.c:
>
>   edid.panel_bits_per_pixel = 24;
>   edid_set_framebuffer_bits_per_pixel(, 32, 0);
>
> It would be good if you could help with more details on how the mismatch 
> happened in your case as I may have missed something.
>

So long story short 'bytes_per_line' reflects how the actual hardware is
set up, while using '(HorizontalResolution * (BitsPerPixel / 8)' is a
guess which is only sometimes correct.

To give an example (on which this was actually a problem):
let's say we have a display 1366 pixel horizontal resolution with 32
bits per pixel.

HorizontalResolution * BitsPerPixel / 8 = 5464

But this value is not 64 byte aligned which the hardware expects so.

aligned value = ((HorizontalResolution * (BitsPerPixel / 8) + 63) & ~63
= 5504

So tianocore should use the value coreboot provides it instead of trying
to compute/guess it.

> Thanks,
>
> - ben
>

I hope this clarifies it.

Arthur

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> art...@aheymans.xyz
>> Sent: Wednesday, January 24, 2018 6:58 PM
>> To: edk2-devel@lists.01.org
>> Cc: Arthur Heymans 
>> Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
>> 
>> From: Arthur Heymans 
>> 
>> Fetch BytesPerScanLine from coreboot table to reflect how the actual
>> framebuffer is set up instead of guessing it from the horizontal
>> resolution.
>> 
>> This fixes a garbled display when HorizontalResolution * (BitsPerPixel
>> / 8) and pFbInfo->BytesPerScanLine don't match.
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Arthur Heymans 
>> 
>> diff --git a/CorebootPayloadPkg/FbGop/FbGop.c
>> b/CorebootPayloadPkg/FbGop/FbGop.c
>> index 37d6def7f7..6790617033 100644
>> --- a/CorebootPayloadPkg/FbGop/FbGop.c
>> +++ b/CorebootPayloadPkg/FbGop/FbGop.c
>> @@ -822,7 +822,7 @@ FbGopCheckForVbe (
>>BitsPerPixel = pFbInfo->BitsPerPixel;
>>HorizontalResolution = pFbInfo->HorizontalResolution;
>>VerticalResolution   = pFbInfo->VerticalResolution;
>> -  BytesPerScanLine = HorizontalResolution * (BitsPerPixel / 8);
>> +  BytesPerScanLine = pFbInfo->BytesPerScanLine;
>> 
>>ModeBuffer = (FB_VIDEO_MODE_DATA *) AllocatePool (
>> 
>> 
>>  ModeNumber * sizeof
>> (FB_VIDEO_MODE_DATA)
>> --
>> 2.16.1
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
<#secure method=pgpmime mode=sign>

-- 
Arthur Heymans
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] UefiCpuPkg/MpInitLib: fix AP init issue in 64-bit PEI

2018-01-25 Thread Ni, Ruiyu


On 1/25/2018 3:42 PM, Jian J Wang wrote:

v2:
Roll back changes (just white spaces) caused by misoperation in git


This issue is introduced by a patch at

f32bfe6d061420a15bac6083063d227c567e6388

The above patch miss the case of 64-bit PEI, which will link
X64/MpFuncs.nasm instead of Ia32/MpFuncs.nasm. For X64/MpFuncs.nasm,
ExchangeInfo->ModeHighMemory should be always initialized no matter
if separate wakeup buffer is allocated or not. Ia32/MpFuncs.nasm will
not need ModeHighMemory during AP init. So the changes made in this
patch should not affect the functionality of it.

Cc: Ruiyu Ni 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
  UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 42011d6231..0b7073fd02 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -834,14 +834,15 @@ FillExchangeInfoData (
);
  
  ExchangeInfo->ModeTransitionMemory = (UINT32)CpuMpData->WakeupBufferHigh;

-ExchangeInfo->ModeHighMemory = (UINT32)CpuMpData->WakeupBufferHigh +
-   (UINT32)ExchangeInfo->ModeOffset -
-   
(UINT32)CpuMpData->AddressMap.ModeTransitionOffset;
-ExchangeInfo->ModeHighSegment = (UINT16)ExchangeInfo->CodeSegment;
} else {
  ExchangeInfo->ModeTransitionMemory = (UINT32)
(ExchangeInfo->BufferStart + 
CpuMpData->AddressMap.ModeTransitionOffset);
}
+
+  ExchangeInfo->ModeHighMemory = ExchangeInfo->ModeTransitionMemory +
+ (UINT32)ExchangeInfo->ModeOffset -
+ (UINT32)CpuMpData->AddressMap.ModeTransitionOffset;
+  ExchangeInfo->ModeHighSegment = (UINT16)ExchangeInfo->CodeSegment;
  }
  
  /**



Reviewed-by: Ruiyu Ni 

--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

56 matches

Mail list logo