Re: [edk2] [PATCH v7 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: Wang, Jian J 
Sent: Tuesday, November 21, 2017 2:17 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star ; 
Laszlo Ersek ; Ard Biesheuvel 
Subject: [PATCH v7 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

> v7:
>   Merge memory map after filtering code

Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set attributes 
and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from 
Capabilities in GCD memory map. This might cause boot problems. Clearing all 
paging related capabilities can workaround it. The code added in this patch is 
supposed to be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute is 
clarified in UEFI spec and adopted by both EDK-II Core and all supported OSs.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 
---
 MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
 MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h 
index 1a0babba71..07b86ba696 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -2948,4 +2948,22 @@ ApplyMemoryProtectionPolicy (
   IN  UINT64Length
   );
 
+/**
+  Merge continous memory map entries whose have same attributes.
+
+  @param  MemoryMap   A pointer to the buffer in which firmware places
+  the current memory map.
+  @param  MemoryMapSize   A pointer to the size, in bytes, of the
+  MemoryMap buffer. On input, this is the size of
+  the current memory map.  On output,
+  it is the size of new memory map after merge.
+  @param  DescriptorSize  Size, in bytes, of an individual 
EFI_MEMORY_DESCRIPTOR.
+**/
+VOID
+MergeMemoryMap (
+  IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
+  IN OUT UINTN  *MemoryMapSize,
+  IN UINTN  DescriptorSize
+  );
+
 #endif
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index f1e4a37f2a..9ff73efdfa 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1687,6 +1687,7 @@ CoreGetMemoryMap (
   EFI_GCD_MAP_ENTRY MergeGcdMapEntry;
   EFI_MEMORY_TYPE   Type;
   EFI_MEMORY_DESCRIPTOR *MemoryMapStart;
+  EFI_MEMORY_DESCRIPTOR *MemoryMapEnd;
 
   //
   // Make sure the parameters are valid @@ -1896,6 +1897,26 @@ 
CoreGetMemoryMap (
   //
   BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
 
+  //
+  // Note: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
+  //   set attributes and change memory paging attribute accordingly.
+  //   But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
+  //   value from Capabilities in GCD memory map. This might cause
+  //   boot problems. Clearing all paging related capabilities can
+  //   workaround it. Following code is supposed to be removed once
+  //   the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
+  //   UEFI spec and adopted by both EDK-II Core and all supported
+  //   OSs.
+  //
+  MemoryMapEnd = MemoryMap;
+  MemoryMap = MemoryMapStart;
+  while (MemoryMap < MemoryMapEnd) {
+MemoryMap->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
+  EFI_MEMORY_XP);
+MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);  }  
+ MergeMemoryMap (MemoryMapStart, , Size);
+
   Status = EFI_SUCCESS;
 
 Done:
diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 6cf5edcbe5..75d9b14c1f 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -182,7 +182,6 @@ SortMemoryMap (
  it is the size of new memory map after merge.
   @param  DescriptorSize Size, in bytes, of an individual 
EFI_MEMORY_DESCRIPTOR.
 **/
-STATIC
 VOID
 MergeMemoryMap (
   IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
--
2.14.1.windows.1

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

Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

You're right about XP/NX in this function. But from DxeCore or other drivers
perspective, they have no knowledge of current capability of NX. I think it's 
the
responsibility of cpu driver to add/remove it for the sake of GCD.

Actually Star has filed a bz to use GCD service instead of CPU arch protocol to
change memory attributes in DxeCore (like enforce image protection). If the 
knowledge between GCD and cpu mismatch, the GCD may not do right thing
upon requests. For example, if we always add XP to capability but current cpu
doesn't support it, the DxeCore or other drivers may still try to enable image
protection which won't take into effect actually.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 4:32 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star ; Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> On 11/16/17 08:27, Jian J Wang wrote:
> >> v6:
> >>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP
> 
> Another change relative to v5 is the fixing of the first DEBUG_WARN
> message -- in my v5 review I had missed that the DEBUG_WARN arguments
> didn't match the preceding gDS->SetMemorySpaceCapabilities() arguments.
> 
> Yet another change that could have been (maybe) possible for this patch
> is to replace the remaining occurrences of EFI_MEMORY_PAGETYPE_MASK with
> "Capabilities". Namely, in v6, the attributes are enforced on a mask
> that is possibly wider than supported by the hardware (i.e., in case NX
> is not supported).
> 
> However, this should not be a functionality problem, because with NX
> unavailable, the GetAttributesFromPageEntry() function should never
> return EFI_MEMORY_XP. Thus, the "wider than needed" attribute setting
> will just clear EFI_MEMORY_XP.
> 
> Reviewed-by: Laszlo Ersek 
> 
> (I hope that Star and/or Jiewen will also R-b this patch.)
> 
> In addition, I will follow up with test results for the series.
> 
> Thanks
> Laszlo
> 
> >> v5:
> >>Coding style clean-up
> >
> >> v4:
> >> a. Remove DoUpdate and check attributes mismatch all the time to avoid
> >>a logic hole
> >> b. Add warning message if failed to update capability
> >> c. Add local variable to hold new attributes to make code cleaner
> >
> >> v3:
> >> a. Add comment to explain more on updating memory capabilities
> >> b. Fix logic hole in updating attributes
> >> c. Instead of checking illegal memory space address and size, use return
> >>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
> >>cannot be updated with new capabilities.
> >
> >> v2
> >> a. Fix an issue which will cause setting capability failure if size is 
> >> smaller
> >>than a page.
> >
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > More detailed information, please refer to
> > https://bugzilla.tianocore.org/show_bug.cgi?id=753
> >
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Cc: Star Zeng 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94
> +++-
> >  1 file changed, 73 insertions(+), 21 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..3297c1900b 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
> >return Status;
> >  }
> >
> > +/**
> > + Check if Execute Disable feature is enabled or not.
> > +**/
> > +BOOLEAN
> > +IsExecuteDisableEnabled (
> > +  VOID
> > +  )
> > +{
> > +  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
> > +
> > +  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
> > +  return (MsrEfer.Bits.NXE == 1);
> > +}
> > +
> >  /**
> >Update GCD memory space attributes according to current page table setup.
> >  **/
> > @@ -790,7 +804,7 @@ RefreshGcdMemoryAttributesFromPaging (
> >UINT64  PageStartAddress;
> >UINT64  Attributes;
> >UINT64  Capabilities;
> > -  BOOLEAN DoUpdate;
> > +  UINT64  NewAttributes;
> >UINTN   Index;
> >
> >//
> > @@ -802,17 +816,50 @@ RefreshGcdMemoryAttributesFromPaging (
> >
> >GetCurrentPagingContext ();
> >
> > -  DoUpdate  = FALSE;
> > -  

[edk2] [platforms: PATCH v2 0/4] Armada 7k/8k variable support

[Marcin Wojtas]

Hi,

I submit v2 of the Armada variable support with the style of
the MvFvbDxe driver fixed and other minor modifications. Depex
configuration was moved from 4/4 to previous patches. Details
can be found in the changelog and commit messages.

Patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/var-upstream-r20171121

I'm looking forward to the comments or remarks.

Best regards,
Marcin

Changelog:
v1 -> v2:
* Change patches order in order to safely apply related Depex modifications

* 1/4:
  - Fix style (line breaking, openining brackets, alignment, typos)
  - Rework MvFvbSetAttributes - because it can return only EFI_SUCCESS /
EFI_INVALID_PARAMETER and should return FVB attributes,
add debug information, that operation is not supported and return
default values via MvFvbGetAttributes.
  - Return EFI_SUCCESS, in case NumBytes == 0 in MvFvbRead.

* 2/4:
  - Move Depex configuration from 4/4

* 3/4:
  - Move Depex configuration from 4/4
  - Reword and break commit message.

* 4/4:
  - Remove Depex configuration

Marcin Wojtas (4):
  Platform/Marvell: Introduce MvFvbDxe variable support driver
  Marvell/Drivers: MvSpiFlash: Enable using driver in RT
  Marvell/Drivers: MvSpiDxe: Enable using driver in RT
  Marvell/Armada: Enable variables support

 Platform/Marvell/Armada/Armada.dsc.inc  |   25 +-
 Platform/Marvell/Armada/Armada70x0.fdf  |6 +-
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c   |   58 +-
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h   |1 +
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf |   11 +-
 Platform/Marvell/Drivers/Spi/MvSpiDxe.c |   50 +-
 Platform/Marvell/Drivers/Spi/MvSpiDxe.h |2 +
 Platform/Marvell/Drivers/Spi/MvSpiDxe.inf   |9 +-
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c   | 1056 
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h   |  114 +++
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf |   91 ++
 Platform/Marvell/Include/Protocol/Spi.h |7 +
 Platform/Marvell/Marvell.dec|4 +
 13 files changed, 1420 insertions(+), 14 deletions(-)
 create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
 create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h
 create mode 100644 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf

-- 
2.7.4

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

[edk2] [platforms: PATCH v2 3/4] Marvell/Drivers: MvSpiDxe: Enable using driver in RT

[Marcin Wojtas]

This patch applies necessary modifications, which allow to use
MvSpiDxe driver in variable support as a runtime service.

The driver's type is modified to DXE_RUNTIME_DRIVER, as well as
a new callback is introduced as a part of the SpiMasterProtocol.
It configures the memory space for mmio access to the host
controller registers.

Apply locking in the driver only during boot services. Once at
runtime, resource protection is handled by the operating system.

Moreover ensure proper execution order before MvSpiFlashDxe
(and hence MvFvbDxe) by setting according Depex dependency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Spi/MvSpiDxe.c   | 50 ++--
 Platform/Marvell/Drivers/Spi/MvSpiDxe.h   |  2 +
 Platform/Marvell/Drivers/Spi/MvSpiDxe.inf |  9 +++-
 Platform/Marvell/Include/Protocol/Spi.h   |  7 +++
 Platform/Marvell/Marvell.dec  |  1 +
 5 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
index c60a520..bab6cf4 100755
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
@@ -211,7 +211,9 @@ MvSpiTransfer (
 
   Length = 8 * DataByteCount;
 
-  EfiAcquireLock (>Lock);
+  if (!EfiAtRuntime ()) {
+EfiAcquireLock (>Lock);
+  }
 
   if (Flag & SPI_TRANSFER_BEGIN) {
 SpiActivateCs (Slave);
@@ -254,7 +256,9 @@ MvSpiTransfer (
 SpiDeactivateCs (Slave);
   }
 
-  EfiReleaseLock (>Lock);
+  if (!EfiAtRuntime ()) {
+EfiReleaseLock (>Lock);
+  }
 
   return EFI_SUCCESS;
 }
@@ -338,6 +342,44 @@ MvSpiFreeSlave (
   return EFI_SUCCESS;
 }
 
+EFI_STATUS
+EFIAPI
+MvSpiConfigRuntime (
+  IN SPI_DEVICE *Slave
+  )
+{
+  EFI_STATUS Status;
+  UINTN AlignedAddress;
+
+  //
+  // Host register base may be not aligned to the page size,
+  // which is not accepted when setting memory space attributes.
+  // Add one aligned page of memory space which covers the host
+  // controller registers.
+  //
+  AlignedAddress = Slave->HostRegisterBaseAddress & ~(SIZE_4KB - 1);
+
+  Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo,
+  AlignedAddress,
+  SIZE_4KB,
+  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to add memory space\n", __FUNCTION__));
+return Status;
+  }
+
+  Status = gDS->SetMemorySpaceAttributes (AlignedAddress,
+  SIZE_4KB,
+  EFI_MEMORY_UC | EFI_MEMORY_RUNTIME);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to set memory attributes\n", 
__FUNCTION__));
+gDS->RemoveMemorySpace (AlignedAddress, SIZE_4KB);
+return Status;
+  }
+
+  return EFI_SUCCESS;
+}
+
 STATIC
 EFI_STATUS
 SpiMasterInitProtocol (
@@ -350,6 +392,7 @@ SpiMasterInitProtocol (
   SpiMasterProtocol->FreeDevice  = MvSpiFreeSlave;
   SpiMasterProtocol->Transfer= MvSpiTransfer;
   SpiMasterProtocol->ReadWrite   = MvSpiReadWrite;
+  SpiMasterProtocol->ConfigRuntime = MvSpiConfigRuntime;
 
   return EFI_SUCCESS;
 }
@@ -363,8 +406,7 @@ SpiMasterEntryPoint (
 {
   EFI_STATUS  Status;
 
-  mSpiMasterInstance = AllocateZeroPool (sizeof (SPI_MASTER));
-
+  mSpiMasterInstance = AllocateRuntimeZeroPool (sizeof (SPI_MASTER));
   if (mSpiMasterInstance == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.h 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
index e7e280a..50cdc02 100644
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
@@ -38,10 +38,12 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.inf 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.inf
index 08c6c04..ac0e407 100644
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.inf
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.inf
@@ -33,7 +33,7 @@
   INF_VERSION= 0x00010005
   BASE_NAME  = SpiMasterDxe
   FILE_GUID  = c19dbc8a-f4f9-43b0-aee5-802e3ed03d15
-  MODULE_TYPE= DXE_DRIVER
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
   VERSION_STRING = 1.0
   ENTRY_POINT= SpiMasterEntryPoint
 
@@ -53,8 +53,10 @@
   TimerLib
   UefiLib
   DebugLib
+  DxeServicesTableLib
   MemoryAllocationLib
   IoLib
+  UefiRuntimeLib
 
 [FixedPcd]
   gMarvellTokenSpaceGuid.PcdSpiRegBase
@@ -65,4 +67,7 @@
   gMarvellSpiMasterProtocolGuid
 
 [Depex]
-  TRUE
+  #
+  # MvSpiDxe must be loaded prior to MvSpiFlash driver
+  #
+  BEFORE gMarvellSpiFlashDxeGuid
diff --git a/Platform/Marvell/Include/Protocol/Spi.h 
b/Platform/Marvell/Include/Protocol/Spi.h
index d993021..abbad19 100644
--- a/Platform/Marvell/Include/Protocol/Spi.h
+++ 

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

[Marcin Wojtas]

MvFvbDxe driver introduces non-volatile EFI variable support
for Armada platforms. It relies on memory-mapped SPI read access.
Implementation of EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL
is done with using existing Marvell SPI infrastructure
(SpiMasterProtocol and SpiFlashProtocol), thanks to which
this driver will be able to support various combinations of
flash devices and host controllers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c   | 1056 
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.h   |  114 +++
 Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf |   91 ++
 Platform/Marvell/Marvell.dec|1 +
 4 files changed, 1262 insertions(+)

diff --git a/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c 
b/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
new file mode 100644
index 000..7a44f80
--- /dev/null
+++ b/Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
@@ -0,0 +1,1056 @@
+/*++ @file  MvFvbDxe.c
+
+ Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+ Copyright (c) 2017 Marvell International Ltd.
+
+ This program and the accompanying materials are licensed and made available
+ under the terms and conditions of the BSD License which accompanies this
+ distribution.  The full text of the license may be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+ --*/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "MvFvbDxe.h"
+
+STATIC EFI_EVENT mFvbVirtualAddrChangeEvent;
+STATIC FVB_DEVICE*mFvbDevice;
+
+STATIC CONST FVB_DEVICE mMvFvbFlashInstanceTemplate = {
+  {
+0,// SpiFlash Chip Select ... NEED TO BE FILLED
+0,// SpiFlash Maximum Frequency ... NEED TO BE FILLED
+0,// SpiFlash Transfer Mode ... NEED TO BE FILLED
+0,// SpiFlash Address Size ... NEED TO BE FILLED
+NULL, // SpiFlash detailed information ... NEED TO BE FILLED
+0,// HostRegisterBaseAddress ... NEED TO BE FILLED
+0,// CoreClock ... NEED TO BE FILLED
+  }, // SpiDevice
+
+  NULL, // SpiFlashProtocol ... NEED TO BE FILLED
+  NULL, // SpiMasterProtocol ... NEED TO BE FILLED
+  NULL, // Handle ... NEED TO BE FILLED
+
+  FVB_FLASH_SIGNATURE, // Signature
+
+  0, // DeviceBaseAddress ... NEED TO BE FILLED
+  0, // RegionBaseAddress ... NEED TO BE FILLED
+  SIZE_256KB, // Size
+  0, // FvbOffset ... NEED TO BE FILLED
+  0, // FvbSize ... NEED TO BE FILLED
+  0, // StartLba
+
+  {
+0, // MediaId ... NEED TO BE FILLED
+FALSE, // RemovableMedia
+TRUE,  // MediaPresent
+FALSE, // LogicalPartition
+FALSE, // ReadOnly
+FALSE, // WriteCaching;
+0, // BlockSize ... NEED TO BE FILLED
+4, // IoAlign
+0, // LastBlock ... NEED TO BE FILLED
+0, // LowestAlignedLba
+1, // LogicalBlocksPerPhysicalBlock
+  }, //Media;
+
+  {
+MvFvbGetAttributes,   // GetAttributes
+MvFvbSetAttributes,   // SetAttributes
+MvFvbGetPhysicalAddress,  // GetPhysicalAddress
+MvFvbGetBlockSize,// GetBlockSize
+MvFvbRead,// Read
+MvFvbWrite,   // Write
+MvFvbEraseBlocks, // EraseBlocks
+NULL, // ParentHandle
+  }, //  FvbProtocol;
+
+  {
+{
+  {
+HARDWARE_DEVICE_PATH,
+HW_VENDOR_DP,
+{
+  (UINT8)sizeof (VENDOR_DEVICE_PATH),
+  (UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+}
+  },
+  { 0xfc0cb972, 0x21df, 0x44d2, { 0x92, 0xa5, 0x78, 0x98, 0x99, 0xcb, 
0xf6, 0x61 } }
+},
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 }
+}
+  } // DevicePath
+};
+
+//
+// The Firmware Volume Block Protocol is the low-level interface
+// to a firmware volume. File-level access to a firmware volume
+// should not be done using the Firmware Volume Block Protocol.
+// Normal access to a firmware volume must use the Firmware
+// Volume Protocol. Typically, only the file system driver that
+// produces the Firmware Volume Protocol will bind to the
+// Firmware Volume Block Protocol.
+//
+
+/**
+  Initialises the FV Header and Variable Store Header
+  to support variable operations.
+
+  @param[in]  Ptr - Location to initialise the headers
+
+**/
+STATIC
+EFI_STATUS
+MvFvbInitFvAndVariableStoreHeaders (
+  IN FVB_DEVICE *FlashInstance
+  )
+{
+  EFI_FIRMWARE_VOLUME_HEADER  *FirmwareVolumeHeader;
+  VARIABLE_STORE_HEADER   *VariableStoreHeader;
+  EFI_STATUS  Status;
+  VOID*   Headers;
+  UINTN   HeadersLength;
+  UINTN   

[edk2] [platforms: PATCH v2 2/4] Marvell/Drivers: MvSpiFlash: Enable using driver in RT

[Marcin Wojtas]

This patch applies necessary modifications, which allow to use
MvSpiFlash driver in variable support as a runtime service.
Its type is modified to DXE_RUNTIME_DRIVER, as well as
an event is created, which converts the pointers to the
SpiMasterProtocol and its routines. In order to ensure proper
execution of the MvFvbDxe driver, configure initialization
order with Depex entry.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c   | 58 ++--
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h   |  1 +
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf | 11 +++-
 Platform/Marvell/Marvell.dec|  2 +
 4 files changed, 66 insertions(+), 6 deletions(-)

diff --git a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c 
b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
index 456d9f9..6886d01 100755
--- a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
+++ b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
@@ -33,6 +33,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
***/
 #include "MvSpiFlash.h"
 
+STATIC EFI_EVENTmMvSpiFlashVirtualAddrChangeEvent;
 MARVELL_SPI_MASTER_PROTOCOL *SpiMasterProtocol;
 SPI_FLASH_INSTANCE  *mSpiFlashInstance;
 
@@ -503,6 +504,33 @@ MvSpiFlashInitProtocol (
   return EFI_SUCCESS;
 }
 
+/**
+  Fixup internal data so that EFI can be call in virtual mode.
+  Call the passed in Child Notify event and convert any pointers in
+  lib to virtual mode.
+
+  @param[in]Event   The Event that is being processed
+  @param[in]Context Event Context
+**/
+STATIC
+VOID
+EFIAPI
+MvSpiFlashVirtualNotifyEvent (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  //
+  // Convert SpiMasterProtocol callbacks in MvSpiFlashErase and
+  // MvSpiFlashWrite required by runtime variable support.
+  //
+  EfiConvertPointer (0x0, (VOID**)>ReadWrite);
+  EfiConvertPointer (0x0, (VOID**)>Transfer);
+  EfiConvertPointer (0x0, (VOID**));
+
+  return;
+}
+
 EFI_STATUS
 EFIAPI
 MvSpiFlashEntryPoint (
@@ -522,8 +550,7 @@ MvSpiFlashEntryPoint (
 return EFI_DEVICE_ERROR;
   }
 
-  mSpiFlashInstance = AllocateZeroPool (sizeof (SPI_FLASH_INSTANCE));
-
+  mSpiFlashInstance = AllocateRuntimeZeroPool (sizeof (SPI_FLASH_INSTANCE));
   if (mSpiFlashInstance == NULL) {
 DEBUG((DEBUG_ERROR, "SpiFlash: Cannot allocate memory\n"));
 return EFI_OUT_OF_RESOURCES;
@@ -540,10 +567,33 @@ MvSpiFlashEntryPoint (
   NULL
   );
   if (EFI_ERROR (Status)) {
-FreePool (mSpiFlashInstance);
 DEBUG((DEBUG_ERROR, "SpiFlash: Cannot install SPI flash protocol\n"));
-return EFI_DEVICE_ERROR;
+goto ErrorInstallProto;
+  }
+
+  //
+  // Register for the virtual address change event
+  //
+  Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL,
+  TPL_NOTIFY,
+  MvSpiFlashVirtualNotifyEvent,
+  NULL,
+  ,
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to register VA change event\n", 
__FUNCTION__));
+goto ErrorCreateEvent;
   }
 
   return EFI_SUCCESS;
+
+ErrorCreateEvent:
+  gBS->UninstallMultipleProtocolInterfaces (>Handle,
+,
+NULL);
+
+ErrorInstallProto:
+  FreePool (mSpiFlashInstance);
+
+  return EFI_SUCCESS;
 }
diff --git a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h 
b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
index f09ff50..f69c562 100755
--- a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
+++ b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
@@ -42,6 +42,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf 
b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
index 6587f69..c6bbe5e 100644
--- a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
+++ b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
@@ -33,7 +33,7 @@
   INF_VERSION= 0x00010005
   BASE_NAME  = SpiFlashDxe
   FILE_GUID  = 49d7fb74-306d-42bd-94c8-c0c54b181dd7
-  MODULE_TYPE= DXE_DRIVER
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
   VERSION_STRING = 1.0
   ENTRY_POINT= MvSpiFlashEntryPoint
 
@@ -54,10 +54,17 @@
   UefiLib
   DebugLib
   MemoryAllocationLib
+  UefiRuntimeLib
+
+[Guids]
+  gEfiEventVirtualAddressChangeGuid
 
 [Protocols]
   gMarvellSpiMasterProtocolGuid
   gMarvellSpiFlashProtocolGuid
 
 [Depex]
-  TRUE
+  #
+  # MvSpiFlashDxe must be loaded prior to variables driver MvFvbDxe
+  #
+  BEFORE gMarvellFvbDxeGuid
diff --git a/Platform/Marvell/Marvell.dec b/Platform/Marvell/Marvell.dec
index 6aa2a8d..e40771b 100644
--- 

[edk2] [platforms: PATCH v2 4/4] Marvell/Armada: Enable variables support

[Marcin Wojtas]

Wire up the non-volatile EFI variable store support, by switching from
the emulation driver to the real one. Define default values for
memory mapped SPI access, which must be configured by the early
firmware.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 25 +++-
 Platform/Marvell/Armada/Armada70x0.fdf |  6 -
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 2cd96e6..3e0 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -371,6 +371,17 @@
   # TRNG
   gMarvellTokenSpaceGuid.PcdEip76TrngBaseAddress|0xF276
 
+  #
+  # Variable store - default values
+  #
+  gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0xF93C
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0xF93D
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0xF93E
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform
@@ -428,7 +439,6 @@
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
 
   EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
@@ -485,6 +495,19 @@
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
   }
 
+  #
+  # Variable services
+  #
+  Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
+  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+  
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+  }
+
   # UEFI application (Shell Embedded Boot Loader)
   ShellPkg/Application/Shell/Shell.inf {
 
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index ec2c368..ca92c60 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -103,7 +103,6 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
-  INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
   INF EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
   INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
@@ -115,6 +114,11 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
   INF Platform/Marvell/Armada/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
 
+  # Variable services
+  INF Platform/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
+  INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
+  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+
   # Network support
   INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
   INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-- 
2.7.4

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

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Wang, Jian J]

Thanks for the comments. V7 patch has added one more variable so that
MemoryMapStart will be kept intact.

V7 added code to merge memory map after filtering. I have verified that
the output keeps the same as v6 on both OVMF and our real platform
(default platform configuration). I think it may be not necessary to validate
all OS boot again. But if you want and have time, you can do it anyway.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 4:23 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zeng, Star ;
> Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all
> paging capabilities
> 
> On 11/16/17 08:26, Jian J Wang wrote:
> > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> > set attributes and change memory paging attribute accordingly.
> > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > value from Capabilities in GCD memory map. This might cause
> > boot problems. Clearing all paging related capabilities can
> > workaround it. The code added in this patch is supposed to
> > be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> > is clarified in UEFI spec and adopted by both EDK-II Core and
> > all supported OSs.
> >
> > Cc: Jiewen Yao 
> > Cc: Star Zeng 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > index c9219cc068..783b576e35 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
> >//
> >BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
> >
> > +  //
> > +  // WORKAROUND: Some OSs will treat
> EFI_MEMORY_DESCRIPTOR.Attribute as really
> > +  // set attributes and change memory paging attribute 
> > accordingly.
> > +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > +  // value from Capabilities in GCD memory map. This might 
> > cause
> > +  // boot problems. Clearing all paging related capabilities 
> > can
> > +  // workaround it. Following code is supposed to be removed 
> > once
> > +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified 
> > in
> > +  // UEFI spec and adopted by both EDK-II Core and all 
> > supported
> > +  // OSs.
> > +  //
> > +  while (MemoryMapStart < MemoryMap) {
> > +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP |
> EFI_MEMORY_RO |
> > +   EFI_MEMORY_XP);
> > +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
> > +  }
> > +
> >Status = EFI_SUCCESS;
> >
> >  Done:
> >
> 
> OK, let me check if I understand the discussion thus far, for this patch:
> 
> - Ard asked about EFI_MEMORY_WP, but clearing that bit is not necessary
> because CpuDxe does not add it anyway, in the GCD memory space map.
> 
> - The code comment might be updated (according to Jiewen's suggestion)
> before pushing the patch. I don't have any particular opinion about the
> comment.
> 
> - If I understand correctly, Jiewen agrees with applying both patches in
> this series.
> 
> 
> I have one superficial comment on this patch: in the CoreGetMemoryMap()
> function, we keep "MemoryMapStart" unchanged (after the initial
> assignment), and keep incrementing "MemoryMap". At the location where
> the new code is being added, "MemoryMap" points one past the last
> descriptor, and "MemoryMapStart" still points to the first one.
> 
> In order to keep this property for possible future "scans" of the full
> map, I would prefer keeping "MemoryMapStart" unchanged in this location,
> and using an independent loop variable.
> 
> ... On the other hand, we can easily restore "MemoryMapStart", should it
> be necessary, with the help of "BufferSize". So, I guess the function
> does not become more difficult to work with after this patch.
> 
> Reviewed-by: Laszlo Ersek 
> 
> (I hope that Star and/or Jiewen will also R-b this patch, possibly with
> the updated code comment.)
> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v7 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Jian J Wang]

> v7:
>   Merge memory map after filtering code

Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 
---
 MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
 MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +
 MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h b/MdeModulePkg/Core/Dxe/DxeMain.h
index 1a0babba71..07b86ba696 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.h
+++ b/MdeModulePkg/Core/Dxe/DxeMain.h
@@ -2948,4 +2948,22 @@ ApplyMemoryProtectionPolicy (
   IN  UINT64Length
   );
 
+/**
+  Merge continous memory map entries whose have same attributes.
+
+  @param  MemoryMap   A pointer to the buffer in which firmware places
+  the current memory map.
+  @param  MemoryMapSize   A pointer to the size, in bytes, of the
+  MemoryMap buffer. On input, this is the size of
+  the current memory map.  On output,
+  it is the size of new memory map after merge.
+  @param  DescriptorSize  Size, in bytes, of an individual 
EFI_MEMORY_DESCRIPTOR.
+**/
+VOID
+MergeMemoryMap (
+  IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
+  IN OUT UINTN  *MemoryMapSize,
+  IN UINTN  DescriptorSize
+  );
+
 #endif
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index f1e4a37f2a..9ff73efdfa 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1687,6 +1687,7 @@ CoreGetMemoryMap (
   EFI_GCD_MAP_ENTRY MergeGcdMapEntry;
   EFI_MEMORY_TYPE   Type;
   EFI_MEMORY_DESCRIPTOR *MemoryMapStart;
+  EFI_MEMORY_DESCRIPTOR *MemoryMapEnd;
 
   //
   // Make sure the parameters are valid
@@ -1896,6 +1897,26 @@ CoreGetMemoryMap (
   //
   BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
 
+  //
+  // Note: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
+  //   set attributes and change memory paging attribute accordingly.
+  //   But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
+  //   value from Capabilities in GCD memory map. This might cause
+  //   boot problems. Clearing all paging related capabilities can
+  //   workaround it. Following code is supposed to be removed once
+  //   the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
+  //   UEFI spec and adopted by both EDK-II Core and all supported
+  //   OSs.
+  //
+  MemoryMapEnd = MemoryMap;
+  MemoryMap = MemoryMapStart;
+  while (MemoryMap < MemoryMapEnd) {
+MemoryMap->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
+  EFI_MEMORY_XP);
+MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);
+  }
+  MergeMemoryMap (MemoryMapStart, , Size);
+
   Status = EFI_SUCCESS;
 
 Done:
diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c 
b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
index 6cf5edcbe5..75d9b14c1f 100644
--- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
+++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
@@ -182,7 +182,6 @@ SortMemoryMap (
  it is the size of new memory map after merge.
   @param  DescriptorSize Size, in bytes, of an individual 
EFI_MEMORY_DESCRIPTOR.
 **/
-STATIC
 VOID
 MergeMemoryMap (
   IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
-- 
2.14.1.windows.1

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

[edk2] [PATCH v7 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Jian J Wang]

> v7:
>No change.

> v6:
>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP

> v5:
>Coding style clean-up

> v4:
> a. Remove DoUpdate and check attributes mismatch all the time to avoid
>a logic hole
> b. Add warning message if failed to update capability
> c. Add local variable to hold new attributes to make code cleaner

> v3:
> a. Add comment to explain more on updating memory capabilities
> b. Fix logic hole in updating attributes
> c. Instead of checking illegal memory space address and size, use return
>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
>cannot be updated with new capabilities.

> v2
> a. Fix an issue which will cause setting capability failure if size is smaller
>than a page.

More than one entry of RT_CODE memory might cause boot problem for some
old OSs. This patch will fix this issue to keep OS compatibility as much
as possible.

More detailed information, please refer to
https://bugzilla.tianocore.org/show_bug.cgi?id=753

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
Tested-by: Laszlo Ersek 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +++-
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index 309f448a83..db41fa401f 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
   return Status;
 }
 
+/**
+ Check if Execute Disable feature is enabled or not.
+**/
+BOOLEAN
+IsExecuteDisableEnabled (
+  VOID
+  )
+{
+  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
+
+  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
+  return (MsrEfer.Bits.NXE == 1);
+}
+
 /**
   Update GCD memory space attributes according to current page table setup.
 **/
@@ -790,7 +804,7 @@ RefreshGcdMemoryAttributesFromPaging (
   UINT64  PageStartAddress;
   UINT64  Attributes;
   UINT64  Capabilities;
-  BOOLEAN DoUpdate;
+  UINT64  NewAttributes;
   UINTN   Index;
 
   //
@@ -802,17 +816,50 @@ RefreshGcdMemoryAttributesFromPaging (
 
   GetCurrentPagingContext ();
 
-  DoUpdate  = FALSE;
-  Capabilities  = 0;
-  Attributes= 0;
-  BaseAddress   = 0;
-  PageLength= 0;
+  Attributes  = 0;
+  NewAttributes   = 0;
+  BaseAddress = 0;
+  PageLength  = 0;
+
+  if (IsExecuteDisableEnabled ()) {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP | EFI_MEMORY_XP;
+  } else {
+Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP;
+  }
 
   for (Index = 0; Index < NumberOfDescriptors; Index++) {
 if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeNonExistent) {
   continue;
 }
 
+//
+// Sync the actual paging related capabilities back to GCD service first.
+// As a side effect (good one), this can also help to avoid unnecessary
+// memory map entries due to the different capabilities of the same type
+// memory, such as multiple RT_CODE and RT_DATA entries in memory map,
+// which could cause boot failure of some old Linux distro (before v4.3).
+//
+Status = gDS->SetMemorySpaceCapabilities (
+MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].Length,
+MemorySpaceMap[Index].Capabilities | Capabilities
+);
+if (EFI_ERROR (Status)) {
+  //
+  // If we cannot udpate the capabilities, we cannot update its
+  // attributes either. So just simply skip current block of memory.
+  //
+  DEBUG ((
+DEBUG_WARN,
+"Failed to update capability: [%lu] %016lx - %016lx (%016lx -> 
%016lx)\r\n",
+(UINT64)Index, MemorySpaceMap[Index].BaseAddress,
+MemorySpaceMap[Index].BaseAddress + MemorySpaceMap[Index].Length - 1,
+MemorySpaceMap[Index].Capabilities,
+MemorySpaceMap[Index].Capabilities | Capabilities
+));
+  continue;
+}
+
 if (MemorySpaceMap[Index].BaseAddress >= (BaseAddress + PageLength)) {
   //
   // Current memory space starts at a new page. Resetting PageLength will
@@ -826,7 +873,9 @@ RefreshGcdMemoryAttributesFromPaging (
   PageLength -= (MemorySpaceMap[Index].BaseAddress - BaseAddress);
 }
 
-// Sync real page attributes to GCD
+//
+// Sync actual page attributes to GCD
+//
 BaseAddress   = MemorySpaceMap[Index].BaseAddress;
 MemorySpaceLength = MemorySpaceMap[Index].Length;
 while (MemorySpaceLength > 0) {

Re: [edk2] [Patch] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

[Long, Qin]

Reviewed-by: Long Qin 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Wu, Jiaxin 
Sent: Friday, November 17, 2017 11:57 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Long, Qin ; Fu, Siyuan 
; Wu, Jiaxin 
Subject: [Patch] CryptoPkg/TlsLib: Change the return type of TlsInitialize().

Currently, in TlsInitialize(), neither the return status of OPENSSL_init_ssl(0, 
or 1) nor the return code of RandomSeed (TRUE or FALSE) is not checked. Also 
VOID is used as the return type of TlsInitialize(), which can't be used to 
capture the returned value for the error handling.

>From Long Qin (CryptoPkg owner):
The early version of OPENSSL_init_ssl() use the "VOID" as the return value, 
which was updated to "int" later because the function changes can fail.

So, this patch is to change the return type of TlsInitialize() to follow up the 
OPENSSL_init_ssl() update.

Cc: Ye Ting 
Cc: Long Qin 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 CryptoPkg/Include/Library/TlsLib.h |  7 +--  
CryptoPkg/Library/TlsLib/TlsInit.c | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/CryptoPkg/Include/Library/TlsLib.h 
b/CryptoPkg/Include/Library/TlsLib.h
index fa6cb99..b69d513 100644
--- a/CryptoPkg/Include/Library/TlsLib.h
+++ b/CryptoPkg/Include/Library/TlsLib.h
@@ -1,9 +1,9 @@
 /** @file
   Defines TLS Library APIs.
 
-Copyright (c) 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at  
http://opensource.org/licenses/bsd-license.php
 
@@ -20,12 +20,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   );
 
diff --git a/CryptoPkg/Library/TlsLib/TlsInit.c 
b/CryptoPkg/Library/TlsLib/TlsInit.c
index e524647..a530ff7 100644
--- a/CryptoPkg/Library/TlsLib/TlsInit.c
+++ b/CryptoPkg/Library/TlsLib/TlsInit.c
@@ -20,30 +20,38 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   This function registers ciphers and digests used directly and indirectly
   by SSL/TLS, and initializes the readable error messages.
   This function must be called before any other action takes places.
 
+  @retval TRUE   The OpenSSL library has been initialized.
+  @retval FALSE  Failed to initialize the OpenSSL library.
+
 **/
-VOID
+BOOLEAN
 EFIAPI
 TlsInitialize (
   VOID
   )
 {
+  INTNRet;
+
   //
   // Performs initialization of crypto and ssl library, and loads required
   // algorithms.
   //
-  OPENSSL_init_ssl (
-OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
-NULL
-);
+  Ret = OPENSSL_init_ssl (
+  OPENSSL_INIT_LOAD_SSL_STRINGS | OPENSSL_INIT_LOAD_CRYPTO_STRINGS,
+  NULL
+  );
+  if (Ret != 1) {
+return FALSE;
+  }
 
   //
   // Initialize the pseudorandom number generator.
   //
-  RandomSeed (NULL, 0);
+  return RandomSeed (NULL, 0);
 }
 
 /**
   Free an allocated SSL_CTX object.
 
--
1.9.5.msysgit.1

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

Re: [edk2] [PATCH v6 0/2] Fix multiple entries of RT_CODE in memory map

[Laszlo Ersek]

On 11/16/17 08:26, Jian J Wang wrote:
>> v6
>> a. Add workaround in core to filter out all paging related capabilities.
>>This is to fix boot issue in Fedora 26 and Windows Server 2016.
>> b. Add code to check if EFI_MEMORY_XP should be added for GCD memory map
> 
> More than one entry of RT_CODE memory might cause boot problem for some
> old OSs. This patch will fix this issue to keep OS compatibility as much
> as possible.
> 
> Jian J Wang (2):
>   MdeModulePkg/DxeCore: Filter out all paging capabilities
>   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
> 
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 
> +++-
>  2 files changed, 90 insertions(+), 21 deletions(-)
> 

Series
Tested-by: Laszlo Ersek 

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

Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Laszlo Ersek]

On 11/16/17 08:27, Jian J Wang wrote:
>> v6:
>>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP

Another change relative to v5 is the fixing of the first DEBUG_WARN
message -- in my v5 review I had missed that the DEBUG_WARN arguments
didn't match the preceding gDS->SetMemorySpaceCapabilities() arguments.

Yet another change that could have been (maybe) possible for this patch
is to replace the remaining occurrences of EFI_MEMORY_PAGETYPE_MASK with
"Capabilities". Namely, in v6, the attributes are enforced on a mask
that is possibly wider than supported by the hardware (i.e., in case NX
is not supported).

However, this should not be a functionality problem, because with NX
unavailable, the GetAttributesFromPageEntry() function should never
return EFI_MEMORY_XP. Thus, the "wider than needed" attribute setting
will just clear EFI_MEMORY_XP.

Reviewed-by: Laszlo Ersek 

(I hope that Star and/or Jiewen will also R-b this patch.)

In addition, I will follow up with test results for the series.

Thanks
Laszlo

>> v5:
>>Coding style clean-up
> 
>> v4:
>> a. Remove DoUpdate and check attributes mismatch all the time to avoid
>>a logic hole
>> b. Add warning message if failed to update capability
>> c. Add local variable to hold new attributes to make code cleaner
> 
>> v3:
>> a. Add comment to explain more on updating memory capabilities
>> b. Fix logic hole in updating attributes
>> c. Instead of checking illegal memory space address and size, use return
>>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
>>cannot be updated with new capabilities.
> 
>> v2
>> a. Fix an issue which will cause setting capability failure if size is 
>> smaller
>>than a page.
> 
> More than one entry of RT_CODE memory might cause boot problem for some
> old OSs. This patch will fix this issue to keep OS compatibility as much
> as possible.
> 
> More detailed information, please refer to
> https://bugzilla.tianocore.org/show_bug.cgi?id=753
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 
> +++-
>  1 file changed, 73 insertions(+), 21 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c 
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index d312eb66f8..3297c1900b 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
>return Status;
>  }
>  
> +/**
> + Check if Execute Disable feature is enabled or not.
> +**/
> +BOOLEAN
> +IsExecuteDisableEnabled (
> +  VOID
> +  )
> +{
> +  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
> +
> +  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
> +  return (MsrEfer.Bits.NXE == 1);
> +}
> +
>  /**
>Update GCD memory space attributes according to current page table setup.
>  **/
> @@ -790,7 +804,7 @@ RefreshGcdMemoryAttributesFromPaging (
>UINT64  PageStartAddress;
>UINT64  Attributes;
>UINT64  Capabilities;
> -  BOOLEAN DoUpdate;
> +  UINT64  NewAttributes;
>UINTN   Index;
>  
>//
> @@ -802,17 +816,50 @@ RefreshGcdMemoryAttributesFromPaging (
>  
>GetCurrentPagingContext ();
>  
> -  DoUpdate  = FALSE;
> -  Capabilities  = 0;
> -  Attributes= 0;
> -  BaseAddress   = 0;
> -  PageLength= 0;
> +  Attributes  = 0;
> +  NewAttributes   = 0;
> +  BaseAddress = 0;
> +  PageLength  = 0;
> +
> +  if (IsExecuteDisableEnabled ()) {
> +Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP | EFI_MEMORY_XP;
> +  } else {
> +Capabilities = EFI_MEMORY_RO | EFI_MEMORY_RP;
> +  }
>  
>for (Index = 0; Index < NumberOfDescriptors; Index++) {
>  if (MemorySpaceMap[Index].GcdMemoryType == EfiGcdMemoryTypeNonExistent) {
>continue;
>  }
>  
> +//
> +// Sync the actual paging related capabilities back to GCD service first.
> +// As a side effect (good one), this can also help to avoid unnecessary
> +// memory map entries due to the different capabilities of the same type
> +// memory, such as multiple RT_CODE and RT_DATA entries in memory map,
> +// which could cause boot failure of some old Linux distro (before v4.3).
> +//
> +Status = gDS->SetMemorySpaceCapabilities (
> +MemorySpaceMap[Index].BaseAddress,
> +MemorySpaceMap[Index].Length,
> +MemorySpaceMap[Index].Capabilities | Capabilities
> +);
> +if (EFI_ERROR (Status)) {
> +  //
> +  // If we cannot 

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Laszlo Ersek]

On 11/16/17 08:26, Jian J Wang wrote:
> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> set attributes and change memory paging attribute accordingly.
> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> value from Capabilities in GCD memory map. This might cause
> boot problems. Clearing all paging related capabilities can
> workaround it. The code added in this patch is supposed to
> be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> is clarified in UEFI spec and adopted by both EDK-II Core and
> all supported OSs.
> 
> Cc: Jiewen Yao 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c 
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index c9219cc068..783b576e35 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
>//
>BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
>  
> +  //
> +  // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as 
> really
> +  // set attributes and change memory paging attribute 
> accordingly.
> +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> +  // value from Capabilities in GCD memory map. This might cause
> +  // boot problems. Clearing all paging related capabilities can
> +  // workaround it. Following code is supposed to be removed once
> +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in
> +  // UEFI spec and adopted by both EDK-II Core and all supported
> +  // OSs.
> +  //
> +  while (MemoryMapStart < MemoryMap) {
> +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO |
> +   EFI_MEMORY_XP);
> +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
> +  }
> +
>Status = EFI_SUCCESS;
>  
>  Done:
> 

OK, let me check if I understand the discussion thus far, for this patch:

- Ard asked about EFI_MEMORY_WP, but clearing that bit is not necessary
because CpuDxe does not add it anyway, in the GCD memory space map.

- The code comment might be updated (according to Jiewen's suggestion)
before pushing the patch. I don't have any particular opinion about the
comment.

- If I understand correctly, Jiewen agrees with applying both patches in
this series.


I have one superficial comment on this patch: in the CoreGetMemoryMap()
function, we keep "MemoryMapStart" unchanged (after the initial
assignment), and keep incrementing "MemoryMap". At the location where
the new code is being added, "MemoryMap" points one past the last
descriptor, and "MemoryMapStart" still points to the first one.

In order to keep this property for possible future "scans" of the full
map, I would prefer keeping "MemoryMapStart" unchanged in this location,
and using an independent loop variable.

... On the other hand, we can easily restore "MemoryMapStart", should it
be necessary, with the help of "BufferSize". So, I guess the function
does not become more difficult to work with after this patch.

Reviewed-by: Laszlo Ersek 

(I hope that Star and/or Jiewen will also R-b this patch, possibly with
the updated code comment.)

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

Re: [edk2] [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

[Pete Batard]

Hi Liming,

On 2017.11.20 08:46, Gao, Liming wrote:

   Here, I suggest to mention VS version 15.2 or above, because vswhere.exe 
depends on this version.
   After later, you may also update this version to 15.4 for ARM and AARCH64 
support.


I assume you mean replacing the "Microsoft Visual Studio 2017 
Professional or Community Edition" from the comment with something like 
"Microsoft Visual Studio 2017 version 15.2 or later", right?


If so, I will do that and submit a v3.

Do you think the possibility of adding vswhere.exe to 
BaseTools\Bin\Win32 is also worth exploring? For one thing this would 
solve the issue of locating 15.2 VS 2017 (as well as nonstandard 
installations that may have removed the installer directory), and the 
executable is both Open Source (MIT) and redistributable.


The other possibility of course is to let pre 15.2 VS2017 fail the 
detection process, and expect users to get a hint that they need an 
updated version from the comments in tools_def...


Regards,

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

Re: [edk2] [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register values

[Duran, Leo]

Are we OK with pushing this patch-set?
If so, is that something you can do, Ray?

Thanks,
Leo.

> -Original Message-
> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
> Sent: Wednesday, November 08, 2017 12:30 AM
> To: Duran, Leo ; edk2-devel@lists.01.org
> Subject: RE: [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register
> values
> 
> Reviewed-by: Ruiyu Ni 
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Leo Duran [mailto:leo.du...@amd.com]
> > Sent: Wednesday, November 1, 2017 1:55 AM
> > To: edk2-devel@lists.01.org
> > Cc: Leo Duran ; Ni, Ruiyu 
> > Subject: [PATCH 1/2] PcAtChipsetPkg: Define FixePCD's for RTC register
> > values
> >
> > Define FixedPCD's to replace macros in RTC driver, to allow for
> > platform- specific configurations.
> >
> > Cc: Ruiyu Ni 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leo Duran 
> > ---
> >  PcAtChipsetPkg/PcAtChipsetPkg.dec | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > index b0b2b62..f11d204 100644
> > --- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > @@ -5,6 +5,7 @@
> >  # PcAt defacto standard.
> >  #
> >  # Copyright (c) 2009 - 2015, Intel Corporation. All rights
> > reserved.
> > +# Copyright (c) 2017, AMD Inc. All rights reserved.
> >  #
> >  # This program and the accompanying materials  # are licensed and
> > made available under the terms and conditions of the BSD License @@
> > -181,5
> > +182,17 @@
> ># @Prompt Reset Control Register value for cold reset
> >
> >
> gPcAtChipsetPkgTokenSpaceGuid.PcdResetControlValueColdReset|0xFE|UI
> > NT8|0x001A
> >
> > +  ## Specifies the initial value for Register_A in RTC.
> > +  # @Prompt Initial value for Register_A in RTC.
> > +
> > +
> >
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterA|0x26|UINT8|
> > 0
> > + x001B
> > +
> > +  ## Specifies the initial value for Register_B in RTC.
> > +  # @Prompt Initial value for Register_B in RTC.
> > +
> > +
> >
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterB|0x02|UINT8|
> > 0
> > + x001C
> > +
> > +  ## Specifies the initial value for Register_D in RTC.
> > +  # @Prompt Initial value for Register_D in RTC.
> > +
> > +
> >
> gPcAtChipsetPkgTokenSpaceGuid.PcdInitialValueRtcRegisterD|0x00|UINT8|
> > 0
> > + x001D
> > +
> >  [UserExtensions.TianoCore."ExtraFiles"]
> >PcAtChipsetPkgExtra.uni
> > --
> > 2.7.4

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

Re: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

[Supreeth Venkatesh]

Rebecca,

Thanks for your comment. I too did wonder that.
However, "MM" abbreviation is used multiple times
in PI Specification v1.5  "Volume 4: Management Mode Core Interface"
Also, since the package is going to be called "StandaloneMmPkg" and not just 
MM, thereby avoiding
intersection with Memory Management.

Supreeth

-Original Message-
From: Rebecca Cran [mailto:rebe...@bluestop.org]
Sent: Saturday, November 18, 2017 2:11 PM
To: Supreeth Venkatesh ; edk2-devel@lists.01.org
Cc: jiewen@intel.com; leif.lindh...@linaro.org
Subject: Re: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

Could there be any confusion between 'MM' meaning Management Mode and Memory 
Management?


--
Rebecca


On 11/17/2017 4:07 PM, Supreeth Venkatesh wrote:
> ***
> PI Specification v1.5  "Volume 4: Management Mode Core Interface"
> introduces the concept of MM Standalone Mode. Initialization of this mode
> can be done during the SEC phase (Section 1.5.2).
> On ARMv8-A systems, ARM Trusted Firmware is responsible for launching
> the normal world firmware e.g. UEFI.
>
> The Standalone MM environment is instantiated in Secure EL0 as a separate
> firmware volume. It executes as BL32 Image under control of ARM TF
> which is instantiated in EL3. Both components execute in the AArch64 
> execution state.
> This patchset will build upon the StandaloneSmmPkg module originally
> contributed by Intel.
>
> This package can be used in conjunction with ARM Trusted Firmware
> to recreate a simple MM secure environment that demonstrates communication
> between two UEFI images where one is executing in the normal world and the 
> other is
> executing in the secure world.
>
> The normal world image includes:
> MM Communication DXE runtime driver that implements the protocol for 
> communication
> with the MM environment in the secure world.
>
> The secure world image includes:
> The MM Standalone framework.
>
> This RFC patchset includes the proposed organization/structure and
> has architecture agnostic core changes only as a first pass.
> Once the organization/structure have been agreed upon, patchset for
> supporting libraries and AARCH64 implementation will be sent.
>
> Steps to build MM Standalone images
> In user preferred "work" directory, execute the following shell commands
>
> git clone https://github.com/tianocore/edk2.git
> git checkout master
>
> git clone https://github.com/tianocore/edk2-platforms.git
> git checkout master
>
> mkdir arm-tf
> cd arm-tf
> git clone https://github.com/ARM-software/arm-trusted-firmware.git .
> git checkout master
> cd ..
>
> git clone https://git.linaro.org/uefi/uefi-tools.git .
> git checkout master
>
> The following will build the MM Standalone image which runs in secure world.
> ./uefi-tools/edk2-build.sh -b DEBUG fvp_mm_standalone
>
> The follwing will build the normal world UEFI image, ARM Trusted Firmware and
> a Firmware Image Package (FIP) that includes both the UEFI images.
> ./uefi-tools/edk2-build.sh -a ./arm-tf -b DEBUG fvp_mm_normal
>
> Boot Loader Stage 1 (BL1) binary and combined arm-tf/uefi firmware image 
> package (fip) binary will be generated at:
>
> Build Output
> Build/ArmVExpress-FVP-AArch64-MM-Normal/DEBUG_GCC5/FV/bl1.bin
> Build/ArmVExpress-FVP-AArch64-MM-Normal/DEBUG_GCC5/FV/fip.bin
>
> Steps to run MM Standalone image
> 1. Download the ARMv8 Architecture FVP from
>   https://silver.arm.com/download/download.tm?pv=3744408=1424570
>   For more information, please refer
>   https://developer.arm.com/products/system-design/fixed-virtual-platforms
> 2.  Install FVP into preferred "work" directory.
> 3.  Create a shell script "run_mm.sh" in the same folder where 
> "FVP_Base_AEMv8A-AEMv8A" is present.
>   Sample Shell script below:
>  ./FVP_Base_AEMv8A-AEMv8A
>  -C cache_state_modelled=0
>  -C bp.secure_memory=1
>  -C bp.tzc_400.diagnostics=1
>  -C bp.pl011_uart0.untimed_fifos=0
>  -C cluster1.NUM_CORES=4
>  -C cluster0.NUM_CORES=4
>  -C bp.pl011_uart0.out_file=uart0.output
>  -C bp.pl011_uart1.out_file=uart1.output
>  -C bp.pl011_uart2.out_file=uart2.output
>  -C bp.pl011_uart3.out_file=uart3.output
>  -C bp.secureflashloader.fname=""
>  -C bp.flashloader0.fname=""
>  -S -R
> 4. ./run_mm.sh
> 5. Output can be seen on FVP console.
> 6. The normal world will boot to the UEFI shell.
>
> Sample Output
>
> MM Standalone Output (FVP UART2)
> SPM Version: Major=0x0, Minor=0x1
> NumSpMemRegions - 0x6
> SpMemBase   - 0xFF20
> SpMemLimit  - 0x1
> SpImageBase - 0xFF20
> SpStackBase - 0xFF61
> SpHeapBase  - 0xFF62
> SpNsCommBufBase - 0xFF60
> SpSharedBufBase - 0xFF50
> SpImageSize - 0x30
> SpPcpuStackSize - 0x2000
> SpHeapSize  - 0x9E
> SpNsCommBufSize - 0x1
> SpPcpuSharedBufSize - 0x2
> NumCpus - 0x8
> CpuInfo - 0xFF500680
> Mpidr   - 0x8000
> LinearId- 0x0
> 

Re: [edk2] [PATCH v2 0/4] UefiCpuPkg, OvmfPkg: add reset vector docs, tweak temp stack / RAM

[Dong, Eric]

Hi Laszlo,

Reviewed-by: Eric Dong 

I'm ok with this change, Sorry for later response.

Thanks,
Eric
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Saturday, November 18, 2017 1:15 AM
> To: edk2-devel-01 
> Cc: Justen, Jordan L ; Dong, Eric
> ; Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH v2 0/4] UefiCpuPkg, OvmfPkg: add reset vector
> docs, tweak temp stack / RAM
> 
> On 11/15/17 22:56, Laszlo Ersek wrote:
> > Repo:   https://github.com/lersek/edk2.git
> > Branch: temp_ram_tweaks_v2
> >
> > This is a series for
> >
> >   https://bugzilla.tianocore.org/show_bug.cgi?id=747
> >
> > specifically an update on the v1 series at
> >
> >   https://lists.01.org/pipermail/edk2-devel/2017-November/017239.html
> >
> > Each patch has its notes section on the changes relative to v1.
> >
> > I re-ran the unit tests described in some of the patches; in addition
> > to the functional tests and my usual regression tests.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Eric Dong 
> > Cc: Jordan Justen 
> >
> > Thanks
> > Laszlo
> >
> > Laszlo Ersek (4):
> >   UefiCpuPkg/ResetVector/Vtf0: document segment register setup
> >   OvmfPkg/Sec/Ia32: seed the temporary RAM with
> PcdInitValueInTempStack
> >   OvmfPkg/Sec/X64: seed the temporary RAM with
> PcdInitValueInTempStack
> >   OvmfPkg: restore temporary SEC/PEI RAM size to 64KB
> >
> >  OvmfPkg/OvmfPkgIa32.fdf |  2 +-
> >  OvmfPkg/OvmfPkgIa32X64.fdf  |  2 +-
> >  OvmfPkg/OvmfPkgX64.fdf  |  2 +-
> >  OvmfPkg/Sec/Ia32/SecEntry.nasm  | 18 +
> >  OvmfPkg/Sec/SecMain.inf |  1 +
> >  OvmfPkg/Sec/X64/SecEntry.nasm   | 21
> 
> >  UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm |  6 ++
> >  UefiCpuPkg/ResetVector/Vtf0/Main.asm|  5 +
> >  8 files changed, 54 insertions(+), 3 deletions(-)
> >
> 
> Pushed as commit range 1195b8578764..d41fd8e839a3.
> 
> (I didn't get a maintainer review from Eric for patch #1, but it adds only
> comments (no regressions possible) and Ard and Jordan reviewed that too.
> My queue is overflowing. :/)
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] 答复: [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Paulo Alcantara]

Hi Jeff,

(sorry for the late response)

On 11/17/2017 5:24 AM, Fan Jeff wrote:

Paulo,


I don't understand why you - 1 when calculating EIP offset in image, it 
confused me.


That's an offset relative to the PE/COFF image base: 0 - (ImageBase + 
ImageBaseSize - 1)


Doesn't that look right to you?

Thanks
Paulo




+  for (;;) {
+    //
+    // Print stack frame in the following format:
+    //
+    // #  @ + (RBP) in [ | ]
+    //
+    InternalPrintMessage (
+  "%d 0x%016lx @ 0x%016lx+0x%x (0x%016lx) in %a\n",
+  *UnwoundStacksCount - 1,
+  Rip,
+  ImageBase,
+  Rip - ImageBase - 1,   // 
+  Rbp,
+  PdbFileName
+  );
+

Jeff





*发件人:* edk2-devel  代表 Paulo 
Alcantara 

*发送时间:* 2017年11月17日 5:56
*收件人:* edk2-devel@lists.01.org
*抄送:* Laszlo Ersek; Eric Dong
*主题:* [edk2] [RFC v3 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add 
stack trace support

This patch adds stack trace support during a X64 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 
---
  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 
376 +++-

  1 file changed, 374 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c

index 65f0cff680..fe776ccc2d 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,6 +14,11 @@

  #include "CpuExceptionCommon.h"

+//
+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
  /**
    Return address map of exception handler template so that C code can 
generate

    exception tables.
@@ -242,6 +247,357 @@ DumpCpuContext (
  );
  }

+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBase    Base address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+STATIC
+VOID
+GetPdbFileName (
+  IN  UINTN    ImageBase,
+  OUT CHAR8    **PdbAbsoluteFilePath,
+  OUT CHAR8    **PdbFileName
+  )
+{
+  VOID   *PdbPointer;
+  CHAR8  *Str;
+
+  //
+  // Get PDB file name from PE/COFF image
+  //
+  PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *)ImageBase);
+  if (PdbPointer == NULL) {
+    //
+    // No PDB file name found. Set it to an unknown file name.
+    //
+    *PdbFileName = (CHAR8 *)mUnknownPdbFileName;
+    if (PdbAbsoluteFilePath != NULL) {
+  *PdbAbsoluteFilePath = NULL;
+    }
+  } else {
+    //
+    // Get file name portion out of PDB file in PE/COFF image
+    //
+    Str = (CHAR8 *)((UINTN)PdbPointer +
+    AsciiStrLen ((CHAR8 *)PdbPointer) - sizeof *Str);
+    for (; *Str != '/' && *Str != '\\'; Str--) {
+  ;
+    }
+
+    //
+    // Set PDB file name (also skip trailing path separator: '/' or '\\')
+    //
+    *PdbFileName = Str + 1;
+
+    if (PdbAbsoluteFilePath != NULL) {
+  //
+  // Set absolute file path of PDB file
+  //
+  *PdbAbsoluteFilePath = PdbPointer;
+    }
+  }
+}
+
+/**
+  Dump stack contents.
+
+  @param[in]  CurrentRsp Current stack pointer address.
+  @param[in]  UnwoundStacksCount  Count of unwound stack frames.
+**/
+STATIC
+VOID
+DumpStackContents (
+  IN UINT64  CurrentRsp,
+  IN INTN    UnwoundStacksCount
+  )
+{
+  //
+  // Check for proper stack pointer alignment
+  //
+  if (((UINTN)CurrentRsp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+    InternalPrintMessage (" Unaligned stack pointer. \n");
+    return;
+  }
+
+  //
+  // Dump out stack contents
+  //
+  InternalPrintMessage ("\nStack dump:\n");
+  while (UnwoundStacksCount-- > 0) {
+    InternalPrintMessage (
+  "0x%016lx: %016lx %016lx\n",
+  CurrentRsp,
+  *(UINT64 *)CurrentRsp,
+  *(UINT64 *)((UINTN)CurrentRsp + 8)
+  );
+
+    //
+    // Point to next stack
+    //
+    CurrentRsp += CPU_STACK_ALIGNMENT;
+  }
+}
+
+/**
+  Dump all image module names from call stack.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+**/
+STATIC
+VOID
+DumpImageModuleNames (
+  IN EFI_SYSTEM_CONTEXT   SystemContext
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Rip;
+  UINTN   ImageBase;
+  VOID    *EntryPoint;
+  CHAR8   *PdbAbsoluteFilePath;
+  CHAR8   *PdbFileName;
+  UINT64  Rbp;
+  UINTN   LastImageBase;
+
+  //
+  // Set current RIP address
+  //
+  Rip = SystemContext.SystemContextX64->Rip;
+
+  //
+  // Set current frame pointer address
+  //
+  

Re: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

[Paulo Alcantara]

Hi Jiewen,

(sorry for the late response)

On 11/17/2017 1:43 AM, Yao, Jiewen wrote:

Thanks for your reply. Comments below:


-Original Message-
From: Paulo Alcantara [mailto:pca...@zytor.com]
Sent: Friday, November 17, 2017 6:13 AM
To: Yao, Jiewen 
Cc: Paulo Alcantara ; edk2-devel@lists.01.org; Laszlo Ersek
; Dong, Eric 
Subject: RE: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add
stack trace support

Hi Jiewen,

On Wed, November 15, 2017 11:57 pm, Yao, Jiewen wrote:

Hi Paulo
Thanks to bring this cool feature.

I have same feeling as Jeff Fan. It is great!

I have some questions, hope you can clarify.
1) Would you please let us know which tool change is validated? Such as
MSVC, or GCC?


GCC only. This should not work on MSVC because it relies on frame pointers.


[Jiewen] Not work is OK.
But my question is more about: Have you tested? Or have you tried?
Do you see basic exception information can be dumped without any problem for 
MSVC?
Or do you see system crash immediately for MSVC?


No, I haven't tried it. I built it with VS2015 and just run 'objdump -x 
-D' in an arbitrary .efi to check whether RBP was being used in 
function's prologues. They weren't and then I didn't even give it try. 
I'll test it though and then let you know its behavior.







2) Would you please let us know which phase is validated? Such as PEI
PreMemory, PEI PostMemory, DXE, SMM?


DXE. I'm currently testing it by placing a random "CpuBreakpoint ()" in
PartitionDxe driver.



[Jiewen] Ummm.
Based upon the fact that the code you update may be used in all those phases.
I recommend to validate them in the final patch.


Sure.





3) Would you please let us know if there is any special condition
validated? Such as code is in an interrupt handler, SMM initialization
code, thunk code during mode switch, etc.
I ask this because I have seen lots of discussion on sanity check, to
avoid double exception.


At the moment I'm only ensuring proper aligned RSP and ESP values. But we
still need to validate the RIP values, etc. as Andrew and Brian suggested.


[Jiewen] OK. I look forward to seeing your patch to validate more.
Same as #2. I suggest you validate all those corner cases in the final patch.


I will for sure.




4) We supported some security feature to create a hole in normal memory
map, such as PageGuard, StackGuard, SMM communication protection, etc.
Accessing those memory directly will cause #PF immediately.
Would you please let us know how we detect that case, to avoid RIP or RSP
fail to the non-present page?


Sorry. I have no idea :-( I'd hope to get some help from you guys.



[Jiewen] One possible solution is to scan page table, before access this 
address, to make sure you are accessing present page.
You can also filer invalid address directly by checking CPUID physical address 
bit before that. The invalid address will cause #GP instead of #PF.


Oh, looks like a great solution. I'll try them out and let you know if 
it worked. Thank you!!




All I all, I would like to clarify the goal for exception lib: whatever 
exception condition the BIOS meets, the exception handler can always dump the 
*basic* exception information and halt.
The missing of advanced symbol info is acceptable. But system crash, when we 
want to dump the advanced info, is not the best choice.


You're right. I'll make sure to validate it as much as possible and 
avoid such issues. Please, give me some more time because currently I've 
got pretty busy with something else.


I really appreciate your help. Thanks!

Paulo






5) May I know why we check RIP < ImageBase? Is that legal or illegal if
RIP > ImageBase+ImageSize, but RIP in another PE/COFF image?


That check was a wrong assumption that I had in the beginning. RIP may
point to either lower or higher addresses where the other PE/COFF images
are located. Fixed it in v3.



[Jiewen] Great. Thanks.



Sorry for the delay in the response. I'm only able to work on this in my
free time.

Thanks!
Paulo


+//
+// Check if RIP is within another PE/COFF image base address
+//
+if (Rip < ImageBase) {
+  //
+  // Search for the respective PE/COFF image based on RIP
+  //


Thank you
Yao Jiewen



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Paulo
Alcantara
Sent: Thursday, November 16, 2017 9:18 AM
To: edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Dong, Eric 
Subject: [edk2] [RFC v2 1/3] UefiCpuPkg/CpuExceptionHandlerLib/X64: Add
stack
trace support

This patch adds stack trace support during a X64 CPU exception.

It will dump out back trace, stack contents as well as image module
names that were part of the call stack.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Eric Dong 
Cc: Laszlo Ersek 
Signed-off-by: Paulo Alcantara 

[edk2] [PATCH edk2-non-osi 1/2] Hisilicon/D0x/Sas: fix occasional exception

[Heyi Guo]

There is a temporary variable in SAS driver which was not initialized
with SAS disk, so the value of this variable depends on the unknown
stack content. Later it will be used as source buffer in gBS->CopyMem,
and a translation fault exception would occur if the value is beyond
valid memory address as a pointer. Details can be found in
https://bugs.linaro.org/show_bug.cgi?id=3464

This patch is to fix this bug, avoiding to use uninitialized value
when connecting SAS disks.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi | Bin 98144 -> 98112 bytes
 Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi | Bin 116288 -> 112832 
bytes
 2 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi 
b/Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi
index c9b2ad6..c37b922 100644
Binary files a/Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi and 
b/Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi differ
diff --git a/Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi 
b/Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi
index 9a680c5..a57b8e1 100644
Binary files a/Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi and 
b/Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi differ
-- 
1.9.1

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

[edk2] [PATCH edk2-non-osi 2/2] Hisilicon/LpcSerialPortLib: return SUCCESS for SetAttributes

[Heyi Guo]

After EDK2 upgrades to 91cc526, SerialDxe will exit immediately if
SerialPortLib.SetAttributes returns error, and there will be no serial
port terminal in UEFI BDS. Since Hisilicon LPC serial port does not
support setting attributes, we change SerialPortSetAttributes in
LpcSerialPortLib to simply return SUCCESS to get around of this.

The issue can be found in https://bugs.linaro.org/show_bug.cgi?id=3464

It only affects Hisilicon D03 platform since only D03 uses LPC serial
port.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib | 
Bin 16942 -> 16950 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git 
a/Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib 
b/Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib
index d6ce068..00c5c2f 100644
Binary files 
a/Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib 
and 
b/Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib 
differ
-- 
1.9.1

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

[edk2] [PATCH edk2-non-osi 0/2] Fix Linaro RP bug 3464

[Heyi Guo]

We have found 2 bugs with Linaro Reference Platform bug 3464:
https://bugs.linaro.org/show_bug.cgi?id=3464
1. SAS driver might use uninitialized value which would cause system
exception;
2. LpcSerialPortLib used on D03 will cause SerialDxe initialized with
failure and exited immediately, which would cause no serial terminal
in BDS.

Patches with binary files can also be found in
https://github.com/hisilicon/OpenPlatformPkg/commits/rp-osi-bug-v4

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 

Heyi Guo (2):
  Hisilicon/D0x/Sas: fix occasional exception
  Hisilicon/LpcSerialPortLib: return SUCCESS for SetAttributes

 Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi | 
Bin 98144 -> 98112 bytes
 Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi | 
Bin 116288 -> 112832 bytes
 Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib | 
Bin 16942 -> 16950 bytes
 3 files changed, 0 insertions(+), 0 deletions(-)

-- 
1.9.1

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

[edk2] [PATCH 0/2] remove ARM BdsLib and FdtPlatformDxe

[Ard Biesheuvel]

Remove two pieces of legacy that are only used by platforms residing under
Platform/ARM in edk2-platforms, and really shouldn't serve as examples for
new contributions. So after migrating the code to edk2-platforms, remove it
from EDK2.

Ard Biesheuvel (2):
  EmbeddedPkg: remove FdtPlatformDxe
  ArmPkg: remove BdsLib and remaining ARM BDS related PCDs

 ArmPkg/ArmPkg.dec |8 -
 ArmPkg/Library/BdsLib/BdsAppLoader.c  |  253 
 ArmPkg/Library/BdsLib/BdsFilePath.c   | 1411 

 ArmPkg/Library/BdsLib/BdsHelper.c |  183 ---
 ArmPkg/Library/BdsLib/BdsInternal.h   |  111 --
 ArmPkg/Library/BdsLib/BdsLib.inf  |   69 -
 ArmPkg/Library/BdsLib/BdsLoadOption.c |  272 
 BeagleBoardPkg/BeagleBoardPkg.dsc |3 -
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c  |  461 ---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h  |  174 ---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |   64 -
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni |  109 --
 EmbeddedPkg/Drivers/FdtPlatformDxe/README.txt |   72 -
 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellDumpFdt.c |  279 
 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellSetFdt.c  |  468 ---
 EmbeddedPkg/EmbeddedPkg.dec   |6 -
 16 files changed, 3943 deletions(-)
 delete mode 100644 ArmPkg/Library/BdsLib/BdsAppLoader.c
 delete mode 100644 ArmPkg/Library/BdsLib/BdsFilePath.c
 delete mode 100644 ArmPkg/Library/BdsLib/BdsHelper.c
 delete mode 100644 ArmPkg/Library/BdsLib/BdsInternal.h
 delete mode 100644 ArmPkg/Library/BdsLib/BdsLib.inf
 delete mode 100644 ArmPkg/Library/BdsLib/BdsLoadOption.c
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/README.txt
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellDumpFdt.c
 delete mode 100644 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellSetFdt.c

-- 
2.11.0

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

[edk2] [PATCH 2/2] ArmPkg: remove BdsLib and remaining ARM BDS related PCDs

[Ard Biesheuvel]

With the last user FdtPlatformDxe removed, we can finally get rid of the
last bit of ARM BDS related cruft.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec |8 -
 ArmPkg/Library/BdsLib/BdsAppLoader.c  |  253 
 ArmPkg/Library/BdsLib/BdsFilePath.c   | 1411 
 ArmPkg/Library/BdsLib/BdsHelper.c |  183 ---
 ArmPkg/Library/BdsLib/BdsInternal.h   |  111 --
 ArmPkg/Library/BdsLib/BdsLib.inf  |   69 -
 ArmPkg/Library/BdsLib/BdsLoadOption.c |  272 
 BeagleBoardPkg/BeagleBoardPkg.dsc |3 -
 8 files changed, 2310 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index f3fb77c16f75..5dbd019e2966 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -114,14 +114,6 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdL2x0ControllerBase|0|UINT32|0x001B
 
   #
-  # BdsLib
-  #
-  # The compressed Linux kernel is expected to be under 128MB from the 
beginning of the System Memory
-  gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F
-  # Maximum file size for TFTP servers that do not support 'tsize' extension
-  gArmTokenSpaceGuid.PcdMaxTftpFileSize|0x0100|UINT32|0x
-
-  #
   # ARM Normal (or Non Secure) Firmware PCDs
   #
   gArmTokenSpaceGuid.PcdFdSize|0|UINT32|0x002C
diff --git a/ArmPkg/Library/BdsLib/BdsAppLoader.c 
b/ArmPkg/Library/BdsLib/BdsAppLoader.c
deleted file mode 100644
index 1f208f8dd796..
--- a/ArmPkg/Library/BdsLib/BdsAppLoader.c
+++ /dev/null
@@ -1,253 +0,0 @@
-/** @file
-*
-*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
-*
-*  This program and the accompanying materials
-*  are licensed and made available under the terms and conditions of the BSD 
License
-*  which accompanies this distribution.  The full text of the license may be 
found at
-*  http://opensource.org/licenses/bsd-license.php
-*
-*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-*
-**/
-
-#include "BdsInternal.h"
-
-/**
-  Locate an EFI application in a the Firmware Volumes by its Name
-
-  @param  EfiAppGuidGuid of the EFI Application into the Firmware 
Volume
-  @param  DevicePathEFI Device Path of the EFI application
-
-  @return EFI_SUCCESS   The function completed successfully.
-  @return EFI_NOT_FOUND The protocol could not be located.
-  @return EFI_OUT_OF_RESOURCES  There are not enough resources to find the 
protocol.
-
-**/
-EFI_STATUS
-LocateEfiApplicationInFvByName (
-  IN  CONST CHAR16* EfiAppName,
-  OUT EFI_DEVICE_PATH   **DevicePath
-  )
-{
-  VOID  *Key;
-  EFI_STATUSStatus, FileStatus;
-  EFI_GUID  NameGuid;
-  EFI_FV_FILETYPE   FileType;
-  EFI_FV_FILE_ATTRIBUTESAttributes;
-  UINTN Size;
-  UINTN UiStringLen;
-  CHAR16*UiSection;
-  UINT32Authentication;
-  EFI_DEVICE_PATH   *FvDevicePath;
-  MEDIA_FW_VOL_FILEPATH_DEVICE_PATHFileDevicePath;
-  EFI_HANDLE*HandleBuffer;
-  UINTN NumberOfHandles;
-  UINTN Index;
-  EFI_FIRMWARE_VOLUME2_PROTOCOL *FvInstance;
-
-  ASSERT (DevicePath != NULL);
-
-  // Length of FilePath
-  UiStringLen = StrLen (EfiAppName);
-
-  // Locate all the Firmware Volume protocols.
-  Status = gBS->LocateHandleBuffer (
-   ByProtocol,
-   ,
-   NULL,
-   ,
-   
-   );
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
-  *DevicePath = NULL;
-
-  // Looking for FV with ACPI storage file
-  for (Index = 0; Index < NumberOfHandles; Index++) {
-//
-// Get the protocol on this handle
-// This should not fail because of LocateHandleBuffer
-//
-Status = gBS->HandleProtocol (
- HandleBuffer[Index],
- ,
- (VOID**) 
- );
-if (EFI_ERROR (Status)) {
-  goto FREE_HANDLE_BUFFER;
-}
-
-// Allocate Key
-Key = AllocatePool (FvInstance->KeySize);
-ASSERT (Key != NULL);
-ZeroMem (Key, FvInstance->KeySize);
-
-do {
-  // Search in all files
-  FileType = EFI_FV_FILETYPE_ALL;
-
-  Status = FvInstance->GetNextFile (FvInstance, Key, , , 
, );
-  if (!EFI_ERROR (Status)) {
-UiSection = NULL;
-FileStatus = FvInstance->ReadSection (
-  FvInstance,
-  ,
-  EFI_SECTION_USER_INTERFACE,
-  0,
-  (VOID **),
-  ,
-  
-  );
-if (!EFI_ERROR 

[edk2] [PATCH 1/2] EmbeddedPkg: remove FdtPlatformDxe

[Ard Biesheuvel]

With the last users migrated to a private version, we can now remove
FdtPlatformDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c  | 461 ---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.h  | 174 
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |  64 ---
 EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni | 109 -
 EmbeddedPkg/Drivers/FdtPlatformDxe/README.txt |  72 ---
 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellDumpFdt.c | 279 
 EmbeddedPkg/Drivers/FdtPlatformDxe/ShellSetFdt.c  | 468 

 EmbeddedPkg/EmbeddedPkg.dec   |   6 -
 8 files changed, 1633 deletions(-)

diff --git a/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c 
b/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c
deleted file mode 100644
index b4be2a078991..
--- a/EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatform.c
+++ /dev/null
@@ -1,461 +0,0 @@
-/** @file
-
-  Copyright (c) 2015, ARM Ltd. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "FdtPlatform.h"
-
-#include 
-#include 
-#include 
-
-#include 
-
-//
-// Internal variables
-//
-
-STATIC CONST EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL mShellDynCmdProtocolSetFdt = {
-L"setfdt",// Name of the command
-ShellDynCmdSetFdtHandler, // Handler
-ShellDynCmdSetFdtGetHelp  // GetHelp
-};
-
-STATIC CONST EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL mShellDynCmdProtocolDumpFdt = {
-L"dumpfdt",// Name of the command
-ShellDynCmdDumpFdtHandler, // Handler
-ShellDynCmdDumpFdtGetHelp  // GetHelp
-};
-
-STATIC CONST EFI_GUID  mFdtPlatformDxeHiiGuid = {
- 0x8afa7610, 0x62b1, 0x46aa,
- {0xb5, 0x34, 0xc3, 0xde, 0xff, 0x39, 0x77, 0x8c}
- };
-
-EFI_HANDLE mFdtPlatformDxeHiiHandle;
-
-/**
-  Install the FDT specified by its device path in text form.
-
-  @param[in]  TextDevicePath  Device path of the FDT to install in text form
-
-  @retval  EFI_SUCCESSThe FDT was installed.
-  @retval  EFI_NOT_FOUND  Failed to locate a protocol or a file.
-  @retval  EFI_INVALID_PARAMETER  Invalid device path.
-  @retval  EFI_UNSUPPORTEDDevice path not supported.
-  @retval  EFI_OUT_OF_RESOURCES   An allocation failed.
-**/
-STATIC
-EFI_STATUS
-InstallFdt (
-  IN CONST CHAR16*  TextDevicePath
-  )
-{
-  EFI_STATUS  Status;
-  EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL  *EfiDevicePathFromTextProtocol;
-  EFI_DEVICE_PATH *DevicePath;
-  EFI_PHYSICAL_ADDRESSFdtBlobBase;
-  UINTN   FdtBlobSize;
-  UINTN   NumPages;
-  EFI_PHYSICAL_ADDRESSFdtConfigurationTableBase;
-
-  Status = gBS->LocateProtocol (
-  ,
-  NULL,
-  (VOID **)
-  );
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "InstallFdt() - Failed to locate 
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL protocol\n"));
-return Status;
-  }
-
-  DevicePath = 
(EFI_DEVICE_PATH*)EfiDevicePathFromTextProtocol->ConvertTextToDevicePath 
(TextDevicePath);
-  if (DevicePath == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  //
-  // Load the FDT given its device path.
-  // This operation may fail if the device path is not supported.
-  //
-  FdtBlobBase = 0;
-  NumPages= 0;
-  Status = BdsLoadImage (DevicePath, AllocateAnyPages, , 
);
-  if (EFI_ERROR (Status)) {
-goto Error;
-  }
-
-  //
-  // Ensure that the FDT header is valid and that the Size of the Device Tree
-  // is smaller than the size of the read file
-  //
-  if (fdt_check_header ((VOID*)(UINTN)FdtBlobBase) != 0 ||
-  (UINTN)fdt_totalsize ((VOID*)(UINTN)FdtBlobBase) > FdtBlobSize) {
-DEBUG ((EFI_D_ERROR, "InstallFdt() - loaded FDT binary image seems 
corrupt\n"));
-Status = EFI_LOAD_ERROR;
-goto Error;
-  }
-
-  //
-  // Store the FDT as Runtime Service Data to prevent the Kernel from
-  // overwritting its data.
-  //
-  NumPages = EFI_SIZE_TO_PAGES (FdtBlobSize);
-  Status = gBS->AllocatePages (
-  AllocateAnyPages, EfiRuntimeServicesData,
-  NumPages, 
-  );
-  if (EFI_ERROR (Status)) {
-goto Error;
-  }
-  CopyMem (
-(VOID*)(UINTN)FdtConfigurationTableBase,
-(VOID*)(UINTN)FdtBlobBase,
-FdtBlobSize
-);
-
-  //
-  // Install the FDT into the 

[edk2] [PATCH edk2-platforms 4/4] Platform/TC2: move to private FdtPlatformDxe implementation

[Ard Biesheuvel]

Move to our own private copy of FdtPlatformDxe and BdsLib so that we
can get rid of the upstream version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc | 6 +++---
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 1e6884ad5480..995dacd0b473 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -183,7 +183,7 @@ [PcdsFixedAtBuild.common]
   #
   # Define the device path to the FDT for the platform
   #
-  
gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7"
+  
gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/ca15a7"
 
   #
   # ARM Architectural Timer Frequency
@@ -296,7 +296,7 @@ [Components.common]
   #
   # FDT installation
   #
-  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf {
+  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf {
 
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
+  BdsLib|Platform/ARM/Library/BdsLib/BdsLib.inf
   }
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
index ed901f9f1f86..86d6f1415383 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf
@@ -183,7 +183,7 @@ [FV.FvMain]
   #
   # The UEFI driver is at the end of the list of the driver to be dispatched
   # after the device drivers (eg: Ethernet) to ensure we have support for them.
-  INF EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
+  INF Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
 
   # Example to add a Device Tree to the Firmware Volume
   #FILE FREEFORM = PCD(gArmVExpressTokenSpaceGuid.PcdFdtVExpressHwA15x2A7x3) {
-- 
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/4] Platform/ARM: import BdsLib and FdtPlatformDxe

[Ard Biesheuvel]

The only remnant of the deprecated ARM BDS in EDK2 is its BdsLib, which is
depended upon by FdtPlatformDxe in EmbeddedPkg, which itself is something
we'd prefer to get rid of. Since only TC2 and Juno actually use this driver,
let's move both FdtPlatformDxe and BdsLib under Platform/ARM, so that we can
remove it from the main EDK2 repository.

Ard Biesheuvel (4):
  Platform/ARM: import BdsLib from ArmPkg
  Platform/ARM: import FdtPlatformDxe driver from EDK2
  Platform/ARM/Juno: move to migrated FdtPlatformDxe
  Platform/TC2: move to private FdtPlatformDxe implementation

 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c  |  461 +++
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.h  |  174 +++
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec |   31 +
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |   65 +
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni |  109 ++
 Platform/ARM/Drivers/FdtPlatformDxe/README.txt |   72 +
 Platform/ARM/Drivers/FdtPlatformDxe/ShellDumpFdt.c |  279 
 Platform/ARM/Drivers/FdtPlatformDxe/ShellSetFdt.c  |  468 +++
 Platform/ARM/JunoPkg/ArmJuno.dsc   |6 +-
 Platform/ARM/JunoPkg/ArmJuno.fdf   |2 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf |3 +-
 Platform/ARM/Library/BdsLib/BdsAppLoader.c |  253 
 Platform/ARM/Library/BdsLib/BdsFilePath.c  | 1413 

 Platform/ARM/Library/BdsLib/BdsHelper.c|  183 +++
 Platform/ARM/Library/BdsLib/BdsInternal.h  |  111 ++
 Platform/ARM/Library/BdsLib/BdsLib.inf |   62 +
 Platform/ARM/Library/BdsLib/BdsLoadOption.c|  272 
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc  |6 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf  |2 +-
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   |5 +-
 20 files changed, 3964 insertions(+), 13 deletions(-)
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.h
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/README.txt
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/ShellDumpFdt.c
 create mode 100644 Platform/ARM/Drivers/FdtPlatformDxe/ShellSetFdt.c
 create mode 100644 Platform/ARM/Library/BdsLib/BdsAppLoader.c
 create mode 100644 Platform/ARM/Library/BdsLib/BdsFilePath.c
 create mode 100644 Platform/ARM/Library/BdsLib/BdsHelper.c
 create mode 100644 Platform/ARM/Library/BdsLib/BdsInternal.h
 create mode 100644 Platform/ARM/Library/BdsLib/BdsLib.inf
 create mode 100644 Platform/ARM/Library/BdsLib/BdsLoadOption.c

-- 
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/4] Platform/ARM: import FdtPlatformDxe driver from EDK2

[Ard Biesheuvel]

Import FdtPlatformDxe from EmbeddedPkg into Platform/ARM, given that it
is not used anywhere else, nor should it be.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c  | 461 
+++
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.h  | 174 
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec |  31 ++
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf |  65 +++
 Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.uni | 109 +
 Platform/ARM/Drivers/FdtPlatformDxe/README.txt |  72 +++
 Platform/ARM/Drivers/FdtPlatformDxe/ShellDumpFdt.c | 279 
 Platform/ARM/Drivers/FdtPlatformDxe/ShellSetFdt.c  | 468 

 8 files changed, 1659 insertions(+)

diff --git a/Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c 
b/Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c
new file mode 100644
index ..b4be2a078991
--- /dev/null
+++ b/Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatform.c
@@ -0,0 +1,461 @@
+/** @file
+
+  Copyright (c) 2015, ARM Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "FdtPlatform.h"
+
+#include 
+#include 
+#include 
+
+#include 
+
+//
+// Internal variables
+//
+
+STATIC CONST EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL mShellDynCmdProtocolSetFdt = {
+L"setfdt",// Name of the command
+ShellDynCmdSetFdtHandler, // Handler
+ShellDynCmdSetFdtGetHelp  // GetHelp
+};
+
+STATIC CONST EFI_SHELL_DYNAMIC_COMMAND_PROTOCOL mShellDynCmdProtocolDumpFdt = {
+L"dumpfdt",// Name of the command
+ShellDynCmdDumpFdtHandler, // Handler
+ShellDynCmdDumpFdtGetHelp  // GetHelp
+};
+
+STATIC CONST EFI_GUID  mFdtPlatformDxeHiiGuid = {
+ 0x8afa7610, 0x62b1, 0x46aa,
+ {0xb5, 0x34, 0xc3, 0xde, 0xff, 0x39, 0x77, 0x8c}
+ };
+
+EFI_HANDLE mFdtPlatformDxeHiiHandle;
+
+/**
+  Install the FDT specified by its device path in text form.
+
+  @param[in]  TextDevicePath  Device path of the FDT to install in text form
+
+  @retval  EFI_SUCCESSThe FDT was installed.
+  @retval  EFI_NOT_FOUND  Failed to locate a protocol or a file.
+  @retval  EFI_INVALID_PARAMETER  Invalid device path.
+  @retval  EFI_UNSUPPORTEDDevice path not supported.
+  @retval  EFI_OUT_OF_RESOURCES   An allocation failed.
+**/
+STATIC
+EFI_STATUS
+InstallFdt (
+  IN CONST CHAR16*  TextDevicePath
+  )
+{
+  EFI_STATUS  Status;
+  EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL  *EfiDevicePathFromTextProtocol;
+  EFI_DEVICE_PATH *DevicePath;
+  EFI_PHYSICAL_ADDRESSFdtBlobBase;
+  UINTN   FdtBlobSize;
+  UINTN   NumPages;
+  EFI_PHYSICAL_ADDRESSFdtConfigurationTableBase;
+
+  Status = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "InstallFdt() - Failed to locate 
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL protocol\n"));
+return Status;
+  }
+
+  DevicePath = 
(EFI_DEVICE_PATH*)EfiDevicePathFromTextProtocol->ConvertTextToDevicePath 
(TextDevicePath);
+  if (DevicePath == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  //
+  // Load the FDT given its device path.
+  // This operation may fail if the device path is not supported.
+  //
+  FdtBlobBase = 0;
+  NumPages= 0;
+  Status = BdsLoadImage (DevicePath, AllocateAnyPages, , 
);
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+
+  //
+  // Ensure that the FDT header is valid and that the Size of the Device Tree
+  // is smaller than the size of the read file
+  //
+  if (fdt_check_header ((VOID*)(UINTN)FdtBlobBase) != 0 ||
+  (UINTN)fdt_totalsize ((VOID*)(UINTN)FdtBlobBase) > FdtBlobSize) {
+DEBUG ((EFI_D_ERROR, "InstallFdt() - loaded FDT binary image seems 
corrupt\n"));
+Status = EFI_LOAD_ERROR;
+goto Error;
+  }
+
+  //
+  // Store the FDT as Runtime Service Data to prevent the Kernel from
+  // overwritting its data.
+  //
+  NumPages = EFI_SIZE_TO_PAGES (FdtBlobSize);
+  Status = gBS->AllocatePages (
+  AllocateAnyPages, EfiRuntimeServicesData,
+  NumPages, 
+  );
+  if (EFI_ERROR (Status)) {
+goto Error;
+  }
+  CopyMem (
+(VOID*)(UINTN)FdtConfigurationTableBase,
+(VOID*)(UINTN)FdtBlobBase,
+FdtBlobSize
+);
+
+  

[edk2] [PATCH edk2-platforms 1/4] Platform/ARM: import BdsLib from ArmPkg

[Ard Biesheuvel]

We are about to migrate the only remaining user of the deprecated ARM
BdsLib, i.e., FdtPlatformDxe, into Platform/ARM. So create our own
copy of BdsLib, allowing us to finally remove it from upstream EDK2.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/Library/BdsLib/BdsAppLoader.c  |  253 
 Platform/ARM/Library/BdsLib/BdsFilePath.c   | 1413 
 Platform/ARM/Library/BdsLib/BdsHelper.c |  183 +++
 Platform/ARM/Library/BdsLib/BdsInternal.h   |  111 ++
 Platform/ARM/Library/BdsLib/BdsLib.inf  |   62 +
 Platform/ARM/Library/BdsLib/BdsLoadOption.c |  272 
 6 files changed, 2294 insertions(+)

diff --git a/Platform/ARM/Library/BdsLib/BdsAppLoader.c 
b/Platform/ARM/Library/BdsLib/BdsAppLoader.c
new file mode 100644
index ..1f208f8dd796
--- /dev/null
+++ b/Platform/ARM/Library/BdsLib/BdsAppLoader.c
@@ -0,0 +1,253 @@
+/** @file
+*
+*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "BdsInternal.h"
+
+/**
+  Locate an EFI application in a the Firmware Volumes by its Name
+
+  @param  EfiAppGuidGuid of the EFI Application into the Firmware 
Volume
+  @param  DevicePathEFI Device Path of the EFI application
+
+  @return EFI_SUCCESS   The function completed successfully.
+  @return EFI_NOT_FOUND The protocol could not be located.
+  @return EFI_OUT_OF_RESOURCES  There are not enough resources to find the 
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByName (
+  IN  CONST CHAR16* EfiAppName,
+  OUT EFI_DEVICE_PATH   **DevicePath
+  )
+{
+  VOID  *Key;
+  EFI_STATUSStatus, FileStatus;
+  EFI_GUID  NameGuid;
+  EFI_FV_FILETYPE   FileType;
+  EFI_FV_FILE_ATTRIBUTESAttributes;
+  UINTN Size;
+  UINTN UiStringLen;
+  CHAR16*UiSection;
+  UINT32Authentication;
+  EFI_DEVICE_PATH   *FvDevicePath;
+  MEDIA_FW_VOL_FILEPATH_DEVICE_PATHFileDevicePath;
+  EFI_HANDLE*HandleBuffer;
+  UINTN NumberOfHandles;
+  UINTN Index;
+  EFI_FIRMWARE_VOLUME2_PROTOCOL *FvInstance;
+
+  ASSERT (DevicePath != NULL);
+
+  // Length of FilePath
+  UiStringLen = StrLen (EfiAppName);
+
+  // Locate all the Firmware Volume protocols.
+  Status = gBS->LocateHandleBuffer (
+   ByProtocol,
+   ,
+   NULL,
+   ,
+   
+   );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  *DevicePath = NULL;
+
+  // Looking for FV with ACPI storage file
+  for (Index = 0; Index < NumberOfHandles; Index++) {
+//
+// Get the protocol on this handle
+// This should not fail because of LocateHandleBuffer
+//
+Status = gBS->HandleProtocol (
+ HandleBuffer[Index],
+ ,
+ (VOID**) 
+ );
+if (EFI_ERROR (Status)) {
+  goto FREE_HANDLE_BUFFER;
+}
+
+// Allocate Key
+Key = AllocatePool (FvInstance->KeySize);
+ASSERT (Key != NULL);
+ZeroMem (Key, FvInstance->KeySize);
+
+do {
+  // Search in all files
+  FileType = EFI_FV_FILETYPE_ALL;
+
+  Status = FvInstance->GetNextFile (FvInstance, Key, , , 
, );
+  if (!EFI_ERROR (Status)) {
+UiSection = NULL;
+FileStatus = FvInstance->ReadSection (
+  FvInstance,
+  ,
+  EFI_SECTION_USER_INTERFACE,
+  0,
+  (VOID **),
+  ,
+  
+  );
+if (!EFI_ERROR (FileStatus)) {
+  if (StrnCmp (EfiAppName, UiSection, UiStringLen) == 0) {
+//
+// We found a UiString match.
+//
+Status = gBS->HandleProtocol (HandleBuffer[Index], 
, (VOID **));
+
+// Generate the Device Path for the file
+EfiInitializeFwVolDevicepathNode (, );
+*DevicePath = AppendDevicePathNode (FvDevicePath, 
(EFI_DEVICE_PATH_PROTOCOL *));
+ASSERT (*DevicePath != NULL);
+
+FreePool (Key);
+FreePool (UiSection);
+FreePool (HandleBuffer);
+return FileStatus;
+  }
+  FreePool (UiSection);

[edk2] [PATCH edk2-platforms 3/4] Platform/ARM/Juno: move to migrated FdtPlatformDxe

[Ard Biesheuvel]

Move Juno to the migrated version of FdtPlatformDxe.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/JunoPkg/ArmJuno.dsc   | 6 +++---
 Platform/ARM/JunoPkg/ArmJuno.fdf   | 2 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf | 3 ++-
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   | 5 +
 4 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 4c63309d36f1..e7cb280ff381 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -200,7 +200,7 @@ [PcdsDynamicDefault.common]
   # character "empty" string, to allow to be able to set FDT text device paths
   # up to 128 characters long.
   #
-  gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths|L" 

   "
+  gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths|L"   

 "
 
   # Not all Juno platforms support PCI. This dynamic PCD disables or enable
   # PCI support.
@@ -352,9 +352,9 @@ [Components.common]
   #
   # FDT installation
   #
-  EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf {
+  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf {
 
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
+  BdsLib|Platform/ARM/Library/BdsLib/BdsLib.inf
   }
 
 [Components.AARCH64]
diff --git a/Platform/ARM/JunoPkg/ArmJuno.fdf b/Platform/ARM/JunoPkg/ArmJuno.fdf
index 04d58323d130..898c471248d7 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.fdf
+++ b/Platform/ARM/JunoPkg/ArmJuno.fdf
@@ -230,7 +230,7 @@ [FV.FvMain]
   #
   # The UEFI driver is at the end of the list of the driver to be dispatched
   # after the device drivers (eg: Ethernet) to ensure we have support for them.
-  INF EmbeddedPkg/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
+  INF Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.inf
 
 !if $(ARCH) == AARCH64
   #
diff --git a/Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
index 70175c2d2405..7da336fbd8e7 100644
--- a/Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
+++ b/Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
@@ -29,6 +29,7 @@ [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   Platform/ARM/ARM.dec
+  Platform/ARM/Drivers/FdtPlatformDxe/FdtPlatformDxe.dec
   Platform/ARM/JunoPkg/ArmJuno.dec
 
 [LibraryClasses]
@@ -81,7 +82,7 @@ [FixedPcd]
   gArmTokenSpaceGuid.PcdPciBusMax
 
 [Pcd]
-  gEmbeddedTokenSpaceGuid.PcdFdtDevicePaths
+  gFdtPlatformDxeTokenSpaceGuid.PcdFdtDevicePaths
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
 
 [Depex]
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 75f4e924cb9f..3679530decf0 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -457,10 +457,7 @@ [Components.common]
   #
   # Android Fastboot
   #
-  EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf {
-
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
-  }
+  EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
   
EmbeddedPkg/Drivers/AndroidFastbootTransportUsbDxe/FastbootTransportUsbDxe.inf
   
Platform/ARM/VExpressPkg/Drivers/ArmVExpressFastBootDxe/ArmVExpressFastBootDxe.inf
 
-- 
2.11.0

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

Re: [edk2] [Patch] BaseTools: Fix a bug for single module build with GenC/GenMake option

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Friday, November 17, 2017 12:03 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [edk2] [Patch] BaseTools: Fix a bug for single module build with
>GenC/GenMake option
>
>when build a single module with GenC/GenMake option, currently it will
>direct return after create Autogen code files, then it cause MaList is
>empty, which cause an incorrect error message is reported.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/build/build.py | 5 -
> 1 file changed, 5 deletions(-)
>
>diff --git a/BaseTools/Source/Python/build/build.py
>b/BaseTools/Source/Python/build/build.py
>index 4f73bba..53f1245 100644
>--- a/BaseTools/Source/Python/build/build.py
>+++ b/BaseTools/Source/Python/build/build.py
>@@ -1835,17 +1835,12 @@ class Build():
> # Not to auto-gen for targets 'clean', 
> 'cleanlib', 'cleanall', 'run',
>'fds'
> if self.Target not in ['clean', 'cleanlib', 
> 'cleanall', 'run', 'fds']:
> # for target which must generate AutoGen code 
> and makefile
> if not self.SkipAutoGen or self.Target == 
> 'genc':
> Ma.CreateCodeFile(True)
>-if self.Target == "genc":
>-continue
>-
> if not self.SkipAutoGen or self.Target == 
> 'genmake':
> Ma.CreateMakeFile(True)
>-if self.Target == "genmake":
>-continue
> MaList.append(Ma)
> self.BuildModules.append(Ma)
> self.AutoGenTime += int(round((time.time() - 
> AutoGenStart)))
> MakeStart = time.time()
> for Ma in self.BuildModules:
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Guid.xref contain information from FILE statements in FDF

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Thursday, November 16, 2017 5:14 PM
>To: edk2-devel@lists.01.org
>Cc: Dmitry Antipov ; Gao, Liming
>
>Subject: [edk2] [Patch] BaseTools: Guid.xref contain information from FILE
>statements in FDF
>
>Update Guid.xref to contain information from FILE statements in FDF
>file.
>
>Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=778
>Cc: Liming Gao 
>Cc: Dmitry Antipov 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/GenFds/GenFds.py | 88
>+++-
> 1 file changed, 86 insertions(+), 2 deletions(-)
>
>diff --git a/BaseTools/Source/Python/GenFds/GenFds.py
>b/BaseTools/Source/Python/GenFds/GenFds.py
>index 277da35..c19dc40 100644
>--- a/BaseTools/Source/Python/GenFds/GenFds.py
>+++ b/BaseTools/Source/Python/GenFds/GenFds.py
>@@ -40,10 +40,13 @@ from Common.Misc import ClearDuplicatedInf
> from Common.Misc import GuidStructureStringToGuidString
> from Common.Misc import CheckPcdDatum
> from Common.Misc import BuildOptionPcdValueFormat
> from Common.BuildVersion import gBUILD_VERSION
> from Common.MultipleWorkspace import MultipleWorkspace as mws
>+import FfsFileStatement
>+import glob
>+from struct import unpack
>
> ## Version and Copyright
> versionNumber = "1.0" + ' ' + gBUILD_VERSION
> __version__ = "%prog Version " + versionNumber
> __copyright__ = "Copyright (c) 2007 - 2017, Intel Corporation  All rights
>reserved."
>@@ -325,11 +328,11 @@ def main():
>
> """Call GenFds"""
> GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
>
> """Generate GUID cross reference file"""
>-GenFds.GenerateGuidXRefFile(BuildWorkSpace, ArchList)
>+GenFds.GenerateGuidXRefFile(BuildWorkSpace, ArchList, FdfParserObj)
>
> """Display FV space info."""
> GenFds.DisplayFvSpaceInfo(FdfParserObj)
>
> except FdfParser.Warning, X:
>@@ -722,25 +725,106 @@ class GenFds :
> ModuleDict = BuildDb.BuildObject[DscFile, 'COMMON',
>GenFdsGlobalVariable.TargetName,
>GenFdsGlobalVariable.ToolChainTag].Modules
> for Key in ModuleDict:
> ModuleObj = BuildDb.BuildObject[Key, 'COMMON',
>GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
> print ModuleObj.BaseName + ' ' + ModuleObj.ModuleType
>
>-def GenerateGuidXRefFile(BuildDb, ArchList):
>+def GenerateGuidXRefFile(BuildDb, ArchList, FdfParserObj):
> GuidXRefFileName = os.path.join(GenFdsGlobalVariable.FvDir,
>"Guid.xref")
> GuidXRefFile = StringIO.StringIO('')
> GuidDict = {}
>+ModuleList = []
>+FileGuidList = []
> for Arch in ArchList:
> PlatformDataBase =
>BuildDb.BuildObject[GenFdsGlobalVariable.ActivePlatform, Arch,
>GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
> for ModuleFile in PlatformDataBase.Modules:
> Module = BuildDb.BuildObject[ModuleFile, Arch,
>GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
>+if Module in ModuleList:
>+continue
>+else:
>+ModuleList.append(Module)
> GuidXRefFile.write("%s %s\n" % (Module.Guid, Module.BaseName))
> for key, item in Module.Protocols.items():
> GuidDict[key] = item
> for key, item in Module.Guids.items():
> GuidDict[key] = item
> for key, item in Module.Ppis.items():
> GuidDict[key] = item
>+for FvName in FdfParserObj.Profile.FvDict:
>+for FfsObj in FdfParserObj.Profile.FvDict[FvName].FfsList:
>+if not isinstance(FfsObj, FfsFileStatement.FileStatement):
>+InfPath =
>PathClass(NormPath(mws.join(GenFdsGlobalVariable.WorkSpaceDir,
>FfsObj.InfFileName)))
>+FdfModule = BuildDb.BuildObject[InfPath, Arch,
>GenFdsGlobalVariable.TargetName, GenFdsGlobalVariable.ToolChainTag]
>+if FdfModule in ModuleList:
>+continue
>+else:
>+ModuleList.append(FdfModule)
>+GuidXRefFile.write("%s %s\n" % (FdfModule.Guid,
>FdfModule.BaseName))
>+for key, item in FdfModule.Protocols.items():
>+GuidDict[key] = item
>+for key, item in FdfModule.Guids.items():
>+GuidDict[key] = item
>+for key, item in FdfModule.Ppis.items():
>+GuidDict[key] = item
>+else:
>+  

Re: [edk2] [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools tools_def.template

[Gao, Liming]

Pete:
  Here, I suggest to mention VS version 15.2 or above, because vswhere.exe 
depends on this version. 
  After later, you may also update this version to 15.4 for ARM and AARCH64 
support. 

>-Original Message-
>From: Pete Batard [mailto:p...@akeo.ie]
>Sent: Friday, November 17, 2017 9:09 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [PATCH v2 2/4] BaseTools: Add VS2017 tool chain in BaseTools
>tools_def.template
>
>From: Liming Gao 
>
>VS2017 tool chain enables /WHOLEARCHIVE linker option
>Split host-related and arch-related elements
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Liming Gao 
>Signed-off-by: Pete Batard 
>---
> BaseTools/Conf/tools_def.template | 126 
> 1 file changed, 126 insertions(+)
>
>diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>index aebd7d558633..0e8f9e6cdbf1 100755
>--- a/BaseTools/Conf/tools_def.template
>+++ b/BaseTools/Conf/tools_def.template
>@@ -74,6 +74,12 @@ DEFINE VS2015x86_BIN= ENV(VS2015_PREFIX)Vc\bin
> DEFINE VS2015x86_DLL=
>ENV(VS2015_PREFIX)Common7\IDE;DEF(VS2015x86_BIN)
> DEFINE VS2015x86_BINX64 = DEF(VS2015x86_BIN)\x86_amd64
>
>+DEFINE VS2017_BIN = ENV(VS2017_PREFIX)bin
>+DEFINE VS2017_HOST= x86
>+DEFINE VS2017_BIN_HOST=
>DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\DEF(VS2017_HOST)
>+DEFINE VS2017_BIN_IA32= DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x86
>+DEFINE VS2017_BIN_X64 = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x64
>+
> DEFINE WINSDK_BIN   = ENV(WINSDK_PREFIX)
> DEFINE WINSDKx86_BIN= ENV(WINSDKx86_PREFIX)
>
>@@ -93,6 +99,9 @@ DEFINE WINSDK8x86_BIN=
>ENV(WINSDK8x86_PREFIX)x64
> DEFINE WINSDK81_BIN   = ENV(WINSDK81_PREFIX)x86\
> DEFINE WINSDK81x86_BIN= ENV(WINSDK81x86_PREFIX)x64
>
>+# Microsoft Visual Studio 2017 Professional Edition
>+DEFINE WINSDK10_BIN   = ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)
>+
> # These defines are needed for certain Microsoft Visual Studio tools that
> # are used by other toolchains.  An example is that ICC on Windows normally
> # uses Microsoft's nmake.exe.
>@@ -318,6 +327,14 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
> # Required to build platforms or ACPI tables:
> #   Intel(r) ACPI Compiler (iasl.exe) from
> #   https://acpica.org/downloads
>+#   VS2017  -win32-  Requires:
>+# Microsoft Visual Studio 2017 Professional or 
>Community
>Edition
>+#Optional:
>+# Required to build EBC drivers:
>+#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
>EBC Compiler)
>+# Required to build platforms or ACPI tables:
>+#   Intel(r) ACPI Compiler (iasl.exe) from
>+#   https://acpica.org/downloads
> #   DDK3790 -win32-  Requires:
> # Microsoft Windows Server 2003 Driver 
> Development Kit
>(Microsoft WINDDK) version 3790.1830
> #Optional:
>@@ -4062,6 +4079,115 @@ NOOPT_VS2015x86xASL_X64_DLINK_FLAGS=
>/NOLOGO /NODEFAULTLIB /IGNORE:4001 /OPT
>
>
>
>###
>#
>+#   VS2017   - Microsoft Visual Studio 2017 with Intel ASL
>+#   ASL  - Intel ACPI Source Language Compiler (iasl.exe)
>+##
>##
>+#   VS2017   - Microsoft Visual Studio 2017 professional Edition with 
>Intel
>ASL
>+*_VS2017_*_*_FAMILY= MSFT
>+*_VS2017_*_*_DLL   = DEF(VS2017_BIN_HOST)
>+
>+*_VS2017_*_MAKE_PATH   = DEF(VS2017_BIN_HOST)\nmake.exe
>+*_VS2017_*_MAKE_FLAG   = /nologo
>+*_VS2017_*_RC_PATH = DEF(WINSDK10_BIN)\rc.exe
>+
>+*_VS2017_*_MAKE_FLAGS  = /nologo
>+*_VS2017_*_SLINK_FLAGS = /NOLOGO /LTCG
>+*_VS2017_*_APP_FLAGS   = /nologo /E /TC
>+*_VS2017_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
>+*_VS2017_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE
>/FI$(MODULE_NAME)StrDefs.h
>+*_VS2017_*_DLINK2_FLAGS= /WHOLEARCHIVE
>+*_VS2017_*_ASM16_PATH  = DEF(VS2017_BIN_IA32)\ml.exe
>+
>+##
>+# ASL definitions
>+##
>+*_VS2017_*_ASL_PATH= DEF(WIN_IASL_BIN)
>+*_VS2017_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
>+*_VS2017_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
>+*_VS2017_*_ASLCC_FLAGS = DEF(MSFT_ASLCC_FLAGS)
>+*_VS2017_*_ASLPP_FLAGS = DEF(MSFT_ASLPP_FLAGS)
>+*_VS2017_*_ASLDLINK_FLAGS  = DEF(MSFT_ASLDLINK_FLAGS)
>+
>+##
>+# IA32 definitions
>+##
>+*_VS2017_IA32_CC_PATH  = DEF(VS2017_BIN_IA32)\cl.exe
>+*_VS2017_IA32_VFRPP_PATH   = DEF(VS2017_BIN_IA32)\cl.exe
>+*_VS2017_IA32_ASLCC_PATH   = 

Re: [edk2] [PATCH] MdeModulePkg EhciPei: Also check Buf against NULL to return error

[Wu, Hao A]

Reviewed-by: Hao Wu 


Best Regards,
Hao Wu


> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 20, 2017 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wu, Hao A; Yao, Jiewen
> Subject: [PATCH] MdeModulePkg EhciPei: Also check Buf against NULL to
> return error
> 
> Cc: Hao Wu 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c
> b/MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c
> index 606a53db1da1..6b19362699b1 100644
> --- a/MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c
> @@ -134,7 +134,7 @@ EhcInitSched (
>   
>   );
> 
> -  if (EFI_ERROR (Status)) {
> +  if (EFI_ERROR (Status) || (Buf == NULL)) {
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH v2 0/2] Fix unix style of EOL

[Wu, Hao A]

The series is good to me.
Reviewed-by: Hao Wu 


Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, November 20, 2017 4:22 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v2 0/2] Fix unix style of EOL
> 
> > v2: Split patches per package
> 
> Jian J Wang (2):
>   MdeModulePkg: Fix unix style of EOL
>   UefiCpuPkg: Fix unix style of EOL
> 
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |8 +-
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c  | 2394 
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h  |  788 +++---
>  MdeModulePkg/Core/Dxe/Mem/Imem.h   |   70 +-
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |  210 +-
>  MdeModulePkg/Core/Dxe/Mem/Pool.c   |  242 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  |6 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|2 +-
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   64 +-
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c| 2944 ++-
> -
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.h|  796 +++---
>  MdeModulePkg/Core/PiSmmCore/Page.c |   88 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|   12 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|  158 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |   12 +-
>  MdeModulePkg/Core/PiSmmCore/Pool.c |  126 +-
>  MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h |  272 +-
>  MdeModulePkg/MdeModulePkg.dec  |  120 +-
>  MdeModulePkg/MdeModulePkg.uni  |  116 +-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c   |4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |   20 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |   40 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  196 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |4 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c |  326 +--
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|   28 +-
>  26 files changed, 4523 insertions(+), 4523 deletions(-)
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/2] UefiCpuPkg: Fix unix style of EOL

[Jian J Wang]

Cc: Wu Hao 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c   |   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  20 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  40 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 196 ++---
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 326 ++---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  28 +-
 7 files changed, 309 insertions(+), 309 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index 309f448a83..76f44f9bd1 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -442,8 +442,8 @@ ConvertPageEntryAttribute (
   *PageEntry = NewPageEntry;
   if (CurrentPageEntry != NewPageEntry) {
 *IsModified = TRUE;
-DEBUG ((DEBUG_VERBOSE, "ConvertPageEntryAttribute 0x%lx", 
CurrentPageEntry));
-DEBUG ((DEBUG_VERBOSE, "->0x%lx\n", NewPageEntry));
+DEBUG ((DEBUG_VERBOSE, "ConvertPageEntryAttribute 0x%lx", 
CurrentPageEntry));
+DEBUG ((DEBUG_VERBOSE, "->0x%lx\n", NewPageEntry));
   } else {
 *IsModified = FALSE;
   }
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 9447a31ef5..0396f2daaa 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -196,16 +196,16 @@ SetPageTableAttributes (
   BOOLEAN   IsSplitted;
   BOOLEAN   PageTableSplitted;
 
-  //
-  // Don't mark page table as read-only if heap guard is enabled.
-  //
-  //  BIT2: SMM page guard enabled
-  //  BIT3: SMM pool guard enabled
-  //
-  if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
-return ;
-  }
-
+  //
+  // Don't mark page table as read-only if heap guard is enabled.
+  //
+  //  BIT2: SMM page guard enabled
+  //  BIT3: SMM pool guard enabled
+  //
+  if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+return ;
+  }
+
   DEBUG ((DEBUG_INFO, "SetPageTableAttributes\n"));
 
   //
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
index 6c6d742c95..4b66a0dfd9 100755
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
@@ -76,15 +76,15 @@ EFI_SMM_CPU_PROTOCOL  mSmmCpu  = {
   SmmWriteSaveState
 };
 
-///
-/// SMM Memory Attribute Protocol instance
-///
-EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL  mSmmMemoryAttribute  = {
-  EdkiiSmmGetMemoryAttributes,
-  EdkiiSmmSetMemoryAttributes,
-  EdkiiSmmClearMemoryAttributes
-};
-
+///
+/// SMM Memory Attribute Protocol instance
+///
+EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL  mSmmMemoryAttribute  = {
+  EdkiiSmmGetMemoryAttributes,
+  EdkiiSmmSetMemoryAttributes,
+  EdkiiSmmClearMemoryAttributes
+};
+
 EFI_CPU_INTERRUPT_HANDLER   mExternalVectorTable[EXCEPTION_VECTOR_NUMBER];
 
 //
@@ -902,17 +902,17 @@ PiCpuSmmEntry (
 );
   ASSERT_EFI_ERROR (Status);
 
-  //
-  // Install the SMM Memory Attribute Protocol into SMM protocol database
-  //
-  Status = gSmst->SmmInstallProtocolInterface (
-,
-,
-EFI_NATIVE_INTERFACE,
-
-);
-  ASSERT_EFI_ERROR (Status);
-
+  //
+  // Install the SMM Memory Attribute Protocol into SMM protocol database
+  //
+  Status = gSmst->SmmInstallProtocolInterface (
+,
+,
+EFI_NATIVE_INTERFACE,
+
+);
+  ASSERT_EFI_ERROR (Status);
+
   //
   // Expose address of CPU Hot Plug Data structure if CPU hot plug is 
supported.
   //
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index a2d5f55045..ef32f17676 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@ -25,7 +25,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -1069,101 +1069,101 @@ TransferApToSafeState (
   IN UINTN  NumberToFinishAddress
   );
 
-/**
-  This function set given attributes of the memory region specified by
-  BaseAddress and Length.
-
-  @param  This  The EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL instance.
-  @param  BaseAddress   The physical address that is the start address of
-a memory region.
-  @param  LengthThe size in bytes of the memory region.
-  @param  AttributesThe bit mask of attributes to set for the memory
-region.
-
-  @retval EFI_SUCCESS   The 

[edk2] [PATCH v2 0/2] Fix unix style of EOL

[Jian J Wang]

> v2: Split patches per package

Jian J Wang (2):
  MdeModulePkg: Fix unix style of EOL
  UefiCpuPkg: Fix unix style of EOL

 MdeModulePkg/Core/Dxe/DxeMain.inf  |8 +-
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c  | 2394 
 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h  |  788 +++---
 MdeModulePkg/Core/Dxe/Mem/Imem.h   |   70 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c   |  210 +-
 MdeModulePkg/Core/Dxe/Mem/Pool.c   |  242 +-
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  |6 +-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|2 +-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   64 +-
 MdeModulePkg/Core/PiSmmCore/HeapGuard.c| 2944 ++--
 MdeModulePkg/Core/PiSmmCore/HeapGuard.h|  796 +++---
 MdeModulePkg/Core/PiSmmCore/Page.c |   88 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|   12 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|  158 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |   12 +-
 MdeModulePkg/Core/PiSmmCore/Pool.c |  126 +-
 MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h |  272 +-
 MdeModulePkg/MdeModulePkg.dec  |  120 +-
 MdeModulePkg/MdeModulePkg.uni  |  116 +-
 UefiCpuPkg/CpuDxe/CpuPageTable.c   |4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |   20 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |   40 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  196 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c |  326 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|   28 +-
 26 files changed, 4523 insertions(+), 4523 deletions(-)

-- 
2.14.1.windows.1

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