[edk2] [PATCH v2 2/2] MdeModulePkg/UdfDxe: Avoid possible loss track of allocated buffer

[Hao Wu]

In function FindFileEntry():

Instead of using the function parameter 'FileEntry', use a local
variable to store the buffer allocated for disk read operation.

For the below calling stack:
UdfOpenVolume() -> FindRootDirectory() -> FindFileEntry()

In FindFileEntry(), the call to 'DiskIo->ReadDisk()' is possible (e.g.
media change for a CD/DVD ROM device) to trigger a re-install of the
BlockIO(2) protocol which will further lead to a call of the BindingStop()
& BingdingStart() of the UdfDxe driver.

Meanwhile, for the above listed calling stack, the '**FileEntry'
parameter passed into FindFileEntry() is '>Root'. 'PrivFsData'
is a driver-managed private data, it will be freed in BindingStop() and
re-allocate in BingdingStart().

In such case, if '*FileEntry' is used to store the allocated buffer, the
information will be lost if 'DiskIo->ReadDisk()' triggers a re-install of
the BlockIO(2) protocol. The subsequent call of the FreePool API:

FreePool (*FileEntry);

will cause issues.

This commit uses a local variable to store the allocated buffer.

Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Paulo Alcantara 
---
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c 
b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
index e048d95d31..ecc172303e 100644
--- a/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
+++ b/MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c
@@ -1615,12 +1615,13 @@ FindFileEntry (
   UINT64  Lsn;
   UINT32  LogicalBlockSize;
   UDF_DESCRIPTOR_TAG  *DescriptorTag;
+  VOID*ReadBuffer;
 
   Lsn   = GetLongAdLsn (Volume, Icb);
   LogicalBlockSize  = Volume->LogicalVolDesc.LogicalBlockSize;
 
-  *FileEntry = AllocateZeroPool (Volume->FileEntrySize);
-  if (*FileEntry == NULL) {
+  ReadBuffer = AllocateZeroPool (Volume->FileEntrySize);
+  if (ReadBuffer == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
 
@@ -1632,13 +1633,13 @@ FindFileEntry (
 BlockIo->Media->MediaId,
 MultU64x32 (Lsn, LogicalBlockSize),
 Volume->FileEntrySize,
-*FileEntry
+ReadBuffer
 );
   if (EFI_ERROR (Status)) {
 goto Error_Read_Disk_Blk;
   }
 
-  DescriptorTag = *FileEntry;
+  DescriptorTag = ReadBuffer;
 
   //
   // Check if the read extent contains a valid Tag Identifier for the expected
@@ -1650,11 +1651,12 @@ FindFileEntry (
 goto Error_Invalid_Fe;
   }
 
+  *FileEntry = ReadBuffer;
   return EFI_SUCCESS;
 
 Error_Invalid_Fe:
 Error_Read_Disk_Blk:
-  FreePool (*FileEntry);
+  FreePool (ReadBuffer);
 
   return Status;
 }
-- 
2.12.0.windows.1

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

[edk2] [PATCH v2 1/2] MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF

[Hao Wu]

In order to create all of the children (El Torito standard and UDF) for
a CD/DVD media in an entry of the PartitionDriverBindingStart(), this
commit merges the discovery of the El Torito feature
(PartitionInstallElToritoChildHandles) into function
PartitionInstallUdfChildHandles.

Cc: Paulo Alcantara 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c |  7 +++--
 MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c   | 27 ++--
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
index f6030e0897..603abfe55a 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
@@ -43,7 +43,6 @@ EFI_DRIVER_BINDING_PROTOCOL gPartitionDriverBinding = {
 //
 PARTITION_DETECT_ROUTINE mPartitionDetectRoutineTable[] = {
   PartitionInstallGptChildHandles,
-  PartitionInstallElToritoChildHandles,
   PartitionInstallMbrChildHandles,
   PartitionInstallUdfChildHandles,
   NULL
@@ -306,9 +305,9 @@ PartitionDriverBindingStart (
   if (BlockIo->Media->MediaPresent ||
   (BlockIo->Media->RemovableMedia && !BlockIo->Media->LogicalPartition)) {
 //
-// Try for GPT, then El Torito, then UDF, and then legacy MBR partition
-// types. If the media supports a given partition type install child 
handles
-// to represent the partitions described by the media.
+// Try for GPT, then legacy MBR partition types, and then UDF and El 
Torito.
+// If the media supports a given partition type install child handles to
+// represent the partitions described by the media.
 //
 Routine = [0];
 while (*Routine != NULL) {
diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
index 7eee748958..5aac5640f6 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
@@ -688,8 +688,10 @@ PartitionInstallUdfChildHandles (
   EFI_PARTITION_INFO_PROTOCOL  PartitionInfo;
   EFI_LBA  StartingLBA;
   EFI_LBA  EndingLBA;
+  BOOLEAN  ChildCreated;
 
   Media = BlockIo->Media;
+  ChildCreated = FALSE;
 
   //
   // Check if UDF logical block size is multiple of underlying device block 
size
@@ -704,11 +706,29 @@ PartitionInstallUdfChildHandles (
   }
 
   //
+  // Detect El Torito feature first.
+  // And always continue to search for UDF.
+  //
+  Status = PartitionInstallElToritoChildHandles (
+ This,
+ Handle,
+ DiskIo,
+ DiskIo2,
+ BlockIo,
+ BlockIo2,
+ DevicePath
+ );
+  if (!EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "PartitionDxe: El Torito standard found on handle 
0x%p.\n", Handle));
+ChildCreated = TRUE;
+  }
+
+  //
   // Search for an UDF file system on block device
   //
   Status = FindUdfFileSystem (BlockIo, DiskIo, , );
   if (EFI_ERROR (Status)) {
-return EFI_NOT_FOUND;
+return (ChildCreated ? EFI_SUCCESS : EFI_NOT_FOUND);
   }
 
   //
@@ -735,6 +755,9 @@ PartitionInstallUdfChildHandles (
 EndingLBA,
 Media->BlockSize
 );
+  if (EFI_ERROR (Status)) {
+return (ChildCreated ? EFI_SUCCESS : Status);
+  }
 
-  return Status;
+  return EFI_SUCCESS;
 }
-- 
2.12.0.windows.1

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

[edk2] [PATCH] MdeModulePkg EhciPei: Support IoMmu

[Star Zeng]

Update the EhciPei driver to consume IOMMU_PPI to allocate DMA buffer.

If no IOMMU_PPI exists, this driver still calls PEI service to allocate
DMA buffer, with assumption that DRAM==DMA.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c| 250 +++
 MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.c   |   4 +-
 MdeModulePkg/Bus/Pci/EhciPei/EhcPeim.h   | 110 +-
 MdeModulePkg/Bus/Pci/EhciPei/EhciPei.inf |   5 +-
 MdeModulePkg/Bus/Pci/EhciPei/EhciSched.c |  38 +++--
 MdeModulePkg/Bus/Pci/EhciPei/EhciUrb.c   |  42 --
 MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.c  |  84 +--
 MdeModulePkg/Bus/Pci/EhciPei/UsbHcMem.h  |  18 ++-
 8 files changed, 506 insertions(+), 45 deletions(-)
 create mode 100644 MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c

diff --git a/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c 
b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
new file mode 100644
index ..1330f53f411a
--- /dev/null
+++ b/MdeModulePkg/Bus/Pci/EhciPei/DmaMem.c
@@ -0,0 +1,250 @@
+/** @file
+The DMA memory help functions.
+
+Copyright (c) 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
+
+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 "EhcPeim.h"
+
+/**
+  Provides the controller-specific addresses required to access system memory 
from a
+  DMA bus master.
+
+  @param IoMmu  Pointer to IOMMU PPI.
+  @param Operation  Indicates if the bus master is going to read 
or write to system memory.
+  @param HostAddressThe system memory address to map to the PCI 
controller.
+  @param NumberOfBytes  On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param DeviceAddress  The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param MappingA resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN EDKII_IOMMU_PPI*IoMmu,
+  IN EDKII_IOMMU_OPERATION  Operation,
+  IN VOID   *HostAddress,
+  IN OUT UINTN  *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUSStatus;
+  UINT64Attribute;
+
+  if (IoMmu != NULL) {
+Status = IoMmu->Map (
+  IoMmu,
+  Operation,
+  HostAddress,
+  NumberOfBytes,
+  DeviceAddress,
+  Mapping
+  );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = IoMmu->SetAttribute (
+  IoMmu,
+  *Mapping,
+  Attribute
+  );
+if (EFI_ERROR (Status)) {
+  IoMmu->Unmap (IoMmu, Mapping);
+  *Mapping = NULL;
+  return Status;
+}
+  } else {
+*DeviceAddress = (EFI_PHYSICAL_ADDRESS) (UINTN) HostAddress;
+*Mapping = NULL;
+Status = EFI_SUCCESS;
+  }
+  return Status;
+}
+
+/**
+  Completes the Map() operation and releases any corresponding resources.
+
+  @param IoMmu  Pointer to IOMMU PPI.
+  @param MappingThe mapping value returned from Map().
+
+**/
+VOID
+IoMmuUnmap (
+  IN EDKII_IOMMU_PPI*IoMmu,
+  IN VOID  *Mapping
+  )
+{
+  if (IoMmu != NULL) {
+IoMmu->SetAttribute (IoMmu, Mapping, 0);
+

[edk2] [PATCH v2 0/2] Refine UDF related codes

[Hao Wu]

V2 changes:
For patch
MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF:

PartitionInstallUdfChildHandles() should return EFI_SUCCESS when either El
Torito feature or UDF support is detected on CD/DVD media.

Previous version of the series only return EFI_SUCCESS when the UDF
support is detected, which may bring issue when only El Torito feature is
supported by a CD/DVD medium. For such case, child handle will be created
but the PartitionDxe driver will close the diskio & device path protocols
on the parent handle.


V1 history:
The series will do the following refinements:
a. Merge the discovery of the El Torito feature on CD/DVD media into the
   detect of UDF;
b. Avoid possible loss track of the allocated buffer pointer in UdfDxe.

Cc: Paulo Alcantara 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 

Hao Wu (2):
  MdeModulePkg/PartitionDxe: Merge the discovery of ElTorito into UDF
  MdeModulePkg/UdfDxe: Avoid possible loss track of allocated buffer

 MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c  |  7 +++--
 MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c| 27 
++--
 MdeModulePkg/Universal/Disk/UdfDxe/FileSystemOperations.c | 12 +
 3 files changed, 35 insertions(+), 11 deletions(-)

-- 
2.12.0.windows.1

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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Linux Build Script Change.

[zwei4]

Add /B build option for Benson FAB B.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: zwei4 

---
 Platform/BroxtonPlatformPkg/BuildBxtBios.sh | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/BuildBxtBios.sh 
b/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
index d0b677f..d1a16e6 100644
--- a/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
+++ b/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
@@ -176,8 +176,13 @@ else
 fi
 
 if [ $BoardId == "BG" ]; then
-  BOARD_REV=A
-  echo BOARD_REV = A >> $WORKSPACE/Conf/BiosId.env
+  if [ $FabId == "B" ]; then
+BOARD_REV=B
+echo BOARD_REV = B >> $WORKSPACE/Conf/BiosId.env
+  else 
+BOARD_REV=A
+echo BOARD_REV = A >> $WORKSPACE/Conf/BiosId.env
+  fi
 fi
 
 if [ $BoardId == "MN" ]; then
@@ -291,10 +296,17 @@ cp -f $BUILD_PATH/FV/FVIBBM.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Too
 cp -f $BUILD_PATH/FV/FVIBBL.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 
 if [ $BoardId == "BG" ]; then
-  cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-  cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-  cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-  cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+  if [ $FabId == "B" ]; then
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_B/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_B/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_B/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_B/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+  else 
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/BensonGlacier/FAB_A/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+  fi
 fi
 
 if [ $BoardId == "MN" ]; then
-- 
2.7.4

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

Re: [edk2] [RFC v2 0/3] Stack trace support in X64 exception handling

[Andrew Fish]

Paulo,

Those attached stack traces don't look right. 

Thanks,

Andrew Fish

> On Nov 15, 2017, at 5:46 PM, Paulo Alcantara  wrote:
> 
> Hi,
> 
> On 11/15/2017 11:18 PM, Paulo Alcantara wrote:
>> Hi,
>> This series adds stack trace support during a X64 CPU exception.
>> Informations like back trace, stack contents and image module names
>> (that were part of the call stack) will be dumped out.
>> We already have such support in ARM/AArch64 (IIRC) exception handling
>> (thanks to Ard), and then I thought we'd also deserve it in X64 and
>> IA-32 platforms.
>> What do you think guys?
>> BTW, I've tested this only with OVMF (X64 only), using:
>>   - gcc-6.3.0, GCC5, NOOPT
>> Any other tests  would be really appreciable.
>> Thanks!
>> Paulo
>> Repo:   https://github.com/pcacjr/edk2.git
>> Branch: stacktrace_v2
>> Cc: Rick Bramley 
>> Cc: Andrew Fish 
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Cc: "Brian J. Johnson" 
>> Cc: Jeff Fan 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Paulo Alcantara 
>> ---
>> v1 -> v2:
>>   * Add IA32 arch support (GCC toolchain only)
>>   * Replace hard-coded stack alignment value (16) with
>> CPU_STACK_ALIGNMENT.
>>   * Check for proper stack and frame pointer alignments.
>>   * Fix initialization of UnwoundStacksCount to 1.
>>   * Move GetPdbFileName() to common code since it will be used by both
>> IA32 and X64 implementations.
> 
> Sorry for the delay in sending v2. It's holiday here :-)
> 
> FWIW, I've attached two files which contain stack trace dumps of IA32 and X64 
> exceptions.
> 
> The new IA32 arch support is still limited to GCC only (that is, relying on 
> frame pointers), but I'll start investing in a new solution that would work 
> on both MSVC and GCC toolchains -- probably this weekend. If I come up with 
> something, I'll let you know.
> 
> On IA32, I performed the same test as in X64 to trigger an NMI interrupt 
> manually with: asm ("int $0x2") in PartitionDxe driver and watched out the 
> call stack. The difference between the two dumps, regardless the CPU context, 
> etc. is that we don't see the calls from PeiCore.dll. Then I figured out that 
> the EIP gets a value of 0 before jumping to PartitionDxe's entry point.
> 
> I guess that's related to the "push $0" that Andrew mentioned earlier so the 
> debugger knows when to stop unwinding. Although I can't see a "push 0" 
> equivalent neither in SwitchStack.nasm nor in SwitchStack.asm for X64
> -- so we're able to see the calls within PeiCore.dll.
> 
> Thanks!
> Paulo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org 
> https://lists.01.org/mailman/listinfo/edk2-devel 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V3 0/2] Add Max LUN status/value checks

[Zeng, Star]

Reviewed-by: Star Zeng 

Thanks,
Star
-Original Message-
From: Kinney, Michael D 
Sent: Thursday, November 16, 2017 11:58 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric 
Subject: [Patch V3 0/2] Add Max LUN status/value checks

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

Changes in V3
* Only check number of bytes transfered if Direction is not UsbNoData.

Add error check to USB I/O Protocol UsbControlTransfer() for the number of 
bytes actually transfered.  If less than requested, then return 
EFI_DEVICE_ERROR.

Check Get Max LUN status/value in USB Mass Storage Driver to handle cases where 
USB device does not support Get Max LUN command or returned an invalud Max LUN 
value.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 

Michael D Kinney (2):
  MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check
  MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN status/value

 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c | 16 +++-
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 14 +-
 2 files changed, 28 insertions(+), 2 deletions(-)

--
2.14.2.windows.3

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

[edk2] [Patch V3 0/2] Add Max LUN status/value checks

[Michael D Kinney]

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

Changes in V3
* Only check number of bytes transfered if Direction is not UsbNoData.

Add error check to USB I/O Protocol UsbControlTransfer() for the
number of bytes actually transfered.  If less than requested, then
return EFI_DEVICE_ERROR.

Check Get Max LUN status/value in USB Mass Storage Driver to handle
cases where USB device does not support Get Max LUN command or
returned an invalud Max LUN value.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 

Michael D Kinney (2):
  MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check
  MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN status/value

 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c | 16 +++-
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 14 +-
 2 files changed, 28 insertions(+), 2 deletions(-)

-- 
2.14.2.windows.3

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

[edk2] [Patch V3 1/2] MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check

[Michael D Kinney]

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

The USB I/O Protocol function ControlTransfer() has a DataLength
parameter that specifies the size of the Data buffer.  The
UsbBusDxe module implements the USB I/O Protocol using the
services of the USB2 Host Controller Protocol.  The DataLength
parameter in the USB2 Host Controller Protocol ControlTransfer()
service is an IN OUT parameter so the number of bytes actually
transferred is returned.  Since the USB I/O Protocol
ControlTransfer() service can not return the number of bytes
actually transferred, the only option if the number of bytes
actually transferred is less than the number of bytes requested
is to return EFI_DEVICE_ERROR.

The change fixes an issue with a USB mass storage device that
responds with 0 bytes to the Get MAX LUN command.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c 
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c
index 78220222f6..7c58fe8d36 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c
@@ -2,7 +2,7 @@
 
 Usb Bus Driver Binding and Bus IO Protocol.
 
-Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 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
@@ -76,6 +76,7 @@ UsbIoControlTransfer (
   USB_ENDPOINT_DESC   *EpDesc;
   EFI_TPL OldTpl;
   EFI_STATUS  Status;
+  UINTN   RequestedDataLength;
 
   if (UsbStatus == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -86,6 +87,7 @@ UsbIoControlTransfer (
   UsbIf  = USB_INTERFACE_FROM_USBIO (This);
   Dev= UsbIf->Device;
 
+  RequestedDataLength = DataLength;
   Status = UsbHcControlTransfer (
  Dev->Bus,
  Dev->Address,
@@ -99,6 +101,18 @@ UsbIoControlTransfer (
  >Translator,
  UsbStatus
  );
+  //
+  // If the request completed sucessfully and the Direction of the request is
+  // EfiUsbDataIn or EfiUsbDataOut, then make sure the actual number of bytes
+  // transfered is the same as the number of bytes requested.  If a different
+  // number of bytes were transfered, then return EFI_DEVICE_ERROR.
+  //
+  if (!EFI_ERROR (Status)) {
+if (Direction != EfiUsbNoData && DataLength != RequestedDataLength) {
+  Status = EFI_DEVICE_ERROR;
+  goto ON_EXIT;
+}
+  }
 
   if (EFI_ERROR (Status) || (*UsbStatus != EFI_USB_NOERROR)) {
 //
-- 
2.14.2.windows.3

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

[edk2] [Patch V3 2/2] MdeModulePkg/UsbMassStorageDxe: Check Get Max LUN status/value

[Michael D Kinney]

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

If a USB Mass Storage device does not support the Get
Max LUN command, then the USB I/O Protocol ControlTransfer()
service may return an error.  If an error is returned for
this command, then assume that the device does not support
multiple LUNs and return a maximum LUN value of 0.

The USB Mass Storage Class Specification states that a
maximum LUN value larger than 0x0F is invalid.  Add
a check to make sure this maximum LUN value is in this
valid range, and if it is not, then assume that the
device does not support multiple LUNs and return a
maximum LUN value of 0.

This change improves compatibility with USB FLASH drives
that do not support the Get Max LUN command or return
an invalid maximum LUN value.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
---
 MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c 
b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
index 4bb7222b89..6afe2ae235 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
@@ -2,7 +2,7 @@
   Implementation of the USB mass storage Bulk-Only Transport protocol,
   according to USB Mass Storage Class Bulk-Only Transport, Revision 1.0.
 
-Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 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
@@ -576,6 +576,18 @@ UsbBotGetMaxLun (
 1,
 
 );
+  if (EFI_ERROR (Status) || *MaxLun > USB_BOT_MAX_LUN) {
+//
+// If the Get LUN request returns an error or the MaxLun is larger than
+// the maximum LUN value (0x0f) supported by the USB Mass Storage Class
+// Bulk-Only Transport Spec, then set MaxLun to 0.
+//
+// This improves compatibility with USB FLASH drives that have a single LUN
+// and either do not return a max LUN value or return an invalid maximum 
LUN
+// value.
+//
+*MaxLun = 0;
+  }
 
   return Status;
 }
-- 
2.14.2.windows.3

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

Re: [edk2] [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check

[Kinney, Michael D]

Star,

I agree they are optional.  The description says
DataLength should be 0 and Data should be NULL for
the EfiUsbNoData case.  That is why I did not think
Direction needed to be evaluated if DataLength must
be 0 in this case.

In fact, the Host Controller implementations return
an error if this is not the case:

  if ((TransferDirection == EfiUsbNoData) &&
  ((Data != NULL) || (*DataLength != 0))) {
return EFI_INVALID_PARAMETER;
  }

So I think the logic in the current patch is safe.

However, since there are questions on this topic,
I agree I can update the logic to only check for
short data if Direction is not EfiUsbNoData.  That
should help reduce questions in future reviews of
this function.  I will also add more comments.

Thanks for the feedback.

Mike
 
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 15, 2017 6:26 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star
> 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Mike,
> 
> Yes, the DataLength could be read. And Data/DataLength
> is optional when Direction is EfiUsbNoData per my
> understanding.
> 
>   IN  OUT VOID*Data,  OPTIONAL
>   IN  UINTN   DataLength, OPTIONAL
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, November 16, 2017 12:44 AM
> To: Zeng, Star ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> Cc: Dong, Eric 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Star,
> 
> I have read that section, and I do not see anything
> that says the DataLength parameter can not be read.
> 
> Mike
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, November 14, 2017 8:23 PM
> > To: Kinney, Michael D ;
> > edk2-devel@lists.01.org
> > Cc: Dong, Eric ; Zeng, Star
> 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Mike,
> >
> > UEFI spec, EFI_USB_IO_PROTOCOL.UsbControlTransfer(),
> in the
> > description.
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, November 15, 2017 12:00 PM
> > To: Zeng, Star ; edk2-
> de...@lists.01.org;
> > Kinney, Michael D 
> > Cc: Dong, Eric 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Star,
> >
> > I am curious.  Which spec statement are you referring
> to?
> >
> > Mike
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Tuesday, November 14, 2017 6:59 PM
> > > To: Kinney, Michael D ;
> > > edk2-devel@lists.01.org
> > > Cc: Dong, Eric ; Zeng, Star
> > 
> > > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> > Add
> > > UsbControlTransfer() error check
> > >
> > > Mike,
> > >
> > > I do not insist on the check that the Direction is
> > not EfiUsbNoData,
> > > and I know the functionality should have no
> > improvement with the
> > > check.
> > > So, you can have my Reviewed-by: Star Zeng
> > .
> > >
> > > I raised the question just for consideration from
> > literally, as
> > > according to the spec, the code could not touch
> > DataLength at all when
> > > Direction is EfiUsbNoData.
> > >
> > > You can decide to have / have not the check when
> > pushing. :)
> > >
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Wednesday, November 15, 2017 10:46 AM
> > > To: Zeng, Star ; edk2-
> > de...@lists.01.org;
> > > Kinney, Michael D 
> > > Cc: Dong, Eric 
> > > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> > Add
> > > UsbControlTransfer() error check
> > >
> > > Star,
> > >
> > > For that case both DataLength and
> RequestedDataLength
> > will be 0 and
> > > the new path will not be taken.
> > >
> > > Are you concerned that the USB HC Protocol could
> > return a non zero
> > > DataLength for the EfiUsbNoData case?  Even if it
> > does, the new path
> > > can never be taken because 0 is less than all UINTN
> > values.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Zeng, Star
> > > > Sent: Tuesday, November 14, 2017 6:40 PM
> > > > To: Kinney, Michael D
> ;
> > > > edk2-devel@lists.01.org
> > > > Cc: Dong, Eric ; Zeng, Star
> > > 
> > > > Subject: RE: [Patch V2 1/2]
> MdeModulePkg/UsbBusDxe:
> > > Add
> > > > UsbControlTransfer() error check
> > > >
> > > > Mike,
> > > >

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

[Yao, Jiewen]

I second.

Since this patch breaks existing OS, I agree that we should rollback the memory 
map change.
It means we can use original memory map, by filtering all page attributes.
I also suggest we add detail comment on why we do that.
GCD map is OK, which has both attribute and capability. And GCD is OS invisible.

For the ambiguity of the UEFI spec, I also agree. Maybe USWG is a better place 
to clarify the definition. But that cannot resolve the compatibility of exiting 
UEFI OS.

Since we have already seen 2 regression and compatibility issues related to 
UEFI memory map change, I suggest we always keep UEFI memory map always 
unchanged at first, unless we validated all production UEFI OS, to make sure no 
regression at all.

Thank you
Yao Jiewen


> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 16, 2017 10:47 AM
> To: Ard Biesheuvel ; Laszlo Ersek
> 
> Cc: Wang, Jian J ; Matt Fleming
> ; edk2-devel@lists.01.org; Yao, Jiewen
> ; Dong, Eric ; Zeng, Star
> 
> Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> Seemingly, the Memory Attributes Table should be consumed for memory
> protection.
> 
> UEFI spec: "The Memory Attributes Table is currently used to describe memory
> protections that may be applied to the EFI Runtime code and data by an
> operating system or hypervisor."
> Someone (Jiewen?) familiar with the table could help introduce the background.
> 
> And seemingly, the capabilities in UEFI memory map could not have paging
> related as it will break the compatibility to OS.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 15, 2017 11:59 PM
> To: Laszlo Ersek 
> Cc: Wang, Jian J ; Zeng, Star ;
> Matt Fleming ; edk2-devel@lists.01.org; Yao,
> Jiewen ; Dong, Eric 
> Subject: Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> On 15 November 2017 at 15:48, Laszlo Ersek  wrote:
> > Hi Jian,
> >
> > On 11/15/17 10:27, Wang, Jian J wrote:
> >> I tried this workaround and there're no failure in booting Fedora 26
> >> and Windows server 2016 now. If no objection, I'll merge it into new 
> >> version of
> this patch.
> >
> > I'm not too familiar with the Linux kernel's EFI pieces myself; that's
> > why I added Ard and Matt earlier to the thread (when I responded with
> > the regression report) -- Ard and Matt maintain EFI in the Linux kernel.
> >
> > So, if you think there's a bug in Linux (i.e., a mis-interpretation of
> > the UEFI spec), can you guys please discuss that together? Below you wrote:
> >
> > - "I think it must be that the kernel will mark the memory block to be
> >RO/XP/RP memory according to its capabilities but not its current
> >attributes"
> >
> 
> The UEFI spec does not distinguish between capabilities and attributes, so how
> on earth should the OS be able to make this distinction?
> 
> For instance, the UEFI spec defines EFI_MEMORY_RO as
> 
> """
> Physical memory protection attribute: The memory region supports making this
> memory range read-only by system hardware.
> """
> 
> which is essentially a capability not an attribute. However, EFI_MEMORY_RO/XP
> are also used to convey information about the nature of the *contents* of the
> memory region, i.e., is it .text, .rodata or .data/.bss
> 
> So given that the OS only has the UEFI memory map to go on, how exactly should
> it figure out what these attributes are meant to imply?
> 
> > - "there's real gap between UEFI and OS on how to interpret the memory
> >capabilities"
> >
> 
> Yes. There is also a gap between how GCD and the UEFI memory map interpret
> these attributes, which is why nobody bothers to set the protection 
> capabilities
> for GCD: it gets copied into the UEFI memory map, and nobody has a clue how
> the OS should treat it.
> 
> When the [short lived]
> EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DA
> TA
> feature was introduced, it was essentially decided that RO and XP may be used 
> to
> annotate the nature of the contents of memory regions, where code was
> mapped RO and data mapped XP.
> 
> > Why is it wrong for the OS kernel, according to the UEFI spec, to
> > change the attributes / mappings of a memory area, as long as it stays
> > compliant with the advertised capabilities? How is an OS expected to
> > work, upon seeing those new "paging capabilities from UEFI memory map"
> > (in Star's words)?
> >
> > Apparently, it's not just Linux that's confused; see the Win2016 crash
> > too. Is the UEFI spec detailed enough on those capabilities? (Recently
> > I tried to review the paging 

Re: [edk2] [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check

[Zeng, Star]

Mike,

Yes, the DataLength could be read. And Data/DataLength is optional when 
Direction is EfiUsbNoData per my understanding.

  IN  OUT VOID*Data,  OPTIONAL
  IN  UINTN   DataLength, OPTIONAL


Thanks,
Star
-Original Message-
From: Kinney, Michael D 
Sent: Thursday, November 16, 2017 12:44 AM
To: Zeng, Star ; edk2-devel@lists.01.org; Kinney, Michael 
D 
Cc: Dong, Eric 
Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() 
error check

Star,

I have read that section, and I do not see anything that says the DataLength 
parameter can not be read.

Mike

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, November 14, 2017 8:23 PM
> To: Kinney, Michael D ; 
> edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Mike,
> 
> UEFI spec, EFI_USB_IO_PROTOCOL.UsbControlTransfer(), in the 
> description.
> 
> Thanks,
> Star
> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, November 15, 2017 12:00 PM
> To: Zeng, Star ; edk2- de...@lists.01.org; 
> Kinney, Michael D 
> Cc: Dong, Eric 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Star,
> 
> I am curious.  Which spec statement are you referring to?
> 
> Mike
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, November 14, 2017 6:59 PM
> > To: Kinney, Michael D ; 
> > edk2-devel@lists.01.org
> > Cc: Dong, Eric ; Zeng, Star
> 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Mike,
> >
> > I do not insist on the check that the Direction is
> not EfiUsbNoData,
> > and I know the functionality should have no
> improvement with the
> > check.
> > So, you can have my Reviewed-by: Star Zeng
> .
> >
> > I raised the question just for consideration from
> literally, as
> > according to the spec, the code could not touch
> DataLength at all when
> > Direction is EfiUsbNoData.
> >
> > You can decide to have / have not the check when
> pushing. :)
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, November 15, 2017 10:46 AM
> > To: Zeng, Star ; edk2-
> de...@lists.01.org;
> > Kinney, Michael D 
> > Cc: Dong, Eric 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Star,
> >
> > For that case both DataLength and RequestedDataLength
> will be 0 and
> > the new path will not be taken.
> >
> > Are you concerned that the USB HC Protocol could
> return a non zero
> > DataLength for the EfiUsbNoData case?  Even if it
> does, the new path
> > can never be taken because 0 is less than all UINTN
> values.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Tuesday, November 14, 2017 6:40 PM
> > > To: Kinney, Michael D ; 
> > > edk2-devel@lists.01.org
> > > Cc: Dong, Eric ; Zeng, Star
> > 
> > > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> > Add
> > > UsbControlTransfer() error check
> > >
> > > Mike,
> > >
> > > Do you think it is better or not to also check the
> > Direction is not
> > > EfiUsbNoData?
> > >
> > > UEFI spec,
> EFI_USB_IO_PROTOCOL.UsbControlTransfer():
> > > If the Direction parameter is EfiUsbNoData, Data is
> > NULL, and
> > > DataLength is 0, then no data phase exists for the
> > control transfer.
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Wednesday, November 15, 2017 9:03 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Dong, Eric
> > 
> > > Subject: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> > > UsbControlTransfer() error check
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=767
> > >
> > > The USB I/O Protocol function ControlTransfer() has
> a
> > DataLength
> > > parameter that specifies the size of the Data
> buffer.
> > The UsbBusDxe
> > > module implements the USB I/O Protocol using the
> > services of the USB2
> > > Host Controller Protocol.  The DataLength parameter
> > in the
> > > USB2 Host Controller Protocol ControlTransfer()
> > service is an IN OUT
> > > parameter so the number of bytes actually
> transferred
> > is returned.
> > > Since the USB I/O Protocol
> > > ControlTransfer() service can not return the number
> > of bytes actually
> > > transferred, the only option if the number of bytes
> > actually
> > > 

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

[Yao, Jiewen]

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?

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

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.

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?

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?
> +//
> +// 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 
> ---
>  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 369
> +++-
>  1 file changed, 367 insertions(+), 2 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
> index 65f0cff680..11cd7c9e1c 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,350 @@ DumpCpuContext (
>  );
>  }
> 
> +/**
> +  Get absolute path and file name of PDB file in PE/COFF image.
> +
> +  @param[in]  ImageBaseBase 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  UINTNImageBase,
> +  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]  UnwondStacksCount  Count of unwond stack frames.
> +**/
> +STATIC
> +VOID
> +DumpStackContents (
> +  IN UINT64  CurrentRsp,
> +  IN INTNUnwondStacksCount
> +  )
> +{
> +  //
> +  // 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 

Re: [edk2] [RFC v2 0/3] Stack trace support in X64 exception handling

[Paulo Alcantara]

Hi,

On 11/15/2017 11:18 PM, Paulo Alcantara wrote:

Hi,

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

Informations like back trace, stack contents and image module names
(that were part of the call stack) will be dumped out.

We already have such support in ARM/AArch64 (IIRC) exception handling
(thanks to Ard), and then I thought we'd also deserve it in X64 and
IA-32 platforms.

What do you think guys?

BTW, I've tested this only with OVMF (X64 only), using:
   - gcc-6.3.0, GCC5, NOOPT

Any other tests  would be really appreciable.

Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: stacktrace_v2

Cc: Rick Bramley 
Cc: Andrew Fish 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: "Brian J. Johnson" 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---

v1 -> v2:
   * Add IA32 arch support (GCC toolchain only)
   * Replace hard-coded stack alignment value (16) with
 CPU_STACK_ALIGNMENT.
   * Check for proper stack and frame pointer alignments.
   * Fix initialization of UnwoundStacksCount to 1.
   * Move GetPdbFileName() to common code since it will be used by both
 IA32 and X64 implementations.


Sorry for the delay in sending v2. It's holiday here :-)

FWIW, I've attached two files which contain stack trace dumps of IA32 
and X64 exceptions.


The new IA32 arch support is still limited to GCC only (that is, relying 
on frame pointers), but I'll start investing in a new solution that 
would work on both MSVC and GCC toolchains -- probably this weekend. If 
I come up with something, I'll let you know.


On IA32, I performed the same test as in X64 to trigger an NMI interrupt 
manually with: asm ("int $0x2") in PartitionDxe driver and watched out 
the call stack. The difference between the two dumps, regardless the CPU 
context, etc. is that we don't see the calls from PeiCore.dll. Then I 
figured out that the EIP gets a value of 0 before jumping to 
PartitionDxe's entry point.


I guess that's related to the "push $0" that Andrew mentioned earlier so 
the debugger knows when to stop unwinding. Although I can't see a "push 
0" equivalent neither in SwitchStack.nasm nor in SwitchStack.asm for X64

-- so we're able to see the calls within PeiCore.dll.

Thanks!
Paulo
 X64 Exception Type - 02(NMI Interrupt)  CPU Apic ID -  
RIP  - 7EC30266, CS  - 0038, RFLAGS - 0202
RAX  - 7FE71018, RCX - 7F34F498, RDX - 7FE71018
RBX  - 00810248, RSP - 7FEE4C70, RBP - 7FEE4CB0
RSI  - 0007, RDI - 7F34E018
R8   - 7EC32DC8, R9  - 7F34E298, R10 - 0036
R11  - 00D7, R12 - , R13 - 
R14  - , R15 - 
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 80010033, CR2 - , CR3 - 7FE83000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 7FE71A98 0047, LDTR - 
IDTR - 7F7AB018 0FFF,   TR - 
FXSAVE_STATE - 7FEE48D0

Call trace:
0 0x7EC30266 @ 0x7EC28000+0x8265 (0x7FEE4CB0) in 
PartitionDxe.dll
1 0x7EC3063D @ 0x7EC28000+0x863C (0x7FEE4CE0) in 
PartitionDxe.dll
2 0x7EC2B116 @ 0x7EC28000+0x3115 (0x7FEE4D20) in 
PartitionDxe.dll
3 0x7FEF8A15 @ 0x7EC28000+0x12D0A14 (0x7FEE4DB0) in 
PartitionDxe.dll
4 0x7FF10F0A @ 0x7EC28000+0x12E8F09 (0x7FEE4E30) in 
PartitionDxe.dll
5 0x7FF13445 @ 0x7EC28000+0x12EB444 (0x7FEE4F60) in 
PartitionDxe.dll
6 0x7FF13BC9 @ 0x7EC28000+0x12EBBC8 (0x7FEE4F90) in 
PartitionDxe.dll
7 0x7FEE9DDE @ 0x7EC28000+0x12C1DDD (0x7FEE4FC0) in 
PartitionDxe.dll
8 0x7FF5B75F @ 0x7EC28000+0x133375E (0x7BFDC840) in 
PartitionDxe.dll
9 0x7FF61551 @ 0x7EC28000+0x1339550 (0x7BFDC8C0) in 
PartitionDxe.dll
10 0x7FF6031D @ 0x7EC28000+0x133831C (0x7BFDCA30) in 
PartitionDxe.dll
11 0x7FF6CDCB @ 0x7EC28000+0x1344DCA (0x7BFDCF80) in 
PartitionDxe.dll
12 0x008286F4 @ 0x00820140+0x85B3 (0x7BFDD4D0) in 
PeiCore.dll
13 0x00830940 @ 0x00820140+0x107FF (0x00817600) in 
PeiCore.dll
14 0x00831585 @ 0x00820140+0x11444 (0x008176D0) in 
PeiCore.dll
15 0x00828DAD @ 0x00820140+0x8C6C (0x00817C20) in 
PeiCore.dll
16 

[edk2] [RFC v2 0/3] Stack trace support in X64 exception handling

[Paulo Alcantara]

Hi,

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

Informations like back trace, stack contents and image module names
(that were part of the call stack) will be dumped out.

We already have such support in ARM/AArch64 (IIRC) exception handling
(thanks to Ard), and then I thought we'd also deserve it in X64 and
IA-32 platforms.

What do you think guys?

BTW, I've tested this only with OVMF (X64 only), using:
  - gcc-6.3.0, GCC5, NOOPT

Any other tests  would be really appreciable.

Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: stacktrace_v2

Cc: Rick Bramley 
Cc: Andrew Fish 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: "Brian J. Johnson" 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---

v1 -> v2:
  * Add IA32 arch support (GCC toolchain only)
  * Replace hard-coded stack alignment value (16) with
CPU_STACK_ALIGNMENT.
  * Check for proper stack and frame pointer alignments.
  * Fix initialization of UnwoundStacksCount to 1.
  * Move GetPdbFileName() to common code since it will be used by both
IA32 and X64 implementations.

Paulo Alcantara (3):
  UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support
  UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName()
  UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support

 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c| 102 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h|  25 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 303 
++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c  | 310 
+++-
 4 files changed, 682 insertions(+), 58 deletions(-)

-- 
2.14.3

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

[edk2] [RFC v2 3/3] UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support

[Paulo Alcantara]

This patch adds stack trace support during a IA32 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/CpuExceptionCommon.c|  42 ---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h|  11 -
 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 303 
+++-
 3 files changed, 301 insertions(+), 55 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index f62ab8c48c..867c5c01d6 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -109,48 +109,6 @@ InternalPrintMessage (
   SerialPortWrite ((UINT8 *)Buffer, AsciiStrLen (Buffer));
 }
 
-/**
-  Find and display image base address and return image base and its entry 
point.
-
-  @param CurrentEip  Current instruction pointer.
-
-**/
-VOID
-DumpModuleImageInfo (
-  IN  UINTN  CurrentEip
-  )
-{
-  EFI_STATUS   Status;
-  UINTNPe32Data;
-  VOID *PdbPointer;
-  VOID *EntryPoint;
-
-  Pe32Data = PeCoffSearchImageBase (CurrentEip);
-  if (Pe32Data == 0) {
-InternalPrintMessage (" Can't find image information. \n");
-  } else {
-//
-// Find Image Base entry point
-//
-Status = PeCoffLoaderGetEntryPoint ((VOID *) Pe32Data, );
-if (EFI_ERROR (Status)) {
-  EntryPoint = NULL;
-}
-InternalPrintMessage (" Find image ");
-PdbPointer = PeCoffLoaderGetPdbPointer ((VOID *) Pe32Data);
-if (PdbPointer != NULL) {
-  InternalPrintMessage ("%a", PdbPointer);
-} else {
-  InternalPrintMessage ("(No PDB) " );
-}
-InternalPrintMessage (
-  " (ImageBase=%016lp, EntryPoint=%016p) \n",
-  (VOID *) Pe32Data,
-  EntryPoint
-  );
-  }
-}
-
 /**
   Read and save reserved vector information
 
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 042207025e..478374d003 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -119,17 +119,6 @@ InternalPrintMessage (
   ...
   );
 
-/**
-  Find and display image base address and return image base and its entry 
point.
-
-  @param CurrentEip  Current instruction pointer.
-
-**/
-VOID
-DumpModuleImageInfo (
-  IN  UINTN  CurrentEip
-  );
-
 /**
   Display CPU information.
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
index f2c39eb193..169a0b660e 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
@@ -210,6 +210,289 @@ DumpCpuContext (
 );
 }
 
+/**
+  Dump stack trace.
+
+  @param[in]  SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
+  @param[out] UnwondStacksCount  Count of unwond stack frames.
+**/
+STATIC
+VOID
+DumpStackTrace (
+  IN  EFI_SYSTEM_CONTEXT   SystemContext,
+  OUT INTN *UnwondStacksCount
+  )
+{
+  UINT32  Eip;
+  UINT32  Ebp;
+  UINTN   ImageBase;
+  CHAR8   *PdbFileName;
+
+  //
+  // Set current EIP address
+  //
+  Eip = SystemContext.SystemContextIa32->Eip;
+
+  //
+  // Set current frame pointer address
+  //
+  Ebp = SystemContext.SystemContextIa32->Ebp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Ebp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image base address from current EIP
+  //
+  ImageBase = PeCoffSearchImageBase (Eip);
+  if (ImageBase == 0) {
+InternalPrintMessage (" Could not find backtrace information. ");
+return;
+  }
+
+  //
+  // Get PDB file name from initial PE/COFF image
+  //
+  GetPdbFileName (ImageBase, NULL, );
+
+  //
+  // Initialize count of unwond stacks
+  //
+  *UnwondStacksCount = 1;
+
+  //
+  // Print out back trace
+  //
+  InternalPrintMessage ("\nCall trace:\n");
+
+  for (;;) {
+//
+// Print stack frame in the following format:
+//
+// #  @ + (EBP) in [ | ]
+//
+InternalPrintMessage (
+  "%d 0x%08x @ 0x%08x+0x%x (0x%08x) in %a\n",
+  *UnwondStacksCount - 1,
+  Eip,
+  ImageBase,
+  Eip - ImageBase - 1,
+  Ebp,
+  PdbFileName
+  );
+
+//
+// Set EIP with 

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

[Paulo Alcantara]

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 | 369 
+++-
 1 file changed, 367 insertions(+), 2 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 65f0cff680..11cd7c9e1c 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,350 @@ DumpCpuContext (
 );
 }
 
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase 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  UINTNImageBase,
+  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]  UnwondStacksCount  Count of unwond stack frames.
+**/
+STATIC
+VOID
+DumpStackContents (
+  IN UINT64  CurrentRsp,
+  IN INTNUnwondStacksCount
+  )
+{
+  //
+  // 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 (UnwondStacksCount-- > 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;
+
+  //
+  // Set current RIP address
+  //
+  Rip = SystemContext.SystemContextX64->Rip;
+
+  //
+  // Set current frame pointer address
+  //
+  Rbp = SystemContext.SystemContextX64->Rbp;
+
+  //
+  // Check for proper frame pointer alignment
+  //
+  if (((UINTN)Rbp & (CPU_STACK_ALIGNMENT - 1)) != 0) {
+InternalPrintMessage (" Unaligned frame pointer. \n");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image base address from current RIP
+  //
+  ImageBase = PeCoffSearchImageBase (Rip);
+  if (ImageBase == 0) {
+InternalPrintMessage (" Could not find image module names. ");
+return;
+  }
+
+  //
+  // Get initial PE/COFF image's entry point
+  //
+  Status = PeCoffLoaderGetEntryPoint ((VOID *)ImageBase, );
+  if (EFI_ERROR (Status)) {
+EntryPoint = NULL;
+  }
+
+  //
+  // Get file name and absolute path of initial PDB file
+  //
+  GetPdbFileName (ImageBase, , );
+
+  //
+  // Print out initial image module name (if any)
+  //
+  if (PdbAbsoluteFilePath != NULL) {
+InternalPrintMessage (
+  "\n%a (ImageBase=0x%016lx, EntryPoint=0x%016lx):\n",
+  PdbFileName,
+  ImageBase,
+  (UINTN)EntryPoint
+  );
+InternalPrintMessage 

[edk2] [RFC v2 2/3] UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName()

[Paulo Alcantara]

This function will be used by both IA32 and X64 exception handling in
order to print out image module names during stack unwinding.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c   | 60 
+++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h   | 14 +
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 59 
---
 3 files changed, 73 insertions(+), 60 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index dbfaae1d30..f62ab8c48c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -54,6 +54,11 @@ CONST CHAR8 *mExceptionNameStr[] = {
 
 #define EXCEPTION_KNOWN_NAME_NUM  (sizeof (mExceptionNameStr) / sizeof (CHAR8 
*))
 
+//
+// Unknown PDB file name
+//
+GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mUnknownPdbFileName = "";
+
 /**
   Get ASCII format string exception name by exception type.
 
@@ -177,4 +182,57 @@ ReadAndVerifyVectorInfo (
 VectorInfo ++;
   }
   return EFI_SUCCESS;
-}
\ No newline at end of file
+}
+
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  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;
+}
+  }
+}
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 740a58828b..042207025e 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -288,5 +288,19 @@ CommonExceptionHandlerWorker (
   IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );
 
+/**
+  Get absolute path and file name of PDB file in PE/COFF image.
+
+  @param[in]  ImageBaseBase address of PE/COFF image.
+  @param[out] PdbAbsoluteFilePath  Absolute path of PDB file.
+  @param[out] PdbFileName  File name of PDB file.
+**/
+VOID
+GetPdbFileName (
+  IN  UINTNImageBase,
+  OUT CHAR8**PdbAbsoluteFilePath,
+  OUT CHAR8**PdbFileName
+  );
+
 #endif
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 11cd7c9e1c..ace835c02c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -14,11 +14,6 @@
 
 #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.
@@ -247,60 +242,6 @@ DumpCpuContext (
 );
 }
 
-/**
-  Get absolute path and file name of PDB file in PE/COFF image.
-
-  @param[in]  ImageBaseBase 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  UINTNImageBase,
-  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 

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe

[Shannon Zhao]

On 2017/11/15 22:03, Ard Biesheuvel wrote:
> On 15 November 2017 at 13:51, Laszlo Ersek  wrote:
>> > On 11/14/17 11:22, Ard Biesheuvel wrote:
>>> >> The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
>>> >> assuming such regions always have full memory semantics. Given that
>>> >> those regions cannot be mapped as ordinary memory on ARM (due to the
>>> >> fact that the NOR flash requires device semantics while in write mode)
>>> >> this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
>>> >> since it may use unaligned accesses and/or DC ZVA instructions, both
>>> >> of which are incompatible with mappings using device semantics.
>>> >>
>>> >> Note that there is no way we can work around this by changing the
>>> >> mapping type between 'memory' and 'device' when switching from read to
>>> >> write mode and back, because the runtime mapping is created by the OS,
>>> >> and cannot be changed at will.
>>> >>
>>> >> So let's just switch to the unaccelerated version of BaseMemoryLib which
>>> >> does not have the same problem.
>>> >>
>>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>>> >> Signed-off-by: Ard Biesheuvel 
>>> >> ---
>>> >>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
>>> >>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
>>> >>  2 files changed, 4 insertions(+)
>>> >>
>>> >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> >> index 8a60b61f2aa6..7b220d6e3c31 100644
>>> >> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> >> @@ -261,6 +261,8 @@ [Components.common]
>>> >>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>>> >>  
>>> >>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>>> >> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
>>> >> region
>>> >> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>> >>}
>>> >>  !if $(SECURE_BOOT_ENABLE) == TRUE
>>> >>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
>>> >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
>>> >> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>>> >> index 9a31ec93ca06..7c032e1b07e0 100644
>>> >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
>>> >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>>> >> @@ -252,6 +252,8 @@ [Components.common]
>>> >>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>>> >>  
>>> >>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>>> >> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash 
>>> >> region
>>> >> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>> >>}
>>> >>  !if $(SECURE_BOOT_ENABLE) == TRUE
>>> >>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
>>> >>
>> >
>> > Reviewed-by: Laszlo Ersek 
>> >
>> > Given that we've never seen the symptom reported by Shannon, I must
>> > think Shannon is using some kind of new hardware. May I ask what
>> > hardware that is?
>> >
> I think this is equally likely to occur in any KVM hardware
> virtualization context. It is simply a regression after moving to the
> OptDxe BaseMemoryLib flavor.

Exactly. I'm using Huawei D05. It works well when I use a older edk2
while fails when updating to UDK2017 branch.

Tested-by: Shannon Zhao 

Thanks,
-- 
Shannon

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

Re: [edk2] [PATCH] OvmfPkg: PlatformDebugLibIoPort: save on I/O port accesses when the debug port is not in use

[Laszlo Ersek]

Hi Paolo,

On 11/15/17 18:30, Paolo Bonzini wrote:
> When SEV is enabled, every debug message printed by OVMF to the
> QEMU debug port traps from the guest to QEMU character by character
> because "REP OUTSB" cannot be used by IoWriteFifo8.  Furthermore,
> when OVMF is built with the DEBUG_VERBOSE bit (value 0x0040)
> enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
> OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
> library instance that is built into it, produce a huge amount of
> log messages.  Therefore, in SEV guests, the boot time impact is huge
> (about 45 seconds _additional_ time spent writing to the debug port).
> 
> While these messages are very useful for analyzing guest behavior,
> most of the time the user won't be capturing the OVMF debug log.
> In fact libvirt does not provide a method for configuring log capture;
> users that wish to do this (or are instructed to do this) have to resort
> to .
> 
> The debug console device provides a handy detection mechanism; when read,
> it returns 0xE9 (which is very much unlike the 0xFF that is returned by
> an unused port).  Use it to skip the possibly expensive OUT instructions
> when the debug I/O port isn't plugged anywhere.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Cc: Laszlo Ersek 
> Signed-off-by: Paolo Bonzini 
> ---
>  OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)

Thank you for the patch! Let's get the boring formalities out of the way:

- the subject line should be no longer than 74-76 characters,

- the TianoCore Contribution Agreement is now at version 1.1 :)

- please CC all maintainers for OvmfPkg from Maintainers.txt (and for
Xen-related patches, our Xen reviewers too -- probably not relevant
here). I've CC'd Ard and Jordan now.

- "static" is written "STATIC" in edk2 just because.

- not sure if Jordan wants BOCHS_DEBUG_PORT_MAGIC elsewhere (in some
header file), I'm fine with it here

- s/driver is inactive/device is inactive/ in a code comment, I guess (?)


More importantly: the detection via 0xE9 looks great; and the static
variable for caching the detection is suitable for the PEI phase and all
later phases. However, it is not suitable for the SEC phase, because SEC
runs from read-only flash. (This is also why we can't just make
PcdDebugPrintErrorLevel, i.e. the log filter mask, "dynamic" from
"fixed" -- we could never set it for, and consume it in, SEC, dynamically.)

The solution is to have two library instances, one for SEC and another
for all other firmware phases. The second is basically what you posted;
the first one will have to read the debug port in every spot where the
second one reads the variable. This won't be super fast, but SEC doesn't
print a whole lot of messages. Also,

- if the debug port is available, then reading one byte before writing a
full message isn't tragic,
- if the debug port is not available, then reading one byte instead of
writing a full message is still a win.


Steps for that:

(1) Have two INF files rather than one, called
PlatformDebugLibIoPort.inf and (say) PlatformRomDebugLibIoPort.inf

(2) Make sure their FILE_GUIDs differ (use uuidgen)

(3) update BASE_NAMEs as necessary

(4) Factor out a function for mDebugIoPortFound, to a new header file,
in the same directory. The new file should have (a) CRLF terminators,
(b) a license block at the top, (c) #include guards. The function can be
called InternalDebugIoPortFound() or some such.

(5) Add two C files, implementing InternalDebugIoPortFound()
differently. They can be called "DebugIoPort.c" and "RomDebugIoPort.c".

(6) Add the new C files to the INF files as necessary.

(7) Grep the OVMF DSC files for
"OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf", and
update those library resolutions as necessary.

I'll let others comment as well, I'm too tired for thinking clearly.

Thank you,
Laszlo


> diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
> b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> index 5435767c1c..06d6169dc8 100644
> --- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> +++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
> @@ -29,6 +29,16 @@
>  //
>  #define MAX_DEBUG_MESSAGE_LENGTH  0x100
>  
> +//
> +// The constant value that is read from the debug I/O port
> +//
> +#define BOCHS_DEBUG_PORT_MAGIC0xE9
> +
> +//
> +// Set to TRUE if the debug I/O port is enabled
> +//
> +static BOOLEAN mDebugIoPortFound = FALSE;
> +
>  /**
>This constructor function does not have to do anything.
>  
> @@ -41,6 +51,7 @@ PlatformDebugLibIoPortConstructor (
>VOID
>)
>  {
> +  mDebugIoPortFound = IoRead8 (PcdGet16 (PcdDebugIoPort)) == 
> BOCHS_DEBUG_PORT_MAGIC;
>return EFI_SUCCESS;
>  }
>  
> @@ -77,9 +88,9 @@ DebugPrint (
>ASSERT (Format != NULL);
>  
>//
> -  // Check driver debug mask 

Re: [edk2] [Patch] BaseTools: Fix the bug to collect source files per build rule family

[Zhu, Yonghong]

The bug is https://bugzilla.tianocore.org/show_bug.cgi?id=780 .
I will update the message to more clear, thanks.

Best Regards,
Zhu Yonghong

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, November 16, 2017 12:23 AM
To: Zhu, Yonghong ; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: Re: [edk2] [Patch] BaseTools: Fix the bug to collect source files per 
build rule family

Hello Yonghong,

On 11/14/17 06:52, Yonghong Zhu wrote:
> when collect source files list we should also consider build rule 
> family.

what bug does this patch fix? I guess the bug is that something is missed / not 
done, because changes to the build rules are not noticed?
Can you please elaborate in the commit message?

Thanks!
Laszlo

> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index b3e7089..008ad8e 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -3265,17 +3265,17 @@ class ModuleAutoGen(AutoGen):
>  # match tool chain
>  if F.TagName not in ("", "*", self.ToolChain):
>  EdkLogger.debug(EdkLogger.DEBUG_9, "The toolchain [%s] 
> for processing file [%s] is found, "
>  "but [%s] is needed" % (F.TagName, 
> str(F), self.ToolChain))
>  continue
> -# match tool chain family
> -if F.ToolChainFamily not in ("", "*", self.ToolChainFamily):
> +# match tool chain family or build rule family
> +if F.ToolChainFamily not in ("", "*", self.ToolChainFamily, 
> self.BuildRuleFamily):
>  EdkLogger.debug(
>  EdkLogger.DEBUG_0,
>  "The file [%s] must be built by tools of 
> [%s], " \
> -"but current toolchain family is [%s]" \
> -% (str(F), F.ToolChainFamily, 
> self.ToolChainFamily))
> +"but current toolchain family is [%s], 
> buildrule family is [%s]" \
> +% (str(F), F.ToolChainFamily, 
> + self.ToolChainFamily, self.BuildRuleFamily))
>  continue
>  
>  # add the file path into search path list for file including
>  if F.Dir not in self.IncludePathList and self.AutoGenVersion 
> >= 0x00010005:
>  self.IncludePathList.insert(0, F.Dir)
> 

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

Re: [edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Laszlo Ersek]

On 11/15/17 15:03, Ard Biesheuvel wrote:
> Now that the PL031 RTC driver library no longer depends on the ARM
> platform specific ArmPlatformSysConfigLib, we no longer need to
> implement ArmPlatform.h or have a resolution for that library.
> This allows us to get rid of a rather dodgy practice of including
> platform headers using compiler flags, which is a bad idea at various
> levels.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> PL031 patch is on-list and pending.
> 
>  ArmVirtPkg/ArmVirtQemu.dsc |  7 -
>  ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
>  ArmVirtPkg/ArmVirtXen.dsc  |  6 
>  ArmVirtPkg/Include/ArmPlatform.h   | 33 
> 
>  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
>  ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
>  ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
>  ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
>  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
>  ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
>  ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 -
>  11 files changed, 6 insertions(+), 59 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8a60b61f2aa6..d1b3849d856a 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>  
>ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>  
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -71,12 +70,6 @@ [LibraryClasses.common]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>  
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
> -
> -
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 9a31ec93ca06..c7058718b0a6 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -49,7 +49,6 @@ [LibraryClasses.common]
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
>  
>
> ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>  
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
> @@ -71,11 +70,6 @@ [LibraryClasses.common]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>  
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
> -
>  [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
># Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
># executable we build for the relocatable PrePi. They are not runtime
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index e9437066ca56..7a443483d1ac 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -44,7 +44,6 @@ [LibraryClasses]
>
> VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>  
>
> ArmPlatformLib|ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
> -  
> ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
>  
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>  
> @@ -56,11 +55,6 @@ [LibraryClasses]
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>  
> -[BuildOptions]
> -  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
> -I$(WORKSPACE)/ArmVirtPkg/Include
> -  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
> 

[edk2] [PATCH v2 4/4] OvmfPkg: restore temporary SEC/PEI RAM size to 64KB

[Laszlo Ersek]

(1) In the PEI phase, the PCD database is maintained in a GUID HOB. In
OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI),
so that all other PEIMs can use dynamic PCDs. Consequently,

- the PCD GUID HOB is initially allocated from the temporary SEC/PEI
  heap,

- whenever we introduce a dynamic PCD to a PEIM built into OVMF such
  that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and
  its temporary heap footprint) grow.

I've noticed that, if we add just one more dynamic PCD to the PEI
phase, then in the X64 build,

- we get very close to the half of the temporary heap (i.e., 8192
  bytes),

- obscure PEI phase hangs or DXE core initialization failures
  (ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and
  FD_SIZE_4MB builds of X64 OVMF.

(2) I've found that commit

  2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate
optimal settings", 2017-09-27)

introduced a large (16KB) stack allocation:

> The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
> MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation.
> ...
> +#define SCRATCH_BUFFER_SIZE   (4 * SIZE_4KB)
> ...
> @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings (
> ...
> +  UINT8  Scratch[SCRATCH_BUFFER_SIZE];

(3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit

  7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x7 to
0x81", 2014-01-21)

Of that, the upper 16KB half is stack (growing down), and the lower
16KB half is heap.

Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in
QemuInitializeRam(), cause the Scratch array to overflow the entire
stack (heading towards lower addresses), and corrupt the heap below
the stack. It turns out that the total stack demand is about 24KB, so
the overflow is able to corrupt the upper 8KB of the heap. If that
part of the heap is actually used (for example because we grow the PCD
GUID HOB sufficiently), mayhem ensues.

(4) Right after commit 7cb6b0e06809 (see above), there would be no room
left above the 32KB temp SEC/PEI RAM. However, given more recent
commits

  45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent
PEI memory for S3", 2016-07-13)

  6b04cca4d697 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase,
PcdS3AcpiReservedMemorySize", 2016-07-12)

we can now restore the temp SEC/PEI RAM size to the original
(pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI
stack, which accommodates the ~24KB demand mentioned in (3).

(Prior patches in this series will let us monitor the stack usage in
the future.)

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
Ref: a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com">http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com
Ref: 03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com">http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Jordan Justen 
---

Notes:
v2:
- pick up review tags from Ard and Jordan

 OvmfPkg/OvmfPkgIa32.fdf| 2 +-
 OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
 OvmfPkg/OvmfPkgX64.fdf | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 751522411857..06a439f8cba5 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -82,7 +82,7 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
-0x01|0x008000
+0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
 0x02|0x0E
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index f1a2044fb716..ced4c5639f39 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -82,7 +82,7 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
-0x01|0x008000
+0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
 0x02|0x0E
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 32000a3b934c..62dd58f6e47a 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -82,7 +82,7 @@ [FD.MEMFD]
 0x007000|0x001000
 

[edk2] [PATCH v2 2/4] OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack

[Laszlo Ersek]

This allows the PEI core to report the maximum temporary SEC/PEI stack
usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
[MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:

* Normal boot:

> Temp Stack : BaseAddress=0x814000 Length=0x4000
> Temp Heap  : BaseAddress=0x81 Length=0x4000
> Total temporary memory:32768 bytes.
>   temporary memory stack ever used:   3664 bytes. <
>   temporary memory heap used for HobList: 5904 bytes.
>   temporary memory heap occupied by memory pages: 0 bytes.

* S3 resume (with PEI decompression / SMM):

> Temp Stack : BaseAddress=0x814000 Length=0x4000
> Temp Heap  : BaseAddress=0x81 Length=0x4000
> Total temporary memory:32768 bytes.
>   temporary memory stack ever used:   3428 bytes. <
>   temporary memory heap used for HobList: 4816 bytes.
>   temporary memory heap occupied by memory pages: 0 bytes.

I unit-tested this change by transitorily adding an infinite loop right
after the "rep stosd", and dumping the guest's temp SEC/PEI RAM (32KB
currently) while the guest was stuck in the loop. The dump includes one
dword from before and after the temp SEC/PEI RAM:

> $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC'
>
> 0080fffc: 0x 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> 0081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> ...
> 00817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> 00817ffc: 0x5aa55aa5 0x

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- update comment on ES [Jordan]
- document the other segment registers too [Jordan]
- move seeding to top of routine [Jordan]
- hence, drop earlier EAX -> EBX renaming [Jordan]
- replace runtime right shift with compile-time division [Jordan]
- drop Ard's Reviewed-by

 OvmfPkg/Sec/SecMain.inf|  1 +
 OvmfPkg/Sec/Ia32/SecEntry.nasm | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index 711b59530907..6051cb3c6c4c 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -71,6 +71,7 @@ [Pcd]
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
+  gEfiMdeModulePkgTokenSpaceGuid.PcdInitValueInTempStack
 
 [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Sec/Ia32/SecEntry.nasm b/OvmfPkg/Sec/Ia32/SecEntry.nasm
index 7fee1c2b2e4f..03501969ebce 100644
--- a/OvmfPkg/Sec/Ia32/SecEntry.nasm
+++ b/OvmfPkg/Sec/Ia32/SecEntry.nasm
@@ -29,12 +29,30 @@ extern ASM_PFX(SecCoreStartupWithStack)
 ; @param[in]  EAX   Initial value of the EAX register (BIST: Built-in Self 
Test)
 ; @param[in]  DI'BP': boot-strap processor, or 'AP': application processor
 ; @param[in]  EBP   Pointer to the start of the Boot Firmware Volume
+; @param[in]  DSSelector allowing flat access to all addresses
+; @param[in]  ESSelector allowing flat access to all addresses
+; @param[in]  FSSelector allowing flat access to all addresses
+; @param[in]  GSSelector allowing flat access to all addresses
+; @param[in]  SSSelector allowing flat access to all addresses
 ;
 ; @return None  This routine does not return
 ;
 global ASM_PFX(_ModuleEntryPoint)
 ASM_PFX(_ModuleEntryPoint):
 
+;
+; Fill the temporary RAM with the initial stack value.
+; The loop below will seed the heap as well, but that's harmless.
+;
+mov eax, FixedPcdGet32 (PcdInitValueInTempStack)  ; dword to store
+mov edi, FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) ; base address,
+  ;   relative to
+  ;   ES
+mov ecx, FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 4 ; dword count
+cld   ; store from base
+  ;   up
+rep stosd
+
 ;
 ; Load temporary RAM stack based on PCDs
 ;
-- 
2.14.1.3.gb7cf6e02401b


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

[edk2] [PATCH v2 3/4] OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack

[Laszlo Ersek]

This allows the PEI core to report the maximum temporary SEC/PEI stack
usage on the DEBUG_INFO level, in the PeiCheckAndSwitchStack() function
[MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]:

* Normal boot:

> Temp Stack : BaseAddress=0x814000 Length=0x4000
> Temp Heap  : BaseAddress=0x81 Length=0x4000
> Total temporary memory:32768 bytes.
>   temporary memory stack ever used:   5080 bytes. <
>   temporary memory heap used for HobList: 8080 bytes.
>   temporary memory heap occupied by memory pages: 0 bytes.

* S3 resume (no SMM / PEI decompression)

> Temp Stack : BaseAddress=0x814000 Length=0x4000
> Temp Heap  : BaseAddress=0x81 Length=0x4000
> Total temporary memory:32768 bytes.
>   temporary memory stack ever used:   5048 bytes. <
>   temporary memory heap used for HobList: 7112 bytes.
>   temporary memory heap occupied by memory pages: 0 bytes.

I unit-tested this change by transitorily adding an infinite loop right
after the "rep stosq", and dumping the guest's temp SEC/PEI RAM (32KB
currently) while the guest was stuck in the loop. The dump includes one
dword from before and after the temp SEC/PEI RAM:

> $ virsh qemu-monitor-command GUEST_NAME --hmp 'xp /8194wx 0x80FFFC'
>
> 0080fffc: 0x 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> 0081000c: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> ...
> 00817fec: 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5 0x5aa55aa5
> 00817ffc: 0x5aa55aa5 0x

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- update comment on ES [Jordan]
- document the other segment registers too [Jordan]
- move seeding to top of routine, for consistency with the IA32 version
- replace runtime right shift with compile-time division [Jordan]
- compose qword-to-write at compile-time, not at runtime
- drop Ard's Reviewed-by

 OvmfPkg/Sec/X64/SecEntry.nasm | 21 
 1 file changed, 21 insertions(+)

diff --git a/OvmfPkg/Sec/X64/SecEntry.nasm b/OvmfPkg/Sec/X64/SecEntry.nasm
index f40427aa8e04..7c55032ac962 100644
--- a/OvmfPkg/Sec/X64/SecEntry.nasm
+++ b/OvmfPkg/Sec/X64/SecEntry.nasm
@@ -30,12 +30,33 @@ extern ASM_PFX(SecCoreStartupWithStack)
 ; @param[in]  RAX   Initial value of the EAX register (BIST: Built-in Self 
Test)
 ; @param[in]  DI'BP': boot-strap processor, or 'AP': application processor
 ; @param[in]  RBP   Pointer to the start of the Boot Firmware Volume
+; @param[in]  DSSelector allowing flat access to all addresses
+; @param[in]  ESSelector allowing flat access to all addresses
+; @param[in]  FSSelector allowing flat access to all addresses
+; @param[in]  GSSelector allowing flat access to all addresses
+; @param[in]  SSSelector allowing flat access to all addresses
 ;
 ; @return None  This routine does not return
 ;
 global ASM_PFX(_ModuleEntryPoint)
 ASM_PFX(_ModuleEntryPoint):
 
+;
+; Fill the temporary RAM with the initial stack value.
+; The loop below will seed the heap as well, but that's harmless.
+;
+mov rax, (FixedPcdGet32 (\
+PcdInitValueInTempStack  \
+) << 32) |   \
+ FixedPcdGet32 (PcdInitValueInTempStack)  ; qword to store
+mov rdi, FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) ; base address,
+  ;   relative to
+  ;   ES
+mov rcx, FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 8 ; qword count
+cld   ; store from base
+  ;   up
+rep stosq
+
 ;
 ; Load temporary RAM stack based on PCDs
 ;
-- 
2.14.1.3.gb7cf6e02401b


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

[edk2] [PATCH v2 1/4] UefiCpuPkg/ResetVector/Vtf0: document segment register setup

[Laszlo Ersek]

"Main.asm" calls TransitionFromReal16To32BitFlat (and does some other
things) before it jumps to the platform's SEC entry point.

TransitionFromReal16To32BitFlat enters big real mode, and sets the DS, ES,
FS, GS, and SS registers to offset ("selector") LINEAR_SEL in the GDT
(defined in "UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm"). The
GDT entry ("segment descriptor") at LINEAR_SEL defines a segment covering
the full 32-bit address space, meant for "read/write data".

Document this fact for all the affected segment registers, as output
parameters for TransitionFromReal16To32BitFlat, saying "Selector allowing
flat access to all addresses".

For 64-bit SEC, "Main.asm" calls Transition32FlatTo64Flat in addition,
between calling TransitionFromReal16To32BitFlat and jumping to the SEC
entry point. Transition32FlatTo64Flat enters long mode. In long mode,
segmentation is largely ignored:

- all segments are considered flat (covering the whole 64-bit address
  space),

- with the (possible) exception of FS and GS, whose bases can still be
  changed, albeit with new methods, not through the GDT. (Through the
  IA32_FS_BASE and IA32_GS_BASE Model Specific Registers, and/or the
  WRFSBASE, WRGSBASE and SWAPGS instructions.)

Thus, document the segment registers with the same "Selector allowing flat
access to all addresses" language on the "Main.asm" level too, since that
is valid for both 32-bit and 64-bit modes.

(Technically, "Main.asm" does not return, but RBP/EBP, passed similarly to
the SEC entry point, is already documented as an output parameter.)

Cc: Ard Biesheuvel 
Cc: Eric Dong 
Cc: Jordan Justen 
Suggested-by: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new patch [Jordan]

 UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm | 6 ++
 UefiCpuPkg/ResetVector/Vtf0/Main.asm| 5 +
 2 files changed, 11 insertions(+)

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm 
b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
index 146df600a63b..bc68c8dd749a 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
@@ -21,6 +21,12 @@ BITS16
 ;
 ; Modified:  EAX, EBX
 ;
+; @param[out] DS   Selector allowing flat access to all addresses
+; @param[out] ES   Selector allowing flat access to all addresses
+; @param[out] FS   Selector allowing flat access to all addresses
+; @param[out] GS   Selector allowing flat access to all addresses
+; @param[out] SS   Selector allowing flat access to all addresses
+;
 TransitionFromReal16To32BitFlat:
 
 debugShowPostCode POSTCODE_16BIT_MODE
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Main.asm 
b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
index ebfb9015d49c..57f080688b6f 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Main.asm
+++ b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
@@ -24,6 +24,11 @@ BITS16
 ; @param[in,out]  DI   'BP': boot-strap processor, or
 ;  'AP': application processor
 ; @param[out] RBP/EBP  Address of Boot Firmware Volume (BFV)
+; @param[out] DS   Selector allowing flat access to all addresses
+; @param[out] ES   Selector allowing flat access to all addresses
+; @param[out] FS   Selector allowing flat access to all addresses
+; @param[out] GS   Selector allowing flat access to all addresses
+; @param[out] SS   Selector allowing flat access to all addresses
 ;
 ; @return None  This routine jumps to SEC and does not return
 ;
-- 
2.14.1.3.gb7cf6e02401b


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

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

[Laszlo Ersek]

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(-)

-- 
2.14.1.3.gb7cf6e02401b

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

[edk2] [PATCH] OvmfPkg: PlatformDebugLibIoPort: save on I/O port accesses when the debug port is not in use

[Paolo Bonzini]

When SEV is enabled, every debug message printed by OVMF to the
QEMU debug port traps from the guest to QEMU character by character
because "REP OUTSB" cannot be used by IoWriteFifo8.  Furthermore,
when OVMF is built with the DEBUG_VERBOSE bit (value 0x0040)
enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
library instance that is built into it, produce a huge amount of
log messages.  Therefore, in SEV guests, the boot time impact is huge
(about 45 seconds _additional_ time spent writing to the debug port).

While these messages are very useful for analyzing guest behavior,
most of the time the user won't be capturing the OVMF debug log.
In fact libvirt does not provide a method for configuring log capture;
users that wish to do this (or are instructed to do this) have to resort
to .

The debug console device provides a handy detection mechanism; when read,
it returns 0xE9 (which is very much unlike the 0xFF that is returned by
an unused port).  Use it to skip the possibly expensive OUT instructions
when the debug I/O port isn't plugged anywhere.

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek 
Signed-off-by: Paolo Bonzini 
---
 OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c 
b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
index 5435767c1c..06d6169dc8 100644
--- a/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
+++ b/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c
@@ -29,6 +29,16 @@
 //
 #define MAX_DEBUG_MESSAGE_LENGTH  0x100
 
+//
+// The constant value that is read from the debug I/O port
+//
+#define BOCHS_DEBUG_PORT_MAGIC0xE9
+
+//
+// Set to TRUE if the debug I/O port is enabled
+//
+static BOOLEAN mDebugIoPortFound = FALSE;
+
 /**
   This constructor function does not have to do anything.
 
@@ -41,6 +51,7 @@ PlatformDebugLibIoPortConstructor (
   VOID
   )
 {
+  mDebugIoPortFound = IoRead8 (PcdGet16 (PcdDebugIoPort)) == 
BOCHS_DEBUG_PORT_MAGIC;
   return EFI_SUCCESS;
 }
 
@@ -77,9 +88,9 @@ DebugPrint (
   ASSERT (Format != NULL);
 
   //
-  // Check driver debug mask value and global mask
+  // Do nothing if the global mask disables this message or the driver is 
inactive
   //
-  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
+  if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0 || !mDebugIoPortFound) {
 return;
   }
 
@@ -138,7 +149,9 @@ DebugAssert (
   //
   // Send the print string to the debug I/O port
   //
-  IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), Length, Buffer);
+  if (mDebugIoPortFound) {
+IoWriteFifo8 (PcdGet16 (PcdDebugIoPort), Length, Buffer);
+  }
 
   //
   // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings
-- 
2.14.3

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

[edk2] [PATCH 19/19] ArmPlatformPkg: remove BootMonFs and ArmShellCmdRunAxf

[Ard Biesheuvel]

These modules have been imported into edk2-platforms where they belong
so remove them from the main EDK2 branch.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFs.inf  |   61 --
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsApi.h |  388 ---
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsDir.c |  766 
--
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsEntryPoint.c  |  529 
--
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsHw.h  |   57 --
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsImages.c  |  222 
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsInternal.h|  101 --
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsOpenClose.c   |  795 
---
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsReadWrite.c   |  259 -
 ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsUnsupported.c |   37 -
 ArmPlatformPkg/Include/Guid/BootMonFsFileInfo.h|   47 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.c   |   95 --
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.h   |   83 --
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf |   54 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.uni |   68 --
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/BootMonFsLoader.c |  154 ---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/BootMonFsLoader.h |   66 --
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ElfLoader.c   |  340 ---
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/ElfLoader.h   |   64 --
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/RunAxf.c  |  395 
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/elf32.h   |  258 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/elf64.h   |  260 -
 ArmPlatformPkg/Library/ArmShellCmdRunAxf/elf_common.h  | 1059 

 23 files changed, 6158 deletions(-)

diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFs.inf 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFs.inf
deleted file mode 100644
index b42d205a2bc3..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsApi.h 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsApi.h
deleted file mode 100644
index d690520a0f67..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsDir.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsDir.c
deleted file mode 100644
index 64ea0ec68048..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsEntryPoint.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsEntryPoint.c
deleted file mode 100644
index a1150856f6ba..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsHw.h 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsHw.h
deleted file mode 100644
index c1bef755aea0..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsImages.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsImages.c
deleted file mode 100644
index 346c360292eb..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsInternal.h 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsInternal.h
deleted file mode 100644
index c0c6599cb707..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsOpenClose.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsOpenClose.c
deleted file mode 100644
index ae10055255ff..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsReadWrite.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsReadWrite.c
deleted file mode 100644
index f8124e95ac0c..
diff --git a/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsUnsupported.c 
b/ArmPlatformPkg/FileSystem/BootMonFs/BootMonFsUnsupported.c
deleted file mode 100644
index 4ecc4ea008ea..
diff --git a/ArmPlatformPkg/Include/Guid/BootMonFsFileInfo.h 
b/ArmPlatformPkg/Include/Guid/BootMonFsFileInfo.h
deleted file mode 100644
index c4d805c14f0e..
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.c 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.c
deleted file mode 100644
index 67bbb9e86334..
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.h 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.h
deleted file mode 100644
index 2708b53cc172..
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.inf
deleted file mode 100644
index 7d15f6934608..
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.uni 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/ArmShellCmdRunAxf.uni
deleted file mode 100644
index 6b7296079175..
diff --git a/ArmPlatformPkg/Library/ArmShellCmdRunAxf/BootMonFsLoader.c 
b/ArmPlatformPkg/Library/ArmShellCmdRunAxf/BootMonFsLoader.c
deleted file mode 100644

[edk2] [PATCH 18/19] ArmPlatformPkg: remove EblCmdLib implementation

[Ard Biesheuvel]

EBL is being phased out so remove ArmPlatformPkg's copy of EblCmdLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/EblCmdLib/AArch64/EblCmdMmu.c |  33 --
 ArmPlatformPkg/Library/EblCmdLib/Arm/EblCmdMmu.c | 370 --
 ArmPlatformPkg/Library/EblCmdLib/EblCmdFdt.c | 205 
 ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.c | 520 
 ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf   |  63 ---
 5 files changed, 1191 deletions(-)

diff --git a/ArmPlatformPkg/Library/EblCmdLib/AArch64/EblCmdMmu.c 
b/ArmPlatformPkg/Library/EblCmdLib/AArch64/EblCmdMmu.c
deleted file mode 100644
index 169267576bbe..
diff --git a/ArmPlatformPkg/Library/EblCmdLib/Arm/EblCmdMmu.c 
b/ArmPlatformPkg/Library/EblCmdLib/Arm/EblCmdMmu.c
deleted file mode 100644
index fe9d3eae1473..
diff --git a/ArmPlatformPkg/Library/EblCmdLib/EblCmdFdt.c 
b/ArmPlatformPkg/Library/EblCmdLib/EblCmdFdt.c
deleted file mode 100644
index b0f6a72ee22d..
diff --git a/ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.c 
b/ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.c
deleted file mode 100644
index 5bcd750bf9f8..
diff --git a/ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf 
b/ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf
deleted file mode 100644
index f33456abf3c2..
-- 
2.11.0

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

[edk2] [PATCH 16/19] ArmPlatformPkg: remove unused SP804 driver and TimerLib implementation

[Ard Biesheuvel]

None of the platforms we support use these so remove them.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |   7 -
 ArmPlatformPkg/Drivers/SP804TimerDxe/SP804Timer.c  | 395 

 ArmPlatformPkg/Drivers/SP804TimerDxe/SP804TimerDxe.inf |  59 ---
 ArmPlatformPkg/Include/Drivers/SP804Timer.h|  57 ---
 ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.c   | 256 -
 ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf |  44 ---
 6 files changed, 818 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 2d82ead7612a..8df7c8adf9f5 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -81,13 +81,6 @@ [PcdsFixedAtBuild.common]
   # ARM Primecells
   #
 
-  ## SP804 DualTimer
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerFrequencyInMHz|1|UINT32|0x001D
-  
gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicInterruptNum|0|UINT32|0x001E
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPeriodicBase|0|UINT32|0x002A
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerPerformanceBase|0|UINT32|0x002B
-  gArmPlatformTokenSpaceGuid.PcdSP804TimerMetronomeBase|0|UINT32|0x002C
-
   ## SP805 Watchdog
   gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x0|UINT32|0x0023
   
gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|32000|UINT32|0x0021
diff --git a/ArmPlatformPkg/Drivers/SP804TimerDxe/SP804Timer.c 
b/ArmPlatformPkg/Drivers/SP804TimerDxe/SP804Timer.c
deleted file mode 100644
index 7ae25e9bb92a..
diff --git a/ArmPlatformPkg/Drivers/SP804TimerDxe/SP804TimerDxe.inf 
b/ArmPlatformPkg/Drivers/SP804TimerDxe/SP804TimerDxe.inf
deleted file mode 100644
index 386d9649efab..
diff --git a/ArmPlatformPkg/Include/Drivers/SP804Timer.h 
b/ArmPlatformPkg/Include/Drivers/SP804Timer.h
deleted file mode 100644
index 904b13c19325..
diff --git a/ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.c 
b/ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.c
deleted file mode 100644
index 16798e9ba97f..
diff --git a/ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf 
b/ArmPlatformPkg/Library/SP804TimerLib/SP804TimerLib.inf
deleted file mode 100644
index fb5cc189261e..
-- 
2.11.0

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

[edk2] [PATCH 15/19] ArmPlatformPkg: remove unused ArmTrustZone driver

[Ard Biesheuvel]

This driver is no longer used anywhere so remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c   | 113 
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.inf |  33 --
 ArmPlatformPkg/Include/Drivers/ArmTrustzone.h| 105 --
 3 files changed, 251 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
deleted file mode 100644
index 1f002198e552..
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.inf 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.inf
deleted file mode 100644
index 6f90589a5b90..
diff --git a/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h 
b/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
deleted file mode 100644
index 827b5cd568c1..
-- 
2.11.0

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

[edk2] [PATCH 12/19] ArmPlatformPkg: remove unused PL35x driver

[Ard Biesheuvel]

No platform uses this so remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.S   | 60 
 ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.asm | 62 
 ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf  | 29 
 ArmPlatformPkg/Include/Drivers/PL35xSmc.h | 75 
 4 files changed, 226 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.S 
b/ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.S
deleted file mode 100644
index a26a4d43770e..
diff --git a/ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.asm 
b/ArmPlatformPkg/Drivers/PL35xSmc/InitializeSMC.asm
deleted file mode 100644
index 661b0688c85c..
diff --git a/ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf 
b/ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf
deleted file mode 100644
index 2eee5ab5056f..
diff --git a/ArmPlatformPkg/Include/Drivers/PL35xSmc.h 
b/ArmPlatformPkg/Include/Drivers/PL35xSmc.h
deleted file mode 100644
index 750f5088b6de..
-- 
2.11.0

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

[edk2] [PATCH 13/19] ArmPlatformPkg: remove PL34xDmc driver

[Ard Biesheuvel]

Remove PL34xDmc driver which is not used by any platforms

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---

NOTE: this driver is used by the CTA9x4, which is unused itself, so it doesn't
  need to be migrated with the ArmVExpressPkg migration in patch #9

 ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.c   | 227 -
 ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.inf |  29 --
 ArmPlatformPkg/Include/Drivers/PL341Dmc.h| 336 
 3 files changed, 592 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.c 
b/ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.c
deleted file mode 100644
index 08eba6ec6930..
diff --git a/ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.inf 
b/ArmPlatformPkg/Drivers/PL34xDmc/PL341Dmc.inf
deleted file mode 100644
index 0f3d862e14ef..
diff --git a/ArmPlatformPkg/Include/Drivers/PL341Dmc.h 
b/ArmPlatformPkg/Include/Drivers/PL341Dmc.h
deleted file mode 100644
index caba8f445bd8..
-- 
2.11.0

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

[edk2] [PATCH 09/19] ArmPlatformPkg: remove ArmVExpressPkg

[Ard Biesheuvel]

Remove ArmVExpressPkg from EDK2 now that its contents have moved into
edk2-platforms/Platform/ARM where they belong.

Since LcdGraphicsOutputDxe is only used by VExpressPkg, it has been moved
there as well so remove it too.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c   
 |  90 --
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf 
 |  38 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c
 |  38 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf  
 |  37 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressFastBootDxe/ArmVExpressFastBoot.c 
 | 519 
 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressFastBootDxe/ArmVExpressFastBootDxe.inf 
|  51 --
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec   
 |  53 --
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA15-A7/ArmPlatform.h  
 | 154 
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA9x4/ArmPlatform.h
 | 121 ---
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  
 |  79 --
 ArmPlatformPkg/ArmVExpressPkg/Include/VExpressMotherBoard.h
 | 140 
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/ArmVExpressLib.inf 
|  53 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/CTA15-A7.c
 | 195 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/CTA15-A7Helper.S  
 |  81 --
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/CTA15-A7Helper.asm 
|  96 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/CTA15-A7Mem.c 
 | 182 
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/ArmVExpressLib.inf  
 |  57 --
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/ArmVExpressLibSec.inf
|  54 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/CTA9x4.c
 | 198 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/CTA9x4Helper.S  
 |  49 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/CTA9x4Helper.asm
 |  63 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA9x4/CTA9x4Mem.c 
 | 119 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/AArch64/RTSMHelper.S  
 |  61 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/Arm/RTSMHelper.S  
 |  97 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/Arm/RTSMHelper.asm
 | 118 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
 |  62 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLibSec.inf 
 |  59 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
 | 209 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
 | 161 
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
| 273 --
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
   |  35 -
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c
   | 283 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf
 |  37 -
 ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
 | 285 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
   |  45 -
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
  | 370 
 
ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  44 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.c  
 | 111 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ResetSystemLib/ResetSystemLib.inf
 |  35 -
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
 | 133 

[edk2] [PATCH 14/19] ArmPlatformPkg: remove unused PL310 driver

[Ard Biesheuvel]

This driver is not used by any platforms so remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2Cache.c  | 126 

 ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2CacheSec.inf |  31 -
 ArmPlatformPkg/Include/Drivers/PL310L2Cache.h   |  79 
 3 files changed, 236 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2Cache.c 
b/ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2Cache.c
deleted file mode 100644
index 1a6ab33720e5..
diff --git a/ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2CacheSec.inf 
b/ArmPlatformPkg/Drivers/PL310L2Cache/PL310L2CacheSec.inf
deleted file mode 100644
index 78f952a1d0c8..
diff --git a/ArmPlatformPkg/Include/Drivers/PL310L2Cache.h 
b/ArmPlatformPkg/Include/Drivers/PL310L2Cache.h
deleted file mode 100644
index a61099806269..
-- 
2.11.0

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

[edk2] [PATCH 10/19] ArmPlatformPkg: remove ArmPlatformSysConfigLib library class

[Ard Biesheuvel]

The only remaining user of ArmPlatformSysConfigLib has absorbed this
definition into its own edk2-platforms package, so let's remove it from
the shared code.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Include/Library/ArmPlatformSysConfigLib.h   
| 63 ---
 
ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.c
   | 85 
 
ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 | 28 ---
 3 files changed, 176 deletions(-)

diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformSysConfigLib.h 
b/ArmPlatformPkg/Include/Library/ArmPlatformSysConfigLib.h
deleted file mode 100644
index 39a0cc7f734c..
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.c
 
b/ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.c
deleted file mode 100644
index a7199e65d8f6..
diff --git 
a/ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
b/ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
deleted file mode 100644
index f379d7228cd4..
-- 
2.11.0

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

[edk2] [PATCH 11/19] ArmPlatformPkg: remove unused PL301Axi driver

[Ard Biesheuvel]

No platforms use this driver so remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.c   | 108 
 ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.inf |  27 -
 ArmPlatformPkg/Include/Drivers/PL301Axi.h|  21 
 3 files changed, 156 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.c 
b/ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.c
deleted file mode 100644
index 8600721c581f..
diff --git a/ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.inf 
b/ArmPlatformPkg/Drivers/PL301Axi/PL301Axi.inf
deleted file mode 100644
index 108161fc16c4..
diff --git a/ArmPlatformPkg/Include/Drivers/PL301Axi.h 
b/ArmPlatformPkg/Include/Drivers/PL301Axi.h
deleted file mode 100644
index ae941839f08b..
-- 
2.11.0

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

[edk2] [PATCH 07/19] ArmPlatformPkg: remove ArmJunoPkg

[Ard Biesheuvel]

Remove ArmJunoPkg now that it has been moved into edk2-platforms
where it belongs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec |  47 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/AcpiTables.c |  78 ---
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 550 

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf   |  89 

 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h |  54 --
 ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h   | 123 
-
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S  |  58 ---
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S  |  91 

 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c| 193 
---
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf   |  80 ---
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoMem.c | 173 
--
 ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c  |  68 ---
 ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf |  32 --
 13 files changed, 1636 deletions(-)

diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec 
b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec
deleted file mode 100644
index 7af8885ddf2d..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/AcpiTables.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/AcpiTables.c
deleted file mode 100644
index bf0834643411..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
deleted file mode 100644
index 18491c737852..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
deleted file mode 100644
index 0fc8bd88c6ce..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h 
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h
deleted file mode 100644
index 5d2b68fabd12..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h 
b/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
deleted file mode 100644
index f7bfe0a1f937..
diff --git 
a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S 
b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
deleted file mode 100644
index 4bdf08d1a98a..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S 
b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S
deleted file mode 100644
index a7e904eac697..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c 
b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c
deleted file mode 100644
index 4a57ec5517ec..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
deleted file mode 100644
index 77d18f855a83..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoMem.c 
b/ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoMem.c
deleted file mode 100644
index aa8d7d9c3b0d..
diff --git a/ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c 
b/ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c
deleted file mode 100644
index b31b9635b7b7..
diff --git 
a/ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf 
b/ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf
deleted file mode 100644
index 6b13635088cd..
-- 
2.11.0

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

[edk2] [PATCH 08/19] ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib reference

[Ard Biesheuvel]

The PL031 driver implements a VExpress/Juno specific hack to set the
battery backed clock in addition to the PL031. However, none of the
remaining VExpress based hardware we support in EDK2 actuall implements
this feature so we can just remove it, and get rid of the cumbersome
dependency on ArmPlatform.h.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c   | 43 
+++-
 ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf |  1 -
 2 files changed, 6 insertions(+), 38 deletions(-)

diff --git 
a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
index 459dcc0a0519..1334ad446cd9 100644
--- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
+++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,8 +37,6 @@
 
 #include 
 
-#include 
-
 STATIC BOOLEANmPL031Initialized = FALSE;
 STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
 STATIC UINTN  mPL031RtcBase;
@@ -133,6 +130,11 @@ LibGetTime (
   EFI_STATUS  Status = EFI_SUCCESS;
   UINT32  EpochSeconds;
 
+  // Ensure Time is a valid pointer
+  if (Time == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
   // Initialize the hardware if not already done
   if (!mPL031Initialized) {
 Status = InitializePL031 ();
@@ -141,27 +143,7 @@ LibGetTime (
 }
   }
 
-  // Snapshot the time as early in the function call as possible
-  // On some platforms we may have access to a battery backed up hardware 
clock.
-  // If such RTC exists try to use it first.
-  Status = ArmPlatformSysConfigGet (SYS_CFG_RTC, );
-  if (Status == EFI_UNSUPPORTED) {
-// Battery backed up hardware RTC does not exist, revert to PL031
-EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
-Status = EFI_SUCCESS;
-  } else if (EFI_ERROR (Status)) {
-// Battery backed up hardware RTC exists but could not be read due to 
error. Abort.
-return Status;
-  } else {
-// Battery backed up hardware RTC exists and we read the time correctly 
from it.
-// Now sync the PL031 to the new time.
-MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
-  }
-
-  // Ensure Time is a valid pointer
-  if (Time == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
+  EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
 
   // Adjust for the correct time zone
   // The timezone setting also reflects the DST setting of the clock
@@ -235,19 +217,6 @@ LibSetTime (
 EpochSeconds -= SEC_PER_HOUR;
   }
 
-  // On some platforms we may have access to a battery backed up hardware 
clock.
-  //
-  // If such RTC exists then it must be updated first, before the PL031,
-  // to minimise any time drift. This is important because the battery 
backed-up
-  // RTC maintains the master time for the platform across reboots.
-  //
-  // If such RTC does not exist then the following function returns 
UNSUPPORTED.
-  Status = ArmPlatformSysConfigSet (SYS_CFG_RTC, EpochSeconds);
-  if ((EFI_ERROR (Status)) && (Status != EFI_UNSUPPORTED)){
-// Any status message except SUCCESS and UNSUPPORTED indicates a hardware 
failure.
-return Status;
-  }
-
   // Set the PL031
   MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
 
diff --git 
a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf 
b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
index aa06a41d0b2a..a3e4f73e7d05 100644
--- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
+++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
@@ -34,7 +34,6 @@ [LibraryClasses]
   UefiLib
   DebugLib
   PcdLib
-  ArmPlatformSysConfigLib
   DxeServicesTableLib
   TimeBaseLib
   UefiRuntimeLib
-- 
2.11.0

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

[edk2] [PATCH 02/19] ArmPlatformPkg: remove ArmPlatformSecLib definition and implementations

[Ard Biesheuvel]

This library class is not used by any drivers, so remove it in its
entirety.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/ArmVExpressSecLib.inf
  |  55 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.S 
  | 114 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.asm   
  | 126 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c  
  | 176 
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/GicV3.S
  |  70 
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMBoot.S 
  |  64 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMFoundationBoot.S
 |  75 -
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.S
  |  24 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.asm  
  |  27 ---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.S 
  |  50 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.asm   
  |  54 --
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
|  49 --
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/RTSMSec.c  
  | 100 ---
 ArmPlatformPkg/Include/Library/ArmPlatformSecLib.h 
  |  88 --
 ArmPlatformPkg/Library/ArmPlatformSecLibNull/AArch64/ArmPlatformLibNullBoot.S  
  |  61 ---
 ArmPlatformPkg/Library/ArmPlatformSecLibNull/Arm/ArmPlatformLibNullBoot.S  
  |  47 --
 ArmPlatformPkg/Library/ArmPlatformSecLibNull/Arm/ArmPlatformLibNullBoot.asm
  |  49 --
 ArmPlatformPkg/Library/ArmPlatformSecLibNull/ArmPlatformLibNullSec.c   
  |  74 
 ArmPlatformPkg/Library/ArmPlatformSecLibNull/ArmPlatformLibNullSec.inf 
  |  44 -
 19 files changed, 1347 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/ArmVExpressSecLib.inf
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/ArmVExpressSecLib.inf
deleted file mode 100644
index 5705b8bd3f30..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.S 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.S
deleted file mode 100644
index 1579c99ce787..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.asm 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Boot.asm
deleted file mode 100644
index 06ce3776fce9..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
deleted file mode 100644
index 42d731ea98c9..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/GicV3.S 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/GicV3.S
deleted file mode 100644
index 035e0954931e..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMBoot.S
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMBoot.S
deleted file mode 100644
index 6c73cdad3158..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMFoundationBoot.S
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/AArch64/RTSMFoundationBoot.S
deleted file mode 100644
index a07ed97f5f1f..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.S 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.S
deleted file mode 100644
index 4a82cdbd484d..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.asm 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/GicV3.asm
deleted file mode 100644
index 4578c1c31d29..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.S 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.S
deleted file mode 100644
index 371adcb8f964..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.asm 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/Arm/RTSMBoot.asm
deleted file mode 100644
index 2d0b94679f1a..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
deleted file mode 100644
index 

[edk2] [PATCH 05/19] ArmPlatformPkg: remove ArmGetCpuCountPerCluster () from ArmPlatformLib

[Ard Biesheuvel]

The only user of ArmPlatformLib's ArmGetCpuCountPerCluster () is itself
an ArmPlatformLib implementation, i.e., ArmVExpressLibRTSM.

Given that we'd prefer to get rid of ArmPlatformLib entirely, let's
remove ArmGetCpuCountPerCluster () from the API as a first step.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c | 13 
+
 ArmPlatformPkg/Include/Library/ArmPlatformLib.h | 13 
-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
index d8d1c9ac26dd..11dd7ff1bfb0 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
@@ -21,6 +21,19 @@
 
 #include 
 
+/**
+  Return the core per cluster. The method may differ per core type
+
+  This function might be called from assembler before any stack is set.
+
+  @return   Return the core count per cluster
+
+**/
+UINTN
+ArmGetCpuCountPerCluster (
+  VOID
+  );
+
 ARM_CORE_INFO mVersatileExpressMpCoreInfoTable[] = {
   {
 // Cluster 0, Core 0
diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h 
b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
index fe3bc4bb8e6c..77561a3d05b3 100644
--- a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
+++ b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
@@ -41,19 +41,6 @@ typedef struct {
 } ARM_SYSTEM_MEMORY_REGION_DESCRIPTOR;
 
 /**
-  Return the core per cluster. The method may differ per core type
-
-  This function might be called from assembler before any stack is set.
-
-  @return   Return the core count per cluster
-
-**/
-UINTN
-ArmGetCpuCountPerCluster (
-  VOID
-  );
-
-/**
   Return the core position from the value of its MpId register
 
   This function returns the core position from the position 0 in the processor.
-- 
2.11.0

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

[edk2] [PATCH 06/19] ArmPlatformPkg: remove NorFlashArmVExpressLib

[Ard Biesheuvel]

Remove NorFlashArmVExpressLib now that it has been moved into edk2-platforms
where it belongs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 
ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpress.c
  | 84 
 
ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
 | 32 
 2 files changed, 116 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpress.c
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpress.c
deleted file mode 100644
index a136bff4a1d6..
diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
 
b/ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
deleted file mode 100644
index 0798cc30d8fc..
-- 
2.11.0

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

[edk2] [PATCH 04/19] ArmPlatformPkg: remove ArmTrustedMonitorLib definition and implementation

[Ard Biesheuvel]

Remove ArmTrustedMonitorLib and its only [NULL] implementation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Include/Library/ArmTrustedMonitorLib.h  
| 24 
 
ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/AArch64/ArmTrustedMonitorLibNull.c
 | 24 
 ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/ArmTrustedMonitorLibNull.c 
| 38 --
 ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.S 
| 41 
 ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.asm   
| 40 ---
 ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf   
| 40 ---
 6 files changed, 207 deletions(-)

diff --git a/ArmPlatformPkg/Include/Library/ArmTrustedMonitorLib.h 
b/ArmPlatformPkg/Include/Library/ArmTrustedMonitorLib.h
deleted file mode 100644
index 5368697c5cdd..
diff --git 
a/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/AArch64/ArmTrustedMonitorLibNull.c
 
b/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/AArch64/ArmTrustedMonitorLibNull.c
deleted file mode 100644
index 72c62d7f10a1..
diff --git 
a/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/ArmTrustedMonitorLibNull.c
 
b/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/ArmTrustedMonitorLibNull.c
deleted file mode 100644
index 1f950d78f1e0..
diff --git a/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.S 
b/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.S
deleted file mode 100644
index 3e75bee5058b..
diff --git 
a/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.asm 
b/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/Arm/MonitorTable.asm
deleted file mode 100644
index f4f515d05c79..
diff --git 
a/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf 
b/ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
deleted file mode 100644
index 505d2ec0c0ba..
-- 
2.11.0

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

[edk2] [PATCH 03/19] ArmPlatformPkg: remove unused DebugSecExtraActionLib library

[Ard Biesheuvel]

This implementation of ArmPlatformSecExtraActionLib is no longer used
anywhere so remove it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.c   | 121 

 ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf |  54 
-
 2 files changed, 175 deletions(-)

diff --git 
a/ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.c 
b/ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.c
deleted file mode 100644
index e617bdaa9c02..
diff --git 
a/ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf 
b/ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
deleted file mode 100644
index b058f367a52d..
-- 
2.11.0

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

[edk2] [PATCH 00/19] ArmPlatformPkg: remove unused or migrated modules

[Ard Biesheuvel]

Remove everything from ArmPlatformPkg that is either unused, or so highly
specific to development platforms manufactured by ARM Ltd. that they really
don't belong in the main branch.

Note that the migration involves patches against edk2-platforms that add
some of this code back under Platform/ARM. Most of it (but not all of it)
has been posted as a separate series already.

Ard Biesheuvel (19):
  ArmPkg: remove unused ArmGicSecLib library implementation
  ArmPlatformPkg: remove ArmPlatformSecLib definition and
implementations
  ArmPlatformPkg: remove unused DebugSecExtraActionLib library
  ArmPlatformPkg: remove ArmTrustedMonitorLib definition and
implementation
  ArmPlatformPkg: remove ArmGetCpuCountPerCluster () from ArmPlatformLib
  ArmPlatformPkg: remove NorFlashArmVExpressLib
  ArmPlatformPkg: remove ArmJunoPkg
  ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
reference
  ArmPlatformPkg: remove ArmVExpressPkg
  ArmPlatformPkg: remove ArmPlatformSysConfigLib library class
  ArmPlatformPkg: remove unused PL301Axi driver
  ArmPlatformPkg: remove unused PL35x driver
  ArmPlatformPkg: remove PL34xDmc driver
  ArmPlatformPkg: remove unused PL310 driver
  ArmPlatformPkg: remove unused ArmTrustZone driver
  ArmPlatformPkg: remove unused SP804 driver and TimerLib implementation
  ArmPlatformPkg: remove unused L2X0CacheLibNull library
  ArmPlatformPkg: remove EblCmdLib implementation
  ArmPlatformPkg: remove BootMonFs and ArmShellCmdRunAxf

 ArmPkg/ArmPkg.dec  
 |4 +-
 ArmPkg/ArmPkg.dsc  
 |1 -
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
 |   52 -
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2SecLib.c   
 |  100 --
 ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec  
 |   47 -
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/AcpiTables.c  
 |   78 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c  
 |  550 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf
 |   89 --
 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h  
 |   54 -
 ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
 |  123 ---
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S   
 |   58 --
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S   
 |   91 --
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJuno.c 
 |  193 
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
 |   80 --
 ArmPlatformPkg/ArmJunoPkg/Library/ArmJunoLib/ArmJunoMem.c  
 |  173 
 ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c   
 |   68 --
 ArmPlatformPkg/ArmJunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf  
 |   32 -
 ArmPlatformPkg/ArmPlatformPkg.dec  
 |7 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.c   
 |   90 --
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf 
 |   38 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c
 |   38 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.inf  
 |   37 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressFastBootDxe/ArmVExpressFastBoot.c 
 |  519 --
 
ArmPlatformPkg/ArmVExpressPkg/ArmVExpressFastBootDxe/ArmVExpressFastBootDxe.inf 
|   51 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec   
 |   53 -
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA15-A7/ArmPlatform.h  
 |  154 ---
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/CTA9x4/ArmPlatform.h
 |  121 ---
 ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h  
 |   79 --
 ArmPlatformPkg/ArmVExpressPkg/Include/VExpressMotherBoard.h
 |  140 ---
 
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibCTA15-A7/ArmVExpressLib.inf 
|   53 -
 

[edk2] [PATCH 01/19] ArmPkg: remove unused ArmGicSecLib library implementation

[Ard Biesheuvel]

This module is not used anywhere under edk2 or edk2-platforms, so let's
remove it. This removes the only dependency on ArmPlatformLib from ArmPkg.
While at it, remove a mention of ArmPlatformPkg from a comment in the
.dec file as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/ArmPkg.dec|   4 +-
 ArmPkg/ArmPkg.dsc|   1 -
 ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf   |  52 --
 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2SecLib.c | 100 
 4 files changed, 2 insertions(+), 155 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index f99054a7de3e..f3fb77c16f75 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -224,8 +224,8 @@ [PcdsFixedAtBuild.AARCH64]
 [PcdsFixedAtBuild.common, PcdsDynamic.common, PcdsPatchableInModule.common]
 
   # System Memory (DRAM): These PCDs define the region of in-built system 
memory
-  # Some platforms can get DRAM extensions, these additional regions will be 
declared
-  # to UEFI by ArmPlatformLib
+  # Some platforms can get DRAM extensions, these additional regions may be
+  # declared to UEFI using separate resource descriptor HOBs
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029
   gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A
 
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index cf9a5c12108b..382e99868453 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -123,7 +123,6 @@ [Components.common]
   ArmPkg/Drivers/CpuPei/CpuPei.inf
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPkg/Drivers/ArmGic/ArmGicLib.inf
-  ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
   ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
 
diff --git a/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf 
b/ArmPkg/Drivers/ArmGic/ArmGicSecLib.inf
deleted file mode 100644
index fc2e1bc01efe..
diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2SecLib.c 
b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2SecLib.c
deleted file mode 100644
index ac1e0e49450c..
-- 
2.11.0

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

Re: [edk2] [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add UsbControlTransfer() error check

[Kinney, Michael D]

Star,

I have read that section, and I do not see anything
that says the DataLength parameter can not be read.

Mike

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, November 14, 2017 8:23 PM
> To: Kinney, Michael D ;
> edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star
> 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Mike,
> 
> UEFI spec, EFI_USB_IO_PROTOCOL.UsbControlTransfer(), in
> the description.
> 
> Thanks,
> Star
> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, November 15, 2017 12:00 PM
> To: Zeng, Star ; edk2-
> de...@lists.01.org; Kinney, Michael D
> 
> Cc: Dong, Eric 
> Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> UsbControlTransfer() error check
> 
> Star,
> 
> I am curious.  Which spec statement are you referring
> to?
> 
> Mike
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Tuesday, November 14, 2017 6:59 PM
> > To: Kinney, Michael D ;
> > edk2-devel@lists.01.org
> > Cc: Dong, Eric ; Zeng, Star
> 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Mike,
> >
> > I do not insist on the check that the Direction is
> not EfiUsbNoData,
> > and I know the functionality should have no
> improvement with the
> > check.
> > So, you can have my Reviewed-by: Star Zeng
> .
> >
> > I raised the question just for consideration from
> literally, as
> > according to the spec, the code could not touch
> DataLength at all when
> > Direction is EfiUsbNoData.
> >
> > You can decide to have / have not the check when
> pushing. :)
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Wednesday, November 15, 2017 10:46 AM
> > To: Zeng, Star ; edk2-
> de...@lists.01.org;
> > Kinney, Michael D 
> > Cc: Dong, Eric 
> > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> Add
> > UsbControlTransfer() error check
> >
> > Star,
> >
> > For that case both DataLength and RequestedDataLength
> will be 0 and
> > the new path will not be taken.
> >
> > Are you concerned that the USB HC Protocol could
> return a non zero
> > DataLength for the EfiUsbNoData case?  Even if it
> does, the new path
> > can never be taken because 0 is less than all UINTN
> values.
> >
> > Mike
> >
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Tuesday, November 14, 2017 6:40 PM
> > > To: Kinney, Michael D ;
> > > edk2-devel@lists.01.org
> > > Cc: Dong, Eric ; Zeng, Star
> > 
> > > Subject: RE: [Patch V2 1/2] MdeModulePkg/UsbBusDxe:
> > Add
> > > UsbControlTransfer() error check
> > >
> > > Mike,
> > >
> > > Do you think it is better or not to also check the
> > Direction is not
> > > EfiUsbNoData?
> > >
> > > UEFI spec,
> EFI_USB_IO_PROTOCOL.UsbControlTransfer():
> > > If the Direction parameter is EfiUsbNoData, Data is
> > NULL, and
> > > DataLength is 0, then no data phase exists for the
> > control transfer.
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Wednesday, November 15, 2017 9:03 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star ; Dong, Eric
> > 
> > > Subject: [Patch V2 1/2] MdeModulePkg/UsbBusDxe: Add
> > > UsbControlTransfer() error check
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=767
> > >
> > > The USB I/O Protocol function ControlTransfer() has
> a
> > DataLength
> > > parameter that specifies the size of the Data
> buffer.
> > The UsbBusDxe
> > > module implements the USB I/O Protocol using the
> > services of the USB2
> > > Host Controller Protocol.  The DataLength parameter
> > in the
> > > USB2 Host Controller Protocol ControlTransfer()
> > service is an IN OUT
> > > parameter so the number of bytes actually
> transferred
> > is returned.
> > > Since the USB I/O Protocol
> > > ControlTransfer() service can not return the number
> > of bytes actually
> > > transferred, the only option if the number of bytes
> > actually
> > > transferred is less than the number of bytes
> > requested is to return
> > > EFI_DEVICE_ERROR.
> > >
> > > The change fixes an issue with a USB mass storage
> > device that responds
> > > with 0 bytes to the Get MAX LUN command.
> > >
> > > Cc: Star Zeng 
> > > Cc: Eric Dong 
> > > Contributed-under: TianoCore Contribution Agreement
> > 1.1
> > > Signed-off-by: Michael D Kinney
> > > 
> > > ---
> > >  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c | 8
> +++-
> > >  1 file changed, 7 insertions(+), 1 

Re: [edk2] [Patch] BaseTools: Fix the bug to collect source files per build rule family

[Laszlo Ersek]

Hello Yonghong,

On 11/14/17 06:52, Yonghong Zhu wrote:
> when collect source files list we should also consider build rule
> family.

what bug does this patch fix? I guess the bug is that something is
missed / not done, because changes to the build rules are not noticed?
Can you please elaborate in the commit message?

Thanks!
Laszlo

> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index b3e7089..008ad8e 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -3265,17 +3265,17 @@ class ModuleAutoGen(AutoGen):
>  # match tool chain
>  if F.TagName not in ("", "*", self.ToolChain):
>  EdkLogger.debug(EdkLogger.DEBUG_9, "The toolchain [%s] 
> for processing file [%s] is found, "
>  "but [%s] is needed" % (F.TagName, 
> str(F), self.ToolChain))
>  continue
> -# match tool chain family
> -if F.ToolChainFamily not in ("", "*", self.ToolChainFamily):
> +# match tool chain family or build rule family
> +if F.ToolChainFamily not in ("", "*", self.ToolChainFamily, 
> self.BuildRuleFamily):
>  EdkLogger.debug(
>  EdkLogger.DEBUG_0,
>  "The file [%s] must be built by tools of 
> [%s], " \
> -"but current toolchain family is [%s]" \
> -% (str(F), F.ToolChainFamily, 
> self.ToolChainFamily))
> +"but current toolchain family is [%s], 
> buildrule family is [%s]" \
> +% (str(F), F.ToolChainFamily, 
> self.ToolChainFamily, self.BuildRuleFamily))
>  continue
>  
>  # add the file path into search path list for file including
>  if F.Dir not in self.IncludePathList and self.AutoGenVersion 
> >= 0x00010005:
>  self.IncludePathList.insert(0, F.Dir)
> 

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

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

[Ard Biesheuvel]

On 15 November 2017 at 15:48, Laszlo Ersek  wrote:
> Hi Jian,
>
> On 11/15/17 10:27, Wang, Jian J wrote:
>> I tried this workaround and there're no failure in booting Fedora 26 and 
>> Windows
>> server 2016 now. If no objection, I'll merge it into new version of this 
>> patch.
>
> I'm not too familiar with the Linux kernel's EFI pieces myself; that's
> why I added Ard and Matt earlier to the thread (when I responded with
> the regression report) -- Ard and Matt maintain EFI in the Linux kernel.
>
> So, if you think there's a bug in Linux (i.e., a mis-interpretation of
> the UEFI spec), can you guys please discuss that together? Below you wrote:
>
> - "I think it must be that the kernel will mark the memory block to be
>RO/XP/RP memory according to its capabilities but not its current
>attributes"
>

The UEFI spec does not distinguish between capabilities and
attributes, so how on earth should the OS be able to make this
distinction?

For instance, the UEFI spec defines EFI_MEMORY_RO as

"""
Physical memory protection attribute: The memory region
supports making this memory range read-only by system
hardware.
"""

which is essentially a capability not an attribute. However,
EFI_MEMORY_RO/XP are also used to convey information about the nature
of the *contents* of the memory region, i.e., is it .text, .rodata or
.data/.bss

So given that the OS only has the UEFI memory map to go on, how
exactly should it figure out what these attributes are meant to imply?

> - "there's real gap between UEFI and OS on how to interpret the memory
>capabilities"
>

Yes. There is also a gap between how GCD and the UEFI memory map
interpret these attributes, which is why nobody bothers to set the
protection capabilities for GCD: it gets copied into the UEFI memory
map, and nobody has a clue how the OS should treat it.

When the [short lived]
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA
feature was introduced, it was essentially decided that RO and XP may
be used to annotate the nature of the contents of memory regions,
where code was mapped RO and data mapped XP.

> Why is it wrong for the OS kernel, according to the UEFI spec, to change
> the attributes / mappings of a memory area, as long as it stays
> compliant with the advertised capabilities? How is an OS expected to
> work, upon seeing those new "paging capabilities from UEFI memory map"
> (in Star's words)?
>
> Apparently, it's not just Linux that's confused; see the Win2016 crash
> too. Is the UEFI spec detailed enough on those capabilities? (Recently I
> tried to review the paging capabilities myself in the spec, and I ended
> up totally confused...)
>

I think it is simply impossible at this point to interpret those flags
as attributes, i.e., RO means code that may be mapped read-only, and
XP means data that may be mapped non-executable. Anything beyond that
opens a can of worms that is bound to break stuff all over the place.

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

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

[Laszlo Ersek]

Hi Jian,

On 11/15/17 10:27, Wang, Jian J wrote:
> I tried this workaround and there're no failure in booting Fedora 26 and 
> Windows
> server 2016 now. If no objection, I'll merge it into new version of this 
> patch.

I'm not too familiar with the Linux kernel's EFI pieces myself; that's
why I added Ard and Matt earlier to the thread (when I responded with
the regression report) -- Ard and Matt maintain EFI in the Linux kernel.

So, if you think there's a bug in Linux (i.e., a mis-interpretation of
the UEFI spec), can you guys please discuss that together? Below you wrote:

- "I think it must be that the kernel will mark the memory block to be
   RO/XP/RP memory according to its capabilities but not its current
   attributes"

- "there's real gap between UEFI and OS on how to interpret the memory
   capabilities"

Why is it wrong for the OS kernel, according to the UEFI spec, to change
the attributes / mappings of a memory area, as long as it stays
compliant with the advertised capabilities? How is an OS expected to
work, upon seeing those new "paging capabilities from UEFI memory map"
(in Star's words)?

Apparently, it's not just Linux that's confused; see the Win2016 crash
too. Is the UEFI spec detailed enough on those capabilities? (Recently I
tried to review the paging capabilities myself in the spec, and I ended
up totally confused...)


Anyway, whatever the answer, this firmware update would regress shipped
systems, so if there's a way to limit the feature for compatibility
purposes, that would be great.

Thanks,
Laszlo

>> -Original Message-
>> From: Wang, Jian J
>> Sent: Wednesday, November 15, 2017 3:37 PM
>> To: Zeng, Star ; Laszlo Ersek 
>> Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
>> Jiewen ; Dong, Eric ; Ard
>> Biesheuvel 
>> Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
>> memory map
>>
>> Since OS never had chance to use the those capabilities before, I think it's
>> feasible.
>> But it's just a workaround not solution because there's real gap between UEFI
>> and
>> OS on how to interpret the memory capabilities.
>>
>>> -Original Message-
>>> From: Zeng, Star
>>> Sent: Wednesday, November 15, 2017 2:53 PM
>>> To: Wang, Jian J ; Laszlo Ersek 
>>> Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
>>> Jiewen ; Dong, Eric ; Ard
>>> Biesheuvel ; Zeng, Star 
>>> Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE
>> in
>>> memory map
>>>
>>> How about the code to filter out paging capabilities from UEFI memory map in
>>> Page.c CoreGetMemoryMap(), then with maximum compatibility, the UEFI
>>> memory map could be same with before
>>> 14dde9e903bb9a719ebb8f3381da72b19509bc36 [MdeModulePkg/Core: Fix
>> out-
>>> of-sync issue in GCD].
>>>
>>> Thanks,
>>> Star
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Wang,
>>> Jian J
>>> Sent: Tuesday, November 14, 2017 10:36 PM
>>> To: Laszlo Ersek 
>>> Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
>>> Jiewen ; Dong, Eric ; Ard
>>> Biesheuvel 
>>> Subject: Re: [edk2] [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of
>>> RT_CODE in memory map
>>>
>>> Hi Laszlo,
>>>
>>> I did some investigation works on this issue. I think I found the root 
>>> cause and
>>> tend to believe this is a Fedora kernel issue. Here're proves:
>>>
>>> memmap output patterns in which Fedora 26 failed to boot:
>>> 1) BS_DataAE20-AE20EFFF 000F
>>> 0002600F
>>> RT_DataAE20F000-AE38EFFF 0180
>>> 8002600F
>>> RT_CodeAE38F000-AE48EFFF 0100
>>> 8002600F
>>> Reserved   AE48F000-AE58EFFF 0100
>>> 0002600F
>>>
>>> 2) BS_DataAE20-AE20EFFF 000F
>>> 000F
>>> RT_DataAE20F000-AE38EFFF 0180
>>> 800F
>>> RT_CodeAE38F000-AE467FFF 00D9
>>> 800F
>>> RT_CodeAE468000-AE469FFF 0002
>>> 8002600F
>>> RT_CodeAE46A000-AE46EFFF 0005
>>> 800F
>>> RT_CodeAE46F000-AE470FFF 0002
>>> 8002600F
>>> RT_CodeAE471000-AE475FFF 0005
>>> 800F
>>> RT_CodeAE476000-AE479FFF 0004
>>> 8002600F
>>> RT_CodeAE47A000-AE47 

[edk2] 答复: 答复: 答复: [RFC 0/1] Stack trace support in X64 exception handling

[Fan Jeff]

Paulo,



I have no strong opinion on IA32 support  in v2 patch or in separate patch.



I think UefiCpuPkg owner/reviewer may provide their own suggestions on this 
point.



Thanks!

Jeff






From: Paulo Alcantara 
Sent: Wednesday, November 15, 2017 10:41:00 PM
To: Fan Jeff; edk2-devel@lists.01.org
Cc: Rick Bramley; Laszlo Ersek; Andrew Fish; Eric Dong
Subject: Re: 答复: 答复: [edk2] [RFC 0/1] Stack trace support in X64 exception 
handling

Hi Fan,

On 15/11/2017 11:21, Fan Jeff wrote:
> Paulo,
>
> I will try to validate my code firstly and try to integrate into your
> patch.

OK. Thank you very much for the effort!

>
> Before my part ready, it’s also welcome if you or others provide yours
> own solution on X64 MSFT toolchain.
Yes - that would be great. If I get this working on IA32 with GCC
toolchain shortly, then I'll try to come up with a solution for MSVC.

> In my mind, IA32 arch should use the same solution with yours, have you
> tested your solution on IA32 arch with GCC toolchain?

In theory, yes. :-) I haven't tested it yet, but I'll starting working
it on now.

BTW, do you think it's appropriate to just let you know that I pushed
out another commit with IA32 support, or do you think it's better to
send a v2 with it?

Besides we shouldn't forget the suggestions from Andrew and Brian to
validate the RIP and RSP values, as well as to have a kind of PCD to
limit the number of stack frames printed out -- which I think that are
really important even if unlikely.

Thanks!
Paulo

>
> Thanks!
>
> Jeff
>
> 
> *From:* Paulo Alcantara 
> *Sent:* Tuesday, November 14, 2017 11:37:35 PM
> *To:* Fan Jeff; edk2-devel@lists.01.org
> *Cc:* Rick Bramley; Laszlo Ersek; Andrew Fish; Eric Dong
> *Subject:* Re: 答复: [edk2] [RFC 0/1] Stack trace support in X64
> exception handling
> Hi Fan,
>
> On 14/11/2017 12:03, Fan Jeff wrote:
>> Paul,
>>
>> I like this feature very much. Actually, I did some POC one year ago but
>> I did finalize it.
>>
>> In my POC, I could use EBP to tack the stack frame on IAS32 arch.
>>
>> But for x64, I tried to use �Ckeepexceptiontable flag to explain stack
>> frame from the debug section of image.
>>
>> I may workson MSFT toolchain, but it did now work well for GCC toolchain.
>>
>> I think Eric could help to verify MSFT for your patch. If it works well,
>> that’s will be great!
>>
>> Say again, I like this feature!!!:-)
>
> Cool! Your help would be really appreciable! If we get this working for
> X64 in both toolchains, that should be easy to port it to IA-32 as well.
>
> Thank you very much for willing to help on that.
>
> Paulo
>
>>
>> Thanks!
>>
>> Jeff
>>
>> *发件人: *Paulo Alcantara 
>> *发送时间: *2017年11月14日21:23
>> *收件人: *edk2-devel@lists.01.org 
>> *抄送: *Rick Bramley ; Laszlo Ersek
>> ; Andrew Fish ; Eric
>> Dong 
>> *主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling
>>
>> Hi,
>>
>> On 14/11/2017 10:47, Paulo Alcantara wrote:
>>> Hi,
>>>
>>> This series adds stack trace support during a X64 CPU exception.
>>>
>>> Informations like back trace, stack contents and image module names
>>> (that were part of the call stack) will be dumped out.
>>>
>>> We already have such support in ARM/AArch64 (IIRC) exception handling
>>> (thanks to Ard), and then I thought we'd also deserve it in X64 and
>>> IA-32 platforms.
>>>
>>> What do you think guys?
>>>
>>> BTW, I've tested this only with OVMF (X64 only), using:
>>>- gcc-6.3.0, GCC5, NOOPT
>>>
>>> Any other tests  would be really appreciable.
>>
>> I've attached a file to show you how the trace would look like.
>>
>> Thanks!
>> Paulo
>>
>>>
>>> Thanks!
>>> Paulo
>>>
>>> Repo:   https://github.com/pcacjr/edk2.git
>>> Branch: stacktrace_x64
>>>
>>> Cc: Rick Bramley 
>>> Cc: Andrew Fish 
>>> Cc: Eric Dong 
>>> Cc: Laszlo Ersek 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Paulo Alcantara 
>>> ---
>>>
>>> Paulo Alcantara (1):
>>>UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support
>>>
>>>   UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 
>>> 344 +++-
>>>   1 file changed, 342 insertions(+), 2 deletions(-)
>>>
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] 答复: 答复: [RFC 0/1] Stack trace support in X64 exception handling

[Paulo Alcantara]

Hi Fan,

On 15/11/2017 11:21, Fan Jeff wrote:

Paulo,

I will try to validate my code firstly and try to integrate into your 
patch.


OK. Thank you very much for the effort!



Before my part ready, it’s also welcome if you or others provide yours 
own solution on X64 MSFT toolchain.
Yes - that would be great. If I get this working on IA32 with GCC 
toolchain shortly, then I'll try to come up with a solution for MSVC.


In my mind, IA32 arch should use the same solution with yours, have you 
tested your solution on IA32 arch with GCC toolchain?


In theory, yes. :-) I haven't tested it yet, but I'll starting working 
it on now.


BTW, do you think it's appropriate to just let you know that I pushed 
out another commit with IA32 support, or do you think it's better to 
send a v2 with it?


Besides we shouldn't forget the suggestions from Andrew and Brian to 
validate the RIP and RSP values, as well as to have a kind of PCD to 
limit the number of stack frames printed out -- which I think that are 
really important even if unlikely.


Thanks!
Paulo



Thanks!

Jeff


*From:* Paulo Alcantara 
*Sent:* Tuesday, November 14, 2017 11:37:35 PM
*To:* Fan Jeff; edk2-devel@lists.01.org
*Cc:* Rick Bramley; Laszlo Ersek; Andrew Fish; Eric Dong
*Subject:* Re: 答复: [edk2] [RFC 0/1] Stack trace support in X64 
exception handling

Hi Fan,

On 14/11/2017 12:03, Fan Jeff wrote:

Paul,

I like this feature very much. Actually, I did some POC one year ago but 
I did finalize it.


In my POC, I could use EBP to tack the stack frame on IAS32 arch.

But for x64, I tried to use –keepexceptiontable flag to explain stack 
frame from the debug section of image.


I may workson MSFT toolchain, but it did now work well for GCC toolchain.

I think Eric could help to verify MSFT for your patch. If it works well, 
that’s will be great!


Say again, I like this feature!!!:-)


Cool! Your help would be really appreciable! If we get this working for
X64 in both toolchains, that should be easy to port it to IA-32 as well.

Thank you very much for willing to help on that.

Paulo



Thanks!

Jeff

*发件人: *Paulo Alcantara 
*发送时间: *2017年11月14日21:23
*收件人: *edk2-devel@lists.01.org 
*抄送: *Rick Bramley ; Laszlo Ersek
; Andrew Fish ; Eric
Dong 
*主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

Hi,

On 14/11/2017 10:47, Paulo Alcantara wrote:

Hi,

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

Informations like back trace, stack contents and image module names
(that were part of the call stack) will be dumped out.

We already have such support in ARM/AArch64 (IIRC) exception handling
(thanks to Ard), and then I thought we'd also deserve it in X64 and
IA-32 platforms.

What do you think guys?

BTW, I've tested this only with OVMF (X64 only), using:
    - gcc-6.3.0, GCC5, NOOPT

Any other tests  would be really appreciable.


I've attached a file to show you how the trace would look like.

Thanks!
Paulo



Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: stacktrace_x64

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

Paulo Alcantara (1):
    UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

   UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 344 
+++-
   1 file changed, 342 insertions(+), 2 deletions(-)




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

[edk2] [PATCH 3/6] Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference

[Ard Biesheuvel]

No FVP driver uses this library so remove the resolution.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 51f0529db251..fc628ad08c9e 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -62,7 +62,6 @@ [LibraryClasses.common]
   
DtPlatformDtbLoaderLib|Platform/ARM/VExpressPkg/Library/ArmVExpressDtPlatformDtbLoaderLib/ArmVExpressDtPlatformDtbLoaderLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibRTSM/ArmVExpressSecLib.inf
   
ArmPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLibSec.inf
 
 [LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, 
LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
-- 
2.11.0

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

[edk2] [PATCH 2/6] Platform: remove bogus ArmTrustedMonitorLib references

[Ard Biesheuvel]

Remove copy-pasted ArmTrustedMonitorLib library class resolutions
that none of the platforms actually need.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 3 ---
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 2 --
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 2 --
 Silicon/Hisilicon/Hisilicon.dsc.inc | 3 ---
 5 files changed, 12 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index ec350c999f19..7258daa76094 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -175,8 +175,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 7b405a949ebd..3db269086d5b 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -169,9 +169,6 @@ [LibraryClasses.common.SEC]
   PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
 !endif
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
-
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEI_CORE]
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 7c4adb3a53bf..30b080495639 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -154,8 +154,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 73c0c7531f26..5cbf3628fb89 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -160,8 +160,6 @@ [LibraryClasses.common.SEC]
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
 
 [LibraryClasses.common.PEIM, LibraryClasses.common.SEC]
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index c1c947f38cba..fbecb6497469 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -126,9 +126,6 @@ [LibraryClasses.common]
 [LibraryClasses.common.SEC]
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
-  # Trustzone Support
-  
ArmTrustedMonitorLib|ArmPlatformPkg/Library/ArmTrustedMonitorLibNull/ArmTrustedMonitorLibNull.inf
-
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
-- 
2.11.0

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

[edk2] [PATCH 5/6] Platform/ARM/Juno: import ArmJunoPkg from EDK2

[Ard Biesheuvel]

Move ArmJunoPkg into edk2-platforms, so it can be removed from the main
EDK2 tree.

This allows use to remove the dodgy -I arguments to GCC to build shared
modules with a different copy of ArmPlatform.h, which was making it very
difficult to properly split the various modules into their own packages.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf |   
3 +-
 Platform/ARM/JunoPkg/ArmJuno.dec   |  
48 ++
 Platform/ARM/JunoPkg/ArmJuno.dsc   |   
8 +-
 Platform/ARM/JunoPkg/ArmJuno.fdf   |   
2 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/AcpiTables.c   |  
78 +++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c   | 
550 
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf |  
88 
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h   |  
54 ++
 Platform/ARM/JunoPkg/Include/ArmPlatform.h | 
178 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S|  
58 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S|  
91 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJuno.c  | 
193 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf |  
80 +++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c   | 
173 ++
 Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf |   
2 +-
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c|  
68 +++
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf   |  
33 ++
 Platform/ARM/JunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |   
2 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc  |  
12 +
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc   |   
3 +
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   |  
10 -
 21 files changed, 1714 insertions(+), 20 deletions(-)

diff --git a/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf 
b/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
index 741ea191be36..539974ff2416 100644
--- a/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
+++ b/Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf
@@ -33,11 +33,10 @@ [Sources]
 [Packages]
   ArmPkg/ArmPkg.dec
   ArmPlatformPkg/ArmPlatformPkg.dec
-  ArmPlatformPkg/ArmVExpressPkg/ArmVExpressPkg.dec
-  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dec
   EmbeddedPkg/EmbeddedPkg.dec
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  Platform/ARM/JunoPkg/ArmJuno.dec
 
 [FixedPcd]
   gArmPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec b/Platform/ARM/JunoPkg/ArmJuno.dec
new file mode 100644
index ..60cef6d23a2d
--- /dev/null
+++ b/Platform/ARM/JunoPkg/ArmJuno.dec
@@ -0,0 +1,48 @@
+#
+#  Copyright (c) 2013-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.
+#
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = ArmJunoPkg
+  PACKAGE_GUID   = a1147a20-3144-4f8d-8295-b48311c8e4a4
+  PACKAGE_VERSION= 0.1
+
+
+#
+# Include Section - list of Include Paths that are provided by this package.
+#   Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+
+[Includes.common]
+  Include# Root include for the package
+
+[Guids.common]
+  gArmJunoTokenSpaceGuid=  { 0xa1147a20, 0x3144, 0x4f8d, { 0x82, 0x95, 
0xb4, 0x83, 0x11, 0xc8, 0xe4, 0xa4 } }
+
+[PcdsFeatureFlag.common]
+  gArmJunoTokenSpaceGuid.PcdPciMaxPayloadFixup|FALSE|BOOLEAN|0x0013
+
+[PcdsFixedAtBuild.common]
+  gArmJunoTokenSpaceGuid.PcdPcieControlBaseAddress|0x7FF2|UINT64|0x000B
+  
gArmJunoTokenSpaceGuid.PcdPcieRootPortBaseAddress|0x7FF3|UINT64|0x000C
+  
gArmJunoTokenSpaceGuid.PcdPciConfigurationSpaceBaseAddress|0x4000|UINT64|0x0011
+  

[edk2] [PATCH 4/6] Platform/Hisilicon: remove bogus VExpress dependencies

[Ard Biesheuvel]

Remove false copy-pasted dependencies on various VExpress support
libraries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Hisilicon/D02/Pv660D02.dsc | 3 ---
 Platform/Hisilicon/D03/D03.dsc  | 5 -
 Platform/Hisilicon/D05/D05.dsc  | 4 
 Platform/Hisilicon/HiKey/HiKey.dsc  | 1 -
 Silicon/Hisilicon/Hisilicon.dsc.inc | 5 -
 5 files changed, 18 deletions(-)

diff --git a/Platform/Hisilicon/D02/Pv660D02.dsc 
b/Platform/Hisilicon/D02/Pv660D02.dsc
index 1fd2b98f1552..ba3047882611 100644
--- a/Platform/Hisilicon/D02/Pv660D02.dsc
+++ b/Platform/Hisilicon/D02/Pv660D02.dsc
@@ -36,9 +36,6 @@ [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
 
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index f2a120e31b16..491862a3b27e 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -36,11 +36,6 @@ [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
 
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-
-
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index 64101a7d0160..de2d3579a494 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -38,10 +38,6 @@ [Defines]
 [LibraryClasses.common]
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   
ArmPlatformLib|Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-
 
   I2CLib|Silicon/Hisilicon/Library/I2CLib/I2CLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index 2e3b1c8799cc..f0380ee1f929 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -45,7 +45,6 @@ [LibraryClasses.common]
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
   ArmPlatformLib|Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf
   
ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index fbecb6497469..f24f6dabd12c 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -62,12 +62,7 @@ [LibraryClasses.common]
   ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 
-  # Versatile Express Specific Libraries
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
-  
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
-  # ARM PL111 Lcd Driver
-  
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
   # ARM PL354 SMC Driver
   PL35xSmcLib|ArmPlatformPkg/Drivers/PL35xSmc/PL35xSmc.inf
-- 
2.11.0

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

[edk2] [PATCH 0/6] Move ArmPlatformPkg stuff into edk2-platforms

[Ard Biesheuvel]

This is mostly a preparatory series that will allow us to get rid of a lot
of code that is specific to only a single ARM development platform out of
the main EDK2 tree.

First of all, it removes a couple of false dependencies of various platforms
on libraries that are no longer used, or not actually used by the platform
in question. Patches #5 and #6 move the bulk of the support for ARM
development platforms into edk2-platforms.

Ard Biesheuvel (6):
  Platform: remove bogus ArmPlatformSecExtraActionLib references
  Platform: remove bogus ArmTrustedMonitorLib references
  Platform/ArmVExpress-FVP: remove bogus ArmPlatformSecLib reference
  Platform/Hisilicon: remove bogus VExpress dependencies
  Platform/ARM/Juno: import ArmJunoPkg from EDK2
  Platform/ARM/VExpress: import VExpressPkg from EDK2

 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
|   4 -
 Platform/ARM/JunoPkg/AcpiTables/AcpiTables.inf 
|   3 +-
 Platform/ARM/JunoPkg/ArmJuno.dec   
|  48 ++
 Platform/ARM/JunoPkg/ArmJuno.dsc   
|   8 +-
 Platform/ARM/JunoPkg/ArmJuno.fdf   
|   2 +-
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/AcpiTables.c   
|  78 ++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c   
| 550 
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf 
|  88 ++
 Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxeInternal.h   
|  54 ++
 Platform/ARM/JunoPkg/Include/ArmPlatform.h 
| 178 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
|  58 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S
|  91 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJuno.c  
| 193 +
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
|  80 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c   
| 173 
 Platform/ARM/JunoPkg/Library/JunoPciHostBridgeLib/JunoPciHostBridgeLib.inf 
|   2 +-
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJuno.c
|  68 ++
 Platform/ARM/JunoPkg/Library/NorFlashJunoLib/NorFlashJunoLib.inf   
|  33 +
 Platform/ARM/JunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   
|   2 +-
 Platform/ARM/VExpressPkg/AcpiTables/AcpiTables.inf 
|   3 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc  
|  35 +-
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.fdf  
|  10 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc   
|  19 +-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf   
|   2 +-
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc   
|  23 +-
 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
|  53 ++
 Platform/ARM/VExpressPkg/Drivers/ArmVExpressDxe/ArmFvpDxe.c
|  90 ++
 Platform/ARM/VExpressPkg/Drivers/ArmVExpressDxe/ArmFvpDxe.inf  
|  39 +
 Platform/ARM/VExpressPkg/Drivers/ArmVExpressDxe/ArmHwDxe.c 
|  38 +
 Platform/ARM/VExpressPkg/Drivers/ArmVExpressDxe/ArmHwDxe.inf   
|  37 +
 Platform/ARM/VExpressPkg/Drivers/ArmVExpressFastBootDxe/ArmVExpressFastBoot.c  
| 519 
 
Platform/ARM/VExpressPkg/Drivers/ArmVExpressFastBootDxe/ArmVExpressFastBootDxe.inf
 |  51 ++
 Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c  
| 133 +++
 
Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf
   |  63 ++
 Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputBlt.c   
| 882 
 Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c   
| 393 +
 Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h   
| 128 +++
 Platform/ARM/VExpressPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c   

[edk2] [PATCH 1/6] Platform: remove bogus ArmPlatformSecExtraActionLib references

[Ard Biesheuvel]

Remove copy-pasted ArmPlatformSecExtraActionLib library class resolutions
that none of the platforms actually need.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc| 2 --
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  | 2 --
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc | 2 --
 Silicon/Hisilicon/Hisilicon.dsc.inc | 2 --
 5 files changed, 10 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 8620f6be3514..ec350c999f19 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -172,8 +172,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc 
b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
index 1605eedbdd8c..7b405a949ebd 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
@@ -156,8 +156,6 @@ [LibraryClasses.common]
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index e03c7c4c3526..7c4adb3a53bf 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -151,8 +151,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 29ce8b3bd18e..73c0c7531f26 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -157,8 +157,6 @@ [LibraryClasses.common.SEC]
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   ArmPlatformLib|Silicon/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
 
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
diff --git a/Silicon/Hisilicon/Hisilicon.dsc.inc 
b/Silicon/Hisilicon/Hisilicon.dsc.inc
index d77f0e35431e..c1c947f38cba 100644
--- a/Silicon/Hisilicon/Hisilicon.dsc.inc
+++ b/Silicon/Hisilicon/Hisilicon.dsc.inc
@@ -124,8 +124,6 @@ [LibraryClasses.common]
   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
 
 [LibraryClasses.common.SEC]
-  
ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
-
   
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLibBase.inf
 
   # Trustzone Support
-- 
2.11.0

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

[edk2] [PATCH] ArmPlatformPkg: remove ArmGetCpuCountPerCluster () from ArmPlatformLib

[Ard Biesheuvel]

The only user of ArmPlatformLib's ArmGetCpuCountPerCluster () is itself
an ArmPlatformLib implementation, i.e., ArmVExpressLibRTSM.

Given that we'd prefer to get rid of ArmPlatformLib entirely, let's
remove ArmGetCpuCountPerCluster () from the API as a first step.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---

This is another prerequisite of the edk2-platforms series I am about to
post. After that, I will follow up with a couple of cleanup patches that
get rid of a lot of ArmPlatformPkg cruft.

 ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c | 13 
+
 ArmPlatformPkg/Include/Library/ArmPlatformLib.h | 13 
-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
index d8d1c9ac26dd..11dd7ff1bfb0 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
@@ -21,6 +21,19 @@
 
 #include 
 
+/**
+  Return the core per cluster. The method may differ per core type
+
+  This function might be called from assembler before any stack is set.
+
+  @return   Return the core count per cluster
+
+**/
+UINTN
+ArmGetCpuCountPerCluster (
+  VOID
+  );
+
 ARM_CORE_INFO mVersatileExpressMpCoreInfoTable[] = {
   {
 // Cluster 0, Core 0
diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h 
b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
index fe3bc4bb8e6c..77561a3d05b3 100644
--- a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
+++ b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h
@@ -41,19 +41,6 @@ typedef struct {
 } ARM_SYSTEM_MEMORY_REGION_DESCRIPTOR;
 
 /**
-  Return the core per cluster. The method may differ per core type
-
-  This function might be called from assembler before any stack is set.
-
-  @return   Return the core count per cluster
-
-**/
-UINTN
-ArmGetCpuCountPerCluster (
-  VOID
-  );
-
-/**
   Return the core position from the value of its MpId register
 
   This function returns the core position from the position 0 in the processor.
-- 
2.11.0

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

[edk2] [PATCH] ArmVirtPkg: remove ArmPlatformSysConfigLib dependency

[Ard Biesheuvel]

Now that the PL031 RTC driver library no longer depends on the ARM
platform specific ArmPlatformSysConfigLib, we no longer need to
implement ArmPlatform.h or have a resolution for that library.
This allows us to get rid of a rather dodgy practice of including
platform headers using compiler flags, which is a bad idea at various
levels.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
PL031 patch is on-list and pending.

 ArmVirtPkg/ArmVirtQemu.dsc |  7 -
 ArmVirtPkg/ArmVirtQemuKernel.dsc   |  6 
 ArmVirtPkg/ArmVirtXen.dsc  |  6 
 ArmVirtPkg/Include/ArmPlatform.h   | 33 

 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/QemuVirtMem.c |  1 -
 ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/RelocatableVirt.c |  1 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c   |  1 -
 ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c|  1 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/RelocatableVirt.c  |  1 -
 ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/XenVirtMem.c   |  1 -
 ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.c   |  7 -
 11 files changed, 6 insertions(+), 59 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8a60b61f2aa6..d1b3849d856a 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -49,7 +49,6 @@ [LibraryClasses.common]
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
 
   ArmPlatformLib|ArmVirtPkg/Library/ArmVirtPlatformLib/ArmVirtPlatformLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
@@ -71,12 +70,6 @@ [LibraryClasses.common]
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
-[BuildOptions]
-  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
-
-
 

 #
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 9a31ec93ca06..c7058718b0a6 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -49,7 +49,6 @@ [LibraryClasses.common]
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/BaseQemuFwCfgS3LibNull.inf
 
   
ArmPlatformLib|ArmVirtPkg/Library/ArmQemuRelocatablePlatformLib/ArmQemuRelocatablePlatformLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
@@ -71,11 +70,6 @@ [LibraryClasses.common]
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
-[BuildOptions]
-  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
-
 [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
   # Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
   # executable we build for the relocatable PrePi. They are not runtime
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index e9437066ca56..7a443483d1ac 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -44,7 +44,6 @@ [LibraryClasses]
   
VirtioMmioDeviceLib|OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
 
   
ArmPlatformLib|ArmVirtPkg/Library/ArmXenRelocatablePlatformLib/ArmXenRelocatablePlatformLib.inf
-  
ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
@@ -56,11 +55,6 @@ [LibraryClasses]
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
-[BuildOptions]
-  RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 
-I$(WORKSPACE)/ArmVirtPkg/Include
-  GCC:*_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include
-
 [BuildOptions.ARM.EDKII.SEC, BuildOptions.ARM.EDKII.BASE]
   # Avoid MOVT/MOVW instruction pairs in code that may end up in the PIE
   # executable we build for the 

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe

[Ard Biesheuvel]

On 15 November 2017 at 13:51, Laszlo Ersek  wrote:
> On 11/14/17 11:22, Ard Biesheuvel wrote:
>> The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
>> assuming such regions always have full memory semantics. Given that
>> those regions cannot be mapped as ordinary memory on ARM (due to the
>> fact that the NOR flash requires device semantics while in write mode)
>> this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
>> since it may use unaligned accesses and/or DC ZVA instructions, both
>> of which are incompatible with mappings using device semantics.
>>
>> Note that there is no way we can work around this by changing the
>> mapping type between 'memory' and 'device' when switching from read to
>> write mode and back, because the runtime mapping is created by the OS,
>> and cannot be changed at will.
>>
>> So let's just switch to the unaccelerated version of BaseMemoryLib which
>> does not have the same problem.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
>>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index 8a60b61f2aa6..7b220d6e3c31 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -261,6 +261,8 @@ [Components.common]
>>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>>  
>>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
>> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>}
>>  !if $(SECURE_BOOT_ENABLE) == TRUE
>>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
>> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> index 9a31ec93ca06..7c032e1b07e0 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> @@ -252,6 +252,8 @@ [Components.common]
>>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>>  
>>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
>> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>}
>>  !if $(SECURE_BOOT_ENABLE) == TRUE
>>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
>>
>
> Reviewed-by: Laszlo Ersek 
>
> Given that we've never seen the symptom reported by Shannon, I must
> think Shannon is using some kind of new hardware. May I ask what
> hardware that is?
>

I think this is equally likely to occur in any KVM hardware
virtualization context. It is simply a regression after moving to the
OptDxe BaseMemoryLib flavor.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: use non-accelerated CopyMem for VariableRuntimeDxe

[Laszlo Ersek]

On 11/14/17 11:22, Ard Biesheuvel wrote:
> The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
> assuming such regions always have full memory semantics. Given that
> those regions cannot be mapped as ordinary memory on ARM (due to the
> fact that the NOR flash requires device semantics while in write mode)
> this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
> since it may use unaligned accesses and/or DC ZVA instructions, both
> of which are incompatible with mappings using device semantics.
> 
> Note that there is no way we can work around this by changing the
> mapping type between 'memory' and 'device' when switching from read to
> write mode and back, because the runtime mapping is created by the OS,
> and cannot be changed at will.
> 
> So let's just switch to the unaccelerated version of BaseMemoryLib which
> does not have the same problem.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 ++
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8a60b61f2aa6..7b220d6e3c31 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -261,6 +261,8 @@ [Components.common]
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>  
>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>}
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 9a31ec93ca06..7c032e1b07e0 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -252,6 +252,8 @@ [Components.common]
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>  
>NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> +  # don't use unaligned CopyMem () on the UEFI varstore NOR flash region
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>}
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> 

Reviewed-by: Laszlo Ersek 

Given that we've never seen the symptom reported by Shannon, I must
think Shannon is using some kind of new hardware. May I ask what
hardware that is?

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

Re: [edk2] Why we need CapsuleLib even platform does not support this feature

[Ard Biesheuvel]

On 15 November 2017 at 13:34, Udit Kumar  wrote:
> Hi,
> I recently noticed in my build as well, we need to include CapsuleLib even 
> platform does not support Capsule update feature.
> Thanks to help me, why this dependency is added in edk2.
>

It was added as a dependency to
ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf, for
capsule update support.


>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>> Biesheuvel
>> Sent: Tuesday, November 14, 2017 4:48 PM
>> To: Kalyan Nagabhirava 
>> Cc: edk2-devel@lists.01.org; Leif Lindholm ; Mark
>> Gregotski 
>> Subject: Re: [edk2] [PATCH edk2-platforms]: resolving Hikey platform build 
>> error
>>
>> On 14 November 2017 at 11:16, Kalyan Nagabhirava
>>  wrote:
>> >
>> > "Instance of library class [CapsuleLib] is not found" build error is
>> > coming for Hikey platform, to resolve this issueadded CapsuleLib to
>> > "LibraryClasses.common" section
>> >
>> > diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc
>> > b/Platform/Hisilicon/HiKey/HiKey.dsc
>> > index 968e8ac..2e3b1c8 100644
>> > --- a/Platform/Hisilicon/HiKey/HiKey.dsc
>> > +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
>> > @@ -61,6 +61,7 @@
>> >
>> > SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroni
>> > SynchronizationLib|zationLib.inf
>> >
>> >FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
>> > +
>> > + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.
>> > + inf
>> >
>> >
>> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootM
>> an
>> > UefiBootManagerLib|agerLib.inf
>> >
>> >
>> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformB
>> > PlatformBootManagerLib|ootManagerLib.inf
>> >BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>> >
>> >
>>
>> Thanks Kalyan
>>
>> Could you resend it as a proper patch, please? I.e., with the appropriate
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>>
>> and Signed-off-by line,
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
>> .org%2Fmailman%2Flistinfo%2Fedk2-
>> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cc1807332add6499fcd730
>> 8d52b516fad%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6364625
>> 51151191358=joABHCm%2F3Iu0jfplBE3Ora9ffp3IfuNuu2GfOgOTsV8%3D
>> =0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Why we need CapsuleLib even platform does not support this feature

[Udit Kumar]

Hi, 
I recently noticed in my build as well, we need to include CapsuleLib even 
platform does not support Capsule update feature. 
Thanks to help me, why this dependency is added in edk2. 

Regards
Udit

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, November 14, 2017 4:48 PM
> To: Kalyan Nagabhirava 
> Cc: edk2-devel@lists.01.org; Leif Lindholm ; Mark
> Gregotski 
> Subject: Re: [edk2] [PATCH edk2-platforms]: resolving Hikey platform build 
> error
> 
> On 14 November 2017 at 11:16, Kalyan Nagabhirava
>  wrote:
> >
> > "Instance of library class [CapsuleLib] is not found" build error is
> > coming for Hikey platform, to resolve this issueadded CapsuleLib to
> > "LibraryClasses.common" section
> >
> > diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc
> > b/Platform/Hisilicon/HiKey/HiKey.dsc
> > index 968e8ac..2e3b1c8 100644
> > --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> > +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> > @@ -61,6 +61,7 @@
> >
> > SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroni
> > SynchronizationLib|zationLib.inf
> >
> >FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
> > +
> > + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.
> > + inf
> >
> >
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootM
> an
> > UefiBootManagerLib|agerLib.inf
> >
> >
> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformB
> > PlatformBootManagerLib|ootManagerLib.inf
> >BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> >
> >
> 
> Thanks Kalyan
> 
> Could you resend it as a proper patch, please? I.e., with the appropriate
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> and Signed-off-by line,
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cc1807332add6499fcd730
> 8d52b516fad%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6364625
> 51151191358=joABHCm%2F3Iu0jfplBE3Ora9ffp3IfuNuu2GfOgOTsV8%3D
> =0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] 答复: 答复: [RFC 0/1] Stack trace support in X64 exception handling

[Fan Jeff]

Paulo,



I will try to validate my code firstly and try to integrate into your patch.



Before my part ready, it’s also welcome if you or others provide yours own 
solution on X64 MSFT toolchain.



In my mind, IA32 arch should use the same solution with yours, have you tested 
your solution on IA32 arch with GCC toolchain?



Thanks!

Jeff




From: Paulo Alcantara 
Sent: Tuesday, November 14, 2017 11:37:35 PM
To: Fan Jeff; edk2-devel@lists.01.org
Cc: Rick Bramley; Laszlo Ersek; Andrew Fish; Eric Dong
Subject: Re: 答复: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

Hi Fan,

On 14/11/2017 12:03, Fan Jeff wrote:
> Paul,
>
> I like this feature very much. Actually, I did some POC one year ago but
> I did finalize it.
>
> In my POC, I could use EBP to tack the stack frame on IAS32 arch.
>
> But for x64, I tried to use �Ckeepexceptiontable flag to explain stack
> frame from the debug section of image.
>
> I may workson MSFT toolchain, but it did now work well for GCC toolchain.
>
> I think Eric could help to verify MSFT for your patch. If it works well,
> that’s will be great!
>
> Say again, I like this feature!!!:-)

Cool! Your help would be really appreciable! If we get this working for
X64 in both toolchains, that should be easy to port it to IA-32 as well.

Thank you very much for willing to help on that.

Paulo

>
> Thanks!
>
> Jeff
>
> *发件人: *Paulo Alcantara 
> *发送时间: *2017年11月14日21:23
> *收件人: *edk2-devel@lists.01.org 
> *抄送: *Rick Bramley ; Laszlo Ersek
> ; Andrew Fish ; Eric
> Dong 
> *主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling
>
> Hi,
>
> On 14/11/2017 10:47, Paulo Alcantara wrote:
>> Hi,
>>
>> This series adds stack trace support during a X64 CPU exception.
>>
>> Informations like back trace, stack contents and image module names
>> (that were part of the call stack) will be dumped out.
>>
>> We already have such support in ARM/AArch64 (IIRC) exception handling
>> (thanks to Ard), and then I thought we'd also deserve it in X64 and
>> IA-32 platforms.
>>
>> What do you think guys?
>>
>> BTW, I've tested this only with OVMF (X64 only), using:
>>- gcc-6.3.0, GCC5, NOOPT
>>
>> Any other tests  would be really appreciable.
>
> I've attached a file to show you how the trace would look like.
>
> Thanks!
> Paulo
>
>>
>> Thanks!
>> Paulo
>>
>> Repo:   https://github.com/pcacjr/edk2.git
>> Branch: stacktrace_x64
>>
>> Cc: Rick Bramley 
>> Cc: Andrew Fish 
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Paulo Alcantara 
>> ---
>>
>> Paulo Alcantara (1):
>>UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support
>>
>>   UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 344 
>> +++-
>>   1 file changed, 342 insertions(+), 2 deletions(-)
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib reference

[Ard Biesheuvel]

The PL031 driver implements a VExpress/Juno specific hack to set the
battery backed clock in addition to the PL031. However, none of the
remaining VExpress based hardware we support in EDK2 actuall implements
this feature so we can just remove it, and get rid of the cumbersome
dependency on ArmPlatform.h.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 43 
+++-
 1 file changed, 6 insertions(+), 37 deletions(-)

diff --git 
a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
index 459dcc0a0519..1334ad446cd9 100644
--- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
+++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -38,8 +37,6 @@
 
 #include 
 
-#include 
-
 STATIC BOOLEANmPL031Initialized = FALSE;
 STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
 STATIC UINTN  mPL031RtcBase;
@@ -133,6 +130,11 @@ LibGetTime (
   EFI_STATUS  Status = EFI_SUCCESS;
   UINT32  EpochSeconds;
 
+  // Ensure Time is a valid pointer
+  if (Time == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
   // Initialize the hardware if not already done
   if (!mPL031Initialized) {
 Status = InitializePL031 ();
@@ -141,27 +143,7 @@ LibGetTime (
 }
   }
 
-  // Snapshot the time as early in the function call as possible
-  // On some platforms we may have access to a battery backed up hardware 
clock.
-  // If such RTC exists try to use it first.
-  Status = ArmPlatformSysConfigGet (SYS_CFG_RTC, );
-  if (Status == EFI_UNSUPPORTED) {
-// Battery backed up hardware RTC does not exist, revert to PL031
-EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
-Status = EFI_SUCCESS;
-  } else if (EFI_ERROR (Status)) {
-// Battery backed up hardware RTC exists but could not be read due to 
error. Abort.
-return Status;
-  } else {
-// Battery backed up hardware RTC exists and we read the time correctly 
from it.
-// Now sync the PL031 to the new time.
-MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
-  }
-
-  // Ensure Time is a valid pointer
-  if (Time == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
+  EpochSeconds = MmioRead32 (mPL031RtcBase + PL031_RTC_DR_DATA_REGISTER);
 
   // Adjust for the correct time zone
   // The timezone setting also reflects the DST setting of the clock
@@ -235,19 +217,6 @@ LibSetTime (
 EpochSeconds -= SEC_PER_HOUR;
   }
 
-  // On some platforms we may have access to a battery backed up hardware 
clock.
-  //
-  // If such RTC exists then it must be updated first, before the PL031,
-  // to minimise any time drift. This is important because the battery 
backed-up
-  // RTC maintains the master time for the platform across reboots.
-  //
-  // If such RTC does not exist then the following function returns 
UNSUPPORTED.
-  Status = ArmPlatformSysConfigSet (SYS_CFG_RTC, EpochSeconds);
-  if ((EFI_ERROR (Status)) && (Status != EFI_UNSUPPORTED)){
-// Any status message except SUCCESS and UNSUPPORTED indicates a hardware 
failure.
-return Status;
-  }
-
   // Set the PL031
   MmioWrite32 (mPL031RtcBase + PL031_RTC_LR_LOAD_REGISTER, EpochSeconds);
 
-- 
2.11.0

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

Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix UDF fs access on certain CD/DVD medias

[Wu, Hao A]

Pushed at: 1fbe8276c4

Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu,
> Hao A
> Sent: Tuesday, November 14, 2017 3:49 PM
> To: 'Paulo Alcantara'; Ni, Ruiyu; edk2-devel@lists.01.org
> Cc: Dong, Eric; Zeng, Star
> Subject: Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix UDF fs access on
> certain CD/DVD medias
> 
> Hi Paulo,
> 
> Sorry for the delayed response. The patch is good to me:
> Reviewed-by: Hao Wu 
> 
> Hi Ray,
> 
> Do you have any other comment on this?
> 
> 
> Best Regards,
> Hao Wu
> 
> 
> > -Original Message-
> > From: Paulo Alcantara [mailto:pca...@zytor.com]
> > Sent: Friday, October 13, 2017 9:25 PM
> > To: edk2-devel@lists.01.org
> > Cc: Paulo Alcantara; Wu, Hao A; Ni, Ruiyu; Zeng, Star; Dong, Eric
> > Subject: [PATCH] MdeModulePkg/PartitionDxe: Fix UDF fs access on certain
> > CD/DVD medias
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=725
> >
> > Historically many drives or medias do not correctly return their value
> > for block N - which is also referred as last addressable/recorded block.
> > When they do so, there is still a problem when relying on last recorded
> > block number returned by SCSI commands READ CAPACITY and READ TRACK
> > INFORMATION - that is, between block 0 and block N there may be
> > unwritten blocks which are located outside any track.
> >
> > That said, the Partition driver was unable to find AVDP at block N on
> > certain medias that do not either return or report their last recorded
> > block number correctly.
> >
> > Apparently there is no official or correct way to find the correct block
> > number, however tools like the Philips UDF Conformance Tool (udf_test)
> > apply a correction by searching for an AVDP or VAT in blocks N through
> > N-456 -- this can be observed by looking at the log reported by udf_test
> > on those CD/DVD medias. So, if the AVDP or VAT is found, then it sets
> > the last recorded block number to where AVDP or VAT was located.
> >
> > With the below setence in UDF 2.60, 6.13.2.2 Background Physical
> > Formatting:
> >
> > "... the second AVDP must be recorded after the Background physical
> > Formatting has been finished..."
> >
> > Implies that the last recorded block is the one where second AVDP was
> > recorded.
> >
> > This patch implements a similar way to correct the last recorded block
> > number by searching for last AVDP in blocks N-1 through N-512 on those
> > certain medias, as well as ensure a minimum number of 2 AVDPs found as
> > specified by ECMA 167 and UDF 2.60 specifications.
> >
> > Cc: Hao Wu 
> > Cc: Ruiyu Ni 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Reported-by: Hao Wu 
> > Signed-off-by: Paulo Alcantara 
> > ---
> >  MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c | 254
> --
> > --
> >  1 file changed, 201 insertions(+), 53 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> > b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> > index 8aee30c759..7eee748958 100644
> > --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> > +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
> > @@ -14,6 +14,8 @@
> >
> >  #include "Partition.h"
> >
> > +#define MAX_CORRECTION_BLOCKS_NUM 512u
> > +
> >  //
> >  // C5BD4D42-1A76-4996-8956-73CDA326CD0A
> >  //
> > @@ -48,61 +50,199 @@ UDF_DEVICE_PATH gUdfDevicePath = {
> >  /**
> >Find the anchor volume descriptor pointer.
> >
> > -  @param[in]  BlockIo BlockIo interface.
> > -  @param[in]  DiskIo  DiskIo interface.
> > -  @param[out] AnchorPoint Anchor volume descriptor pointer.
> > +  @param[in]  BlockIo   BlockIo interface.
> > +  @param[in]  DiskIoDiskIo interface.
> > +  @param[out] AnchorPoint   Anchor volume descriptor pointer.
> > +  @param[out] LastRecordedBlock Last recorded block.
> >
> > -  @retval EFI_SUCCESS Anchor volume descriptor pointer found.
> > -  @retval EFI_VOLUME_CORRUPTEDThe file system structures are
> > corrupted.
> > -  @retval other   Anchor volume descriptor pointer not 
> > found.
> > +  @retval EFI_SUCCESS   Anchor volume descriptor pointer found.
> > +  @retval EFI_VOLUME_CORRUPTED  The file system structures are
> > corrupted.
> > +  @retval other Anchor volume descriptor pointer not 
> > found.
> >
> >  **/
> >  EFI_STATUS
> >  FindAnchorVolumeDescriptorPointer (
> >IN   EFI_BLOCK_IO_PROTOCOL *BlockIo,
> >IN   EFI_DISK_IO_PROTOCOL  *DiskIo,
> > -  OUT  UDF_ANCHOR_VOLUME_DESCRIPTOR_POINTER  *AnchorPoint
> > +  OUT  UDF_ANCHOR_VOLUME_DESCRIPTOR_POINTER  *AnchorPoint,
> > +  OUT  EFI_LBA   

Re: [edk2] [PATCH] [edk2-platforms]:resolving Hikey platform build error

[Ard Biesheuvel]

On 15 November 2017 at 11:27, kalyan-nagabhirava
 wrote:
> "Instance of library class [CapsuleLib] is not found" build error is
>  coming for Hikey platform, to resolve this issueadded CapsuleLib to
>  "LibraryClasses.common" section
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: kalyan-nagabhirava 

Reviewed-by: Ard Biesheuvel 

Pushed as bf109f8b87077a8f8215c9f0af8c9639d50cc64c

Thanks.

> ---
>  Platform/Hisilicon/HiKey/HiKey.dsc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
> b/Platform/Hisilicon/HiKey/HiKey.dsc
> index 968e8acc0..2e3b1c879 100644
> --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> @@ -61,6 +61,7 @@
>
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
>
>FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
> +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
>
> PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> --
> 2.15.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] [edk2-platforms]:resolving Hikey platform build error

[kalyan-nagabhirava]

"Instance of library class [CapsuleLib] is not found" build error is
 coming for Hikey platform, to resolve this issueadded CapsuleLib to
 "LibraryClasses.common" section

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava 
---
 Platform/Hisilicon/HiKey/HiKey.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index 968e8acc0..2e3b1c879 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -61,6 +61,7 @@
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
 
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
+  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
   
PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
-- 
2.15.0

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

Re: [edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

[Marcin Wojtas]

Hi,

2017-11-15 12:19 GMT+01:00 Ard Biesheuvel :
> From: Pipat Methavanitpong 
>
> Add Macronix MX66U1G45G definition to NorFlashInfoLib
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pipat Methavanitpong 
> Signed-off-by: Ard Biesheuvel 
> ---
>  EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
> b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> index 750f37a0e8..fb26b4f9bc 100644
> --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> @@ -57,6 +57,7 @@ STATIC CONST NOR_FLASH_INFO NorFlashIds[] = {
>{L"mx25l51235f",{0xc2, 0x20, 0x1a}, 3, 256, 64 * 1024,  1024, 0},
>{L"mx25l12855e",{0xc2, 0x26, 0x18}, 3, 256, 64 * 1024,   256, 0},
>{L"mx66u51235f",{0xc2, 0x25, 0x3a}, 3, 256, 64 * 1024,  1024, 0},
> +  {L"mx66u1g45g", {0xc2, 0x25, 0x3b}, 3, 256, 64 * 1024,  2048, 0},
>{L"mx66l1g45g", {0xc2, 0x20, 0x1b}, 3, 256, 64 * 1024,  2048, 0},
>/* SPANSION */
>{L"s25fl008a",  {0x01, 0x02, 0x13}, 3, 256, 64 * 1024,16, 0},
> --

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

[edk2] [PATCH] EmbeddedPkg: add mx66u1g45g nor flash info

[Ard Biesheuvel]

From: Pipat Methavanitpong 

Add Macronix MX66U1G45G definition to NorFlashInfoLib

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pipat Methavanitpong 
Signed-off-by: Ard Biesheuvel 
---
 EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
index 750f37a0e8..fb26b4f9bc 100644
--- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
+++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
@@ -57,6 +57,7 @@ STATIC CONST NOR_FLASH_INFO NorFlashIds[] = {
   {L"mx25l51235f",{0xc2, 0x20, 0x1a}, 3, 256, 64 * 1024,  1024, 0},
   {L"mx25l12855e",{0xc2, 0x26, 0x18}, 3, 256, 64 * 1024,   256, 0},
   {L"mx66u51235f",{0xc2, 0x25, 0x3a}, 3, 256, 64 * 1024,  1024, 0},
+  {L"mx66u1g45g", {0xc2, 0x25, 0x3b}, 3, 256, 64 * 1024,  2048, 0},
   {L"mx66l1g45g", {0xc2, 0x20, 0x1b}, 3, 256, 64 * 1024,  2048, 0},
   /* SPANSION */
   {L"s25fl008a",  {0x01, 0x02, 0x13}, 3, 256, 64 * 1024,16, 0},
-- 
2.14.1

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

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

[Wang, Jian J]

I tried this workaround and there're no failure in booting Fedora 26 and Windows
server 2016 now. If no objection, I'll merge it into new version of this patch.

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, November 15, 2017 3:37 PM
> To: Zeng, Star ; Laszlo Ersek 
> Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
> Jiewen ; Dong, Eric ; Ard
> Biesheuvel 
> Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> Since OS never had chance to use the those capabilities before, I think it's
> feasible.
> But it's just a workaround not solution because there's real gap between UEFI
> and
> OS on how to interpret the memory capabilities.
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Wednesday, November 15, 2017 2:53 PM
> > To: Wang, Jian J ; Laszlo Ersek 
> > Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
> > Jiewen ; Dong, Eric ; Ard
> > Biesheuvel ; Zeng, Star 
> > Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE
> in
> > memory map
> >
> > How about the code to filter out paging capabilities from UEFI memory map in
> > Page.c CoreGetMemoryMap(), then with maximum compatibility, the UEFI
> > memory map could be same with before
> > 14dde9e903bb9a719ebb8f3381da72b19509bc36 [MdeModulePkg/Core: Fix
> out-
> > of-sync issue in GCD].
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang,
> > Jian J
> > Sent: Tuesday, November 14, 2017 10:36 PM
> > To: Laszlo Ersek 
> > Cc: Matt Fleming ; edk2-devel@lists.01.org; Yao,
> > Jiewen ; Dong, Eric ; Ard
> > Biesheuvel 
> > Subject: Re: [edk2] [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > RT_CODE in memory map
> >
> > Hi Laszlo,
> >
> > I did some investigation works on this issue. I think I found the root 
> > cause and
> > tend to believe this is a Fedora kernel issue. Here're proves:
> >
> > memmap output patterns in which Fedora 26 failed to boot:
> > 1) BS_DataAE20-AE20EFFF 000F
> > 0002600F
> > RT_DataAE20F000-AE38EFFF 0180
> > 8002600F
> > RT_CodeAE38F000-AE48EFFF 0100
> > 8002600F
> > Reserved   AE48F000-AE58EFFF 0100
> > 0002600F
> >
> > 2) BS_DataAE20-AE20EFFF 000F
> > 000F
> > RT_DataAE20F000-AE38EFFF 0180
> > 800F
> > RT_CodeAE38F000-AE467FFF 00D9
> > 800F
> > RT_CodeAE468000-AE469FFF 0002
> > 8002600F
> > RT_CodeAE46A000-AE46EFFF 0005
> > 800F
> > RT_CodeAE46F000-AE470FFF 0002
> > 8002600F
> > RT_CodeAE471000-AE475FFF 0005
> > 800F
> > RT_CodeAE476000-AE479FFF 0004
> > 8002600F
> > RT_CodeAE47A000-AE47 0006
> > 800F
> > RT_CodeAE48-AE481FFF 0002
> > 8002600F
> > RT_CodeAE482000-AE487FFF 0006
> > 800F
> > RT_CodeAE488000-AE489FFF 0002
> > 8002600F
> > RT_CodeAE48A000-AE48EFFF 0005
> > 800F
> > Reserved   AE48F000-AE58EFFF 0100
> > 000F
> >
> > 3) RT_DataAE20F000-AE38EFFF 0180
> > 800F
> > RT_CodeAE38F000-AE418FFF 008A
> > 800F
> > RT_CodeAE419000-AE48EFFF 0076
> > 8002600F
> > Reserved   AE48F000-AE58EFFF 0100
> > 000F
> >
> > 4) BS_DataAE20-AE20EFFF 000F
> > 0002400F
> > RT_DataAE20F000-AE38EFFF 0180
> > 8002400F
> > RT_CodeAE38F000-AE48EFFF 0100
> > 8002400F
> > Reserved   AE48F000-AE58EFFF 0100
> > 0002400F
> >
> >
> > memmap output pattern in which Fedora 26 booted successfully
> > 5) BS_DataAE20-AE20EFFF 000F
> > 000F
> > RT_Data

[edk2] [PATCH][edk2-platforms/devel-MinnowBoard3-UDK2017 1/2] Modify FCE tool to be Linux executable file.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: zwei4 
---
 Platform/BroxtonPlatformPkg/Common/Tools/FCE/BfmLib | Bin
 Platform/BroxtonPlatformPkg/Common/Tools/FCE/FCE| Bin
 2 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 
Platform/BroxtonPlatformPkg/Common/Tools/FCE/BfmLib
 mode change 100644 => 100755 Platform/BroxtonPlatformPkg/Common/Tools/FCE/FCE

diff --git a/Platform/BroxtonPlatformPkg/Common/Tools/FCE/BfmLib 
b/Platform/BroxtonPlatformPkg/Common/Tools/FCE/BfmLib
old mode 100644
new mode 100755
diff --git a/Platform/BroxtonPlatformPkg/Common/Tools/FCE/FCE 
b/Platform/BroxtonPlatformPkg/Common/Tools/FCE/FCE
old mode 100644
new mode 100755
-- 
2.7.4

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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 2/2] GPIOs Change.

[zwei4]

GPIOs Change for FAB B. (FAB A does not use these GPIOs)

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: zwei4 
---
 .../Board/BensonGlacier/BoardInitPostMem/BoardGpios.h| 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
index 0278ea388..5adc8e546 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
@@ -92,8 +92,8 @@ BXT_GPIO_PAD_INIT  mBenson_GpioInitData_N[] =
   BXT_GPIO_PAD_CONF(L"GPIO_26",  M0   ,GPIO  ,GPIO_D ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00D0,  NORTH),//SATA_LEDN
   BXT_GPIO_PAD_CONF(L"GPIO_27",  M0   ,GPO   ,GPIO_D ,  HI 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00D8,  NORTH),//Feature:DFUNet in Sch: NFC_DFU
   BXT_GPIO_PAD_CONF(L"GPIO_28",  M2   ,NA,  NA   ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA,IOS_Masked,   SAME, 
GPIO_PADBAR+0x00E0,  NORTH),//   Net in Sch: 
ISH_GPIO10
-  BXT_GPIO_PAD_CONF(L"GPIO_29",  M0   ,GPO   ,GPIO_D ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00E8,  NORTH),// SOC_M2_RST   Net in 
Sch: ISH_GPIO11
-  //BXT_GPIO_PAD_CONF(L"GPIO_30",  M1   ,NA,  NA   ,  
NA,   NA   , Wake_Disabled, P_20K_L,   NA,NA,IOS_Masked,   
SAME, GPIO_PADBAR+0x00F0,  NORTH),// FAB ID  Net in 
Sch: ISH_GPIO12
+  BXT_GPIO_PAD_CONF(L"GPIO_29",  M0   ,GPO   ,GPIO_D ,  HI 
   ,   NA   , Wake_Disabled, P_NONE,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00E8,  NORTH),// SOC_M2_RST
+  //BXT_GPIO_PAD_CONF(L"GPIO_30",  M0   ,NA,  NA   ,  
NA,   NA   , Wake_Disabled, P_20K_L,   NA,NA,IOS_Masked,   
SAME, GPIO_PADBAR+0x00F0,  NORTH),// FAB ID, Programmed by earlier FAB ID 
detection code.
   BXT_GPIO_PAD_CONF(L"GPIO_31",  M5   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA,IOS_Masked,   SAME, 
GPIO_PADBAR+0x00F8,  NORTH),//Feature: SUSCLK1
   BXT_GPIO_PAD_CONF(L"GPIO_32",  M5   ,NA,  NA   ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA,IOS_Masked,   SAME, 
GPIO_PADBAR+0x0100,  NORTH),//   Net in Sch: SUSCLK2
   BXT_GPIO_PAD_CONF(L"GPIO_33",  M5   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA,IOS_Masked,   SAME, 
GPIO_PADBAR+0x0108,  NORTH),//Feature: SUSCLK3
@@ -162,7 +162,7 @@ BXT_GPIO_PAD_INIT  mBenson_GpioInitData_NW [] =
   BXT_GPIO_PAD_CONF(L"GPIO_196 PANEL1_VDDEN",M0  , GPO   ,GPIO_D,  LO  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,NA, NA,  
GPIO_PADBAR+0x0048,  NORTHWEST),//DISP1_VDDEN
   BXT_GPIO_PAD_CONF(L"GPIO_197 PANEL1_BKLTEN",   M0  , GPO   ,GPIO_D,  LO  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,NA, NA,  
GPIO_PADBAR+0x0050,  NORTHWEST),//DISP1_BKLTEN
   BXT_GPIO_PAD_CONF(L"GPIO_198 PANEL1_BKLTCTL",  M1  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,Last_Value,   SAME,  
GPIO_PADBAR+0x0058,  NORTHWEST),//DISP1_BLTCTL
-  BXT_GPIO_PAD_CONF(L"GPIO_199 DBI_CSX", M2  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled, P_20K_H,NA   ,NA  ,NA, NA,  
GPIO_PADBAR+0x0060,  NORTHWEST),//HDMI_HPD
+  BXT_GPIO_PAD_CONF(L"GPIO_199 DBI_CSX", M2  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled,  P_NONE,NA   ,NA  ,NA, NA,  
GPIO_PADBAR+0x0060,  NORTHWEST),//HDMI_HPD
   BXT_GPIO_PAD_CONF(L"GPIO_200 DBI_RESX",M2  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled, P_20K_H,NA   ,NA  ,NA, NA,  
GPIO_PADBAR+0x0068,  NORTHWEST),//EDP_HPD
   BXT_GPIO_PAD_CONF(L"GPIO_201 GP_INTD_DSI_TE1", M1  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,D0RxDRx0I ,   SAME,  
GPIO_PADBAR+0x0070,  NORTHWEST),//DISP_INTD_TE1
   BXT_GPIO_PAD_CONF(L"GPIO_202 GP_INTD_DSI_TE2", M1  , NA, NA   ,  NA  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,D0RxDRx0I ,   SAME,  
GPIO_PADBAR+0x0078,  NORTHWEST),//DISP_INTD_TE2
@@ -189,12 +189,12 @@ BXT_GPIO_PAD_INIT  mBenson_GpioInitData_NW [] =
   BXT_GPIO_PAD_CONF(L"GPIO_76 AVS_I2S1_WS_SYNC", M0   ,GPO   ,GPIO_D,  HI  
   ,   NA  ,Wake_Disabled, P_20K_L,NA   ,NA  ,NA, NA,  

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 1/2] Fix GCC build failure.

[zwei4]

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: zwei4 
---
 .../BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
index 324baf9ad..28fc52922 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
@@ -59,7 +59,7 @@ BensonGlacierPostMemInitCallback (
   ZeroMem (, sizeof (SYSTEM_CONFIGURATION));
 
  (*PeiServices)->LocatePpi (
-PeiServices,
+(CONST EFI_PEI_SERVICES **)PeiServices,
 ,
 0,
 NULL,
-- 
2.14.1.windows.1

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