[edk2] [PATCH V2 2/2] IntelSiliconPkg/VtdPeiSample: Add premem support.

[Jiewen Yao]

Before memory is ready, this sample produces one VTd engine.
After memory and silicon is initialized, this sample produces
both IGD VTd engine and all-rest VTd engine by reinstall the
FV_INFO_PPI.

This update is to demonstrate how to support pre-mem VTd usage.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 
---
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c 
  | 234 +---
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.inf
 |   2 +-
 2 files changed, 202 insertions(+), 34 deletions(-)

diff --git 
a/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
 
b/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
index 6267da7..921daef 100644
--- 
a/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
+++ 
b/IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define R_SA_MCHBAR   (0x48)
 #define R_SA_GGC  (0x50)
@@ -33,6 +34,8 @@
 #define R_SA_MCHBAR_VTD1_OFFSET  0x5400  ///< HW UNIT for IGD
 #define R_SA_MCHBAR_VTD2_OFFSET  0x5410  ///< HW UNIT for all other - PEG, 
USB, SATA etc
 
+EFI_GUID gEdkiiSiliconInitializedPpiGuid = {0x82a72dc8, 0x61ec, 0x403e, {0xb1, 
0x5a, 0x8d, 0x7a, 0x3a, 0x71, 0x84, 0x98}};
+
 typedef struct {
   EFI_ACPI_DMAR_HEADER DmarHeader;
   //
@@ -131,50 +134,190 @@ EFI_PEI_PPI_DESCRIPTOR mPlatformVTdInfoSampleDesc = {
   
 };
 
+typedef struct {
+  EFI_ACPI_DMAR_HEADER DmarHeader;
+  //
+  // VTd engine 2 - all rest
+  //
+  EFI_ACPI_DMAR_DRHD_HEADERDrhd2;
+} MY_VTD_INFO_NO_IGD_PPI;
+
+MY_VTD_INFO_NO_IGD_PPI  mPlatformVTdNoIgdSample = {
+  { // DmarHeader
+{ // Header
+  EFI_ACPI_4_0_DMA_REMAPPING_TABLE_SIGNATURE,
+  sizeof(MY_VTD_INFO_PPI),
+  EFI_ACPI_DMAR_REVISION,
+},
+0x26, // HostAddressWidth
+  },
+
+  { // Drhd2
+{ // Header
+  EFI_ACPI_DMAR_TYPE_DRHD,
+  sizeof(EFI_ACPI_DMAR_DRHD_HEADER)
+},
+EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL, // Flags
+0, // Reserved
+0, // SegmentNumber
+0xFED91000 // RegisterBaseAddress -- TO BE PATCHED
+  },
+};
+
+EFI_PEI_PPI_DESCRIPTOR mPlatformVTdNoIgdInfoSampleDesc = {
+  (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
+  ,
+  
+};
+
 /**
   Patch Graphic UMA address in RMRR and base address.
 **/
 VOID
-PatchDmar (
+InitDmar (
   VOID
   )
 {
   UINT32  MchBar;
-  UINT16  IgdMode;
-  UINT16  GttMode;
-  UINT32  IgdMemSize;
-  UINT32  GttMemSize;
-
-  ///
-  /// Calculate IGD memsize
-  ///
-  IgdMode = ((PciRead16 (PCI_LIB_ADDRESS(0, 0, 0, R_SA_GGC)) & 
B_SKL_SA_GGC_GMS_MASK) >> N_SKL_SA_GGC_GMS_OFFSET) & 0xFF;
-  if (IgdMode < 0xF0) {
-IgdMemSize = IgdMode * 32 * (1024) * (1024);
+
+  DEBUG ((DEBUG_INFO, "InitDmar\n"));
+
+  MchBar = PciRead32 (PCI_LIB_ADDRESS(0, 0, 0, R_SA_MCHBAR)) & ~BIT0;
+  DEBUG ((DEBUG_INFO, "MchBar - %x\n", MchBar));
+
+  PciWrite32 (PCI_LIB_ADDRESS(0, 0, 0, R_SA_MCHBAR), 0xFED1 | BIT0);
+  DEBUG ((DEBUG_INFO, "MchBar - %x\n", MchBar));
+
+  DEBUG ((DEBUG_INFO, "VTd2 - %x\n", (MmioRead32 (MchBar + 
R_SA_MCHBAR_VTD2_OFFSET) &~1)));
+  MmioWrite32 (MchBar + R_SA_MCHBAR_VTD2_OFFSET, 
(UINT32)mPlatformVTdSample.Drhd2.RegisterBaseAddress | 1);
+  DEBUG ((DEBUG_INFO, "VTd2 - %x\n", (MmioRead32 (MchBar + 
R_SA_MCHBAR_VTD2_OFFSET) &~1)));
+}
+
+/**
+  Patch Graphic UMA address in RMRR and base address.
+**/
+EFI_PEI_PPI_DESCRIPTOR *
+PatchDmar (
+  VOID
+  )
+{
+  UINT32  MchBar;
+  UINT16  IgdMode;
+  UINT16  GttMode;
+  UINT32  IgdMemSize;
+  UINT32  GttMemSize;
+  MY_VTD_INFO_PPI *PlatformVTdSample;
+  EFI_PEI_PPI_DESCRIPTOR  *PlatformVTdInfoSampleDesc;
+  MY_VTD_INFO_NO_IGD_PPI  *PlatformVTdNoIgdSample;
+  EFI_PEI_PPI_DESCRIPTOR  *PlatformVTdNoIgdInfoSampleDesc;
+
+  DEBUG ((DEBUG_INFO, "PatchDmar\n"));
+
+  if (PciRead16 (PCI_LIB_ADDRESS(0, 2, 0, 0)) != 0x) {
+PlatformVTdSample = AllocateCopyPool (sizeof(MY_VTD_INFO_PPI), 
);
+ASSERT(PlatformVTdSample != NULL);
+PlatformVTdInfoSampleDesc = AllocateCopyPool 
(sizeof(EFI_PEI_PPI_DESCRIPTOR), );
+ASSERT(PlatformVTdInfoSampleDesc != NULL);
+PlatformVTdInfoSampleDesc->Ppi = PlatformVTdSample;
+
+///
+/// Calculate IGD memsize
+///
+IgdMode = ((PciRead16 (PCI_LIB_ADDRESS(0, 0, 0, R_SA_GGC)) & 
B_SKL_SA_GGC_GMS_MASK) >> N_SKL_SA_GGC_GMS_OFFSET) & 0xFF;
+if (IgdMode < 0xF0) {
+  IgdMemSize = IgdMode * 32 * (1024) * (1024);
+} else {
+  IgdMemSize = 4 * (IgdMode - 0xF0 + 1) * (1024) * (1024);
+}
+
+///
+/// Calculate GTT mem size
+///
+

[edk2] [PATCH V2 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI

[Jiewen Yao]

 V2 =
Minor enhancement:
Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(),
for better code management.

 V1 =
This series patch adds Pre-Memory DMA protection in PEI.
The purpose is to make sure when the system memory is initialized, the DMA
protection takes effect immediately.

The IntelVTdPmrPei driver is updated to remove the global variable and
add VTD_INFO_PPI notification.

The VTdInfoSample driver is updated to install the initial
VTD_INFO_PPI before memory init, and add more content after memory init
by reinstalling VTD_INFO_PPI.

This patch is validated on one Intel Client kabylake platform.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 

Jiewen Yao (2):
  IntelSiliconPkg/VtdPmrPei: Add premem support.
  IntelSiliconPkg/VtdPeiSample: Add premem support.

 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c 
   | 580 ++
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c   
   | 130 ++-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c
   | 846 +++-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h
   |  93 +++
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf  
   |  11 +-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c
   | 293 +++
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.c 
  | 234 +-
 
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.inf
 |   2 +-
 8 files changed, 1558 insertions(+), 631 deletions(-)
 create mode 100644 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c
 create mode 100644 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c

-- 
2.7.4.windows.1

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

[edk2] [PATCH V2 1/2] IntelSiliconPkg/VtdPmrPei: Add premem support.

[Jiewen Yao]

Remove memory discovered dependency to support both premem
VTD_INFO_PPI and postmem VTD_INFO_PPI.

If VTD_INFO_PPI is installed before memory is ready, this
driver protects all memory region.
If VTD_INFO_PPI is installed or reinstalled after memory
is ready, this driver allocates DMA buffer and protect rest.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 
---
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c| 580 
++
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c  | 130 ++-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c   | 846 
+++-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h   |  93 +++
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf |  11 +-
 IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/VtdReg.c   | 293 +++
 6 files changed, 1356 insertions(+), 597 deletions(-)

diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c 
b/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c
new file mode 100644
index 000..891efa6
--- /dev/null
+++ b/IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/DmarTable.c
@@ -0,0 +1,580 @@
+/** @file
+
+  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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "IntelVTdPmrPei.h"
+
+/**
+  Dump DMAR DeviceScopeEntry.
+
+  @param[in]  DmarDeviceScopeEntry  DMAR DeviceScopeEntry
+**/
+VOID
+DumpDmarDeviceScopeEntry (
+  IN EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER *DmarDeviceScopeEntry
+  )
+{
+  UINTN   PciPathNumber;
+  UINTN   PciPathIndex;
+  EFI_ACPI_DMAR_PCI_PATH  *PciPath;
+
+  if (DmarDeviceScopeEntry == NULL) {
+return;
+  }
+
+  DEBUG ((DEBUG_INFO,
+"
*\n"
+));
+  DEBUG ((DEBUG_INFO,
+"*   DMA-Remapping Device Scope Entry Structure
  *\n"
+));
+  DEBUG ((DEBUG_INFO,
+"
*\n"
+));
+  DEBUG ((DEBUG_INFO,
+(sizeof(UINTN) == sizeof(UINT64)) ?
+"DMAR Device Scope Entry address .. 0x%016lx\n" :
+"DMAR Device Scope Entry address .. 0x%08x\n",
+DmarDeviceScopeEntry
+));
+  DEBUG ((DEBUG_INFO,
+"  Device Scope Entry Type  0x%02x\n",
+DmarDeviceScopeEntry->Type
+));
+  switch (DmarDeviceScopeEntry->Type) {
+  case EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_ENDPOINT:
+DEBUG ((DEBUG_INFO,
+  "PCI Endpoint Device\n"
+  ));
+break;
+  case EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_BRIDGE:
+DEBUG ((DEBUG_INFO,
+  "PCI Sub-hierachy\n"
+  ));
+break;
+  default:
+break;
+  }
+  DEBUG ((DEBUG_INFO,
+"  Length . 0x%02x\n",
+DmarDeviceScopeEntry->Length
+));
+  DEBUG ((DEBUG_INFO,
+"  Enumeration ID . 0x%02x\n",
+DmarDeviceScopeEntry->EnumerationId
+));
+  DEBUG ((DEBUG_INFO,
+"  Starting Bus Number  0x%02x\n",
+DmarDeviceScopeEntry->StartBusNumber
+));
+
+  PciPathNumber = (DmarDeviceScopeEntry->Length - 
sizeof(EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER)) / 
sizeof(EFI_ACPI_DMAR_PCI_PATH);
+  PciPath = (EFI_ACPI_DMAR_PCI_PATH *)(DmarDeviceScopeEntry + 1);
+  for (PciPathIndex = 0; PciPathIndex < PciPathNumber; PciPathIndex++) {
+DEBUG ((DEBUG_INFO,
+  "  Device . 0x%02x\n",
+  PciPath[PciPathIndex].Device
+  ));
+DEBUG ((DEBUG_INFO,
+  "  Function ... 0x%02x\n",
+  PciPath[PciPathIndex].Function
+  ));
+  }
+
+  DEBUG ((DEBUG_INFO,
+"
*\n\n"
+));
+
+  return;
+}
+
+/**
+  Dump DMAR RMRR table.
+
+  @param[in]  Rmrr  DMAR RMRR table
+**/
+VOID
+DumpDmarRmrr (
+  IN EFI_ACPI_DMAR_RMRR_HEADER *Rmrr
+  )
+{
+  EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER   *DmarDeviceScopeEntry;
+  INTNRmrrLen;
+
+  if (Rmrr == NULL) {
+return;
+  }
+
+  DEBUG ((DEBUG_INFO,
+"  
***\n"
+));
+  DEBUG ((DEBUG_INFO,
+"  *   

[edk2] [PATCH 2/4] Drivers/SataSiI3132Dxe: Allow 64-bit DMA transfer

[Daniil Egranov]

Set a PCI IO attribute allowing 64-bit DMA transfer.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Daniil Egranov 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
index f4946552a0..c1760fdc1b 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
@@ -384,7 +384,7 @@ SataSiI3132DriverBindingStart (
   
   );
   if (!EFI_ERROR (Status)) {
-  Supports &= EFI_PCI_DEVICE_ENABLE;
+  Supports &= EFI_PCI_DEVICE_ENABLE | 
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE;
   Status = PciIo->Attributes (
 PciIo,
 EfiPciIoAttributeOperationEnable,
-- 
2.11.0

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

[edk2] [PATCH 4/4] Drivers/SataSiI3132Dxe: Fixed startup and shutdown procedures

[Daniil Egranov]

Corrected memory allocation during startup.
Added driver stop procedure and exit boot event handler.
Added driver memory and protocols cleanup procedures.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Daniil Egranov 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c | 281 ++-
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h |  17 ++
 2 files changed, 236 insertions(+), 62 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
index 50253b9160..063086c956 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
@@ -89,20 +89,26 @@ SataSiI3132Constructor (
 {
   SATA_SI3132_INSTANCE*Instance;
   EFI_ATA_PASS_THRU_MODE  *AtaPassThruMode;
+  EFI_STATUS  Status;
 
   if (!SataSiI3132Instance) {
 return EFI_INVALID_PARAMETER;
   }
 
-  Instance = (SATA_SI3132_INSTANCE*)AllocateZeroPool (sizeof 
(SATA_SI3132_INSTANCE));
-  if (Instance == NULL) {
-return EFI_OUT_OF_RESOURCES;
+  Status = gBS->AllocatePool (EfiBootServicesData, sizeof 
(SATA_SI3132_INSTANCE), (VOID **));
+  if (EFI_ERROR (Status)) {
+return Status;
   }
+  gBS->SetMem (Instance, sizeof (SATA_SI3132_INSTANCE), 0);
 
   Instance->Signature   = SATA_SII3132_SIGNATURE;
   Instance->PciIo   = PciIo;
 
-  AtaPassThruMode = (EFI_ATA_PASS_THRU_MODE*)AllocatePool (sizeof 
(EFI_ATA_PASS_THRU_MODE));
+  Status = gBS->AllocatePool (EfiBootServicesData, sizeof 
(EFI_ATA_PASS_THRU_MODE), (VOID **));
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
   AtaPassThruMode->Attributes = EFI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL | 
EFI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL;
   AtaPassThruMode->IoAlign = 0x1000;
 
@@ -200,7 +206,10 @@ SataSiI3132PortInitialization (
   }
 
   // Create Device
-  Device= (SATA_SI3132_DEVICE*)AllocatePool (sizeof 
(SATA_SI3132_DEVICE));
+  Status = gBS->AllocatePool (EfiBootServicesData, sizeof 
(SATA_SI3132_DEVICE), (VOID **));
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
   Device->Index = Port->Index; //TODO: Could need to be fixed when 
SATA Port Multiplier support
   Device->Port  = Port;
   Device->BlockSize = 0;
@@ -310,6 +319,118 @@ ON_EXIT:
 }
 
 /**
+  Free memory allocated by the driver.
+
+  @param  SataSiI3132Instance  pointer to the driver's data structure.
+
+**/
+STATIC
+VOID
+SataSiI3132DriverFreeMemory (
+  IN SATA_SI3132_INSTANCE*  SataSiI3132Instance
+  )
+{
+  UINTN  PortIndex;
+  SATA_SI3132_PORT   *Port;
+  SATA_SI3132_DEVICE *Device;
+  LIST_ENTRY *Node;
+  EFI_STATUS Status;
+  UINTN  NumberOfBytes;
+
+  if (SataSiI3132Instance == NULL) {
+return;
+  }
+
+  for (PortIndex = 0; PortIndex < SATA_SII3132_MAXPORT; PortIndex++) {
+Port = &(SataSiI3132Instance->Ports[PortIndex]);
+if (Port != NULL) {
+
+  //Free Device memory on each port
+  Node = Port->Devices.ForwardLink;
+  while (Node != >Devices) {
+Device = (SATA_SI3132_DEVICE*)Node;
+Node = Node->ForwardLink;
+RemoveEntryList (>Link);
+gBS->FreePool (Device);
+  }
+
+  //Unmap and deallocate PCI IO memory for each port
+  if (Port->PciAllocMappingPRB != NULL) {
+Status = SataSiI3132Instance->PciIo->Unmap (SataSiI3132Instance->PciIo,
+Port->PciAllocMappingPRB);
+if (EFI_ERROR (Status)) {
+  SATA_TRACE ("SataSiI3132DriverFreeMemory: unable to unmap memory");
+}
+  }
+
+  if (Port->HostPRB != 0) {
+NumberOfBytes = sizeof (SATA_SI3132_PRB);
+Status = SataSiI3132Instance->PciIo->FreeBuffer 
(SataSiI3132Instance->PciIo,
+ EFI_SIZE_TO_PAGES 
(NumberOfBytes),
+ Port->HostPRB);
+if (EFI_ERROR (Status)) {
+  SATA_TRACE ("SataSiI3132DriverFreeMemory: unable to free memory");
+}
+  }
+}
+  }
+
+  if (SataSiI3132Instance->AtaPassThruProtocol.Mode != NULL) {
+gBS->FreePool (SataSiI3132Instance->AtaPassThruProtocol.Mode);
+  }
+}
+
+/**
+  Uninstall and close protocols used by the driver.
+
+  @param  SataSiI3132Instance  pointer to the driver's data structure.
+
+**/
+STATIC
+VOID
+SataSiI3132DriverCloseProtocols (
+  IN SATA_SI3132_INSTANCE*  SataSiI3132Instance
+  )
+{
+  EFI_STATUS  Status;
+
+  if (SataSiI3132Instance == NULL) {
+return;
+  }
+
+  // Uninstall ATA Pass-Through Protocol
+  Status = gBS->UninstallProtocolInterface (SataSiI3132Instance->Controller,
+   ,
+   >AtaPassThruProtocol);
+  if (EFI_ERROR (Status)) {
+SATA_TRACE ("SataSiI3132DriverFreeMemory: unable to uninstall 
AtaPassThruProtocol");
+  }
+
+  if 

[edk2] [PATCH 0/4] SataSiI3132Dxe fixes

[Daniil Egranov]

This set of patches fixes an issue with 64-bit DMA and implements
the missing exit boot event and driver stop functionality including
memory/protocols cleanup procedure.

Daniil Egranov (4):
  Drivers/SataSiI3132Dxe: Fixed PCI IO read and write operations
  Drivers/SataSiI3132Dxe: Allow 64-bit DMA transfer
  Drivers/SataSiI3132Dxe: Enable multi-controller support
  Drivers/SataSiI3132Dxe: Fixed startup and shutdown procedures

 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c   | 301 -
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h   |  17 ++
 .../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c|   4 +-
 3 files changed, 252 insertions(+), 70 deletions(-)

-- 
2.11.0

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

[edk2] [PATCH 3/4] Drivers/SataSiI3132Dxe: Enable multi-controller support

[Daniil Egranov]

Saved controller specific data into the driver's information structure.
Removed global variable indicating the driver's status and added
check for the driver's status based on the available protocol.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Daniil Egranov 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
index c1760fdc1b..50253b9160 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c
@@ -309,8 +309,6 @@ ON_EXIT:
   return Status;
 }
 
-BOOLEAN mbStarted = FALSE;
-
 /**
   Starting the Pci SATA Driver.
 
@@ -342,9 +340,18 @@ SataSiI3132DriverBindingStart (
 
   SATA_TRACE ("SataSiI3132DriverBindingStart()");
 
-  //TODO: Find a nicer way to do it !
-  if (mbStarted) {
-return EFI_SUCCESS; // Don't restart me !
+  Status = gBS->OpenProtocol (
+Controller,
+,
+NULL,
+This->DriverBindingHandle,
+Controller,
+EFI_OPEN_PROTOCOL_TEST_PROTOCOL
+);
+
+  if (!EFI_ERROR (Status)) {
+SATA_TRACE ("SataSiI3132DriverBindingStart: driver already started");
+return Status;
   }
 
   //
@@ -426,6 +433,8 @@ SataSiI3132DriverBindingStart (
 return Status;
   }
 
+  SataSiI3132Instance->OriginalPciAttributes = OriginalPciAttributes;
+
   // Initialize SiI3132 Sata Controller
   Status = SataSiI3132Initialization (SataSiI3132Instance);
   if (EFI_ERROR (Status)) {
@@ -458,8 +467,6 @@ SataSiI3132DriverBindingStart (
   goto UNINSTALL_USBHC;
   }*/
 
-  mbStarted = TRUE;
-
   SATA_TRACE ("SataSiI3132DriverBindingStart() Success!");
   return EFI_SUCCESS;
 
-- 
2.11.0

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

[edk2] [PATCH 1/4] Drivers/SataSiI3132Dxe: Fixed PCI IO read and write operations

[Daniil Egranov]

The ATA pass through read should use PCI IO bus master write operation
and ATA pass through write should use PCI IO bus master read operation
as the read and write operations executed from the bus master's point
of view.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Daniil Egranov 
---
 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c 
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 2fb5fd68db..a938563ebd 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand (
 }
 
 Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterRead,
+   PciIo, EfiPciIoOperationBusMasterWrite,
Packet->InDataBuffer, , , 

);
 if (EFI_ERROR (Status)) {
@@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand (
 OutDataBufferLength = Packet->OutTransferLength * SataDevice->BlockSize;
 
 Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterWrite,
+   PciIo, EfiPciIoOperationBusMasterRead,
Packet->OutDataBuffer, , 
, 
);
 if (EFI_ERROR (Status)) {
-- 
2.11.0

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

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Yao, Jiewen]

I think it does exist.
If I use IOMMU to prevent all DMA transaction, I have seen XHCI driver and AHCI 
driver reporting error.

Thank you
Yao Jiewen

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, October 27, 2017 10:38 AM
> To: Yao, Jiewen ; Laszlo Ersek ;
> Zeng, Star ; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> 
> Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> I also doubt such device driver exists.
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Friday, October 27, 2017 9:47 AM
> > To: Ni, Ruiyu ; Laszlo Ersek ; Zeng,
> > Star ; edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Kinney, Michael D
> > 
> > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> > CALLBACK.
> >
> > I think the error might be PCI device specific.
> >
> > BTW: We already have bugzillar on that
> > https://bugzilla.tianocore.org/show_bug.cgi?id=739
> >
> > It has been validated by Microsoft. We can validate more device cards to see
> > if there is any issue.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Ni, Ruiyu
> > > Sent: Friday, October 27, 2017 8:54 AM
> > > To: Yao, Jiewen ; Laszlo Ersek
> > > ; Zeng, Star ;
> > > edk2-devel@lists.01.org
> > > Cc: Ard Biesheuvel ; Kinney, Michael D
> > > 
> > > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > > TPL to CALLBACK.
> > >
> > > Jiewen,
> > > If the BME bit is cleared in Command register, but a device driver
> > > uses DMA to transfer data, what kind of error will be seen by SW?
> > >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Friday, October 27, 2017 8:34 AM
> > > To: Laszlo Ersek ; Zeng, Star
> > > ; edk2-devel@lists.01.org
> > > Cc: Ni, Ruiyu ; Ard Biesheuvel
> > > ; Kinney, Michael D
> > > 
> > > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > > TPL to CALLBACK.
> > >
> > > Good Info. I think a correct implementation should not use busy wait.
> > >
> > > It should add error handling to check if there is hardware error during 
> > > that.
> > >
> > > > - busy wait (poll) unil the transfer is complete,
> > >
> > > The process of busy wait should be something like below:
> > >   while(TRUE) {
> > > if (error) {
> > >   break;
> > > }
> > > GetData
> > > if (complete) {
> > >   Break
> > > }
> > >   }
> > >
> > > BME clear will trigger error break.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > > Sent: Thursday, October 26, 2017 11:07 PM
> > > > To: Yao, Jiewen ; Zeng, Star
> > > > ; edk2-devel@lists.01.org
> > > > Cc: Ni, Ruiyu ; Ard Biesheuvel
> > > > ; Kinney, Michael D
> > > > 
> > > > Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > > > TPL to CALLBACK.
> > > >
> > > > On 10/26/17 15:36, Yao, Jiewen wrote:
> > > > > Hi Laszlo
> > > > > I have discussed this with Mike Kinney offline and some Microsoft
> > engineers.
> > > > >
> > > > > We believe the impact of BME disable is different with the impact of
> > SEV.
> > > > >
> > > > > For SEV, if a DMA buffer is in transition when SEV bit change, the
> > > > > DMA will still
> > > > be active, but the content is different. It will bring wrong data
> > > > from device perspective.
> > > > >
> > > > > For BME, if a DMA buffer is in transition when BME is clear, the
> > > > > DMA will be
> > > > stopped immediately. The device only sees the DMA transition is abort.
> > > > But there is no wrong data transmitted.
> > > >
> > > > I agree with the above analysis.
> > > >
> > > > > Because of above reason, we think it is OK to let PCI bus driver
> > > > > to clear BME bit
> > > > even there is active DMA transaction.
> > > >
> > > > The reason why I believe that the PciBusDxe driver should not clear
> > > > the BME bit is different. It is unrelated to SEV.
> > > >
> > > > Imagine a PCI device that requires a special DMA transfer before it
> > > > can be quiesced at ExitBootServices(). The vendor of this device
> > > > will implement an EBS notification function like this:
> > > >
> > > > - check the private data structure to see if the device needs the
> > > > special DMA transfer
> > > >
> > > > - initiate the special DMA transfer -- write some data to a preallocated

Re: [edk2] [Patch 0/2] Add check to avoid use NULL pointer

[Wu, Hao A]

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin
> Wu
> Sent: Friday, October 27, 2017 10:24 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Ye, Ting; Fu, Siyuan; Wu, Jiaxin
> Subject: [edk2] [Patch 0/2] Add check to avoid use NULL pointer
> 
> Cc: Wu Hao A 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin 
> 
> Jiaxin Wu (2):
>   NetworkPkg/HttpBootDxe: Add check to avoid use NULL pointer
>   NetworkPkg/IScsiDxe: Add check to avoid use NULL pointer
> 
>  NetworkPkg/HttpBootDxe/HttpBootDxe.c | 50 +++
> -
>  NetworkPkg/IScsiDxe/IScsiConfig.c|  4 +++
>  2 files changed, 31 insertions(+), 23 deletions(-)
> 
> --
> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Zeng, Star]

Reviewed-by: Star Zeng  after the minor typo " isse " is 
fixed to " issue ".

Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, October 26, 2017 11:48 PM
To: edk2-devel-01 
Cc: Aleksei Kovura ; Ard Biesheuvel 
; Dann Frazier ; Dong, Eric 
; Zeng, Star 
Subject: [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at 
ExitBootServices()

Clearing I/O port decoding in the PCI command register at
ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx) machine 
type. (AHCI boot on "q35" is unaffected.) Windows seems repeatedly stuck, 
apparently waiting for a timeout of sorts.

This is arguably a Windows bug; a native OS driver should not expect the 
firmware to leave the PCI command register in any particular state.

Strictly speaking, we only need to disable BM-DMA at ExitBootServices(), in 
order to abort pending transfers to/from RAM, which is soon to be owned by the 
OS. BM-DMA is also the only bit that's explicitly named by the UEFI Driver 
Writers' Guide, for clearing at ExitBootServices().

I've verified that clearing only BM-DMA fixes the isse (boot time) on i440fx, 
and does not regress q35/AHCI.

Cc: Aleksei Kovura 
Cc: Ard Biesheuvel 
Cc: Dann Frazier 
Cc: Eric Dong 
Cc: Star Zeng 
Reported-by: Aleksei Kovura 
Reported-by: Dann Frazier 
Reported-by: https://launchpad.net/~cjkrupp
Bisected-by: Dann Frazier 
Bisected-by: https://launchpad.net/~cjkrupp
Suggested-by: Ard Biesheuvel 
Suggested-by: Star Zeng 
Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: ata_disable_only_bmdma

 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--  
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
index 8d6eac706c0b..92c5bf2001cd 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
@@ -123,8 +123,7 @@ typedef struct {
   LIST_ENTRYNonBlockingTaskList;
 
   //
-  // For disabling the device (especially Bus Master DMA) at
-  // ExitBootServices().
+  // For disabling Bus Master DMA on the device at ExitBootServices().
   //
   EFI_EVENT ExitBootEvent;
 } ATA_ATAPI_PASS_THRU_INSTANCE;
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
index 09064dda18b7..e10e0d4e65f6 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
@@ -480,8 +480,7 @@ InitializeAtaAtapiPassThru (  }
 
 /**
-  Disable the device (especially Bus Master DMA) when exiting the boot
-  services.
+  Disable Bus Master DMA on the device when exiting the boot services.
 
   @param[in] EventEvent for which this notification function is being
   called.
@@ -506,7 +505,7 @@ AtaPassThruExitBootServices (
   PciIo->Attributes (
PciIo,
EfiPciIoAttributeOperationDisable,
-   Instance->EnabledPciAttributes,
+   Instance->EnabledPciAttributes & 
+ EFI_PCI_IO_ATTRIBUTE_BUS_MASTER,
NULL
);
 }
--
2.14.1.3.gb7cf6e02401b

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

Re: [edk2] Xen Console input very slow in recent UEFI

[Zeng, Star]

Hi,

The TimeOut handling in SerialRead() in SerialDxe(MdeModulepkg), 
IsaSerialRead() in IsaSerialDxe(IntelFrameworkModulePkg) and  SerialRead() in 
PciSioSerialDxe(MdeModulePkg) are consistent, and we did not see this kind of 
"slow down" before.

After some investigation, I found it is related to the Timeout value.

The Timeout is 100 (1s) by default to follow UEFI spec. And the Terminal 
driver will recalculate and set the Timeout value based on the properties of 
UART in TerminalDriverBindingStart()/TerminalConInTimerHandler().

SerialInTimeOut = 0;
if (Mode->BaudRate != 0) {
  //
  // According to BAUD rate to calculate the timeout value.
  //
  SerialInTimeOut = (1 + Mode->DataBits + Mode->StopBits) * 2 * 100 / 
(UINTN) Mode->BaudRate;
}

For example, based on the PCD values of PcdUartDefaultBaudRate, 
PcdUartDefaultDataBits and PcdUartDefaultStopBits, SerialInTimeOut = (1 + 8  + 
1) * 2 * 100 / (UINTN) 115200 = 173 (us).

When SerialDxe is used,
TerminalDriverBindingStart()/TerminalConInTimerHandler() ->
  SerialIo->SetAttributes() ->
SerialSetAttributes() ->
  SerialPortSetAttributes()

Some implementations of SerialPortSetAttributes() could handle the input 
parameters and return RETURN_SUCCESS, for example BaseSerialPortLib16550, then 
Timeout value will be changed to 173 (us), no "slow down" will be observed.
But some implementations of SerialPortSetAttributes() just return 
RETURN_UNSUPPORTED, for example XenConsoleSerialPortLib, then Timeout value 
will be not changed and kept to be 100 (1s), "slow down" will be observed.

Here, how about to?
1. Handle the input parameters and return status accordingly instead of just 
returning RETURN_UNSUPPORTED in SerialPortSetAttributes().
2. Just return RETURN_SUCCESS instead of RETURN_UNSUPPORTED in 
SerialPortSetAttributes() if the instance does not care the input parameters at 
all.

And SerialDxe may can be enhanced like below to be more robust.

==
6ec9c40f91fc675ee77f3e54aea4e5a41a2de504
 MdeModulePkg/Universal/SerialDxe/SerialIo.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c 
b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
index ebcd92726314..060ea56c2b1a 100644
--- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
+++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
@@ -285,7 +285,21 @@ SerialSetAttributes (
 
   Status = SerialPortSetAttributes (, , , 
, , );
   if (EFI_ERROR (Status)) {
-return Status;
+//
+// If it is just to set Timeout value and unsupported is returned,
+// do not return error.
+//
+if ((Status == EFI_UNSUPPORTED) &&
+(This->Mode->Timeout  != Timeout) &&
+(This->Mode->ReceiveFifoDepth == ReceiveFifoDepth) &&
+(This->Mode->BaudRate == BaudRate) &&
+(This->Mode->DataBits == (UINT32) DataBits) &&
+(This->Mode->Parity   == (UINT32) Parity) &&
+(This->Mode->StopBits == (UINT32) StopBits)) {
+  Status = EFI_SUCCESS;
+} else {
+  return Status;
+}
   }
 
   //



Thanks,
Star

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Julien 
Grall
Sent: Friday, October 27, 2017 2:32 AM
To: Laszlo Ersek ; edk2-devel-01 ; 
Zeng, Star ; heyi@linaro.org; Ni, Ruiyu 

Cc: Anthony PERARD ; Leif Lindholm 
; Ard Biesheuvel 
Subject: Re: [edk2] Xen Console input very slow in recent UEFI

Hi Laszlo,

Thank you for your help.

On 26/10/17 16:20, Laszlo Ersek wrote:
> On 10/26/17 17:13, Laszlo Ersek wrote:
>> Hello Julien,
>>
>> On 10/26/17 13:05, Julien Grall wrote:
>>> Hi all,
>>>
>>> I was doing more testing of UEFI in Xen guests and noticed some slow 
>>> down when using the shell. The characters are only echoed after a 
>>> second or two that is a bit annoying.
>>>
>>> The change that introduced this issue is 4cf3f37c87 "MdeModulePkg
>>> SerialDxe: Process timeout consistently in SerialRead".
>>>
>>> The Serial Driver for Xen PV console is very simple (see 
>>> OvmfPkg/Library/XenConsoleSerialPortLib). So I am not sure where the 
>>> root cause is.
>>>
>>> Would anyone have any tips on it?
>>
>> The exact same issue has been encountered earlier under QEMU, please 
>> refer to the following sub-thread (please read it to end):
>>
>> http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redh
>> at.com
>>
>> The fix was commit 5f0f5e90ae8c ("ArmVirtPkg/FdtPL011SerialPortLib: 
>> call PL011UartLib in all SerialPortLib APIs", 2017-08-16).
>>
>> I think if you can implement the same for XenConsoleSerialPortLib, 
>> that should return to working state as well.
> 
> Hmmm, wait, at a closer look, it looks like
> 
>

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Ni, Ruiyu]

I also doubt such device driver exists.

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, October 27, 2017 9:47 AM
> To: Ni, Ruiyu ; Laszlo Ersek ; Zeng,
> Star ; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> 
> Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> I think the error might be PCI device specific.
> 
> BTW: We already have bugzillar on that
> https://bugzilla.tianocore.org/show_bug.cgi?id=739
> 
> It has been validated by Microsoft. We can validate more device cards to see
> if there is any issue.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Ni, Ruiyu
> > Sent: Friday, October 27, 2017 8:54 AM
> > To: Yao, Jiewen ; Laszlo Ersek
> > ; Zeng, Star ;
> > edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Kinney, Michael D
> > 
> > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > TPL to CALLBACK.
> >
> > Jiewen,
> > If the BME bit is cleared in Command register, but a device driver
> > uses DMA to transfer data, what kind of error will be seen by SW?
> >
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Friday, October 27, 2017 8:34 AM
> > To: Laszlo Ersek ; Zeng, Star
> > ; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Ard Biesheuvel
> > ; Kinney, Michael D
> > 
> > Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > TPL to CALLBACK.
> >
> > Good Info. I think a correct implementation should not use busy wait.
> >
> > It should add error handling to check if there is hardware error during 
> > that.
> >
> > > - busy wait (poll) unil the transfer is complete,
> >
> > The process of busy wait should be something like below:
> >   while(TRUE) {
> > if (error) {
> >   break;
> > }
> > GetData
> > if (complete) {
> >   Break
> > }
> >   }
> >
> > BME clear will trigger error break.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > Sent: Thursday, October 26, 2017 11:07 PM
> > > To: Yao, Jiewen ; Zeng, Star
> > > ; edk2-devel@lists.01.org
> > > Cc: Ni, Ruiyu ; Ard Biesheuvel
> > > ; Kinney, Michael D
> > > 
> > > Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > > TPL to CALLBACK.
> > >
> > > On 10/26/17 15:36, Yao, Jiewen wrote:
> > > > Hi Laszlo
> > > > I have discussed this with Mike Kinney offline and some Microsoft
> engineers.
> > > >
> > > > We believe the impact of BME disable is different with the impact of
> SEV.
> > > >
> > > > For SEV, if a DMA buffer is in transition when SEV bit change, the
> > > > DMA will still
> > > be active, but the content is different. It will bring wrong data
> > > from device perspective.
> > > >
> > > > For BME, if a DMA buffer is in transition when BME is clear, the
> > > > DMA will be
> > > stopped immediately. The device only sees the DMA transition is abort.
> > > But there is no wrong data transmitted.
> > >
> > > I agree with the above analysis.
> > >
> > > > Because of above reason, we think it is OK to let PCI bus driver
> > > > to clear BME bit
> > > even there is active DMA transaction.
> > >
> > > The reason why I believe that the PciBusDxe driver should not clear
> > > the BME bit is different. It is unrelated to SEV.
> > >
> > > Imagine a PCI device that requires a special DMA transfer before it
> > > can be quiesced at ExitBootServices(). The vendor of this device
> > > will implement an EBS notification function like this:
> > >
> > > - check the private data structure to see if the device needs the
> > > special DMA transfer
> > >
> > > - initiate the special DMA transfer -- write some data to a preallocated
> > >   and pre-programmed memory buffer, and then push the doorbell in
> MMIO
> > >   or config space,
> > >
> > > - busy wait (poll) unil the transfer is complete,
> > >
> > > - clear BME (as required by the DWG / spec)
> > >
> > > - done
> > >
> > > Now, if PciBusDxe introduces its own EBS notification function,
> > > which iterates over all the PciIo instances, and clears the BME bit
> > > in each command register, then this notification function may, or
> > > may not, be queued before the other one that I described above.
> > >
> > > If the PciBusDxe function is queued "after", then everything is fine.
> > > If it is queued "before", then the driver's own notification
> > > function will break. (It may even hang, if the busy wait never
> > > completes.)
> > >
> > >
> > > UEFI drivers for 

[edk2] [Patch 2/2] NetworkPkg/IScsiDxe: Add check to avoid use NULL pointer

[Jiaxin Wu]

Cc: Wu Hao A 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiConfig.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 3382982..62df367 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -3594,10 +3594,14 @@ IScsiFormCallback (
 
 case KEY_IP_MODE:
   switch (Value->u8) {
   case IP_MODE_IP6:
 NicInfo = IScsiGetNicInfoByIndex (Private->Current->NicIndex); 
+if(NicInfo == NULL) {
+  break;
+}
+
 if(!NicInfo->Ipv6Available) {  
  //
   // Current NIC doesn't Support IPv6, hence use IPv4.
   //
   IfrNvData->IpMode = IP_MODE_IP4;
-- 
1.9.5.msysgit.1

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

[edk2] [Patch 1/2] NetworkPkg/HttpBootDxe: Add check to avoid use NULL pointer

[Jiaxin Wu]

Cc: Wu Hao A 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/HttpBootDxe/HttpBootDxe.c | 50 +++-
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c 
b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
index b1f9042..8a61f51 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
@@ -613,23 +613,25 @@ HttpBootIp4DxeDriverBindingStart (
   }
   
   return EFI_SUCCESS;
 
 ON_ERROR:
-  if (FirstStart) {
-gBS->UninstallProtocolInterface (
-   ControllerHandle,
-   ,
-   >Id
-   );
-  }
-  
-  HttpBootDestroyIp4Children (This, Private);
-  HttpBootConfigFormUnload (Private);
+  if (Private != NULL) {
+if (FirstStart) {
+  gBS->UninstallProtocolInterface (
+ ControllerHandle,
+ ,
+ >Id
+ );
+}
+
+HttpBootDestroyIp4Children (This, Private);
+HttpBootConfigFormUnload (Private);
 
-  if (FirstStart && Private != NULL) {
-FreePool (Private);
+if (FirstStart) {
+  FreePool (Private);
+}
   }
 
   return Status;
 }
 
@@ -1142,23 +1144,25 @@ HttpBootIp6DxeDriverBindingStart (
   }
 
   return EFI_SUCCESS;

 ON_ERROR:
-  if (FirstStart) {
-gBS->UninstallProtocolInterface (
-   ControllerHandle,
-   ,
-   >Id
-   );
-  }
+  if (Private != NULL) {
+if (FirstStart) {
+  gBS->UninstallProtocolInterface (
+ ControllerHandle,
+ ,
+ >Id
+ );
+}
 
-  HttpBootDestroyIp6Children(This, Private);
-  HttpBootConfigFormUnload (Private);
+HttpBootDestroyIp6Children(This, Private);
+HttpBootConfigFormUnload (Private);
 
-  if (FirstStart && Private != NULL) {
-FreePool (Private);
+if (FirstStart) {
+  FreePool (Private);
+}
   }
 
   return Status;
 }
 
-- 
1.9.5.msysgit.1

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

[edk2] [Patch 0/2] Add check to avoid use NULL pointer

[Jiaxin Wu]

Cc: Wu Hao A 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  NetworkPkg/HttpBootDxe: Add check to avoid use NULL pointer
  NetworkPkg/IScsiDxe: Add check to avoid use NULL pointer

 NetworkPkg/HttpBootDxe/HttpBootDxe.c | 50 +++-
 NetworkPkg/IScsiDxe/IScsiConfig.c|  4 +++
 2 files changed, 31 insertions(+), 23 deletions(-)

-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH] MdePkg/Include: fix incorrect structure definition

[Gao, Liming]

Chris:
  Ni, Ruiyu has sent this patch yesterday. 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Chris Ruffin
>Sent: Friday, October 27, 2017 9:04 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [PATCH] MdePkg/Include: fix incorrect structure definition
>
>Fix incorrect structure definitions for PCI_REG_PCIE_SLOT_CONTROL in
>PciExpress21.h.
>
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Chris Ruffin 
>---
> MdePkg/Include/IndustryStandard/PciExpress21.h | 24 ---
>-
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
>diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
>b/MdePkg/Include/IndustryStandard/PciExpress21.h
>index ce9c06a7c6..d90b5975ba 100644
>--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
>+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
>@@ -182,18 +182,18 @@ typedef union {
>
> typedef union {
>   struct {
>-UINT32 AttentionButtonPressed : 1;
>-UINT32 PowerFaultDetected : 1;
>-UINT32 MrlSensorChanged : 1;
>-UINT32 PresenceDetectChanged : 1;
>-UINT32 CommandCompletedInterrupt : 1;
>-UINT32 HotPlugInterrupt : 1;
>-UINT32 AttentionIndicator : 2;
>-UINT32 PowerIndicator : 2;
>-UINT32 PowerController : 1;
>-UINT32 ElectromechanicalInterlock : 1;
>-UINT32 DataLinkLayerStateChanged : 1;
>-UINT32 Reserved : 3;
>+UINT16 AttentionButtonPressed : 1;
>+UINT16 PowerFaultDetected : 1;
>+UINT16 MrlSensorChanged : 1;
>+UINT16 PresenceDetectChanged : 1;
>+UINT16 CommandCompletedInterrupt : 1;
>+UINT16 HotPlugInterrupt : 1;
>+UINT16 AttentionIndicator : 2;
>+UINT16 PowerIndicator : 2;
>+UINT16 PowerController : 1;
>+UINT16 ElectromechanicalInterlock : 1;
>+UINT16 DataLinkLayerStateChanged : 1;
>+UINT16 Reserved : 3;
>   } Bits;
>   UINT16   Uint16;
> } PCI_REG_PCIE_SLOT_CONTROL;
>--
>2.13.3.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Yao, Jiewen]

I think the error might be PCI device specific.

BTW: We already have bugzillar on that 
https://bugzilla.tianocore.org/show_bug.cgi?id=739

It has been validated by Microsoft. We can validate more device cards to see if 
there is any issue.

Thank you
Yao Jiewen

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, October 27, 2017 8:54 AM
> To: Yao, Jiewen ; Laszlo Ersek ;
> Zeng, Star ; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> 
> Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> Jiewen,
> If the BME bit is cleared in Command register, but a device driver
> uses DMA to transfer data, what kind of error will be seen by SW?
> 
> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, October 27, 2017 8:34 AM
> To: Laszlo Ersek ; Zeng, Star ;
> edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard Biesheuvel 
> ;
> Kinney, Michael D 
> Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> Good Info. I think a correct implementation should not use busy wait.
> 
> It should add error handling to check if there is hardware error during that.
> 
> > - busy wait (poll) unil the transfer is complete,
> 
> The process of busy wait should be something like below:
>   while(TRUE) {
> if (error) {
>   break;
> }
> GetData
> if (complete) {
>   Break
> }
>   }
> 
> BME clear will trigger error break.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, October 26, 2017 11:07 PM
> > To: Yao, Jiewen ; Zeng, Star
> > ; edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Ard Biesheuvel
> > ; Kinney, Michael D
> > 
> > Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event
> > TPL to CALLBACK.
> >
> > On 10/26/17 15:36, Yao, Jiewen wrote:
> > > Hi Laszlo
> > > I have discussed this with Mike Kinney offline and some Microsoft 
> > > engineers.
> > >
> > > We believe the impact of BME disable is different with the impact of SEV.
> > >
> > > For SEV, if a DMA buffer is in transition when SEV bit change, the
> > > DMA will still
> > be active, but the content is different. It will bring wrong data from
> > device perspective.
> > >
> > > For BME, if a DMA buffer is in transition when BME is clear, the DMA
> > > will be
> > stopped immediately. The device only sees the DMA transition is abort.
> > But there is no wrong data transmitted.
> >
> > I agree with the above analysis.
> >
> > > Because of above reason, we think it is OK to let PCI bus driver to
> > > clear BME bit
> > even there is active DMA transaction.
> >
> > The reason why I believe that the PciBusDxe driver should not clear
> > the BME bit is different. It is unrelated to SEV.
> >
> > Imagine a PCI device that requires a special DMA transfer before it
> > can be quiesced at ExitBootServices(). The vendor of this device will
> > implement an EBS notification function like this:
> >
> > - check the private data structure to see if the device needs the
> > special DMA transfer
> >
> > - initiate the special DMA transfer -- write some data to a preallocated
> >   and pre-programmed memory buffer, and then push the doorbell in MMIO
> >   or config space,
> >
> > - busy wait (poll) unil the transfer is complete,
> >
> > - clear BME (as required by the DWG / spec)
> >
> > - done
> >
> > Now, if PciBusDxe introduces its own EBS notification function, which
> > iterates over all the PciIo instances, and clears the BME bit in each
> > command register, then this notification function may, or may not, be
> > queued before the other one that I described above.
> >
> > If the PciBusDxe function is queued "after", then everything is fine.
> > If it is queued "before", then the driver's own notification function
> > will break. (It may even hang, if the busy wait never completes.)
> >
> >
> > UEFI drivers for PCI devices are currently not forbidden from doing a
> > quick CommonBuffer DMA transfer in their EBS callbacks (as long as
> > they don't allocate or release memory -- but the memory buffer and the
> > corresponding CommonBuffer mapping are not hard to set up in advance,
> > for example in DriverBindingStart()).
> >
> > This means that any automated IOMMU deactivation, and/or BME clearing
> > in PciBusDxe, should occur only after the individual driver callbacks
> > have returned. If PciBusDxe can guarantee this, then I have no
> > objections :)
> >
> > Thanks!
> > Laszlo
> >
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > >> -Original Message-
> > >> From: Laszlo Ersek 

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Wang, Jian J]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 9:27 PM
> To: Wang, Jian J 
> Cc: Yao, Jiewen ; edk2-devel@lists.01.org; Kinney,
> Michael D ; Wolman, Ayellet
> ; Dong, Eric ; Zeng, Star
> 
> Subject: Re: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> Hi Jian,
> 
> On 10/26/17 09:38, Wang, Jian J wrote:
> > Thanks for the feedback.
> >
> >> -Original Message-
> >> From: Yao, Jiewen
> >> Sent: Thursday, October 26, 2017 2:49 PM
> >> To: Wang, Jian J ; edk2-devel@lists.01.org
> >> Cc: Kinney, Michael D ; Wolman, Ayellet
> >> ; Dong, Eric ; Zeng, Star
> >> ; Yao, Jiewen 
> >> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> >>
> >> That is great work. Jian.
> >>
> >> Some suggestion for your consideration:
> >>
> >> 0) I suggest add Laszlo to review SMM part, and add Ruiyu to review
> >> SMM_MEMORY_ATTRIBUTE_PROTOCOL.
> >>
> >
> > Ok, already pinged them.
> >
> >> 1) Would you please mention what test we have done for this feature?
> >> Such as OVMF/realPlatform? IA32/X64?
> >>
> >
> > I did following test:
> >
> > Boot to shell (OVMF/Intel platform) (both IA32 and X64)
> > Boot to Fedora 25 (64 only)
> 
> May I ask if you used KVM virtualization (i.e., a Linux host computer)
> for this?
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-
> QEMU,-KVM-and-libvirt
> 

No, I'm using Qemu on Windows. I think Qemu doesn't support VM on Windows
machine but I do enabled SMM mode for it. Please let me know if there's any 
differences between them I should be aware of.

> > Windows 10 boot loader has a limit of 512-memory-descriptor, which will
> > cause boot failure. This is due to a fact that enabling this feature will 
> > cause
> > more memory fragments (pool memory). Since this is a debug feature, I
> suppose
> > this is an acceptable result.
> 
> This feature is large; I can't even attempt to review it in the time
> that I could allocate to it.
> 
> However, I would like to regression test it (thank you Jiewen for the
> reference!) Preferably, given that a v4 is already planned, I should
> test v4.
> 
> If you can post v4 on Oct 27th (tomorrow), I'll make an effort to test
> it in the afternoon / evening, on the 27th. (Please CC me.) Next week I
> will be mostly inactive on edk2-devel -- I wouldn't like to block your
> work, but I also wouldn't like an OVMF regression.
> 

Thanks for trying. I'll try my best to send v4 today. I'd remind you in advance
I have already found heap overflow (just read) in UiApp and Openssl code.

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

Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Keep compatible with former solution.

[Dong, Eric]

Laszlo,

Update both and pushed the change at 86121874.

Thanks,
Eric

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, October 26, 2017 4:26 PM
> To: Dong, Eric ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu 
> Subject: Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Keep compatible with
> former solution.
> 
> On 10/26/17 07:59, Eric Dong wrote:
> > For some special platforms (such as Ovmf), it is possible that, some
> > APs start up *and finish* before the remaining APs not start up *at
> > all*. In this case, the enhance
> 
> (1) I think the word "not" should be removed from the above line, so that we
> get: "some APs start up *and finish* before the remaining APs [] start up *at
> all*".
> 
> (2) For the subject line: can we add "AP counting" or "AP collection"
> somehow? For example:
> 
> UefiCpuPkg/MpInitLib: Keep compatible with former AP counting solution.
> 
> 
> I don't insist, but I think these changes would improve the commit message.
> They can be implemented before pushing. Either way,
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thank you for the quick update, Eric and Jeff!
> Laszlo
> 
> > solution by changes 0594ec41 not works as expected.
> >
> > This change remove check CpuMpData->CpuCount logic to let old solution
> > still workable if platform owner still set a long time for
> > PcdCpuApInitTimeOutInMicroSeconds. It's platform owner's response to
> > decide which solution to use.
> >
> > Cc: Ruiyu Ni 
> > Cc: Laszlo Ersek 
> > Cc: Jeff Fan 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Eric Dong 
> > ---
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c | 21 +
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index 48f930b..18060fd 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -936,15 +936,20 @@ WakeUpAP (
> >  }
> >  if (CpuMpData->InitFlag == ApInitConfig) {
> >//
> > -  // Wait for one potential AP waken up in one specified period
> > +  // Here support two methods to collect AP count through adjust
> > +  // PcdCpuApInitTimeOutInMicroSeconds values.
> >//
> > -  if (CpuMpData->CpuCount == 0) {
> > -TimedWaitForApFinish (
> > -  CpuMpData,
> > -  PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
> > -  PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
> > -  );
> > -  }
> > +  // one way is set a value to just let the first AP to start the
> > +  // initialization, then through the later while loop to wait all Aps
> > +  // finsh the initialization.
> > +  // The other way is set a value to let all APs finished the 
> > initialzation.
> > +  // In this case, the later while loop is useless.
> > +  //
> > +  TimedWaitForApFinish (
> > +CpuMpData,
> > +PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
> > +PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
> > +);
> >
> >while (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) {
> >  CpuPause();
> >
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP initialization logic.

[Dong, Eric]

Brian,

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Brian J. Johnson
> Sent: Friday, October 27, 2017 4:48 AM
> To: Dong, Eric ; Laszlo Ersek ;
> edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Paolo Bonzini 
> Subject: Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for
> AP initialization logic.
> 
> On 10/25/2017 08:13 PM, Dong, Eric wrote:
> > Laszlo,
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Wednesday, October 25, 2017 11:08 PM
> >> To: Dong, Eric ; edk2-devel@lists.01.org
> >> Cc: Ni, Ruiyu ; Paolo Bonzini
> >> 
> >> Subject: Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting
> >> for AP initialization logic.
> >>
> >> Hi Eric,
> >>
> >> On 10/25/17 07:42, Dong, Eric wrote:
> >>> Hi Laszlo,
> >>>
> >>> I think I have clear about your raised issues for Ovmf platform. In
> >>> this case, I
> >> think your platform not suit for this code change.  How about I do
> >> below change based on the new code:
> >>>
> >>> -  if (CpuMpData->CpuCount == 0) {
> >>>  TimedWaitForApFinish (
> >>>CpuMpData,
> >>>PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
> >>>PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
> >>>);
> >>> -  }
> >>>
> >>> After this change, for Ovmf can still set
> >>> PcdCpuApInitTimeOutInMicroSeconds to MAX_UINT32 to keep old
> >> solution.
> >>> For the real platform, it can set a small value to follow the new
> >>> solution. For this new change, it just wait one more
> >>> PcdCpuApInitTimeOutInMicroSeconds timeout, should not have
> >> performance
> >>> impact (This time may also been cost in later while
> >>> (CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) loop) or
> have
> >>> litter performance impact (not cover by the later loop).
> >> The suggested change will work for OVMF, thanks!
> >>
> >> (Just please don't forget to un-indent the TimedWaitForApFinish()
> >> call that will become unconditional again.)
> >>
> >> --o--
> >>
> >> Do you think Brian's concern should be investigated as well (perhaps
> >> in a separate Bugzilla entry)?
> >
> > As Jeff has mentioned, only Ovmf can know the exist Ap numbers before
> > send the Init-sipi-sipi.  So we don't know how many bits needed for this
> bitmap.
> > In case we can create the bitmap, we still don't know when all Aps have
> been
> >   found(If the begin map bit value same as finish map bit value, we
> > still can't get the conclusion that all Aps have been found, because
> > maybe other Aps not started yet).
> >
> 
> Right, physical platforms don't usually know the number of CPUs up front, so
> they still need a timeout.  That's unavoidable.  But we've seen cases where
> interrupts aren't getting delivered reliably, so not all the expected CPUs 
> start
> up (based on the core counts in the physical sockets, as known by the
> developing engineer, not the firmware.)  To debug this failure, it's very
> useful to have a list of exactly which CPUs did start.
> 
> Similarly, we've seen cases where a CPU starts, but crashes due to h/w or
> s/w bugs before signaling the BSP that it has finished.  With only a counter 
> to
> indicate how many CPUs are still running, it's impossible to tell which CPUs
> failed.  That makes debugging much more difficult.
> 
> The bitmaps would need to be sized according to the maximum number of
> CPUs supported by the platform (or the maximum APIC ID, depending on
> how they are indexed), like other data structures in the MpCpu code.
> 
> Bitmaps aren't the only possible implementation of course  My point is
> that it's useful to have a list of which CPUs started executing, and which
> finished.
> 

Seems this is not a must have item for this patch related issue. I think you 
can submit
A bugz for this debug feature.

Thanks,
Eric

> > Thanks,
> > Eric
> >>
> >> Because, I believe, the scheduling pattern that I described earlier
> >> could be possible on physical platforms as well, at least in theory:
> >>
>  (2) After at least one AP has started running, the logic expects
>  "NumApsExecuting" to monotonically grow for a while, and then to
>  monotonically decrease, back to zero. For example, if we have 1 BSP
>  and
>  7 APs, the BSP logic more or less expects the following values in
>  "NumApsExecuting":
> 
>  1; 2; 3; 4; 5; 6; 7;
>  6; 5; 4; 3; 2; 1; 0
> 
> 
>  While this may be a valid expectation for physical processors
>  (which actually run in parallel, in the physical world), in a
>  virtual machine, it is not
> >> guaranteed.
>  Dependent on hypervisor scheduling artifacts, it is possible that,
>  say, three APs start up *and finish* before the remaining four 

Re: [edk2] Adding VLAN changing Boot order to default

[Wu, Jiaxin]

Hi Karunakar,

I guess you configure the VLAN on the NIC that PXE boot option selected. If so, 
that's the expect behavior since the VLAN callback function will destroy the 
previous NIC info including the MNP service data, then PXE driver binding 
stop/start will be called again to update the device path.

Thanks,
Jiaxin



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Karunakar P
> Sent: Thursday, October 26, 2017 10:55 PM
> To: 'edk2-devel@lists.01.org' 
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin 
> Subject: Re: [edk2] Adding VLAN changing Boot order to default
> 
> Could you please provide your comments.
> 
> Thank You,
> Karunakar
> 
> From: Karunakar P
> Sent: Monday, October 23, 2017 8:38 PM
> To: 'edk2-devel@lists.01.org'
> Cc: Wu, Jiaxin; 'Fu, Siyuan'; Ye, Ting
> Subject: RE: Adding VLAN changing Boot order to default
> 
> Hello All,
> 
> Boot order is changing to default if we add VLAN, below are the steps
> followed.
> 
> [Steps]
> 
> 1.   Change default boot order to some other, Then Commit changes and
> Exit. (In my case first boot option Is UEFI Internal Shell, then I changed 
> PXEv4
> as first boot option)
> 
> 2.   Add a VLAN
> 
> Network Device List -> MAC -> VLAN Configuration -> Create new VLAN and
> Add VLAN
> 
> 3.   Now check the Boot order
> 
> Observation:- The boot order was changed to default(In my case, UEFI
> Internal shell becomes first boot option)
> 
> Could you please provide your comments on this?
> 
> Thanks,
> Karunakar
> ___
> 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] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 6:08 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric 
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> Hello Jian,
> 
> On 10/23/17 08:50, Jian J Wang wrote:
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > Cc: Eric Dong 
> > Cc: Jiewen Yao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> Thank you again for the explanation elsewhere in this thread. I filed
> the following TianoCore Bugzilla entry about this issue, and assigned it
> to you:
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=753
> 
> Can you please read the BZ, and add corrections (in further comments) if
> you think any such are necessary?
> 
> I suggest that the BZ reference be included in the commit message. (If
> there is no v2 necessary for this patch, then Eric can do that as well,
> when he commits / pushes your patch.)
> 

You're welcome. Those information should have been provided at the very 
beginning. 
I think I have a lot to learn from you to do better for open source community. 
Like the
Bugzilla entry. I'd say this is the best description I've ever read.

> I think the patch is good, but I have one technical question below:
> 
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..0802464b9d 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -829,6 +829,15 @@ RefreshGcdMemoryAttributesFromPaging (
> >  // Sync real page attributes to GCD
> >  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
> >  MemorySpaceLength = MemorySpaceMap[Index].Length;
> > +Capabilities  = MemorySpaceMap[Index].Capabilities |
> > +EFI_MEMORY_PAGETYPE_MASK;
> > +Status = gDS->SetMemorySpaceCapabilities (
> > +BaseAddress,
> > +MemorySpaceLength,
> > +Capabilities
> > +);
> > +ASSERT_EFI_ERROR (Status);
> > +
> 
> This logic -- i.e. the addition of the EFI_MEMORY_PAGETYPE_MASK
> capabilities -- will be applied to *all* GCD memory space map entries
> that have a type different from "EfiGcdMemoryTypeNonExistent".
> 
> I wonder if that's a good idea -- for example I don't think it makes
> much sense for "EfiGcdMemoryTypeMemoryMappedIo".
> 
> How about the following alternatives:
> 
> (1) *Either* restrict this capability addition to
> EfiGcdMemoryTypeSystemMemory (and maybe some other GCD types as well?),
> 
> (2) *or*, remove this change, and:
> 
> >  while (MemorySpaceLength > 0) {
> >if (PageLength == 0) {
> >  PageEntry = GetPageTableEntry (, BaseAddress,
> );
> > @@ -846,7 +855,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >  if (Attributes != (MemorySpaceMap[Index].Attributes &
> EFI_MEMORY_PAGETYPE_MASK)) {
> >DoUpdate = TRUE;
> >Attributes |= (MemorySpaceMap[Index].Attributes &
> ~EFI_MEMORY_PAGETYPE_MASK);
> > -  Capabilities = Attributes | MemorySpaceMap[Index].Capabilities;
> >  } else {
> >DoUpdate = FALSE;
> >  }
> > @@ -854,8 +862,8 @@ RefreshGcdMemoryAttributesFromPaging (
> >
> >Length = MIN (PageLength, MemorySpaceLength);
> >if (DoUpdate) {
> > -gDS->SetMemorySpaceCapabilities (BaseAddress, Length, 
> > Capabilities);
> > -gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attributes);
> > +Status = gDS->SetMemorySpaceAttributes (BaseAddress, Length,
> Attributes);
> > +ASSERT_EFI_ERROR (Status);
> >  DEBUG ((DEBUG_INFO, "Update memory space attribute: [%02d] %016lx
> - %016lx (%08lx -> %08lx)\r\n",
> >   Index, BaseAddress, BaseAddress + Length - 1,
> >   MemorySpaceMap[Index].Attributes, 
> > Attributes));
> >
> 
> keep the SetMemorySpaceCapabilities() call here, but use the following
> arguments instead:
> 
>   MemorySpaceMap[Index].BaseAddress
>   MemorySpaceMap[Index].Length
> 
> This will ensure that the capabilities are changed on the *entire*
> containing GCD memory space entry, and no entry splitting will take
> place.
> 
> Yes, it is possible that the SetMemorySpaceCapabilities() function will
> be invoked multiple times, on the same GCD memory space entry, but
> that's not a problem, IMO. The Capabilities value (bitmask) should be
> the exact same.
> 
> In fact, 

[edk2] [platforms: PATCH v2 10/10] Marvell/Drivers: XenonDxe: Do not modify FIFO default values

[Marcin Wojtas]

Changing controller's FIFO default values is not necessary and
possibly can cause instabilities, when using some devices.
Disable the modification and rely on initial settings.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
index 31f207e..6bbe5bc 100755
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
@@ -44,20 +44,6 @@ XenonReadVersion (
   SdMmcHcRwMmio (PciIo, SD_BAR_INDEX, SD_MMC_HC_CTRL_VER, TRUE, 
SDHC_REG_SIZE_2B, ControllerVersion);
 }
 
-STATIC
-VOID
-XenonSetFifo (
-  IN EFI_PCI_IO_PROTOCOL   *PciIo
-  )
-{
-  UINTN Data;
-
-  // Set FIFO_RTC, FIFO_WTC, FIFO_CS and FIFO_PDLVMC
-  Data = SDHC_SLOT_FIFO_DEFAULT_CONFIG;
-
-  SdMmcHcRwMmio (PciIo, SD_BAR_INDEX, SDHC_SLOT_FIFO_CTRL, FALSE, 
SDHC_REG_SIZE_4B, );
-}
-
 // Auto Clock Gating
 STATIC
 VOID
@@ -634,8 +620,6 @@ XenonInit (
   // Read XENON version
   XenonReadVersion (PciIo, >ControllerVersion);
 
-  XenonSetFifo (PciIo);
-
   // Disable auto clock generator
   XenonSetAcg (PciIo, FALSE);
 
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 03/10] Marvell/Drivers: MvI2cDxe: Reduce bus occupation time

[Marcin Wojtas]

From: David Greeson 

During each transaction start, clearing the I2C_CONTROL_FLAG
was surrounded by 3 uncoditional stalls. This was not necessary,
so replace them with one busy-wait loop, whose polling
count could be also safely reduced.

Above improvements result in faster transfer initialization
and allow to reduce the I2C bus occupation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: David Greeson 
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 6 +-
 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h | 2 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
index a62383f..d6f590d 100755
--- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
+++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
@@ -243,9 +243,8 @@ MvI2cClearIflg (
  IN I2C_MASTER_CONTEXT *I2cMasterContext
  )
 {
-  gBS->Stall(I2C_OPERATION_TIMEOUT);
+  MvI2cPollCtrl (I2cMasterContext, I2C_OPERATION_TIMEOUT, I2C_CONTROL_IFLG);
   MvI2cControlClear(I2cMasterContext, I2C_CONTROL_IFLG);
-  gBS->Stall(I2C_OPERATION_TIMEOUT);
 }
 
 /* Timeout is given in us */
@@ -295,9 +294,6 @@ MvI2cLockedStart (
 MvI2cClearIflg(I2cMasterContext);
   }
 
-  /* Without this delay we Timeout checking IFLG if the Timeout is 0 */
-  gBS->Stall(I2C_OPERATION_TIMEOUT);
-
   if (MvI2cPollCtrl(I2cMasterContext, Timeout, I2C_CONTROL_IFLG)) {
 DEBUG((DEBUG_ERROR, "MvI2cDxe: Timeout sending %sSTART condition\n",
 Mask == I2C_STATUS_START ? "" : "repeated "));
diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h 
b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
index 028fd54..3c9beaf 100644
--- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
+++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
@@ -68,7 +68,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 #define I2C_SOFT_RESET0x1c
 #define I2C_TRANSFER_TIMEOUT 1
-#define I2C_OPERATION_TIMEOUT 1000
+#define I2C_OPERATION_TIMEOUT 100
 
 #define I2C_UNKNOWN0x0
 #define I2C_SLOW   0x1
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 00/10] Armada 7k/8k - misc improvements pt.2

[Marcin Wojtas]

Hi,

I present you a second version of the patchset with post review
fixes and improvements. 9/10 patch was completely changed -
the diff is bigger, but such generic clock handling gives some chances
to benefit if we want to merge Xenon support with original EDK2
SdMmc driver in future. More details can be found in the commit logs and
a changelog below.

The patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/misc-upstream-r20171027

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Changelog:
v1 -> v2:
1/10
  - remove unrelated style fix
  - fix style around modified functions calls

2/10
  - leave original EFI_SUCCESS assignment

6/10
  - use descriptively named temporary variable for pin index in a loop

7/10
  - use single flag for link up/down
  - simplify logic
  - correct style

8/10
  - mention missing SDR25 in a commit message

9/10
  - use new member of SD_MMC_HC_PRIVATE_DATA
to set actual input clock speed and use it for the output
clock configuration
  - rewrite commit message

3/10, 4/10, 5/10, 10/10
  - add RB's

Ard Biesheuvel (2):
  Marvell/Library: MppLib: Disable the stack protector
  Marvell/Library: MppLib: Take 0xFF placeholders into account

David Greeson (2):
  Marvell/Drivers: MvI2cDxe: Abort transaction immediately upon fail
  Marvell/Drivers: MvI2cDxe: Reduce bus occupation time

Joe Zhou (1):
  Marvell/Library: MppLib: Prevent overwriting PCD values

Marcin Wojtas (5):
  Marvell/Drivers: MvI2cDxe: Fix returning status in MvI2cStartRequest
  Marvell/Drivers: Pp2Dxe: Change settings for the always-up link
  Marvell/Drivers: XenonDxe: Fix UHS signalling mode setting
  Marvell/Drivers: XenonDxe: Allow overriding base clock frequency
  Marvell/Drivers: XenonDxe: Do not modify FIFO default values

 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c| 70 

 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h|  2 +-
 Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c  | 25 +++
 Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h  |  6 ++
 Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c|  6 +-
 Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c|  6 +-
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c  |  4 +-
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c | 13 ++--
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h |  6 ++
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c   | 22 +++---
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.h   | 12 ++--
 Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c| 16 -
 Platform/Marvell/Library/MppLib/MppLib.c| 35 +-
 Platform/Marvell/Library/MppLib/MppLib.inf  |  3 +
 14 files changed, 140 insertions(+), 86 deletions(-)

-- 
2.7.4

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

[edk2] [platforms: PATCH v2 05/10] Marvell/Library: MppLib: Disable the stack protector

[Marcin Wojtas]

From: Ard Biesheuvel 

MppLib may be used very early (in SEC), at which point stack protection
measures are more likely to cause harm than help, given that not even
the UART has been configured to the point where we can complain usefully.
So just disable it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Platform/Marvell/Library/MppLib/MppLib.inf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Platform/Marvell/Library/MppLib/MppLib.inf 
b/Platform/Marvell/Library/MppLib/MppLib.inf
index 2de9cd0..1268542 100644
--- a/Platform/Marvell/Library/MppLib/MppLib.inf
+++ b/Platform/Marvell/Library/MppLib/MppLib.inf
@@ -106,3 +106,6 @@
   gMarvellTokenSpaceGuid.PcdChip3MppSel7
 
   gMarvellTokenSpaceGuid.PcdPciESdhci
+
+[BuildOptions]
+  *_*_*_CC_FLAGS = -fno-stack-protector
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 07/10] Marvell/Drivers: Pp2Dxe: Change settings for the always-up link

[Marcin Wojtas]

Currently initial forcing link status happened for all ports, not only
marked as 'always-up'. Although this didn't actually matter for the MAC
settings, because MAC is automatically updated with PHY HW polling
feature of the controller, perform mv_gop110_fl_cfg only when
the appropriate flag is true. Also in such case, force the link as up,
using a new library routine.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c | 25 
 Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h |  6 +
 Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c   |  6 -
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c 
b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
index 53154db..c2d0199 100644
--- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
+++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
@@ -4804,6 +4804,31 @@ MvGop110PortEventsMask (
   return 0;
 }
 
+/*
+ * Sets "Force Link Pass" and "Do Not Force Link Fail" bits.
+ * This function should only be called when the port is disabled.
+ */
+VOID
+MvGop110GmacForceLinkModeSet(
+  IN PP2DXE_PORT *Port,
+  IN BOOLEAN LinkUp
+  )
+{
+  UINT32 RegVal;
+
+  RegVal = MvGop110GmacRead (Port, MVPP2_PORT_AUTO_NEG_CFG_REG);
+
+  if (LinkUp) {
+RegVal |= MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_UP_MASK;
+RegVal &= ~MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_DOWN_MASK;
+  } else {
+RegVal &= ~MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_UP_MASK;
+RegVal |= MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_DOWN_MASK;
+  }
+
+  MvGop110GmacWrite (Port, MVPP2_PORT_AUTO_NEG_CFG_REG, RegVal);
+}
+
 INT32
 MvGop110FlCfg (
   IN PP2DXE_PORT *Port
diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h 
b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
index a7011f7..3ebe294 100644
--- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
+++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
@@ -504,6 +504,12 @@ MvGop110XlgPortLinkEventMask (
   IN PP2DXE_PORT *Port
   );
 
+VOID
+MvGop110GmacForceLinkModeSet (
+  IN PP2DXE_PORT *Port,
+  IN BOOLEAN LinkUp
+  );
+
 INT32
 MvGop110FlCfg (
   IN PP2DXE_PORT *Port
diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c 
b/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
index 2827976..4a1b9d5 100644
--- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
+++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
@@ -1310,7 +1310,11 @@ Pp2DxeInitialiseController (
 NetCompConfig |= MvpPp2xGop110NetcCfgCreate(>Port);
 
 MvGop110PortInit(>Port);
-MvGop110FlCfg(>Port);
+
+if (Pp2Context->Port.AlwaysUp == TRUE) {
+  MvGop110GmacForceLinkModeSet (>Port, TRUE);
+  MvGop110FlCfg (>Port);
+}
 
 Status = gBS->CreateEvent (
  EVT_SIGNAL_EXIT_BOOT_SERVICES,
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 02/10] Marvell/Drivers: MvI2cDxe: Fix returning status in MvI2cStartRequest

[Marcin Wojtas]

In MvI2cStartRequest the status was assigned to the variable
without dereferencing a pointer. Fix it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
index b4599d2..a62383f 100755
--- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
+++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
@@ -627,7 +627,7 @@ MvI2cStartRequest (
   }
 
   if (I2cStatus != NULL)
-I2cStatus = EFI_SUCCESS;
+*I2cStatus = EFI_SUCCESS;
   if (Event != NULL)
 gBS->SignalEvent(Event);
   return EFI_SUCCESS;
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 08/10] Marvell/Drivers: XenonDxe: Fix UHS signalling mode setting

[Marcin Wojtas]

This patch fixes incorrect settings for UHS mode in
SD_MMC_HC_HOST_CTRL2 register for SDR50 and SDR25, of which
the latter was missing. This field should be set to:

0x4 for DDR52
0x2 for SDR50
0x1 for SDR25
0x0 for others.

This way EmmcSwitchToHighSpeed function is on par with Linux
set_uhs_signaling routine in the Xenon driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
index 3f73194..4d4833f 100755
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
@@ -772,6 +772,8 @@ EmmcSwitchToHighSpeed (
   if (IsDdr) {
 HostCtrl2 = BIT2;
   } else if (ClockFreq == 52) {
+HostCtrl2 = BIT1;
+  } else if (ClockFreq == 26) {
 HostCtrl2 = BIT0;
   } else {
 HostCtrl2 = 0;
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 01/10] Marvell/Drivers: MvI2cDxe: Abort transaction immediately upon fail

[Marcin Wojtas]

From: David Greeson 

Although the I2C transaction routines were prepared to
return their status, they were never used. This could
cause bus lock-up e.g. in case of failing to send a
slave address, the data transfer was attempted to be
continued anyway.

This patch fixes faulty behavior by checking transaction
status and stopping it immediately, once the fail
is detected. On the occasion fix style around modified
functions calls.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: David Greeson 
[Style adjustment and cleanup]
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 62 +---
 1 file changed, 41 insertions(+), 21 deletions(-)

diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
index d85ee0b..b4599d2 100755
--- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
+++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
@@ -565,6 +565,7 @@ MvI2cStartRequest (
   UINTN Transmitted;
   I2C_MASTER_CONTEXT *I2cMasterContext = I2C_SC_FROM_MASTER(This);
   EFI_I2C_OPERATION *Operation;
+  EFI_STATUS Status = EFI_SUCCESS;
 
   ASSERT (RequestPacket != NULL);
   ASSERT (I2cMasterContext != NULL);
@@ -574,33 +575,52 @@ MvI2cStartRequest (
 ReadMode = Operation->Flags & I2C_FLAG_READ;
 
 if (Count == 0) {
-  MvI2cStart ( I2cMasterContext,
-   (SlaveAddress << 1) | ReadMode,
-   I2C_TRANSFER_TIMEOUT
- );
+  Status = MvI2cStart (I2cMasterContext,
+ (SlaveAddress << 1) | ReadMode,
+ I2C_TRANSFER_TIMEOUT);
 } else if (!(Operation->Flags & I2C_FLAG_NORESTART)) {
-  MvI2cRepeatedStart ( I2cMasterContext,
-   (SlaveAddress << 1) | ReadMode,
-   I2C_TRANSFER_TIMEOUT
- );
+  Status = MvI2cRepeatedStart (I2cMasterContext,
+ (SlaveAddress << 1) | ReadMode,
+ I2C_TRANSFER_TIMEOUT);
 }
 
+/* I2C transaction was aborted, so stop further transactions */
+if (EFI_ERROR (Status)) {
+  MvI2cStop (I2cMasterContext);
+  break;
+}
+
+/*
+ * If sending the slave address was successful,
+ * proceed to read or write section.
+ */
 if (ReadMode) {
-  MvI2cRead ( I2cMasterContext,
-  Operation->Buffer,
-  Operation->LengthInBytes,
-  ,
-  Count == 1,
-  I2C_TRANSFER_TIMEOUT
- );
+  Status = MvI2cRead (I2cMasterContext,
+ Operation->Buffer,
+ Operation->LengthInBytes,
+ ,
+ Count == 1,
+ I2C_TRANSFER_TIMEOUT);
+  Operation->LengthInBytes = Transmitted;
 } else {
-  MvI2cWrite ( I2cMasterContext,
-   Operation->Buffer,
-   Operation->LengthInBytes,
-   ,
-   I2C_TRANSFER_TIMEOUT
-  );
+  Status = MvI2cWrite (I2cMasterContext,
+ Operation->Buffer,
+ Operation->LengthInBytes,
+ ,
+ I2C_TRANSFER_TIMEOUT);
+  Operation->LengthInBytes = Transmitted;
 }
+
+/*
+ * The I2C read or write transaction failed.
+ * Stop the I2C transaction.
+ */
+if (EFI_ERROR (Status)) {
+  MvI2cStop (I2cMasterContext);
+  break;
+}
+
+/* Check if there is any more data to be sent */
 if (Count == RequestPacket->OperationCount - 1) {
   MvI2cStop ( I2cMasterContext );
 }
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 09/10] Marvell/Drivers: XenonDxe: Allow overriding base clock frequency

[Marcin Wojtas]

Some SdMmc host controllers are run by clocks with different
frequency than it is reflected in Capabilities Register 1.
Because the bitfield is only 8 bits wide, a maximum value
that could be obtained from hardware is 255(MHz).

In case the actual frequency exceeds 255MHz, the 8-bit BaseClkFreq
member of SD_MMC_HC_SLOT_CAP structure occurs to be not sufficient
to be used for setting the clock speed in SdMmcHcClockSupply
function.

This patch adds new UINT32 array ('BaseClkFreq[]') to
SD_MMC_HC_PRIVATE_DATA structure for specifying
the input clock speed for each slot of the host controller.
All routines that are used for clock configuration are
updated accordingly.

Thanks to above the Xenon host controller driver
could be modified to configure clock speed relatively
to actual 400MHz input.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c|  4 ++--
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c  |  4 ++--
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c | 13 
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h |  6 ++
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c   | 22 
++--
 Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.h   | 12 ++-
 6 files changed, 37 insertions(+), 24 deletions(-)

diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
index 4d4833f..530a01c 100755
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
@@ -705,7 +705,7 @@ EmmcSwitchClockFreq (
   //
   // Convert the clock freq unit from MHz to KHz.
   //
-  Status = SdMmcHcClockSupply (PciIo, Slot, ClockFreq * 1000, 
Private->Capability[Slot]);
+  Status = SdMmcHcClockSupply (PciIo, Slot, ClockFreq * 1000, 
Private->BaseClkFreq[Slot]);
 
   return Status;
 }
@@ -1007,7 +1007,7 @@ EmmcSetBusMode (
 return Status;
   }
 
-  ASSERT (Private->Capability[Slot].BaseClkFreq != 0);
+  ASSERT (Private->BaseClkFreq[Slot] != 0);
   //
   // Check if the Host Controller support 8bits bus width.
   //
diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c
index 9122848..ea7eed7 100644
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdDevice.c
@@ -972,7 +972,7 @@ SdCardSetBusMode (
 return Status;
   }
 
-  Status = SdMmcHcClockSupply (PciIo, Slot, ClockFreq * 1000, *Capability);
+  Status = SdMmcHcClockSupply (PciIo, Slot, ClockFreq * 1000, 
Private->BaseClkFreq[Slot]);
   if (EFI_ERROR (Status)) {
 return Status;
   }
@@ -1144,7 +1144,7 @@ SdCardIdentification (
 goto Error;
   }
 
-  SdMmcHcInitClockFreq (PciIo, Slot, Private->Capability[Slot]);
+  SdMmcHcInitClockFreq (PciIo, Slot, Private->BaseClkFreq[Slot]);
 
   gBS->Stall (1000);
 
diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c
index 981eab5..10e15c5 100644
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.c
@@ -291,7 +291,10 @@ SdMmcPciHcEnumerateDevice (
 //
 // Reinitialize slot and restart identification process for the new 
attached device
 //
-Status = SdMmcHcInitHost (Private->PciIo, Slot, 
Private->Capability[Slot]);
+Status = SdMmcHcInitHost (Private->PciIo,
+   Slot,
+   Private->Capability[Slot],
+   Private->BaseClkFreq[Slot]);
 if (EFI_ERROR (Status)) {
   continue;
 }
@@ -617,9 +620,11 @@ SdMmcPciHcDriverBindingStart (
   Private->Capability[Slot].Sdr50 = 0;
   Private->Capability[Slot].BusWidth8 = 0;
 
-  if (Private->Capability[Slot].BaseClkFreq == 0) {
-Private->Capability[Slot].BaseClkFreq = 0xff;
-  }
+  //
+  // Override inappropriate base clock frequency from Capabilities Register 1.
+  // Actual clock speed of Xenon controller is 400MHz.
+  //
+  Private->BaseClkFreq[Slot] = XENON_MMC_MAX_CLK / 1000 / 1000;
 
   DumpCapabilityReg (Slot, >Capability[Slot]);
 
diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h 
b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h
index 6a2a279..067b9ac 100644
--- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h
+++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHcDxe.h
@@ -115,6 +115,12 @@ typedef struct {
   UINT64  MaxCurrent[SD_MMC_HC_MAX_SLOT];
 
   UINT32  ControllerVersion;
+
+  //
+  // Some controllers may require to override base clock frequency
+  // value stored in Capabilities Register 1.
+  //
+  UINT32  BaseClkFreq[SD_MMC_HC_MAX_SLOT];
 } SD_MMC_HC_PRIVATE_DATA;
 
 #define 

[edk2] [platforms: PATCH v2 06/10] Marvell/Library: MppLib: Take 0xFF placeholders into account

[Marcin Wojtas]

From: Ard Biesheuvel 

The MppSel definition PCDs contain 0xFF placeholders for values that
should be left untouched. MppLib needs to be taught how to take those
into account.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Library/MppLib/MppLib.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/Platform/Marvell/Library/MppLib/MppLib.c 
b/Platform/Marvell/Library/MppLib/MppLib.c
index 383c820..297725f 100644
--- a/Platform/Marvell/Library/MppLib/MppLib.c
+++ b/Platform/Marvell/Library/MppLib/MppLib.c
@@ -79,18 +79,24 @@ SetRegisterValue (
   BOOLEAN ReverseFlag
   )
 {
-  UINT32 i, j, CtrlVal;
+  UINT32 i, j, CtrlVal, CtrlMask, PinIndex;
   INTN Sign;
 
   Sign = ReverseFlag ? -1 : 1;
 
   for (i = 0; i < RegCount; i++) {
 CtrlVal = 0;
+CtrlMask = 0;
 for (j = 0; j < MPP_PINS_PER_REG; j++) {
-  CtrlVal |= MPP_PIN_VAL(7 * (UINTN) ReverseFlag + j * Sign,
-MppRegPcd[i][7 * (UINTN) ReverseFlag + j * Sign]);
+
+  PinIndex = 7 * (UINTN)ReverseFlag + j * Sign;
+
+  if (MppRegPcd[i][PinIndex] != 0xff) {
+CtrlVal |= MPP_PIN_VAL(PinIndex, MppRegPcd[i][PinIndex]);
+CtrlMask |= MPP_PIN_VAL(PinIndex, 0xf);
+  }
 }
-MmioWrite32 (BaseAddr + 4 * i * Sign, CtrlVal);
+MmioAndThenOr32 (BaseAddr + 4 * i * Sign, ~CtrlMask, CtrlVal);
   }
 }
 
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 04/10] Marvell/Library: MppLib: Prevent overwriting PCD values

[Marcin Wojtas]

From: Joe Zhou 

After enabling dynamic PCDs, it is possible to reconfigure
MPP during platform initialization. It occurred that due to
a faulty way of passing temporary values, information obtained
from PCDs was overwritten. This patch fixes the issue, which
on the occasion simplifies PcdToMppRegs function.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Joe Zhou 
Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Platform/Marvell/Library/MppLib/MppLib.c | 21 
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/Platform/Marvell/Library/MppLib/MppLib.c 
b/Platform/Marvell/Library/MppLib/MppLib.c
index c09acf9..383c820 100644
--- a/Platform/Marvell/Library/MppLib/MppLib.c
+++ b/Platform/Marvell/Library/MppLib/MppLib.c
@@ -74,7 +74,7 @@ STATIC
 VOID
 SetRegisterValue (
   UINT8 RegCount,
-  UINT8 **MppRegPcd,
+  UINT8 MppRegPcd[][MPP_PINS_PER_REG],
   UINTN BaseAddr,
   BOOLEAN ReverseFlag
   )
@@ -99,10 +99,10 @@ STATIC
 UINT8
 PcdToMppRegs (
   UINTN PinCount,
-  UINT8 **MppRegPcd
+  UINT8 **MppRegPcd,
+  UINT8 MppRegPcdTmp[][MPP_PINS_PER_REG]
   )
 {
-  UINT8 MppRegPcdTmp[MPP_MAX_REGS][MPP_PINS_PER_REG];
   UINT8 PcdGroupCount, MppRegCount;
   UINTN i, j, k, l;
 
@@ -125,14 +125,7 @@ PcdToMppRegs (
 for (j = 0; j < PCD_PINS_PER_GROUP; j++) {
   k = (PCD_PINS_PER_GROUP * i + j) / MPP_PINS_PER_REG;
   l = (PCD_PINS_PER_GROUP * i + j) % MPP_PINS_PER_REG;
-  MppRegPcdTmp[k][l] = MppRegPcd[i][j];
-}
-  }
-
-  /* Update input table */
-  for (i = 0; i < MppRegCount; i++) {
-for (j = 0; j < MPP_PINS_PER_REG; j++) {
-  MppRegPcd[i][j] = MppRegPcdTmp[i][j];
+  MppRegPcdTmp[k][l] = (UINT8)MppRegPcd[i][j];
 }
   }
 
@@ -191,6 +184,7 @@ MppInitialize (
   BOOLEAN ReverseFlag[MAX_CHIPS];
   UINT8 *MppRegPcd[MAX_CHIPS][MPP_MAX_REGS];
   UINT32 i, ChipCount;
+  UINT8 TmpMppValue[MPP_MAX_REGS][MPP_PINS_PER_REG];
 
   ChipCount = PcdGet32 (PcdMppChipCount);
 
@@ -203,8 +197,9 @@ MppInitialize (
   for (i = 0; i < MAX_CHIPS; i++) {
 if (i == ChipCount)
   break;
-RegCount = PcdToMppRegs (PinCount[i], MppRegPcd[i]);
-SetRegisterValue (RegCount, MppRegPcd[i], BaseAddr[i], ReverseFlag[i]);
+
+RegCount = PcdToMppRegs (PinCount[i], MppRegPcd[i], TmpMppValue);
+SetRegisterValue (RegCount, TmpMppValue, BaseAddr[i], ReverseFlag[i]);
 
 /*
  * eMMC PHY IP has its own MPP configuration.
-- 
2.7.4

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

[edk2] [PATCH] MdePkg/Include: fix incorrect structure definition

[Chris Ruffin]

Fix incorrect structure definitions for PCI_REG_PCIE_SLOT_CONTROL in
PciExpress21.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin 
---
 MdePkg/Include/IndustryStandard/PciExpress21.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h 
b/MdePkg/Include/IndustryStandard/PciExpress21.h
index ce9c06a7c6..d90b5975ba 100644
--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
@@ -182,18 +182,18 @@ typedef union {
 
 typedef union {
   struct {
-UINT32 AttentionButtonPressed : 1;
-UINT32 PowerFaultDetected : 1;
-UINT32 MrlSensorChanged : 1;
-UINT32 PresenceDetectChanged : 1;
-UINT32 CommandCompletedInterrupt : 1;
-UINT32 HotPlugInterrupt : 1;
-UINT32 AttentionIndicator : 2;
-UINT32 PowerIndicator : 2;
-UINT32 PowerController : 1;
-UINT32 ElectromechanicalInterlock : 1;
-UINT32 DataLinkLayerStateChanged : 1;
-UINT32 Reserved : 3;
+UINT16 AttentionButtonPressed : 1;
+UINT16 PowerFaultDetected : 1;
+UINT16 MrlSensorChanged : 1;
+UINT16 PresenceDetectChanged : 1;
+UINT16 CommandCompletedInterrupt : 1;
+UINT16 HotPlugInterrupt : 1;
+UINT16 AttentionIndicator : 2;
+UINT16 PowerIndicator : 2;
+UINT16 PowerController : 1;
+UINT16 ElectromechanicalInterlock : 1;
+UINT16 DataLinkLayerStateChanged : 1;
+UINT16 Reserved : 3;
   } Bits;
   UINT16   Uint16;
 } PCI_REG_PCIE_SLOT_CONTROL;
-- 
2.13.3.windows.1

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

Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid sharing it with other attempts.

[Fu, Siyuan]

Reviewed-by: Fu Siyuan 

> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, October 26, 2017 4:27 PM
> To: edk2-devel@lists.01.org
> Cc: Karunakar P ; Ye, Ting ;
> Fu, Siyuan ; Wu, Jiaxin 
> Subject: [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid
> sharing it with other attempts.
> 
> Cc: Karunakar P 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wu Jiaxin 
> ---
>  NetworkPkg/IScsiDxe/IScsiConfig.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
> b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index 3ce37c5..3382982 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -539,10 +539,11 @@ IScsiConvertAttemptConfigDataToIfrNvData (
>  IScsiIpToStr (, FALSE, IfrNvData->LocalIp);
>  CopyMem (, >SubnetMask, sizeof
> (EFI_IPv4_ADDRESS));
>  IScsiIpToStr (, FALSE, IfrNvData->SubnetMask);
>  CopyMem (, >Gateway, sizeof
> (EFI_IPv4_ADDRESS));
>  IScsiIpToStr (, FALSE, IfrNvData->Gateway);
> +ZeroMem (IfrNvData->TargetIp, sizeof (IfrNvData->TargetIp));
>  if (SessionConfigData->TargetIp.v4.Addr[0] != '\0') {
>CopyMem (, >TargetIp, sizeof
> (EFI_IPv4_ADDRESS));
>IScsiIpToStr (, FALSE, IfrNvData->TargetIp);
>  }
> 
> --
> 1.9.5.msysgit.1

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

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Ni, Ruiyu]

Jiewen,
If the BME bit is cleared in Command register, but a device driver
uses DMA to transfer data, what kind of error will be seen by SW?

-Original Message-
From: Yao, Jiewen 
Sent: Friday, October 27, 2017 8:34 AM
To: Laszlo Ersek ; Zeng, Star ; 
edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Ard Biesheuvel ; 
Kinney, Michael D 
Subject: RE: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to 
CALLBACK.

Good Info. I think a correct implementation should not use busy wait.

It should add error handling to check if there is hardware error during that.

> - busy wait (poll) unil the transfer is complete,

The process of busy wait should be something like below:
  while(TRUE) {
if (error) {
  break;
}
GetData
if (complete) {
  Break
}
  }

BME clear will trigger error break.

Thank you
Yao Jiewen

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 11:07 PM
> To: Yao, Jiewen ; Zeng, Star 
> ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard Biesheuvel 
> ; Kinney, Michael D 
> 
> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event 
> TPL to CALLBACK.
> 
> On 10/26/17 15:36, Yao, Jiewen wrote:
> > Hi Laszlo
> > I have discussed this with Mike Kinney offline and some Microsoft engineers.
> >
> > We believe the impact of BME disable is different with the impact of SEV.
> >
> > For SEV, if a DMA buffer is in transition when SEV bit change, the 
> > DMA will still
> be active, but the content is different. It will bring wrong data from 
> device perspective.
> >
> > For BME, if a DMA buffer is in transition when BME is clear, the DMA 
> > will be
> stopped immediately. The device only sees the DMA transition is abort. 
> But there is no wrong data transmitted.
> 
> I agree with the above analysis.
> 
> > Because of above reason, we think it is OK to let PCI bus driver to 
> > clear BME bit
> even there is active DMA transaction.
> 
> The reason why I believe that the PciBusDxe driver should not clear 
> the BME bit is different. It is unrelated to SEV.
> 
> Imagine a PCI device that requires a special DMA transfer before it 
> can be quiesced at ExitBootServices(). The vendor of this device will 
> implement an EBS notification function like this:
> 
> - check the private data structure to see if the device needs the 
> special DMA transfer
> 
> - initiate the special DMA transfer -- write some data to a preallocated
>   and pre-programmed memory buffer, and then push the doorbell in MMIO
>   or config space,
> 
> - busy wait (poll) unil the transfer is complete,
> 
> - clear BME (as required by the DWG / spec)
> 
> - done
> 
> Now, if PciBusDxe introduces its own EBS notification function, which 
> iterates over all the PciIo instances, and clears the BME bit in each 
> command register, then this notification function may, or may not, be 
> queued before the other one that I described above.
> 
> If the PciBusDxe function is queued "after", then everything is fine. 
> If it is queued "before", then the driver's own notification function 
> will break. (It may even hang, if the busy wait never completes.)
> 
> 
> UEFI drivers for PCI devices are currently not forbidden from doing a 
> quick CommonBuffer DMA transfer in their EBS callbacks (as long as 
> they don't allocate or release memory -- but the memory buffer and the 
> corresponding CommonBuffer mapping are not hard to set up in advance, 
> for example in DriverBindingStart()).
> 
> This means that any automated IOMMU deactivation, and/or BME clearing 
> in PciBusDxe, should occur only after the individual driver callbacks 
> have returned. If PciBusDxe can guarantee this, then I have no 
> objections :)
> 
> Thanks!
> Laszlo
> 
> >
> > Thank you
> > Yao Jiewen
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, October 26, 2017 9:07 PM
> >> To: Zeng, Star ; Yao, Jiewen 
> >> ; edk2-devel@lists.01.org
> >> Cc: Ni, Ruiyu ; Ard Biesheuvel
> 
> >> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS 
> >> Event TPL to CALLBACK.
> >>
> >> On 10/26/17 10:10, Zeng, Star wrote:
> >>> Is it security reason when IOMMU disabled and Bus Master not disabled?
> >>
> >> No, I don't think there is a security issue here.
> >>
> >> But, my previous assessment about VTdDxe was indeed wrong -- there 
> >> may be a *correctness* issue.
> >>
> >> Namely, if the IOMMU is de-activated by VTdDxe before PCI drivers 
> >> abort pending DMA, then live system RAM references in the devices 
> >> may become bogus. This is not a security issue (because 
> >> de-activating the IOMMU 

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Yao, Jiewen]

Good Info. I think a correct implementation should not use busy wait.

It should add error handling to check if there is hardware error during that.

> - busy wait (poll) unil the transfer is complete,

The process of busy wait should be something like below:
  while(TRUE) {
if (error) {
  break;
}
GetData
if (complete) {
  Break
}
  }

BME clear will trigger error break.

Thank you
Yao Jiewen

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 11:07 PM
> To: Yao, Jiewen ; Zeng, Star ;
> edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard Biesheuvel 
> ;
> Kinney, Michael D 
> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> On 10/26/17 15:36, Yao, Jiewen wrote:
> > Hi Laszlo
> > I have discussed this with Mike Kinney offline and some Microsoft engineers.
> >
> > We believe the impact of BME disable is different with the impact of SEV.
> >
> > For SEV, if a DMA buffer is in transition when SEV bit change, the DMA will 
> > still
> be active, but the content is different. It will bring wrong data from device
> perspective.
> >
> > For BME, if a DMA buffer is in transition when BME is clear, the DMA will be
> stopped immediately. The device only sees the DMA transition is abort. But 
> there
> is no wrong data transmitted.
> 
> I agree with the above analysis.
> 
> > Because of above reason, we think it is OK to let PCI bus driver to clear 
> > BME bit
> even there is active DMA transaction.
> 
> The reason why I believe that the PciBusDxe driver should not clear the
> BME bit is different. It is unrelated to SEV.
> 
> Imagine a PCI device that requires a special DMA transfer before it can
> be quiesced at ExitBootServices(). The vendor of this device will
> implement an EBS notification function like this:
> 
> - check the private data structure to see if the device needs the
> special DMA transfer
> 
> - initiate the special DMA transfer -- write some data to a preallocated
>   and pre-programmed memory buffer, and then push the doorbell in MMIO
>   or config space,
> 
> - busy wait (poll) unil the transfer is complete,
> 
> - clear BME (as required by the DWG / spec)
> 
> - done
> 
> Now, if PciBusDxe introduces its own EBS notification function, which
> iterates over all the PciIo instances, and clears the BME bit in each
> command register, then this notification function may, or may not, be
> queued before the other one that I described above.
> 
> If the PciBusDxe function is queued "after", then everything is fine. If
> it is queued "before", then the driver's own notification function will
> break. (It may even hang, if the busy wait never completes.)
> 
> 
> UEFI drivers for PCI devices are currently not forbidden from doing a
> quick CommonBuffer DMA transfer in their EBS callbacks (as long as they
> don't allocate or release memory -- but the memory buffer and the
> corresponding CommonBuffer mapping are not hard to set up in advance,
> for example in DriverBindingStart()).
> 
> This means that any automated IOMMU deactivation, and/or BME clearing in
> PciBusDxe, should occur only after the individual driver callbacks have
> returned. If PciBusDxe can guarantee this, then I have no objections :)
> 
> Thanks!
> Laszlo
> 
> >
> > Thank you
> > Yao Jiewen
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, October 26, 2017 9:07 PM
> >> To: Zeng, Star ; Yao, Jiewen ;
> >> edk2-devel@lists.01.org
> >> Cc: Ni, Ruiyu ; Ard Biesheuvel
> 
> >> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> >> CALLBACK.
> >>
> >> On 10/26/17 10:10, Zeng, Star wrote:
> >>> Is it security reason when IOMMU disabled and Bus Master not disabled?
> >>
> >> No, I don't think there is a security issue here.
> >>
> >> But, my previous assessment about VTdDxe was indeed wrong -- there may
> >> be a *correctness* issue.
> >>
> >> Namely, if the IOMMU is de-activated by VTdDxe before PCI drivers abort
> >> pending DMA, then live system RAM references in the devices may become
> >> bogus. This is not a security issue (because de-activating the IOMMU
> >> will grant the devices access to all of the system RAM anyway), instead
> >> it's a correctness problem: DMA read/write may now be directed to the
> >> wrong spots in RAM (if the IOMMU mappings were not 1:1 previously).
> >>
> >> So, I agree that PCI drivers should get a chance to abort pending DMA
> >> first, before the IOMMU driver removes the mappings.
> >>
> >>> Could our code have a central place to disable Bus Master? For example
> >> PciBusDxe?
> >>
> >> No, I don't think PciBusDxe is a good idea. Higher-level PCI drivers
> >> might want to do one-shot bus 

Re: [edk2] [PATCH edk2-platforms v2 08/23] Platform/SynQuacerEvalBoard: add PCI support

[Leif Lindholm]

On Thu, Oct 26, 2017 at 04:41:07PM +0100, Ard Biesheuvel wrote:
> > - Is there a good reason for leaving out Uhci/Ehci?
> 
> No not really, other than the fact that nobody is every likely to use
> it (although I suppose you could put a UHCI PCI card into a PCIe to
> PCI bridge)

Well, more likely a cheapo UHCI/EHCI chip to PCI->PCIe bridge bundled
together on a card. I've lent you a real card more messed up than
that.

> I will add them.

Thanks.

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

Re: [edk2] [PATCH edk2-platforms v2 22/23] Platform/Socionext: add support for Socionext Developer Box rev 0.1

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:46PM +0100, Ard Biesheuvel wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
>| 624 
>  Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
>| 455 ++
>  
> Platform/Socionext/DeveloperBox/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
>   |  80 +++
>  
> Platform/Socionext/DeveloperBox/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
>|  46 ++
>  
> Platform/Socionext/DeveloperBox/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
>   |  68 +++
>  
> Platform/Socionext/DeveloperBox/SystemFirmwareUpdateConfig/SystemFirmwareUpdateConfig.ini
>|  25 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
>|   2 +-
>  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareUpdateConfig/SystemFirmwareUpdateConfig.ini
>  |   2 +-
>  Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts  
>|  21 +
>  Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.inf  
>|  34 ++
>  10 files changed, 1355 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> new file mode 100644
> index ..bc3ae8eef08a
> --- /dev/null
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -0,0 +1,624 @@
> +#
> +#  Copyright (c) 2013-2014, ARM Limited. All rights reserved.
> +#  Copyright (c) 2017, Linaro 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 Section - statements that will be processed to create a Makefile.
> +#
> +
> +[Defines]
> +  PLATFORM_NAME  = DeveloperBox
> +  PLATFORM_GUID  = d32612b4-e1c5-431f-823a-fa1aa7b9deb7
> +  PLATFORM_VERSION   = 0.1
> +  DSC_SPECIFICATION  = 0x00010005

Bump.

> +  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
> +  SUPPORTED_ARCHITECTURES= AARCH64|ARM
> +  BUILD_TARGETS  = DEBUG|RELEASE
> +  SKUID_IDENTIFIER   = DEFAULT
> +  FLASH_DEFINITION   = 
> Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> +
> +[BuildOptions]
> +  RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=0
> +
> +[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +
> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> +  GCC:*_*_ARM_DLINK_FLAGS = -z common-page-size=0x1000
> +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
> +
> +[LibraryClasses.common]
> +  
> ArmPlatformLib|Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacerLib.inf
> +  ArmHvcLib|ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
> +  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> +
> +  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +
> +!if $(TARGET) == RELEASE
> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> +!else
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!endif
> +  
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> +
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
> +
> +  # Networking Requirements
> +  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
> +  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> +  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> +  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
> +
> +  # ARM Architectural Libraries
> +  
> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
> +  
> DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
> +  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
> +  ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
> 

Re: [edk2] [PATCH edk2-platforms v2 23/23] Platform/DeveloperBox: add ConsolePrefDxe driver

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:47PM +0100, Ard Biesheuvel wrote:
> In order to improve the 'out of the box' experience when booting
> this system with a monitor and keyboard attached, include the serial
> console preference driver that prevents the installer GUI to only
> appear on the serial port in this case.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 8 
>  Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 5 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index bc3ae8eef08a..735ce91bef6f 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -592,6 +592,14 @@ [Components.common]
>}
>  
>#
> +  # Console preference selection
> +  #
> +  EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf {
> +
> +  FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
> +  }
> +
> +  #
># ACPI support
>#
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> index 61481a55721f..4cbd387e0962 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
> @@ -204,6 +204,11 @@ [FV.FvMain]
>INF Silicon/Socionext/SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.inf
>  
>#
> +  # Console preference selection
> +  #
> +  INF EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf
> +
> +  #
># ACPI support
>#
>INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 21/23] Silicon/SynQuacerPciHostBridgeLib: add workaround to support 32-bit only cards

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:45PM +0100, Ard Biesheuvel wrote:
> Implement workaround suggested by Socionext to get legacy endpoints with
> 32-bit BARs working.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

This was the modification that made the Developerbox onboard AHCI
work? Worth mentioning explicitly if so. Regardless:

Reviewed-by: Leif Lindholm 

> ---
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>  | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>  
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> index 3c6eff602f74..dd6c9bf90223 100644
> --- 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> +++ 
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
> @@ -31,10 +31,13 @@
>  #define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_IO   0x2
>  #define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG0 0x4
>  #define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG1 0x5
> +#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_THBIT12
>  
>  #define IATU_REGION_CTRL_2_OFF_OUTBOUND_0   0x908
>  #define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN BIT31
>  #define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_CFG_SHIFT_MODEBIT28
> +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_MSG_CODE_32BIT0xF
> +#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_MSG_CODE_64BIT0xFF
>  
>  #define IATU_LWR_BASE_ADDR_OFF_OUTBOUND_0   0x90C
>  #define IATU_UPPER_BASE_ADDR_OFF_OUTBOUND_0 0x910
> @@ -296,8 +299,9 @@ PciInitController (
>  RootBridge->Mem.Base,
>  RootBridge->Mem.Base,
>  RootBridge->Mem.Limit - RootBridge->Mem.Base + 1,
> -IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_MEM,
> -0);
> +IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_MEM |
> +IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TH,
> +IATU_REGION_CTRL_2_OFF_OUTBOUND_0_MSG_CODE_32BIT);
>  
>// Region 1: Type 0 config space
>ConfigureWindow (DbiBase, 1,
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 20/23] Silicon/SynQuacer/AcpiTables: hide PCI domain #0

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:44PM +0100, Ard Biesheuvel wrote:
> The ACPI hack to support the broken Synopsys IP only works for endpoints,
> not for non-trivial topologies involving switches. Given that the Linaro
> developer board has a switch soldered on, there is really no way to do
> anything useful with it when booting via ACPI. On top of that, the ITS
> can only be enabled for a single RC.
> 
> So let's hide PCIe domain #0 entirely from the OS. We may be able to
> expose the USB and SATA ports at some point using another ungodly hack,
> but for now, this allows us to boot the board with unmodified installers
> and install onto NVME.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Sounds plausible, but ... Graeme?

/
Leif

> ---
>  Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl | 264 
> ++--
>  Silicon/Socionext/SynQuacer/AcpiTables/Iort.aslc   |  44 ++--
>  Silicon/Socionext/SynQuacer/AcpiTables/Mcfg.aslc   |  14 +-
>  3 files changed, 161 insertions(+), 161 deletions(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl 
> b/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl
> index fb845d2c107e..3e231e10f7dd 100644
> --- a/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl
> +++ b/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl
> @@ -25,138 +25,138 @@ DefinitionBlock("SsdtPci.aml", "SSDT", 1, "SNI", 
> "SYNQUACR", EFI_ACPI_OEM_REVISI
>  //
>  // PCI Root Complex
>  //
> -Device(PCI0)
> -{
> -Name(_HID, EISAID("PNP0A08"))   // PCI Express Root Bridge
> -Name(_CID, EISAID("PNP0A03"))   // Compatible PCI Root Bridge
> -Name(_SEG, Zero)// PCI Segment Group number
> -Name(_BBN, Zero)// PCI Base Bus Number
> -Name(_CCA, 1)   // Cache Coherency Attribute
> -
> -// PCI Routing Table
> -Name(_PRT, Package() {
> -Package () { 0x, 0, Zero, 222 },   // INTA
> -Package () { 0x, 1, Zero, 222 },   // INTB
> -Package () { 0x, 2, Zero, 222 },   // INTC
> -Package () { 0x, 3, Zero, 222 },   // INTD
> -})
> -// Root complex resources
> -Method (_CRS, 0, Serialized) {
> -Name (RBUF, ResourceTemplate () {
> -WordBusNumber ( // Bus numbers assigned to this root
> -ResourceProducer,
> -MinFixed, MaxFixed, PosDecode,
> -0,  // AddressGranularity
> -SYNQUACER_PCI_SEG0_BUSNUM_MIN,  // AddressMinimum - 
> Minimum Bus Number
> -SYNQUACER_PCI_SEG0_BUSNUM_MIN,  // AddressMaximum - 
> Maximum Bus Number
> -0,  // AddressTranslation - 
> Set to 0
> -1   // RangeLength - Number 
> of Busses
> -)
> -
> -DWordMemory ( // 32-bit BAR Windows
> -ResourceProducer, PosDecode,
> -MinFixed, MaxFixed,
> -Cacheable, ReadWrite,
> -0x, // Granularity
> -SYNQUACER_PCI_SEG0_MMIO32_MIN,  // Min Base Address
> -SYNQUACER_PCI_SEG0_MMIO32_MAX,  // Max Base Address
> -0x, // Translate
> -SYNQUACER_PCI_SEG0_MMIO32_SIZE  // Length
> -)
> -
> -QWordMemory ( // 64-bit BAR Windows
> -ResourceProducer, PosDecode,
> -MinFixed, MaxFixed,
> -Cacheable, ReadWrite,
> -0x, // Granularity
> -SYNQUACER_PCI_SEG0_MMIO64_MIN,  // Min Base Address
> -SYNQUACER_PCI_SEG0_MMIO64_MAX,  // Max Base Address
> -0x, // Translate
> -SYNQUACER_PCI_SEG0_MMIO64_SIZE  // Length
> -)
> -
> -DWordIo ( // IO window
> -ResourceProducer,
> -MinFixed,
> -MaxFixed,
> -PosDecode,
> -EntireRange,
> -0x, // Granularity
> -SYNQUACER_PCI_SEG0_PORTIO_MIN,  // Min Base Address
> -SYNQUACER_PCI_SEG0_PORTIO_MAX,  // Max Base Address
> -SYNQUACER_PCI_SEG0_PORTIO_MEMBASE,  // Translate
> -SYNQUACER_PCI_SEG0_PORTIO_SIZE, // Length
> -,
> -,
> -,
> -TypeTranslation
> -)
> - 

Re: [edk2] [PATCH edk2-platforms v2 19/23] Platform/SynQuacerEvalBoard: add signed capsule update support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:43PM +0100, Ard Biesheuvel wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
>| 20 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
>| 92 +++-
>  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
> | 80 +
>  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
>  | 46 ++
>  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptorPei.c
> | 68 +++
>  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareUpdateConfig/SystemFirmwareUpdateConfig.ini
>  | 25 ++
>  6 files changed, 328 insertions(+), 3 deletions(-)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index cb6922a5940e..78c92cbca5a2 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -120,6 +120,10 @@ [LibraryClasses.common]
>NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>  
> +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
> +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> +
>  [LibraryClasses.common.SEC]
>PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> @@ -154,7 +158,15 @@ [LibraryClasses.common.DXE_CORE]
>  [LibraryClasses.common.DXE_DRIVER]
>
> SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
>PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
> +
> +  #
> +  # Firmware update
> +  #
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
> +  
> EdkiiSystemCapsuleLib|SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> +  
> FmpAuthenticationLib|SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
> +  
> PlatformFlashAccessLib|Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.inf
> +  IniParsingLib|SignedCapsulePkg/Library/IniParsingLib/IniParsingLib.inf
>  
>#
># PCI
> @@ -580,3 +592,11 @@ [Components.common]
>  
>
> DtPlatformDtbLoaderLib|EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.inf
>}
> +
> +  #
> +  # Firmware update
> +  #
> +  
> Platform/Socionext/SynQuacerEvalBoard/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
> +  MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
> +  SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf
> +  SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index 1e3258821a8c..337486d361fc 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -27,12 +27,12 @@
>  
>  [FD.BL33_AP_UEFI]
>  BaseAddress   = 0x0820|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
> address of the Firmware in NOR Flash.
> -Size  = 0x001B|gArmTokenSpaceGuid.PcdFdSize # The size 
> in bytes of the FLASH Device
> +Size  = 0x001A|gArmTokenSpaceGuid.PcdFdSize # The size 
> in bytes of the FLASH Device
>  ErasePolarity = 1
>  
>  # This one is tricky, it must be: BlockSize * NumBlocks = Size
>  BlockSize = 0x0001
> -NumBlocks = 0x1B
> +NumBlocks = 0x1A
>  
>  
> 
>  #
> @@ -50,7 +50,7 @@ [FD.BL33_AP_UEFI]
>  #
>  
> 
>  
> -0x|0x001B
> +0x|0x001A

There are a few "could you sort please" things I could comment about
below, but this is the only thing that really looks out of place to
me. Why is this being shrunk as part of this patch? If intentional and
related, this really needs a comment in the commit message.

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

Re: [edk2] [PATCH edk2-platforms v2 18/23] Socionext/SynQuacerEvalBoard: switch to execute in place

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:42PM +0100, Ard Biesheuvel wrote:
> Now that we switched to PrePeiCore, we can execute the firmware image
> in place, using a stack and temporary heap in non-secure SRAM. This
> allows us to query the secure firmware for the size and placement of
> DRAM, and also allows the use of capsules for firmware update.
> 
> NOTE: this requires a matching change on the ARM Trusted Firmware side.

Could you fold in a repo link and a git hash to the commit doing that?

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

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index dc1e15420818..1e3258821a8c 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -26,7 +26,7 @@
>  
> 
>  
>  [FD.BL33_AP_UEFI]
> -BaseAddress   = 0xE000|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
> address of the Firmware in NOR Flash.
> +BaseAddress   = 0x0820|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
> address of the Firmware in NOR Flash.
>  Size  = 0x001B|gArmTokenSpaceGuid.PcdFdSize # The size 
> in bytes of the FLASH Device
>  ErasePolarity = 1
>  
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 17/23] Socionext/SynQuacerEvalBoard: wire up basic capsule support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:41PM +0100, Ard Biesheuvel wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 7 ++-
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf | 2 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index e1983ff43676..cb6922a5940e 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -154,6 +154,7 @@ [LibraryClasses.common.DXE_CORE]
>  [LibraryClasses.common.DXE_DRIVER]
>
> SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
>PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
> +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
>  
>#
># PCI
> @@ -178,7 +179,7 @@ [LibraryClasses.common.UEFI_APPLICATION]
>  
>  [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> -  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf
>
> ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
>  
>  
> 
> @@ -194,6 +195,8 @@ [PcdsFeatureFlag]
>gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
>gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
>  
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset|TRUE
> +
>  [PcdsFixedAtBuild.common]
>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"Linaro"
>  
> @@ -380,7 +383,9 @@ [Components.common]
>ArmPlatformPkg/PlatformPei/PlatformPeim.inf
>ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
>ArmPkg/Drivers/CpuPei/CpuPei.inf
> +  MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> +  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
>  
>
> NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index 27582be34cb4..dc1e15420818 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -237,7 +237,9 @@ [FV.FVMAIN_COMPACT]
>INF ArmPlatformPkg/PlatformPei/PlatformPeim.inf
>INF ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
>INF ArmPkg/Drivers/CpuPei/CpuPei.inf
> +  INF MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> +  INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
>INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>  
>FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 16/23] SynQuacer/SynQuacerMemoryInitPeiLib: add capsule support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:40PM +0100, Ard Biesheuvel wrote:
> Add support for dealing with capsules left in memory by the OS before
> reboot. This needs to be done early, before the memory is reused, which
> is why the initial handling must reside here.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
>| 59 +++-
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
>  | 12 
>  2 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
>  
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
> index 9359f7c320b7..a249210a3192 100644
> --- 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
> +++ 
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.c
> @@ -17,12 +17,17 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ARM_MEMORY_REGION(Base, Size) \
>{ (Base), (Base), (Size), ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK }
>  
> @@ -39,7 +44,8 @@ BuildMemoryTypeInformationHob (
>  
>  STATIC ARM_MEMORY_REGION_DESCRIPTOR mVirtualMemoryTable[] = {
>// Memory mapped SPI NOR flash
> -  ARM_UNCACHED_REGION (SYNQUACER_SPI_NOR_BASE, SYNQUACER_SPI_NOR_BASE),
> +  ARM_UNCACHED_REGION (FixedPcdGet64 (PcdFdBaseAddress),
> +   FixedPcdGet32 (PcdFdSize)),
>  
>// DDR - 2 GB
>ARM_MEMORY_REGION (SYNQUACER_SYSTEM_MEMORY_1_BASE,
> @@ -113,6 +119,12 @@ MemoryPeim (
>  {
>EFI_RESOURCE_ATTRIBUTE_TYPE   ResourceAttributes;
>RETURN_STATUS Status;
> +  EFI_PEI_SERVICES  **PeiServices;
> +  PEI_CAPSULE_PPI   *Capsule;
> +  VOID  *CapsuleBuffer;
> +  UINTN CapsuleBufferLength;
> +  EFI_STATUSEfiStatus;
> +  BOOLEAN   HaveCapsule;
>  
>ResourceAttributes =
>EFI_RESOURCE_ATTRIBUTE_PRESENT |
> @@ -140,12 +152,57 @@ MemoryPeim (
>  //SYNQUACER_SYSTEM_MEMORY_3_BASE,
>  //SYNQUACER_SYSTEM_MEMORY_3_SZ);
>  
> +  PeiServices = (EFI_PEI_SERVICES **) GetPeiServicesTablePointer ();
> +  ASSERT (PeiServices != NULL);
> +
> +  EfiStatus = PeiServicesLocatePpi (, 0, NULL,
> +(VOID **));
> +  ASSERT_EFI_ERROR (EfiStatus);
> +
> +  //
> +  // Check for persistent capsules
> +  //
> +  HaveCapsule = FALSE;
> +  EfiStatus = Capsule->CheckCapsuleUpdate (PeiServices);
> +  if (!EFI_ERROR (EfiStatus)) {
> +
> +//
> +// Coalesce the capsule into unused memory. CreateState() below will copy
> +// it to a properly allocated buffer.
> +//
> +CapsuleBuffer = (VOID *)FixedPcdGet64 (PcdSystemMemoryBase);
> +CapsuleBufferLength = UefiMemoryBase - FixedPcdGet64 
> (PcdSystemMemoryBase);
> +
> +PeiServicesSetBootMode (BOOT_ON_FLASH_UPDATE);
> +
> +EfiStatus = Capsule->Coalesce (PeiServices, ,
> +   );
> +if (!EFI_ERROR (EfiStatus)) {
> +  DEBUG ((DEBUG_INFO, "%a: Coalesced capsule @ %p (0x%lx)\n",
> +  __FUNCTION__, CapsuleBuffer, CapsuleBufferLength));
> +  HaveCapsule = TRUE;
> +} else {
> +  DEBUG ((DEBUG_WARN, "%a: failed to coalesce() capsule (Status == 
> %r)\n",
> +  __FUNCTION__, EfiStatus));
> +}
> +  }
> +
>Status = ArmConfigureMmu (mVirtualMemoryTable, NULL, NULL);
>ASSERT_EFI_ERROR (Status);
>if (EFI_ERROR (Status)) {
>  return Status;
>}
>  
> +  if (HaveCapsule) {
> +EfiStatus = Capsule->CreateState (PeiServices, CapsuleBuffer,
> +   CapsuleBufferLength);
> +
> +if (EFI_ERROR (EfiStatus)) {
> +  DEBUG ((DEBUG_WARN, "%a: Capsule->CreateState failed (Status == %r)\n",
> +  __FUNCTION__, EfiStatus));
> +}
> +  }
> +
>if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
>  // Optional feature that helps prevent EFI memory map fragmentation.
>  BuildMemoryTypeInformationHob ();
> diff --git 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
>  
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
> index 1ddaee8a9d45..d294c943d7f9 100644
> --- 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
> +++ 
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerMemoryInitPeiLib/SynQuacerMemoryInitPeiLib.inf
> @@ -36,14 +36,20 @@ [Packages]
>  [LibraryClasses]
>ArmLib
>ArmMmuLib
> +  CacheMaintenanceLib
>

Re: [edk2] [PATCH edk2-platforms v2 15/23] Silicon/SynQuacer: implement PlatformFlashAccessLib

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:39PM +0100, Ard Biesheuvel wrote:
> In order to support capsule update, implement PlatformFlashAccessLib that
> exposes write access to the UEFI NOR partition.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
>| 250 
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.inf
>  |  38 +++
>  2 files changed, 288 insertions(+)
> 
> diff --git 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
>  
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
> new file mode 100644
> index ..cb4e1eece436
> --- /dev/null
> +++ 
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPlatformFlashAccessLib/SynQuacerPlatformFlashAccessLib.c
> @@ -0,0 +1,250 @@
> +/** @file
> +  Platform flash device access library NULL instance.

!NULL!

> +
> +  Copyright (c) 2016, Intel Corporation. All rights reserved.

Linaro?

If you fold those in:
Reviewed-by: Leif Lindholm 

> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/**
> +  Gets firmware volume block handle by given address.
> +
> +  This function gets firmware volume block handle whose
> +  address range contains the parameter Address.
> +
> +  @param[in]  AddressAddress which should be contained
> + by returned FVB handle.
> +  @param[out] FvbHandle  Pointer to FVB handle for output.
> +
> +  @retval EFI_SUCCESSFVB handle successfully returned.
> +  @retval EFI_NOT_FOUND  Failed to find FVB handle by address.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +GetFvbByAddress (
> +  IN  EFI_PHYSICAL_ADDRESSAddress,
> +  OUT EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  **OutFvb,
> +  OUT EFI_PHYSICAL_ADDRESS*FvbBaseAddress
> +  )
> +{
> +  EFI_STATUS  Status;
> +  EFI_HANDLE  *HandleBuffer;
> +  UINTN   HandleCount;
> +  UINTN   Index;
> +  EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  *Fvb;
> +  EFI_FIRMWARE_VOLUME_HEADER  *FwVolHeader;
> +  EFI_FVB_ATTRIBUTES_2Attributes;
> +
> +  //
> +  // Locate all handles with Firmware Volume Block protocol
> +  //
> +  Status = gBS->LocateHandleBuffer (
> +  ByProtocol,
> +  ,
> +  NULL,
> +  ,
> +  
> +  );
> +  if (EFI_ERROR (Status)) {
> +return EFI_NOT_FOUND;
> +  }
> +  //
> +  // Traverse all the handles, searching for the one containing parameter 
> Address
> +  //
> +  for (Index = 0; Index < HandleCount; Index += 1) {
> +Status = gBS->HandleProtocol (
> +HandleBuffer[Index],
> +,
> +(VOID **) 
> +);
> +if (EFI_ERROR (Status)) {
> +  Status = EFI_NOT_FOUND;
> +  break;
> +}
> +//
> +// Checks if the address range of this handle contains parameter Address
> +//
> +Status = Fvb->GetPhysicalAddress (Fvb, FvbBaseAddress);
> +if (EFI_ERROR (Status)) {
> +  continue;
> +}
> +
> +//
> +// Check if this FVB is writable: DXE core produces FVB protocols for
> +// firmware volumes as well.
> +//
> +Status = Fvb->GetAttributes (Fvb, );
> +if (EFI_ERROR (Status) || !(Attributes & EFI_FVB2_WRITE_STATUS)) {
> +  DEBUG ((DEBUG_INFO,
> +"%a: ignoring read-only FVB protocol implementation\n",
> +__FUNCTION__));
> +  continue;
> +}
> +
> +FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *) ((UINTN) *FvbBaseAddress);
> +if ((Address >= *FvbBaseAddress) && (Address <= (*FvbBaseAddress + 
> FwVolHeader->FvLength))) {
> +  *OutFvb  = Fvb;
> +  Status   = EFI_SUCCESS;
> +  break;
> +}
> +
> +Status = EFI_NOT_FOUND;
> +  }
> +
> +  FreePool (HandleBuffer);
> +  return Status;
> +}
> +
> +/**
> +  Perform flash write operation.
> +
> +  @param[in] FirmwareType  The type of firmware.
> +  @param[in] FlashAddress  The address of flash device to be accessed.
> +  @param[in] FlashAddressType  The type of flash device address.
> +  @param[in] Buffer  

Re: [edk2] [PATCH edk2-platforms v2 13/23] Silicon/Socionext: add driver for SPI NOR flash

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:37PM +0100, Ard Biesheuvel wrote:
> From: Pipat Methavanitpong 
> 
> This imports the driver sources provided by Socionext for the FIP006
> SPI NOR flash device found on SynQuacer SoCs. It has been slightly
> tweaked to bring it up to date with the changes made on the EDK2 side
> since it was forked.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pipat Methavanitpong 
> 
> [various tweaks and bugfixes]
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Do we need Contributed-under twice?
I'm not sure that carries any legal significane anyway.

Sorry, I would love to trim the below, but there are minor comments
spread throughout.

> ---
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.dec|   31 +
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.inf|   79 ++
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Reg.h  |  244 
> 
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashBlockIoDxe.c |  138 ++
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.c| 1376 
> 
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashDxe.h|  314 
> +
>  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/NorFlashFvbDxe.c |  859 
> 
>  7 files changed, 3041 insertions(+)
> 
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.dec 
> b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.dec
> new file mode 100644
> index ..aec95bc82387
> --- /dev/null
> +++ b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.dec
> @@ -0,0 +1,31 @@
> +## @file
> +#  Socionext FIP006 High-Speed SPI Controller with NOR Flash Driver
> +#
> +#  Copyright (c) 2017, Socionext Inc. 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  = Fip006DxePkg
> +  PACKAGE_GUID  = ABC7870B-FE82-4DAD-8179-FEC5F5194FA0
> +  PACKAGE_VERSION   = 0.1
> +
> +[Guids]
> +  gFip006DxeTokenSpaceGuid  = {0x4D45399E, 0x98F9, 0x4127, {0x8F, 
> 0xB9,0xF8, 0xDE, 0x22, 0xA1, 0x09, 0x2C}}
> +
> +[PcdsFixedAtBuild]
> +  gFip006DxeTokenSpaceGuid.PcdFip006DxeRegBaseAddress|0x0|UINT32|0x0001
> +  gFip006DxeTokenSpaceGuid.PcdFip006DxeMemBaseAddress|0x0|UINT32|0x0002
> +  gFip006DxeTokenSpaceGuid.PcdN25qSlaveId|0x0|UINT8|0x0003
> +  gFip006DxeTokenSpaceGuid.PcdN25qBlockSize|256|UINT32|0x0004
> +  gFip006DxeTokenSpaceGuid.PcdN25qBlockCount|524288|UINT32|0x0005
> +
> diff --git a/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.inf 
> b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.inf
> new file mode 100644
> index ..145aeb442d90
> --- /dev/null
> +++ b/Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.inf
> @@ -0,0 +1,79 @@
> +## @file
> +#  Socionext FIP006 High-Speed SPI Controller with NOR Flash Driver
> +#
> +#  Copyright (c) 2017, Socionext Inc. All rights reserved.
> +#  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> +#
> +#  This program and the accompanying materials
> +#  are licensed and made available under the terms and conditions of the BSD 
> License
> +#  which accompanies this distribution.  The full text of the license may be 
> found at
> +#  http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +##
> +
> +
> +[Defines]
> +  INF_VERSION= 0x0001001A
> +  BASE_NAME  = Fip006Dxe
> +  FILE_GUID  = 44F7D21F-C36F-4766-BC5B-C72E97E6897B
> +  MODULE_TYPE= DXE_RUNTIME_DRIVER
> +  VERSION_STRING = 0.1
> +  ENTRY_POINT= NorFlashInitialise
> +
> +[Sources]
> +  NorFlashDxe.c
> +  NorFlashBlockIoDxe.c
> +  NorFlashFvbDxe.c

Sort?

> +
> +[Packages]
> +  ArmPlatformPkg/ArmPlatformPkg.dec
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006Dxe.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  BaseMemoryLib
> +  DebugLib
> +  DevicePathLib
> +  DxeServicesTableLib
> +  HobLib
> +  IoLib
> +  MemoryAllocationLib
> +  NorFlashPlatformLib
> +  UefiLib

Move down two rows?

Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for AP initialization logic.

[Brian J. Johnson]

On 10/25/2017 08:13 PM, Dong, Eric wrote:

Laszlo,



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Laszlo Ersek
Sent: Wednesday, October 25, 2017 11:08 PM
To: Dong, Eric ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Paolo Bonzini 
Subject: Re: [edk2] [Patch 2/2] UefiCpuPkg/MpInitLib: Enhance waiting for
AP initialization logic.

Hi Eric,

On 10/25/17 07:42, Dong, Eric wrote:

Hi Laszlo,

I think I have clear about your raised issues for Ovmf platform. In this case, I

think your platform not suit for this code change.  How about I do below
change based on the new code:


-  if (CpuMpData->CpuCount == 0) {
 TimedWaitForApFinish (
   CpuMpData,
   PcdGet32 (PcdCpuMaxLogicalProcessorNumber) - 1,
   PcdGet32 (PcdCpuApInitTimeOutInMicroSeconds)
   );
-  }

After this change, for Ovmf can still set
PcdCpuApInitTimeOutInMicroSeconds to MAX_UINT32 to keep old

solution.

For the real platform, it can set a small value to follow the new
solution. For this new change, it just wait one more
PcdCpuApInitTimeOutInMicroSeconds timeout, should not have

performance

impact (This time may also been cost in later while
(CpuMpData->MpCpuExchangeInfo->NumApsExecuting != 0) loop) or have
litter performance impact (not cover by the later loop).

The suggested change will work for OVMF, thanks!

(Just please don't forget to un-indent the TimedWaitForApFinish() call that
will become unconditional again.)

--o--

Do you think Brian's concern should be investigated as well (perhaps in a
separate Bugzilla entry)?


As Jeff has mentioned, only Ovmf can know the exist Ap numbers before
send the Init-sipi-sipi.  So we don't know how many bits needed for this bitmap.
In case we can create the bitmap, we still don't know when all Aps have been
  found(If the begin map bit value same as finish map bit value, we still can't 
get
the conclusion that all Aps have been found, because maybe other Aps not
started yet).



Right, physical platforms don't usually know the number of CPUs up 
front, so they still need a timeout.  That's unavoidable.  But we've 
seen cases where interrupts aren't getting delivered reliably, so not 
all the expected CPUs start up (based on the core counts in the physical 
sockets, as known by the developing engineer, not the firmware.)  To 
debug this failure, it's very useful to have a list of exactly which 
CPUs did start.


Similarly, we've seen cases where a CPU starts, but crashes due to h/w 
or s/w bugs before signaling the BSP that it has finished.  With only a 
counter to indicate how many CPUs are still running, it's impossible to 
tell which CPUs failed.  That makes debugging much more difficult.


The bitmaps would need to be sized according to the maximum number of 
CPUs supported by the platform (or the maximum APIC ID, depending on how 
they are indexed), like other data structures in the MpCpu code.


Bitmaps aren't the only possible implementation of course  My point 
is that it's useful to have a list of which CPUs started executing, and 
which finished.



Thanks,
Eric


Because, I believe, the scheduling pattern that I described earlier could be
possible on physical platforms as well, at least in theory:


(2) After at least one AP has started running, the logic expects
"NumApsExecuting" to monotonically grow for a while, and then to
monotonically decrease, back to zero. For example, if we have 1 BSP
and
7 APs, the BSP logic more or less expects the following values in
"NumApsExecuting":

1; 2; 3; 4; 5; 6; 7;
6; 5; 4; 3; 2; 1; 0


While this may be a valid expectation for physical processors (which
actually run in parallel, in the physical world), in a virtual machine, it is 
not

guaranteed.

Dependent on hypervisor scheduling artifacts, it is possible that,
say, three APs start up *and finish* before the remaining four APs
start up *at all*. The INIT-SIPI-SIPI marks all APs for execution /
scheduling in the hypervisor, yes, but the actual code execution may
commence a lot later. For example, the BSP may witness the following

series of values in "NumApsExecuting":


1; 2; 3;
2; 1; 0;
1; 2; 3; 4;
3; 2; 1; 0

and the BSP could think that there are 3 APs only, when it sees the
first 0 value.


I don't know if such a pattern is "likely", "unlikely", or "extremely unlikely" 
on
physical platforms. I think the pattern is "theoretically possible" at least.

I suggest that we go ahead with the small patch for the OVMF use case first,
and then open a new BZ if Brian thinks there's a real safety problem with the
code.



We also notice this theoretical problem when we implement this change, but
We think this is rarely to happen on physical platforms. We think the value for
the change is much bigger than not do this change because of this theoretical
problem.


I strongly disagree.  Any chance for it to happen on physical platforms 
is too 

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[dann frazier]

On Thu, Oct 26, 2017 at 9:48 AM, Laszlo Ersek  wrote:
> Clearing I/O port decoding in the PCI command register at
> ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx)
> machine type. (AHCI boot on "q35" is unaffected.) Windows seems repeatedly
> stuck, apparently waiting for a timeout of sorts.
>
> This is arguably a Windows bug; a native OS driver should not expect the
> firmware to leave the PCI command register in any particular state.
>
> Strictly speaking, we only need to disable BM-DMA at ExitBootServices(),
> in order to abort pending transfers to/from RAM, which is soon to be owned
> by the OS. BM-DMA is also the only bit that's explicitly named by the UEFI
> Driver Writers' Guide, for clearing at ExitBootServices().
>
> I've verified that clearing only BM-DMA fixes the isse (boot time) on
> i440fx, and does not regress q35/AHCI.

Worked for my test case (booting a Win10 install ISO in ~30s). Thanks Laszlo!

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

Re: [edk2] Xen Console input very slow in recent UEFI

[Julien Grall]

Hi Laszlo,

Thank you for your help.

On 26/10/17 16:20, Laszlo Ersek wrote:

On 10/26/17 17:13, Laszlo Ersek wrote:

Hello Julien,

On 10/26/17 13:05, Julien Grall wrote:

Hi all,

I was doing more testing of UEFI in Xen guests and noticed some slow
down when using the shell. The characters are only echoed after a second
or two that is a bit annoying.

The change that introduced this issue is 4cf3f37c87 "MdeModulePkg
SerialDxe: Process timeout consistently in SerialRead".

The Serial Driver for Xen PV console is very simple (see
OvmfPkg/Library/XenConsoleSerialPortLib). So I am not sure where the
root cause is.

Would anyone have any tips on it?


The exact same issue has been encountered earlier under QEMU, please
refer to the following sub-thread (please read it to end):

http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com

The fix was commit 5f0f5e90ae8c ("ArmVirtPkg/FdtPL011SerialPortLib: call
PL011UartLib in all SerialPortLib APIs", 2017-08-16).

I think if you can implement the same for XenConsoleSerialPortLib, that
should return to working state as well.


Hmmm, wait, at a closer look, it looks like

   OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c

already implements that suggestion? (I.e., it sets
EFI_SERIAL_INPUT_BUFFER_EMPTY in *Control as necessary?)

Are we sure the SerialPortPoll() function works correctly? I don't see
any MemoryFence() calls in SerialPortPoll(), around checking the fields
in (*mXenConsoleInterface). Could that be the problem?


I am not entirely sure. But I added a couple of MemoryFence() in 
SerialPort just in case to clear that from potential cause:


XENCONS_RING_IDX  Consumer, Producer;

if (!mXenConsoleInterface) {
return FALSE;
}

MemoryFence ();

Consumer = mXenConsoleInterface->in_cons;
Producer = mXenConsoleInterface->in_prod;

MemoryFence ();

return Consumer != Producer;

I also added some debug printk (using a different interface) to confirm 
the value of Consumer and Producer are valid.  I can see the Producer 
increasing every time a key is pressed and then soon followed by 
SerialPortRead incrementing Consumer.


I did more debugging and find out the following is happening in 
TerminalConInTimerHandler (MdeModulePkg/Universal/Console/TerminalDxe) 
when a character is received:


  1) GetControl will return EFI_SERIAL_INPUT_BUFFER_EMPTY unset
=> Entering in the loop to fetch character from the serial
  2) GetOneKeyFromSerial()
=> Return directly with the character read
  3) Looping as the fifo is not full and no error
  4) GetOneKeyFromSerial() -> SerialRead()
  	=> No more character so SerialPortPoll() will return FALSE and loop 
until timeout

=> Return EFI_TIMEOUT
  5) Exiting the loop from TerminalConInTimerHandler
  6) Characters are printed

So the step 4) will introduce the timeout seen and delay the echoing of 
the characters received.


I could see a couple of solutions to fix it:
1) Remove the timeout from SerialPortRead and rely on either
a) caller to handle timeout
b) each UART driver
	2) TerminalConInTimerHandler to check at every iteration whether the 
buffer is empty.


Any other ideas?

Cheers,

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

Re: [edk2] [PATCH edk2-platforms v2 11/23] Silicon/SynQuacer: add device tree support for eval board

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:35PM +0100, Ard Biesheuvel wrote:
> Add a device tree description of the SynQuacer SoC, and expose it for
> the SynQuacerEvalBoard platforms. This includes the menu option in the
> UEFI boot menu to switch between ACPI and DT.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Looks plausible, plus I've used it in anger.
Reviewed-by: Leif Lindholm 

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

Re: [edk2] [PATCH edk2-platforms v2 10/23] Silicon/SynQuacer: add ACPI support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:34PM +0100, Ard Biesheuvel wrote:
> Enable ACPI support for the SynQuacerEvalBoard platform: add descriptions
> of the CPUs, the GIC, the serial port, the timers and the PCIe RCs,
> including the MSI routing via the GICv3 ITS.
> 
> Note that PCIe support is limited to a single bus per RC. Anything beyond
> that is unsupported due to a limitation in the hardware that makes it
> impossible to expose the PCIe RCs in a fully ECAM compliant manner.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

I have no further comments on this, you've fixed the bits you didn't
explain to me how I was wrong about.

I'd still like to see review by someone additional. Graeme should be
back in office Monday. Graeme?

/
Leif

> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc |  15 +
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf |  14 +
>  Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl   | 294 
> 
>  Silicon/Socionext/SynQuacer/AcpiTables/AcpiTables.h  |  58 
>  Silicon/Socionext/SynQuacer/AcpiTables/AcpiTables.inf|  63 +
>  Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl  | 167 
> +++
>  Silicon/Socionext/SynQuacer/AcpiTables/Fadt.aslc |  89 ++
>  Silicon/Socionext/SynQuacer/AcpiTables/Gtdt.aslc |  98 +++
>  Silicon/Socionext/SynQuacer/AcpiTables/Iort.aslc | 164 
> +++
>  Silicon/Socionext/SynQuacer/AcpiTables/Madt.aslc | 152 ++
>  Silicon/Socionext/SynQuacer/AcpiTables/Mcfg.aslc |  63 +
>  Silicon/Socionext/SynQuacer/AcpiTables/Spcr.aslc | 127 +
>  12 files changed, 1304 insertions(+)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index 926e504ff9fd..3a7e5183093d 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -523,3 +523,18 @@ [Components.common]
>  
>DmaLib|EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
>}
> +
> +  #
> +  # ACPI support
> +  #
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> +
> +  #NULL|EmbeddedPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> +
> +
> +  # support ACPI v5.0 or later
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
> +  }
> +  MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +  Silicon/Socionext/SynQuacer/AcpiTables/AcpiTables.inf
> +  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index 658c9b83ca05..062480dda6a2 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -193,6 +193,14 @@ [FV.FvMain]
>INF NetworkPkg/HttpBootDxe/HttpBootDxe.inf
>INF Silicon/Socionext/SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.inf
>  
> +  #
> +  # ACPI support
> +  #
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +  INF RuleOverride = ACPITABLE 
> Silicon/Socionext/SynQuacer/AcpiTables/AcpiTables.inf
> +  INF 
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> @@ -329,3 +337,9 @@ [Rule.Common.UEFI_APPLICATION.BINARY]
>  UISTRING="$(MODULE_NAME)" Optional
>  VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
>}
> +
> +[Rule.Common.USER_DEFINED.ACPITABLE]
> +  FILE FREEFORM = $(NAMED_GUID) {
> +RAW ACPI   |.acpi
> +RAW ASL|.aml
> +  }
> diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl 
> b/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl
> new file mode 100644
> index ..fb845d2c107e
> --- /dev/null
> +++ b/Silicon/Socionext/SynQuacer/AcpiTables/AcpiSsdtRootPci.asl
> @@ -0,0 +1,294 @@
> +/** @file
> +  Secondary System Description Table (SSDT) for SynQuacer PCIe RCs
> +
> +  Copyright (c) 2014-2016, ARM Ltd. All rights reserved.
> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR 

Re: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Supreeth Venkatesh]

On Thu, 2017-10-26 at 11:13 +0100, Achin Gupta wrote:
> Hi Supreeth,
> 
> some CIL,
> 
> On Wed, Oct 25, 2017 at 05:32:57PM +0100, Supreeth Venkatesh wrote:
> > 
> > PI v1.5 Specification Volume 4 defines Management Mode Core
> > Interface
> > and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> > means of communicating between drivers outside of MM and MMI
> > handlers inside of MM.
> > 
> > This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime
> > driver for AARCH64 platforms. It uses SMCs allocated from the
> > standard
> > SMC range defined in
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_
> > ARM_MM_Interface_Specification.pdf
> > to communicate with the standalone MM environment in the secure
> > world.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
> > ---
> >  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339
> > +
> >  1 file changed, 339 insertions(+)
> >  create mode 100644
> > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > 
> > diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > new file mode 100644
> > index 00..ecf70e666c
> > --- /dev/null
> > +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > @@ -0,0 +1,339 @@
> > +/** @file
> > +
> > +  Copyright (c) 2016-2017, ARM Limited. All rights reserved.
> > +
> > +  This program and the accompanying materials
> > +  are licensed and made available under the terms and conditions
> > of the BSD License
> > +  which accompanies this distribution.  The full text of the
> > license may be found at
> > +  http://opensource.org/licenses/bsd-license.php
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +/**
> > +  Communicates with a registered handler.
> > +
> > +  This function provides an interface to send and receive messages
> > to the
> > +  Standalone MM environment on behalf of UEFI services.  This
> > function is part
> > +  of the MM Communication Protocol that may be called in physical
> > mode prior to
> > +  SetVirtualAddressMap() and in virtual mode after
> > SetVirtualAddressMap().
> > +
> > +  @param[in]  ThisThe
> > EFI_MM_COMMUNICATION_PROTOCOL instance.
> > +  @param[in, out] CommBuffer  A pointer to the buffer to
> > convey into MMRAM.
> > +  @param[in, out] CommSizeThe size of the data buffer
> > being passed in.On exit, the size of data
> > +  being returned. Zero if the
> > handler does not wish to reply with any data.
> > +
> > +  @retval EFI_SUCCESS The message was successfully
> > posted.
> > +  @retval EFI_INVALID_PARAMETER   The CommBuffer was NULL.
> > +  @retval EFI_BAD_BUFFER_SIZE The buffer is too large for
> > the MM implementation. If this error is
> > +  returned, the MessageLength
> > field in the CommBuffer header or the integer
> > +  pointed by CommSize are
> > updated to reflect the maximum payload size the
> > +  implementation can
> > accommodate.
> > +  @retval EFI_ACCESS_DENIED   The CommunicateBuffer
> > parameter or CommSize parameter, if not omitted,
> > +  are in address range that
> > cannot be accessed by the MM environment
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +MmCommunicationCommunicate (
> > +  IN CONST EFI_MM_COMMUNICATION_PROTOCOL  *This,
> > +  IN OUT VOID *CommBuffer,
> > +  IN OUT UINTN*CommSizeOPTIONAL
> > +  );
> > +
> > +//
> > +// Address, Length of the pre-allocated buffer for communication
> > with the secure
> > +// world.
> > +//
> > +STATIC ARM_MEMORY_REGION_DESCRIPTOR  mNsCommBuffMemRegion;
> > +
> > +// Notification event when virtual address map is set.
> > +STATIC EFI_EVENT  mSetVirtualAddressMapEvent;
> > +
> > +//
> > +// Handle to install the MM Communication Protocol
> > +//
> > +STATIC EFI_HANDLE  mMmCommunicateHandle;
> > +
> > +//
> > +// MM Communication Protocol instance
> > +//
> > +EFI_MM_COMMUNICATION_PROTOCOL  mMmCommunication = {
> > +  MmCommunicationCommunicate
> > +};
> > +
> > +/**
> > +  Communicates with a registered handler.
> > +
> > +  This function provides an interface to send and receive messages
> > to the
> > +  Standalone MM environment on behalf of UEFI services.  This
> > function is part
> > +  of 

[edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

[Laszlo Ersek]

Clearing I/O port decoding in the PCI command register at
ExitBootServices() breaks IDE boot in Windows, on QEMU's "pc" (i440fx)
machine type. (AHCI boot on "q35" is unaffected.) Windows seems repeatedly
stuck, apparently waiting for a timeout of sorts.

This is arguably a Windows bug; a native OS driver should not expect the
firmware to leave the PCI command register in any particular state.

Strictly speaking, we only need to disable BM-DMA at ExitBootServices(),
in order to abort pending transfers to/from RAM, which is soon to be owned
by the OS. BM-DMA is also the only bit that's explicitly named by the UEFI
Driver Writers' Guide, for clearing at ExitBootServices().

I've verified that clearing only BM-DMA fixes the isse (boot time) on
i440fx, and does not regress q35/AHCI.

Cc: Aleksei Kovura 
Cc: Ard Biesheuvel 
Cc: Dann Frazier 
Cc: Eric Dong 
Cc: Star Zeng 
Reported-by: Aleksei Kovura 
Reported-by: Dann Frazier 
Reported-by: https://launchpad.net/~cjkrupp
Bisected-by: Dann Frazier 
Bisected-by: https://launchpad.net/~cjkrupp
Suggested-by: Ard Biesheuvel 
Suggested-by: Star Zeng 
Ref: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1725560
Fixes: 6fb8ddd36bde45614b0a069528cdc97077835a74
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
Repo:   https://github.com/lersek/edk2.git
Branch: ata_disable_only_bmdma

 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h | 3 +--
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 5 ++---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
index 8d6eac706c0b..92c5bf2001cd 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h
@@ -123,8 +123,7 @@ typedef struct {
   LIST_ENTRYNonBlockingTaskList;
 
   //
-  // For disabling the device (especially Bus Master DMA) at
-  // ExitBootServices().
+  // For disabling Bus Master DMA on the device at ExitBootServices().
   //
   EFI_EVENT ExitBootEvent;
 } ATA_ATAPI_PASS_THRU_INSTANCE;
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
index 09064dda18b7..e10e0d4e65f6 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c
@@ -480,8 +480,7 @@ InitializeAtaAtapiPassThru (
 }
 
 /**
-  Disable the device (especially Bus Master DMA) when exiting the boot
-  services.
+  Disable Bus Master DMA on the device when exiting the boot services.
 
   @param[in] EventEvent for which this notification function is being
   called.
@@ -506,7 +505,7 @@ AtaPassThruExitBootServices (
   PciIo->Attributes (
PciIo,
EfiPciIoAttributeOperationDisable,
-   Instance->EnabledPciAttributes,
+   Instance->EnabledPciAttributes & EFI_PCI_IO_ATTRIBUTE_BUS_MASTER,
NULL
);
 }
-- 
2.14.1.3.gb7cf6e02401b

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

Re: [edk2] [PATCH edk2-platforms v2 08/23] Platform/SynQuacerEvalBoard: add PCI support

[Ard Biesheuvel]

On 26 October 2017 at 16:38, Leif Lindholm  wrote:
> On Wed, Oct 25, 2017 at 06:59:32PM +0100, Ard Biesheuvel wrote:
>> Wire up the various drivers and libraries for the SynQuacerEvalBoard
>> platform. Also enable the usual PCI suspects: XHCI, SATA and NVME,
>> and the various bus, partition and file system drivers that we need
>> to make use of PCIe devices.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>
> Comments unaddressed from v1:
> - If you're folding ChaosKey driver in here (as you are) it deserves a
>   mention in the commit message.

Ack

> - Is there a good reason for leaving out Uhci/Ehci?
>

No not really, other than the fact that nobody is every likely to use
it (although I suppose you could put a UHCI PCI card into a PCIe to
PCI bridge)

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

Re: [edk2] [PATCH edk2-platforms v2 09/23] Platform/SynQuacerEvalBoard: add NETSEC driver

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:33PM +0100, Ard Biesheuvel wrote:
> Add the NETSEC driver to the SynQuacerEvalBoard platform.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 47 
> 
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf | 25 +++
>  2 files changed, 72 insertions(+)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> index efac41837599..926e504ff9fd 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -114,6 +114,9 @@ [LibraryClasses.common]
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>PL011UartLib|ArmPlatformPkg/Drivers/PL011Uart/PL011Uart.inf
>  
> +  HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
> +  TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
> +
>NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>  
> @@ -230,6 +233,22 @@ [PcdsFixedAtBuild.common]
>gArmTokenSpaceGuid.PcdGenericWatchdogControlBase|0x2a44
>gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase|0x2a45
>  
> +  #
> +  # NETSEC Info
> +  #
> +  gNetsecDxeTokenSpaceGuid.PcdNetsecDxeBaseAddress|0x522D
> +  gNetsecDxeTokenSpaceGuid.PcdEepRomBase|0x1000
> +  gNetsecDxeTokenSpaceGuid.PcdEncTxDescNum|128
> +  gNetsecDxeTokenSpaceGuid.PcdDecRxDescNum|128
> +  gNetsecDxeTokenSpaceGuid.PcdJumboPacket|0
> +  gNetsecDxeTokenSpaceGuid.PcdFlowCtrl|0
> +  gNetsecDxeTokenSpaceGuid.PcdFlowCtrlStartThreshold|36
> +  gNetsecDxeTokenSpaceGuid.PcdFlowCtrlStopThreshold|48
> +  gNetsecDxeTokenSpaceGuid.PcdPauseTime|256
> +  gNetsecDxeTokenSpaceGuid.PcdPhyDevAddr|1
> +
> +  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
> +
>gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
> @@ -476,3 +495,31 @@ [Components.common]
># RNG
>#
>Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDxe.inf
> +
> +  #
> +  # Networking stack
> +  #
> +  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
> +  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
> +  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
> +  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
> +  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
> +  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
> +  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
> +  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
> +  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> +  NetworkPkg/TcpDxe/TcpDxe.inf
> +  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> +  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> +  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  NetworkPkg/IScsiDxe/IScsiDxe.inf
> +  NetworkPkg/DnsDxe/DnsDxe.inf
> +  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
> +  NetworkPkg/HttpDxe/HttpDxe.inf
> +  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> +  Silicon/Socionext/SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.inf {
> +
> +  DmaLib|EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
> +  }
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> index 1f85ee636dfa..658c9b83ca05 100644
> --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> @@ -168,6 +168,31 @@ [FV.FvMain]
>#
>INF Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDxe.inf
>  
> +  #
> +  # Networking stack
> +  #
> +  INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
> +  INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
> +  INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
> +  INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
> +  INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
> +  INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
> +  INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
> +  INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
> +  INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> +  INF NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> +  INF NetworkPkg/TcpDxe/TcpDxe.inf
> +  INF NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> +  INF NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> +  INF NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> +  INF NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> +  INF NetworkPkg/IScsiDxe/IScsiDxe.inf
> +  INF NetworkPkg/DnsDxe/DnsDxe.inf
> +  INF NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
> +  INF 

Re: [edk2] [PATCH edk2-platforms v2 08/23] Platform/SynQuacerEvalBoard: add PCI support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:32PM +0100, Ard Biesheuvel wrote:
> Wire up the various drivers and libraries for the SynQuacerEvalBoard
> platform. Also enable the usual PCI suspects: XHCI, SATA and NVME,
> and the various bus, partition and file system drivers that we need
> to make use of PCIe devices.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Comments unaddressed from v1:
- If you're folding ChaosKey driver in here (as you are) it deserves a
  mention in the commit message.
- Is there a good reason for leaving out Uhci/Ehci?

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

Re: [edk2] Xen Console input very slow in recent UEFI

[Laszlo Ersek]

On 10/26/17 17:13, Laszlo Ersek wrote:
> Hello Julien,
> 
> On 10/26/17 13:05, Julien Grall wrote:
>> Hi all,
>>
>> I was doing more testing of UEFI in Xen guests and noticed some slow
>> down when using the shell. The characters are only echoed after a second
>> or two that is a bit annoying.
>>
>> The change that introduced this issue is 4cf3f37c87 "MdeModulePkg
>> SerialDxe: Process timeout consistently in SerialRead".
>>
>> The Serial Driver for Xen PV console is very simple (see
>> OvmfPkg/Library/XenConsoleSerialPortLib). So I am not sure where the
>> root cause is.
>>
>> Would anyone have any tips on it?
> 
> The exact same issue has been encountered earlier under QEMU, please
> refer to the following sub-thread (please read it to end):
> 
> http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com
> 
> The fix was commit 5f0f5e90ae8c ("ArmVirtPkg/FdtPL011SerialPortLib: call
> PL011UartLib in all SerialPortLib APIs", 2017-08-16).
> 
> I think if you can implement the same for XenConsoleSerialPortLib, that
> should return to working state as well.

Hmmm, wait, at a closer look, it looks like

  OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c

already implements that suggestion? (I.e., it sets
EFI_SERIAL_INPUT_BUFFER_EMPTY in *Control as necessary?)

Are we sure the SerialPortPoll() function works correctly? I don't see
any MemoryFence() calls in SerialPortPoll(), around checking the fields
in (*mXenConsoleInterface). Could that be the problem?

Thanks,
Laszlo


> 
> ... This is why we need active Xen participants in edk2 ;)
> 
> Thanks!
> Laszlo
> 

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

Re: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver.

[Supreeth Venkatesh]

On Thu, 2017-10-26 at 05:05 +, Udit Kumar wrote:
> Hi 
> 
> > 
> > +  Status = gBS->AllocatePages (AllocateAddress,
> > +   EfiRuntimeServicesData,
> > +   EFI_SIZE_TO_PAGES
> > (mNsCommBuffMemRegion.Length),
> > +   )
> > ;
> > +  if (EFI_ERROR (Status)) {
> > +DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: Failed to
> > allocate MM-
> > NS Buffer Memory Space\n"));
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> > +  // Install the communication protocol  Status =
> > + gBS->InstallProtocolInterface (,
> > +  
> > ocolGuid,
> > +  EFI_NATIVE_INTERFACE,
> > +  );  if
> > + (EFI_ERROR(Status)) {
> > +DEBUG ((DEBUG_ERROR, "MmCommunicationInitialize: Failed to
> > install MM
> > communication protocol\n"));
> In case of error, you could free the above allocated memory 
> 
> > 
> > +return EFI_INVALID_PARAMETER;
> > +  

Thanks. Yes. It could be done. I will fix it in next version.

> Regards
> Udit 
> 
> > 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > Of
> > Supreeth Venkatesh
> > Sent: Wednesday, October 25, 2017 10:03 PM
> > To: edk2-devel@lists.01.org
> > Cc: leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> > Subject: [edk2] [PATCH v2 2/3] ArmPkg/Drivers: Add
> > EFI_MM_COMMUNICATION_PROTOCOL DXE driver.
> > 
> > PI v1.5 Specification Volume 4 defines Management Mode Core
> > Interface and
> > defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a
> > means of communicating between drivers outside of MM and MMI
> > handlers
> > inside of MM.
> > 
> > This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE
> > runtime driver for AARCH64 platforms. It uses SMCs allocated from
> > the standard
> > SMC range defined in
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fi
> > nfocen
> > ter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.den0060a%2FDEN0060A_ARM_
> > MM_Interface_Specification.pdf=02%7C01%7Cudit.kumar%40nxp.com%
> > 7
> > C43194cfd48f84756da6908d51bc6185b%7C686ea1d3bc2b4c6fa92cd99c5c3016
> > 35%7C0%7C1%7C636445460008712743=Nk9bnFSzqB4zxCcyd4C2HyqZ2a
> > Iluu%2FWKXOVho4a6g8%3D=0
> > to communicate with the standalone MM environment in the secure
> > world.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
> > ---
> >  .../Drivers/MmCommunicationDxe/MmCommunication.c   | 339
> > +
> >  1 file changed, 339 insertions(+)
> >  create mode 100644
> > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > 
> > diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > new file mode 100644
> > index 00..ecf70e666c
> > --- /dev/null
> > +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > @@ -0,0 +1,339 @@
> > +/** @file
> > +
> > +  Copyright (c) 2016-2017, 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
> > +
> > + https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2
> > Fopen
> > + source.org%2Flicenses%2Fbsd-
> > license.php=02%7C01%7Cudit.kumar%40nx
> > +
> > p.com%7C43194cfd48f84756da6908d51bc6185b%7C686ea1d3bc2b4c6fa92cd9
> > 9c5c3
> > +
> > 01635%7C0%7C0%7C636445460008712743=%2Fw7nb5B%2Bw3NKLV4v
> > 5LwcaQ0%2
> > + F6gh2Cva%2FEyDsb69NEAM%3D=0
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > BASIS,
> > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include  #include
> > 
> > +#include  #include
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +/**
> > +  Communicates with a registered handler.
> > +
> > +  This function provides an interface to send and receive messages
> > to
> > + the  Standalone MM environment on behalf of UEFI services.  This
> > + function is part  of the MM Communication Protocol that may be
> > called
> > + in physical mode prior to
> > +  SetVirtualAddressMap() and in virtual mode after
> > SetVirtualAddressMap().
> > +
> > +  @param[in]  ThisThe
> > EFI_MM_COMMUNICATION_PROTOCOL
> > instance.
> > +  @param[in, out] CommBuffer  A pointer to the buffer to
> > convey into
> > MMRAM.
> > +  @param[in, out] CommSizeThe size of the data buffer
> > being passed
> > in.On exit, the size of data
> > +  being returned. Zero if the
> > 

Re: [edk2] [PATCH edk2-platforms v2 04/23] Platform: add support for Socionext SynQuacer eval board

[Ard Biesheuvel]

On 26 October 2017 at 16:02, Leif Lindholm  wrote:
> On Wed, Oct 25, 2017 at 06:59:28PM +0100, Ard Biesheuvel wrote:
>> This is a barebones port based on the .DSC/.FDF and ArmPlatformLib
>> code provided by Socionext. It can boot into the UiApp menu screen
>> or the UEFI Shell, but lacks support for any peripherals.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   
>> | 428 
>>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf   
>> | 267 
>>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/AArch64/SynQuacerHelper.S 
>> |  87 
>>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/Arm/SynQuacerHelper.S 
>> |  87 
>>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacer.c   
>> | 125 ++
>>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacerLib.inf  
>> |  43 ++
>>  6 files changed, 1037 insertions(+)
>>
>> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
>> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
>> new file mode 100644
>> index ..b083698451a2
>> --- /dev/null
>> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
>> @@ -0,0 +1,428 @@
>> +#
>> +#  Copyright (c) 2013-2014, ARM Limited. All rights reserved.
>> +#  Copyright (c) 2017, Linaro 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 Section - statements that will be processed to create a Makefile.
>> +#
>> +
>> +[Defines]
>> +  PLATFORM_NAME  = SynQuacerEvalBoard
>> +  PLATFORM_GUID  = a8180daa-fb8b-11e5-ab24-9fc3167c073d
>> +  PLATFORM_VERSION   = 0.1
>> +  DSC_SPECIFICATION  = 0x0001001B
>> +  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
>> +  SUPPORTED_ARCHITECTURES= AARCH64|ARM
>> +  BUILD_TARGETS  = DEBUG|RELEASE
>> +  SKUID_IDENTIFIER   = DEFAULT
>> +  FLASH_DEFINITION   = 
>> Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
>> +
>> +[BuildOptions]
>> +  RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG -U_FORTIFY_SOURCE 
>> -D_FORTIFY_SOURCE=0
>> +
>> +[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
>> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
>> +
>> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>> +  GCC:*_*_ARM_DLINK_FLAGS = -z common-page-size=0x1000
>> +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
>> +
>> +[LibraryClasses.common]
>> +  
>> ArmPlatformLib|Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacerLib.inf
>> +  ArmHvcLib|ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
>> +  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
>> +
>> +  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> +
>> +!if $(TARGET) == RELEASE
>> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>> +!else
>> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>> +!endif
>> +  
>> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
>> +
>> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
>> +
>> +  # Networking Requirements
>> +  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
>> +  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
>> +  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
>> +  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
>> +
>> +  # ARM Architectural Libraries
>> +  
>> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
>> +  
>> DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
>> +  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
>> +  
>> ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
>> +  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>> +  ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
>> +  

Re: [edk2] [PATCH edk2-platforms v2 07/23] Silicon/SynQuacer: implement EFI_CPU_IO2_PROTOCOL

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:31PM +0100, Ard Biesheuvel wrote:
> The SynQuacer SOC has two separate PCIe RCs, which means there is
> no single value for the translation offset between I/O port accesses
> and MMIO accesses. So add a special implementation of EFI_CPU_IO2_PROTOCOL
> that takes the two disjoint I/O windows into account.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

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

Re: [edk2] Xen Console input very slow in recent UEFI

[Laszlo Ersek]

Hello Julien,

On 10/26/17 13:05, Julien Grall wrote:
> Hi all,
> 
> I was doing more testing of UEFI in Xen guests and noticed some slow
> down when using the shell. The characters are only echoed after a second
> or two that is a bit annoying.
> 
> The change that introduced this issue is 4cf3f37c87 "MdeModulePkg
> SerialDxe: Process timeout consistently in SerialRead".
> 
> The Serial Driver for Xen PV console is very simple (see
> OvmfPkg/Library/XenConsoleSerialPortLib). So I am not sure where the
> root cause is.
> 
> Would anyone have any tips on it?

The exact same issue has been encountered earlier under QEMU, please
refer to the following sub-thread (please read it to end):

http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com

The fix was commit 5f0f5e90ae8c ("ArmVirtPkg/FdtPL011SerialPortLib: call
PL011UartLib in all SerialPortLib APIs", 2017-08-16).

I think if you can implement the same for XenConsoleSerialPortLib, that
should return to working state as well.

... This is why we need active Xen participants in edk2 ;)

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

Re: [edk2] [PATCH edk2-platforms v2 06/23] Silicon/SynQuacer: implement PciHostBridgeLib support

[Ard Biesheuvel]

On 26 October 2017 at 16:10, Leif Lindholm  wrote:
> On Wed, Oct 25, 2017 at 06:59:30PM +0100, Ard Biesheuvel wrote:
>> Implement the glue library that exposes the PCIe root complexes to
>> the generic PCI host bridge driver. Since that driver is the first
>> one to access the PCI config space, put the low level init code for
>> the RCs into this library's constructor.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  
>> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
>> | 220 +++
>>  
>> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
>>   |  50 +++
>>  
>> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>>  | 388 
>>  3 files changed, 658 insertions(+)
>>
>> diff --git 
>> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
>>  
>> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
>> new file mode 100644
>> index ..3937e98c0213
>> --- /dev/null
>> +++ 
>> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
>> @@ -0,0 +1,220 @@
>> +/** @file
>> +  PCI Host Bridge Library instance for Socionext SynQuacer ARM SOC
>> +
>> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
>> +
>> +  This program and the accompanying materials are licensed and made 
>> available
>> +  under the terms and conditions of the BSD License which accompanies this
>> +  distribution.  The full text of the license may be found at
>> +  http://opensource.org/licenses/bsd-license.php.
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
>> WITHOUT
>> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
>> +
>> +**/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#pragma pack(1)
>> +typedef struct {
>> +  ACPI_HID_DEVICE_PATH AcpiDevicePath;
>> +  EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
>> +} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
>> +#pragma pack ()
>> +
>> +STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath[] 
>> = {
>> +  {
>> +{
>> +  {
>> +ACPI_DEVICE_PATH,
>> +ACPI_DP,
>> +{
>> +  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
>> +  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
>> +}
>> +  },
>> +  EISA_PNP_ID (0x0A08), // PCI Express
>> +  0
>> +},
>> +
>> +{
>> +  END_DEVICE_PATH_TYPE,
>> +  END_ENTIRE_DEVICE_PATH_SUBTYPE,
>> +  {
>> +END_DEVICE_PATH_LENGTH,
>> +0
>> +  }
>> +}
>> +  },
>> +  {
>> +{
>> +  {
>> +ACPI_DEVICE_PATH,
>> +ACPI_DP,
>> +{
>> +  (UINT8)(sizeof(ACPI_HID_DEVICE_PATH)),
>> +  (UINT8)(sizeof(ACPI_HID_DEVICE_PATH) >> 8)
>> +}
>> +  },
>> +  EISA_PNP_ID (0x0A08), // PCI Express
>> +  1
>> +},
>> +
>> +{
>> +  END_DEVICE_PATH_TYPE,
>> +  END_ENTIRE_DEVICE_PATH_SUBTYPE,
>> +  {
>> +END_DEVICE_PATH_LENGTH,
>> +0
>> +  }
>> +}
>> +  }
>> +};
>> +
>> +GLOBAL_REMOVE_IF_UNREFERENCED
>> +CHAR16 *mPciHostBridgeLibAcpiAddressSpaceTypeStr[] = {
>> +  L"Mem", L"I/O", L"Bus"
>> +};
>> +
>> +STATIC PCI_ROOT_BRIDGE mPciRootBridges[] = {
>> +  {
>> +0,  // Segment
>> +0,  // Supports
>> +0,  // Attributes
>> +TRUE,   // DmaAbove4G
>> +FALSE,  // NoExtendedConfigSpace
>> +FALSE,  // ResourceAssigned
>> +EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
>> +EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
>> +{ SYNQUACER_PCI_SEG0_BUSNUM_MIN,
>> +  SYNQUACER_PCI_SEG0_BUSNUM_MAX },  // Bus
>> +{ SYNQUACER_PCI_SEG0_PORTIO_MIN,
>> +  SYNQUACER_PCI_SEG0_PORTIO_MAX },  // Io
>> +{ SYNQUACER_PCI_SEG0_MMIO32_MIN,
>> +  SYNQUACER_PCI_SEG0_MMIO32_MAX },  // Mem
>> +{ SYNQUACER_PCI_SEG0_MMIO64_MIN,
>> +  SYNQUACER_PCI_SEG0_MMIO64_MAX },  // MemAbove4G
>> +{ MAX_UINT64, 0x0 },// PMem
>> +{ MAX_UINT64, 0x0 },// PMemAbove4G
>> +(EFI_DEVICE_PATH_PROTOCOL *)[0]
>> +  }, {
>> +1,  // Segment
>> +0,  // Supports
>> +0,  // Attributes
>> +TRUE,   // DmaAbove4G
>> +FALSE,  // NoExtendedConfigSpace
>> +FALSE,   

Re: [edk2] [PATCH edk2-platforms v2 06/23] Silicon/SynQuacer: implement PciHostBridgeLib support

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:30PM +0100, Ard Biesheuvel wrote:
> Implement the glue library that exposes the PCIe root complexes to
> the generic PCI host bridge driver. Since that driver is the first
> one to access the PCI config space, put the low level init code for
> the RCs into this library's constructor.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
> | 220 +++
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf
>   |  50 +++
>  
> Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c
>  | 388 
>  3 files changed, 658 insertions(+)
> 
> diff --git 
> a/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
>  
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
> new file mode 100644
> index ..3937e98c0213
> --- /dev/null
> +++ 
> b/Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.c
> @@ -0,0 +1,220 @@
> +/** @file
> +  PCI Host Bridge Library instance for Socionext SynQuacer ARM SOC
> +
> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#pragma pack(1)
> +typedef struct {
> +  ACPI_HID_DEVICE_PATH AcpiDevicePath;
> +  EFI_DEVICE_PATH_PROTOCOL EndDevicePath;
> +} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
> +#pragma pack ()
> +
> +STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH mEfiPciRootBridgeDevicePath[] = 
> {
> +  {
> +{
> +  {
> +ACPI_DEVICE_PATH,
> +ACPI_DP,
> +{
> +  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
> +  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
> +}
> +  },
> +  EISA_PNP_ID (0x0A08), // PCI Express
> +  0
> +},
> +
> +{
> +  END_DEVICE_PATH_TYPE,
> +  END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +  {
> +END_DEVICE_PATH_LENGTH,
> +0
> +  }
> +}
> +  },
> +  {
> +{
> +  {
> +ACPI_DEVICE_PATH,
> +ACPI_DP,
> +{
> +  (UINT8)(sizeof(ACPI_HID_DEVICE_PATH)),
> +  (UINT8)(sizeof(ACPI_HID_DEVICE_PATH) >> 8)
> +}
> +  },
> +  EISA_PNP_ID (0x0A08), // PCI Express
> +  1
> +},
> +
> +{
> +  END_DEVICE_PATH_TYPE,
> +  END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +  {
> +END_DEVICE_PATH_LENGTH,
> +0
> +  }
> +}
> +  }
> +};
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED
> +CHAR16 *mPciHostBridgeLibAcpiAddressSpaceTypeStr[] = {
> +  L"Mem", L"I/O", L"Bus"
> +};
> +
> +STATIC PCI_ROOT_BRIDGE mPciRootBridges[] = {
> +  {
> +0,  // Segment
> +0,  // Supports
> +0,  // Attributes
> +TRUE,   // DmaAbove4G
> +FALSE,  // NoExtendedConfigSpace
> +FALSE,  // ResourceAssigned
> +EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
> +EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
> +{ SYNQUACER_PCI_SEG0_BUSNUM_MIN,
> +  SYNQUACER_PCI_SEG0_BUSNUM_MAX },  // Bus
> +{ SYNQUACER_PCI_SEG0_PORTIO_MIN,
> +  SYNQUACER_PCI_SEG0_PORTIO_MAX },  // Io
> +{ SYNQUACER_PCI_SEG0_MMIO32_MIN,
> +  SYNQUACER_PCI_SEG0_MMIO32_MAX },  // Mem
> +{ SYNQUACER_PCI_SEG0_MMIO64_MIN,
> +  SYNQUACER_PCI_SEG0_MMIO64_MAX },  // MemAbove4G
> +{ MAX_UINT64, 0x0 },// PMem
> +{ MAX_UINT64, 0x0 },// PMemAbove4G
> +(EFI_DEVICE_PATH_PROTOCOL *)[0]
> +  }, {
> +1,  // Segment
> +0,  // Supports
> +0,  // Attributes
> +TRUE,   // DmaAbove4G
> +FALSE,  // NoExtendedConfigSpace
> +FALSE,  // ResourceAssigned
> +EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
> +EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
> +{ SYNQUACER_PCI_SEG1_BUSNUM_MIN,
> +  

Re: [edk2] [PATCH] BaseTools/tools_def: suppress GCC predefined macros in DTB compilation

[Laszlo Ersek]

On 10/26/17 13:34, Ard Biesheuvel wrote:
> On 26 October 2017 at 12:33, Leif Lindholm  wrote:
>> On Thu, Oct 26, 2017 at 12:11:16PM +0100, Ard Biesheuvel wrote:
>>> On 26 October 2017 at 12:09, Laszlo Ersek  wrote:
 On 10/26/17 12:12, Ard Biesheuvel wrote:
> The standard GCC preprocessor we use to preprocess device tree sources
> files has a whole bunch of macros predefined, among which
>

 The example you wanted to paste is missing.

>>>
>>> Yeah, the leading # made git-commit throw them away :-)
>>
>> Haha :)

Been there, burned myself similarly :)

>>> #define __linux 1
>>> #define __linux__ 1
>>> #define __gnu_linux__ 1
>>> #define linux 1
>>
>> How did you make it not throw them away?
>> (I can find a few suggestions online, neither sounds optimal.)
>>
> 
> Oh Gmail doesn't care, so pasting them here is not a problem
> 
> In Git, I just added some spaces at the beginning.

Or use email-style quoting ("> ").

Thanks,
Laszlo

> This causes a property like 'linux,code' to be converted into '1,code'
> which is obviously wrong. So let's get rid of all the predefined macros
> by passing -undef to the preprocessor command line.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index df7c109438fd..98df0ffc9294 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4369,7 +4369,7 @@ DEFINE GCC_VFRPP_FLAGS = -x c -E -P 
> -DVFRCOMPILE --include $(DEST_DI
>  DEFINE GCC_ASLPP_FLAGS = -x c -E -include AutoGen.h
>  DEFINE GCC_ASLCC_FLAGS = -x c
>  DEFINE GCC_WINDRES_FLAGS   = -J rc -O coff
> -DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros 
> $(DEST_DIR_DEBUG)/AutoGen.h -nostdinc
> +DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros 
> $(DEST_DIR_DEBUG)/AutoGen.h -nostdinc -undef
>  DEFINE GCC_IA32_RC_FLAGS   = -I binary -O elf32-i386  -B 
> i386--rename-section .data=.hii
>  DEFINE GCC_X64_RC_FLAGS= -I binary -O elf64-x86-64-B 
> i386--rename-section .data=.hii
>  DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little   -B 
> ia64--rename-section .data=.hii
>

 With the commit message fixed:

 Acked-by: Laszlo Ersek 
>>
>> With the same precondition:
>>
>> Reviewed-by: Leif Lindholm 
>>
>> /
>> Leif

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

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Marcin Wojtas]

2017-10-26 16:52 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 04:29:39PM +0200, Marcin Wojtas wrote:
>> 2017-10-26 16:02 GMT+02:00 Leif Lindholm :
>> >> > Why is Capability.BaseClkFreq the wrong frequency to use?
>> >>
>> >> The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
>> >> An alternative would be change this generic type to UINT16 and update
>> >> field properly during initialization - do you prefer that?
>> >
>> > No, I'm still dreaming we might be able to reintegrate this into the
>> > MdeModulePkg driver in some glorious future.
>>
>> Yes, that would be great. I imagine some SDMMC_HOST_PROTOCOL exposing
>> callbacks to set UHS, custom clock handling, etc (like it's done in
>> the Linux).
>
> Yes, *waves hands*, something like that.

Just 'a bit' spare time needed.

>
>> > So what you are basically saying is that this controller is running at
>> > a higher frequency than is permitted (or even describable) by the
>> > specification? If so, _that_ needs to be in the commit message (and
>> > really, a comment by the code as well).
>>
>> Yes, this clock value is Xenon controller's quirk. I will mention it
>> in commit log/comment, but please let know if you wish me to:
>> a. extend BaseClkFreq to UINT16 and configure it properly during init
>> b. leave as is with better description only
>> I lean towards a., it's a very low-cost quirk to be applied.
>
> I would actually lean towards b. That way it stands out and is less
> likely to actually _confuse_ someone in the future.
>

If we dream about possible merge with edk2 original code, I'd really
suggest not to spoil (well, I'm criticizing my own patch:)) the
SdMmcHcClockSupply and continue to rely on BaseClkFreq field there.
This way the code can be common for various hosts.

Let's take look at linux - there is SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN
flag, thanks to which the host controller driver can override the
capability register value during initialization. Most common method
here ends up in clk_get_rate () call and this quirk is used by overall
10 different controllers. Modifying BaseClkFreq type and assignment
during driver initialization (if needed) will be IMO better for
maintenance than creating a custom version of SdMmcHcClockSupply
routine.

Is there any chance I might have convinced you?:)

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

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Laszlo Ersek]

On 10/26/17 15:36, Yao, Jiewen wrote:
> Hi Laszlo
> I have discussed this with Mike Kinney offline and some Microsoft engineers.
> 
> We believe the impact of BME disable is different with the impact of SEV.
> 
> For SEV, if a DMA buffer is in transition when SEV bit change, the DMA will 
> still be active, but the content is different. It will bring wrong data from 
> device perspective.
> 
> For BME, if a DMA buffer is in transition when BME is clear, the DMA will be 
> stopped immediately. The device only sees the DMA transition is abort. But 
> there is no wrong data transmitted.

I agree with the above analysis.

> Because of above reason, we think it is OK to let PCI bus driver to clear BME 
> bit even there is active DMA transaction.

The reason why I believe that the PciBusDxe driver should not clear the
BME bit is different. It is unrelated to SEV.

Imagine a PCI device that requires a special DMA transfer before it can
be quiesced at ExitBootServices(). The vendor of this device will
implement an EBS notification function like this:

- check the private data structure to see if the device needs the
special DMA transfer

- initiate the special DMA transfer -- write some data to a preallocated
  and pre-programmed memory buffer, and then push the doorbell in MMIO
  or config space,

- busy wait (poll) unil the transfer is complete,

- clear BME (as required by the DWG / spec)

- done

Now, if PciBusDxe introduces its own EBS notification function, which
iterates over all the PciIo instances, and clears the BME bit in each
command register, then this notification function may, or may not, be
queued before the other one that I described above.

If the PciBusDxe function is queued "after", then everything is fine. If
it is queued "before", then the driver's own notification function will
break. (It may even hang, if the busy wait never completes.)


UEFI drivers for PCI devices are currently not forbidden from doing a
quick CommonBuffer DMA transfer in their EBS callbacks (as long as they
don't allocate or release memory -- but the memory buffer and the
corresponding CommonBuffer mapping are not hard to set up in advance,
for example in DriverBindingStart()).

This means that any automated IOMMU deactivation, and/or BME clearing in
PciBusDxe, should occur only after the individual driver callbacks have
returned. If PciBusDxe can guarantee this, then I have no objections :)

Thanks!
Laszlo

> 
> Thank you
> Yao Jiewen
> 
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, October 26, 2017 9:07 PM
>> To: Zeng, Star ; Yao, Jiewen ;
>> edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu ; Ard Biesheuvel 
>> 
>> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
>> CALLBACK.
>>
>> On 10/26/17 10:10, Zeng, Star wrote:
>>> Is it security reason when IOMMU disabled and Bus Master not disabled?
>>
>> No, I don't think there is a security issue here.
>>
>> But, my previous assessment about VTdDxe was indeed wrong -- there may
>> be a *correctness* issue.
>>
>> Namely, if the IOMMU is de-activated by VTdDxe before PCI drivers abort
>> pending DMA, then live system RAM references in the devices may become
>> bogus. This is not a security issue (because de-activating the IOMMU
>> will grant the devices access to all of the system RAM anyway), instead
>> it's a correctness problem: DMA read/write may now be directed to the
>> wrong spots in RAM (if the IOMMU mappings were not 1:1 previously).
>>
>> So, I agree that PCI drivers should get a chance to abort pending DMA
>> first, before the IOMMU driver removes the mappings.
>>
>>> Could our code have a central place to disable Bus Master? For example
>> PciBusDxe?
>>
>> No, I don't think PciBusDxe is a good idea. Higher-level PCI drivers
>> might want to do one-shot bus master DMA operations in their own EBS
>> callbacks. If PciBusDxe's callback ran first, then these higher-level
>> drivers would break.
>>
>> For the SEV IOMMU driver, we solved the problem in commit 7aee391fa3d0
>> ("OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()",
>> 2017-09-07). I think the same could be applied to VTdDxe.
>>
>>
>> Another idea (suggested / supported by Ard) was to modify the edk2
>> ExitBootServices() implementation. In CoreExitBootServices()
>> [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c], we could signal a special
>> edk2 IOMMU event group, right after signaling
>> "gEfiEventExitBootServicesGuid":
>>
>>   //
>>   // Notify other drivers that we are exiting boot services.
>>   //
>>   CoreNotifySignalList ();
>>
>>   [HERE]
>>
>>   //
>>   // Report that ExitBootServices() has been called
>>   //
>>   REPORT_STATUS_CODE (
>> EFI_PROGRESS_CODE,
>> (EFI_SOFTWARE_EFI_BOOT_SERVICE |
>> EFI_SW_BS_PC_EXIT_BOOT_SERVICES)
>> );
>>
>> This would ensure that the IOMMU callback ran last.
>>
>>
>> Yet another idea 

Re: [edk2] [PATCH edk2-platforms v2 05/23] Silicon/SynQuacer: implement PciSegmentLib to support dual RCs

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:29PM +0100, Ard Biesheuvel wrote:
> Having two distinct root complexes is not supported by the standard
> set of PciLib/PciExpressLib/PciSegmentLib, so let's reimplement one
> of the latter specifically for this platform (and forget about the
> others).
> 
> This also allows us to implement the Synopsys Designware PCIe specific
> workaround for PCI config space accesses to devices 1 and up on bus 0.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

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

Re: [edk2] [PATCH edk2-platforms v2 03/23] Silicon/SynQuacer: add MemoryInitPeiLib implementation

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:57:38PM +0100, Ard Biesheuvel wrote:
> On 26 October 2017 at 15:56, Leif Lindholm  wrote:
> > On Wed, Oct 25, 2017 at 06:59:27PM +0100, Ard Biesheuvel wrote:
> >> Replace the common MemoryInitPeiLib implementation with one that does
> >> not remove the primary FV from the memory map. This is a waste of
> >> memory and TLB entries, given that the OS can no longer use a 1 GB
> >> block mapping to map this memory.
> >>
> >> Since we have our own implementation now, there is no point in using
> >> ArmPlatformLib's GetVirtualMemoryMap() implementation, and we can
> >> simply declare and map the regions directly.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel 
> >
> > This one still has commented-out bits of code.
> > I don't really want to have that in master.
> > Are we holding off on pushing until we get the dynamic detection
> > support ove SCMI, and are we expecting to drop the commented-out bits
> > when we do?
> 
> Yes.

Right, so this is my only comment on this patch, but I guess there
will be non-trivial changes once that happens, so there's probably no
point for me to give a r-b at this point.

/
Leif

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

Re: [edk2] [PATCH edk2-platforms v2 04/23] Platform: add support for Socionext SynQuacer eval board

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:28PM +0100, Ard Biesheuvel wrote:
> This is a barebones port based on the .DSC/.FDF and ArmPlatformLib
> code provided by Socionext. It can boot into the UiApp menu screen
> or the UEFI Shell, but lacks support for any peripherals.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc   | 
> 428 
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf   | 
> 267 
>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/AArch64/SynQuacerHelper.S | 
>  87 
>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/Arm/SynQuacerHelper.S | 
>  87 
>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacer.c   | 
> 125 ++
>  Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacerLib.inf  | 
>  43 ++
>  6 files changed, 1037 insertions(+)
> 
> diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc 
> b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> new file mode 100644
> index ..b083698451a2
> --- /dev/null
> +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc
> @@ -0,0 +1,428 @@
> +#
> +#  Copyright (c) 2013-2014, ARM Limited. All rights reserved.
> +#  Copyright (c) 2017, Linaro 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 Section - statements that will be processed to create a Makefile.
> +#
> +
> +[Defines]
> +  PLATFORM_NAME  = SynQuacerEvalBoard
> +  PLATFORM_GUID  = a8180daa-fb8b-11e5-ab24-9fc3167c073d
> +  PLATFORM_VERSION   = 0.1
> +  DSC_SPECIFICATION  = 0x0001001B
> +  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
> +  SUPPORTED_ARCHITECTURES= AARCH64|ARM
> +  BUILD_TARGETS  = DEBUG|RELEASE
> +  SKUID_IDENTIFIER   = DEFAULT
> +  FLASH_DEFINITION   = 
> Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf
> +
> +[BuildOptions]
> +  RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=0
> +
> +[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
> +  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +
> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> +  GCC:*_*_ARM_DLINK_FLAGS = -z common-page-size=0x1000
> +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
> +
> +[LibraryClasses.common]
> +  
> ArmPlatformLib|Silicon/Socionext/SynQuacer/Library/SynQuacerLib/SynQuacerLib.inf
> +  ArmHvcLib|ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
> +  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> +
> +  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +
> +!if $(TARGET) == RELEASE
> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> +!else
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!endif
> +  
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> +
> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
> +
> +  # Networking Requirements
> +  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
> +  DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
> +  UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> +  IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
> +
> +  # ARM Architectural Libraries
> +  
> CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
> +  
> DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
> +  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
> +  ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
> +  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> +  ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> +  ArmGicArchLib|ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
> +  
> ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
> +  

Re: [edk2] [PATCH edk2-platforms v2 03/23] Silicon/SynQuacer: add MemoryInitPeiLib implementation

[Ard Biesheuvel]

On 26 October 2017 at 15:56, Leif Lindholm  wrote:
> On Wed, Oct 25, 2017 at 06:59:27PM +0100, Ard Biesheuvel wrote:
>> Replace the common MemoryInitPeiLib implementation with one that does
>> not remove the primary FV from the memory map. This is a waste of
>> memory and TLB entries, given that the OS can no longer use a 1 GB
>> block mapping to map this memory.
>>
>> Since we have our own implementation now, there is no point in using
>> ArmPlatformLib's GetVirtualMemoryMap() implementation, and we can
>> simply declare and map the regions directly.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>
> This one still has commented-out bits of code.
> I don't really want to have that in master.
> Are we holding off on pushing until we get the dynamic detection
> support ove SCMI, and are we expecting to drop the commented-out bits
> when we do?
>

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

Re: [edk2] [PATCH edk2-platforms v2 03/23] Silicon/SynQuacer: add MemoryInitPeiLib implementation

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:27PM +0100, Ard Biesheuvel wrote:
> Replace the common MemoryInitPeiLib implementation with one that does
> not remove the primary FV from the memory map. This is a waste of
> memory and TLB entries, given that the OS can no longer use a 1 GB
> block mapping to map this memory.
> 
> Since we have our own implementation now, there is no point in using
> ArmPlatformLib's GetVirtualMemoryMap() implementation, and we can
> simply declare and map the regions directly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

This one still has commented-out bits of code.
I don't really want to have that in master.
Are we holding off on pushing until we get the dynamic detection
support ove SCMI, and are we expecting to drop the commented-out bits
when we do?

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

Re: [edk2] Adding VLAN changing Boot order to default

[Karunakar P]

Could you please provide your comments.

Thank You,
Karunakar

From: Karunakar P
Sent: Monday, October 23, 2017 8:38 PM
To: 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; 'Fu, Siyuan'; Ye, Ting
Subject: RE: Adding VLAN changing Boot order to default

Hello All,

Boot order is changing to default if we add VLAN, below are the steps followed.

[Steps]

1.   Change default boot order to some other, Then Commit changes and Exit. 
(In my case first boot option Is UEFI Internal Shell, then I changed PXEv4 as 
first boot option)

2.   Add a VLAN

Network Device List -> MAC -> VLAN Configuration -> Create new VLAN and Add VLAN

3.   Now check the Boot order

Observation:- The boot order was changed to default(In my case, UEFI Internal 
shell becomes first boot option)

Could you please provide your comments on this?

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

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Leif Lindholm]

On Thu, Oct 26, 2017 at 04:29:39PM +0200, Marcin Wojtas wrote:
> 2017-10-26 16:02 GMT+02:00 Leif Lindholm :
> >> > Why is Capability.BaseClkFreq the wrong frequency to use?
> >>
> >> The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
> >> An alternative would be change this generic type to UINT16 and update
> >> field properly during initialization - do you prefer that?
> >
> > No, I'm still dreaming we might be able to reintegrate this into the
> > MdeModulePkg driver in some glorious future.
> 
> Yes, that would be great. I imagine some SDMMC_HOST_PROTOCOL exposing
> callbacks to set UHS, custom clock handling, etc (like it's done in
> the Linux).

Yes, *waves hands*, something like that.

> > So what you are basically saying is that this controller is running at
> > a higher frequency than is permitted (or even describable) by the
> > specification? If so, _that_ needs to be in the commit message (and
> > really, a comment by the code as well).
> 
> Yes, this clock value is Xenon controller's quirk. I will mention it
> in commit log/comment, but please let know if you wish me to:
> a. extend BaseClkFreq to UINT16 and configure it properly during init
> b. leave as is with better description only
> I lean towards a., it's a very low-cost quirk to be applied.

I would actually lean towards b. That way it stands out and is less
likely to actually _confuse_ someone in the future.

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

Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid sharing it with other attempts.

[Karunakar P]

Hi Jiaxin,

It can resolve the issue.

Thanks,
Karunakar

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Thursday, October 26, 2017 1:57 PM
To: edk2-devel@lists.01.org
Cc: Karunakar P; Ye Ting; Fu Siyuan; Wu Jiaxin
Subject: [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid 
sharing it with other attempts.

Cc: Karunakar P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
---
 NetworkPkg/IScsiDxe/IScsiConfig.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c 
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 3ce37c5..3382982 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -539,10 +539,11 @@ IScsiConvertAttemptConfigDataToIfrNvData (
 IScsiIpToStr (, FALSE, IfrNvData->LocalIp);
 CopyMem (, >SubnetMask, sizeof 
(EFI_IPv4_ADDRESS));
 IScsiIpToStr (, FALSE, IfrNvData->SubnetMask);
 CopyMem (, >Gateway, sizeof (EFI_IPv4_ADDRESS));
 IScsiIpToStr (, FALSE, IfrNvData->Gateway);
+ZeroMem (IfrNvData->TargetIp, sizeof (IfrNvData->TargetIp));
 if (SessionConfigData->TargetIp.v4.Addr[0] != '\0') {
   CopyMem (, >TargetIp, sizeof 
(EFI_IPv4_ADDRESS));
   IScsiIpToStr (, FALSE, IfrNvData->TargetIp);
 }
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH edk2-platforms v2 02/23] Silicon/Socionext: add driver for NETSEC network controller

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:26PM +0100, Ard Biesheuvel wrote:
> This adds the NetSecDxe driver provided by Socionext, but reworked
> extensively to improve compliance with the SimpleNetworkProtocol API,
> and to avoid uncached allocations for streaming DMA.

So, I see all of my important style comments addressed, including
comment improvements, but not much else. Could you answer the
questions in my original response?

In the meantime, I can give you a
Tested-by: Leif Lindholm 

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

Re: [edk2] [PATCH edk2-platforms v2 01/23] Silicon/SynQuacer: add package with platform headers

[Leif Lindholm]

On Wed, Oct 25, 2017 at 06:59:25PM +0100, Ard Biesheuvel wrote:
> Add a package .DEC description for SynQuacer with an [Includes]
> section, and add header files containing descriptions of the
> platform's memory map and PCIe configuration. No code yet.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 
Special thanks for the tedious name case-change.

> ---
>  Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h | 69 
> 
>  Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h  | 63 
> ++
>  Silicon/Socionext/SynQuacer/SynQuacer.dec| 20 ++
>  3 files changed, 152 insertions(+)
> 
> diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h 
> b/Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h
> new file mode 100644
> index ..a53b9088c3af
> --- /dev/null
> +++ b/Silicon/Socionext/SynQuacer/Include/Platform/MemoryMap.h
> @@ -0,0 +1,69 @@
> +/** @file
> +  Physical memory map for SynQuacer
> +
> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _SYNQUACER_PLATFORM_MEMORYMAP_H_
> +#define _SYNQUACER_PLATFORM_MEMORYMAP_H_
> +
> +// Memory mapped SPI NOR
> +#define SYNQUACER_SPI_NOR_BASE  0x0800
> +#define SYNQUACER_SPI_NOR_SIZE  SIZE_128MB
> +
> +// On-Chip non-secure ROM
> +#define SYNQUACER_NON_SECURE_ROM_BASE   0x1F00
> +#define SYNQUACER_NON_SECURE_ROM_SZ SIZE_512KB
> +
> +// On-Chip Peripherals
> +#define SYNQUACER_PERIPHERALS_BASE  0x2000
> +#define SYNQUACER_PERIPHERALS_SZ0x0E00
> +
> +// On-Chip non-secure SRAM
> +#define SYNQUACER_NON_SECURE_SRAM_BASE  0x2E00
> +#define SYNQUACER_NON_SECURE_SRAM_SZSIZE_64KB
> +
> +// GIC-500
> +#define SYNQUACER_GIC500_DIST_BASE  FixedPcdGet64 (PcdGicDistributorBase)
> +#define SYNQUACER_GIC500_DIST_SIZE  SIZE_256KB
> +#define SYNQUACER_GIC500_RDIST_BASE FixedPcdGet64 
> (PcdGicRedistributorsBase)
> +#define SYNQUACER_GIC500_RDIST_SIZE SIZE_8MB
> +
> +// GPIO block
> +#define SYNQUACER_GPIO_BASE 0x5100
> +#define SYNQUACER_GPIO_SIZE SIZE_4KB
> +
> +// eMMC(SDH30)
> +#define SYNQUACER_EMMC_BASE 0x5230
> +#define SYNQUACER_EMMC_BASE_SZ  SIZE_4KB
> +
> +#define SYNQUACER_EEPROM_BASE   0x1000
> +#define SYNQUACER_EEPROM_BASE_SZSIZE_64KB
> +
> +// NETSEC
> +#define SYNQUACER_NETSEC_BASE   0x522D
> +#define SYNQUACER_NETSEC_BASE_SZSIZE_64KB
> +
> +#define SYNQUACER_SYSTEM_MEMORY_1_BASE  0x8000
> +#define SYNQUACER_SYSTEM_MEMORY_1_SZ(SIZE_2GB - SIZE_16MB)
> +
> +#define SYNQUACER_SYSTEM_MEMORY_2_BASE  0x088000ULL
> +#define SYNQUACER_SYSTEM_MEMORY_2_SZ(SIZE_32GB - SIZE_2GB)
> +
> +#define SYNQUACER_SYSTEM_MEMORY_3_BASE  0x88ULL
> +#define SYNQUACER_SYSTEM_MEMORY_3_SZSIZE_32GB
> +
> +// PCI
> +#define SYNQUACER_PCIE_BASE 0x5820
> +#define SYNQUACER_PCIE_SIZE 0x0020
> +
> +#endif
> diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h 
> b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
> new file mode 100644
> index ..d2a3f9acbf49
> --- /dev/null
> +++ b/Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h
> @@ -0,0 +1,63 @@
> +/** @file
> +  PCI memory configuration for SynQuacer
> +
> +  Copyright (c) 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made available
> +  under the terms and conditions of the BSD License which accompanies this
> +  distribution.  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
> WITHOUT
> +  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _SYNQUACER_PLATFORM_PCI_H_
> +#define _SYNQUACER_PLATFORM_PCI_H_
> +
> +#define SYNQUACER_PCI_SEG0_CONFIG_BASE  0x6000
> +#define SYNQUACER_PCI_SEG0_CONFIG_SIZE  0x07f0
> +#define SYNQUACER_PCI_SEG0_DBI_BASE 0x583d
> +#define SYNQUACER_PCI_SEG0_EXS_BASE 0x5839
> +
> +#define SYNQUACER_PCI_SEG0_BUSNUM_MIN   0x0
> +#define SYNQUACER_PCI_SEG0_BUSNUM_MAX   0x7e
> +
> +#define SYNQUACER_PCI_SEG0_PORTIO_MIN   0x0
> +#define SYNQUACER_PCI_SEG0_PORTIO_MAX   0x
> +#define 

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Marcin Wojtas]

2017-10-26 16:02 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 03:54:41PM +0200, Marcin Wojtas wrote:
>> 2017-10-26 15:46 GMT+02:00 Leif Lindholm :
>> > On Thu, Oct 26, 2017 at 03:19:36AM +0200, Marcin Wojtas wrote:
>> >> Incorrectly the clock divisor was calculated relatively
>> >> to 255MHz instead of actual 400MHz.
>> >
>> > This describes the specific symptom, not the problem with the existing
>> > code.
>> >
>> >> Fix this.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Marcin Wojtas 
>> >> ---
>> >>  Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c | 4 ++--
>> >>  1 file changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c 
>> >> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> >> index ccbf355..0b9328b 100644
>> >> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> >> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> >> @@ -16,6 +16,7 @@
>> >>  **/
>> >>
>> >>  #include "SdMmcPciHcDxe.h"
>> >> +#include "XenonSdhci.h"
>> >>
>> >>  /**
>> >>Dump the content of SD/MMC host controller's Capability Register.
>> >> @@ -703,9 +704,8 @@ SdMmcHcClockSupply (
>> >>//
>> >>// Calculate a divisor for SD clock frequency
>> >>//
>> >> -  ASSERT (Capability.BaseClkFreq != 0);
>> >>
>> >> -  BaseClkFreq = Capability.BaseClkFreq;
>> >
>> > Why is Capability.BaseClkFreq the wrong frequency to use?
>>
>> The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
>> An alternative would be change this generic type to UINT16 and update
>> field properly during initialization - do you prefer that?
>
> No, I'm still dreaming we might be able to reintegrate this into the
> MdeModulePkg driver in some glorious future.

Yes, that would be great. I imagine some SDMMC_HOST_PROTOCOL exposing
callbacks to set UHS, custom clock handling, etc (like it's done in
the Linux).

>
> So what you are basically saying is that this controller is running at
> a higher frequency than is permitted (or even describable) by the
> specification? If so, _that_ needs to be in the commit message (and
> really, a comment by the code as well).

Yes, this clock value is Xenon controller's quirk. I will mention it
in commit log/comment, but please let know if you wish me to:
a. extend BaseClkFreq to UINT16 and configure it properly during init
b. leave as is with better description only
I lean towards a., it's a very low-cost quirk to be applied.

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

Re: [edk2] [PATCH 03/10] MdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices()

[Ard Biesheuvel]

On 26 October 2017 at 15:09, Laszlo Ersek  wrote:
> Ard, Star,
>
> (CC Igor)
>
> On 10/26/17 07:08, Zeng, Star wrote:
>> Good point.
>>
>> Could we find out what change causes the performance regression? Bus Master 
>> disable / Memory Space disable / IO Space disable?
>> How about to only disable Bus Master in the exit boot service event 
>> notification? It seems the key point suggested by UEFI 
>> Driver_Writer_Guide_V1.0.1_120308.pdf.
>>
>> 7.7
>> Examples from the EDK II that use this feature are the PCI device drivers 
>> for USB Host
>> Controllers. Some USB Host Controllers are PCI Bus Masters that continuously 
>> access a
>> memory buffer to poll for operation requests. Access to this memory buffer 
>> by a USB
>> Host Controller may be required to boot an operation system, but this 
>> activity must be
>> terminated when the OS calls ExitBootServices(). *The typical action in the 
>> Exit Boot
>> Services Event for these types of drivers is to disable the PCI bus master* 
>> and place the
>> USB Host Controller into a halted state
>
> thank you for the ideas.
>
> * Disabling only EFI_PCI_IO_ATTRIBUTE_BUS_MASTER at EBS mitigates the
>   symptom.
>
> * Disabling (EFI_PCI_IO_ATTRIBUTE_BUS_MASTER | EFI_PCI_IO_ATTRIBUTE_IO)
>   at EBS preserves the symptom.
>
> * Disabling
>   (EFI_PCI_IO_ATTRIBUTE_BUS_MASTER | EFI_PCI_IO_ATTRIBUTE_MEMORY) at EBS
>   also mitigates the symptom.
>

Excellent!

> So it is as Ard suspected, disabling IO port decoding is what tickles
> the bug in Windows.
>
> (Now I'm vaguely recalling an earlier discussion from qemu-devel that
> Windows has a bug in that, if any given PCI device is disabled at boot,
> then Windows will not load drivers for it, or some such. I'm struggling
> to recall the context; maybe it was related to ACPI generation in QEMU.
> I'm CC'ing Igor; maybe he remembers better.)
>
> I will post a patch, for disabling EFI_PCI_IO_ATTRIBUTE_BUS_MASTER only.
> First, that's going to follow the driver writers' guide verbatim;
> second, disabling BMDMA and MMIO, but not IO, would look weird in the
> code. :/
>
> Thank you both for the help!

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

Re: [edk2] [PATCH 03/10] MdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices()

[Laszlo Ersek]

Ard, Star,

(CC Igor)

On 10/26/17 07:08, Zeng, Star wrote:
> Good point.
> 
> Could we find out what change causes the performance regression? Bus Master 
> disable / Memory Space disable / IO Space disable?
> How about to only disable Bus Master in the exit boot service event 
> notification? It seems the key point suggested by UEFI 
> Driver_Writer_Guide_V1.0.1_120308.pdf.
> 
> 7.7
> Examples from the EDK II that use this feature are the PCI device drivers for 
> USB Host
> Controllers. Some USB Host Controllers are PCI Bus Masters that continuously 
> access a
> memory buffer to poll for operation requests. Access to this memory buffer by 
> a USB
> Host Controller may be required to boot an operation system, but this 
> activity must be
> terminated when the OS calls ExitBootServices(). *The typical action in the 
> Exit Boot
> Services Event for these types of drivers is to disable the PCI bus master* 
> and place the
> USB Host Controller into a halted state

thank you for the ideas.

* Disabling only EFI_PCI_IO_ATTRIBUTE_BUS_MASTER at EBS mitigates the
  symptom.

* Disabling (EFI_PCI_IO_ATTRIBUTE_BUS_MASTER | EFI_PCI_IO_ATTRIBUTE_IO)
  at EBS preserves the symptom.

* Disabling
  (EFI_PCI_IO_ATTRIBUTE_BUS_MASTER | EFI_PCI_IO_ATTRIBUTE_MEMORY) at EBS
  also mitigates the symptom.

So it is as Ard suspected, disabling IO port decoding is what tickles
the bug in Windows.

(Now I'm vaguely recalling an earlier discussion from qemu-devel that
Windows has a bug in that, if any given PCI device is disabled at boot,
then Windows will not load drivers for it, or some such. I'm struggling
to recall the context; maybe it was related to ACPI generation in QEMU.
I'm CC'ing Igor; maybe he remembers better.)

I will post a patch, for disabling EFI_PCI_IO_ATTRIBUTE_BUS_MASTER only.
First, that's going to follow the driver writers' guide verbatim;
second, disabling BMDMA and MMIO, but not IO, would look weird in the
code. :/

Thank you both for the help!
Laszlo


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
> Sent: Thursday, October 26, 2017 4:12 AM
> To: Laszlo Ersek 
> Cc: Dong, Eric ; Zeng, Star ; 
> edk2-devel-01 ; Yao, Jiewen ; 
> Brijesh Singh 
> Subject: Re: [edk2] [PATCH 03/10] MdeModulePkg/AtaAtapiPassThru: disable the 
> device at ExitBootServices()
> 
> On 25 October 2017 at 16:26, Laszlo Ersek  wrote:
>> Hi Star, Eric,
>>
>> On 09/08/17 00:41, Laszlo Ersek wrote:
>>> The AtaAtapiPassThru driver maps three system memory regions for Bus 
>>> Master Common Buffer operation on the following call path, if the 
>>> controller has PCI_CLASS_MASS_STORAGE_SATADPA class code:
>>>
>>>   AtaAtapiPassThruStart()
>>> EnumerateAttachedDevice()
>>>   AhciModeInitialization()
>>> AhciCreateTransferDescriptor()
>>>
>>> The device is disabled (including Bus Master DMA) when the controller 
>>> is unbound, in AtaAtapiPassThruStop(). Then the regions are unmapped.
>>>
>>> The former step should also be done when we exit the boot services, 
>>> and the OS gains ownership of system memory.
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Brijesh Singh 
>>> Cc: Eric Dong 
>>> Cc: Jiewen Yao 
>>> Cc: Star Zeng 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h |  6 ++  
>>> MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c | 59 
>>> +++-
>>>  2 files changed, 64 insertions(+), 1 deletion(-)
>>
>> this patch -- that is, commit 6fb8ddd36bde
>> ("MdeModulePkg/AtaAtapiPassThru: disable the device at 
>> ExitBootServices()", 2017-09-03) -- has caused a performance 
>> regression in OVMF, in booting Windows installer ISOs from emulated IDE 
>> CD-ROMs.
>>
>> Interestingly, the performance regression only affects the "traditional"
>> IDE controller of the "pc" (i440fx) machine type of QEMU; it does not 
>> affect the AHCI/SATA controller of the "q35" machine type.
> 
> Does it make any difference if you only disable memory decoding and bus 
> mastering, but leave I/O port decoding enabled?
> ___
> 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] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:54:41PM +0200, Marcin Wojtas wrote:
> 2017-10-26 15:46 GMT+02:00 Leif Lindholm :
> > On Thu, Oct 26, 2017 at 03:19:36AM +0200, Marcin Wojtas wrote:
> >> Incorrectly the clock divisor was calculated relatively
> >> to 255MHz instead of actual 400MHz.
> >
> > This describes the specific symptom, not the problem with the existing
> > code.
> >
> >> Fix this.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marcin Wojtas 
> >> ---
> >>  Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c 
> >> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> >> index ccbf355..0b9328b 100644
> >> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> >> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> >> @@ -16,6 +16,7 @@
> >>  **/
> >>
> >>  #include "SdMmcPciHcDxe.h"
> >> +#include "XenonSdhci.h"
> >>
> >>  /**
> >>Dump the content of SD/MMC host controller's Capability Register.
> >> @@ -703,9 +704,8 @@ SdMmcHcClockSupply (
> >>//
> >>// Calculate a divisor for SD clock frequency
> >>//
> >> -  ASSERT (Capability.BaseClkFreq != 0);
> >>
> >> -  BaseClkFreq = Capability.BaseClkFreq;
> >
> > Why is Capability.BaseClkFreq the wrong frequency to use?
> 
> The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
> An alternative would be change this generic type to UINT16 and update
> field properly during initialization - do you prefer that?

No, I'm still dreaming we might be able to reintegrate this into the
MdeModulePkg driver in some glorious future.

So what you are basically saying is that this controller is running at
a higher frequency than is permitted (or even describable) by the
specification? If so, _that_ needs to be in the commit message (and
really, a comment by the code as well).

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

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Marcin Wojtas]

2017-10-26 15:55 GMT+02:00 Ard Biesheuvel :
> On 26 October 2017 at 14:54, Marcin Wojtas  wrote:
>> 2017-10-26 15:46 GMT+02:00 Leif Lindholm :
>>> On Thu, Oct 26, 2017 at 03:19:36AM +0200, Marcin Wojtas wrote:
 Incorrectly the clock divisor was calculated relatively
 to 255MHz instead of actual 400MHz.
>>>
>>> This describes the specific symptom, not the problem with the existing
>>> code.
>>>
 Fix this.

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Marcin Wojtas 
 ---
  Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c 
 b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
 index ccbf355..0b9328b 100644
 --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
 +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
 @@ -16,6 +16,7 @@
  **/

  #include "SdMmcPciHcDxe.h"
 +#include "XenonSdhci.h"

  /**
Dump the content of SD/MMC host controller's Capability Register.
 @@ -703,9 +704,8 @@ SdMmcHcClockSupply (
//
// Calculate a divisor for SD clock frequency
//
 -  ASSERT (Capability.BaseClkFreq != 0);

 -  BaseClkFreq = Capability.BaseClkFreq;
>>>
>>> Why is Capability.BaseClkFreq the wrong frequency to use?
>>>
>>
>> The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
>> An alternative would be change this generic type to UINT16 and update
>> field properly during initialization - do you prefer that?
>>
>
> Isn't that value read from device registers?

This field in generic Capability1 register is only 8-bit wide, hence
the 255MHz limitation. Xenon controller however is fed with 400MHz and
it clearly cannot be obtained from there.

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

Re: [edk2] [platforms: PATCH 05/10] Marvell/Library: MppLib: Disable the stack protector

[Leif Lindholm]

On Thu, Oct 26, 2017 at 02:29:02PM +0100, Ard Biesheuvel wrote:
> On 26 October 2017 at 14:26, Leif Lindholm  wrote:
> > On Thu, Oct 26, 2017 at 03:19:32AM +0200, Marcin Wojtas wrote:
> >> From: Ard Biesheuvel 
> >>
> >> MppLib may be used very early (in SEC), at which point stack protection
> >> measures are more likely to cause harm than help, given that not even
> >> the UART has been configured to the point where we can complain usefully.
> >> So just disable it.
> >
> > It may. But it is also used by PlatInitDxe.
> > Can we use different build options for SEC and later phases?
> 
> No, libraries are only built a single time during the build, and
> linked into every module that depends on them. This is the same issue
> we had with -mstrict-align.

Sure, but we could have duplicated the .inf and have a SEC version and
use that mapping for SEC...

Clearly that's tedious. I guess it comes down to how useful we think
the stack checking is in general. If the answer is "not very, to be
honest":
Reviewed-by: Leif Lindholm 

/
Leif

> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel 
> >> Signed-off-by: Marcin Wojtas 
> >> ---
> >>  Platform/Marvell/Library/MppLib/MppLib.inf | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/Platform/Marvell/Library/MppLib/MppLib.inf 
> >> b/Platform/Marvell/Library/MppLib/MppLib.inf
> >> index 2de9cd0..1268542 100644
> >> --- a/Platform/Marvell/Library/MppLib/MppLib.inf
> >> +++ b/Platform/Marvell/Library/MppLib/MppLib.inf
> >> @@ -106,3 +106,6 @@
> >>gMarvellTokenSpaceGuid.PcdChip3MppSel7
> >>
> >>gMarvellTokenSpaceGuid.PcdPciESdhci
> >> +
> >> +[BuildOptions]
> >> +  *_*_*_CC_FLAGS = -fno-stack-protector
> >> --
> >> 2.7.4
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/10] Marvell/Drivers: MvI2cDxe: Abort transaction immediately upon fail

[Marcin Wojtas]

2017-10-26 15:54 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 03:19:36PM +0200, Marcin Wojtas wrote:
>> Hi Leif,
>>
>> 2017-10-26 14:51 GMT+02:00 Leif Lindholm :
>> > On Thu, Oct 26, 2017 at 03:19:28AM +0200, Marcin Wojtas wrote:
>> >> From: David Greeson 
>> >>
>> >> Although the I2C transaction routines were prepared to
>> >> return their status, they were never used. This could
>> >> cause bus lock-up e.g. in case of failing to send a
>> >> slave address, the data transfer was attempted to be
>> >> continued anyway.
>> >>
>> >> This patch fixes faulty behavior by checking transaction
>> >> status and stopping it immediately, once the fail
>> >> is detected.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: David Greeson 
>> >> [Style adjustment and cleanup]
>> >> Signed-off-by: Marcin Wojtas 
>> >> ---
>> >>  Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 34 
>> >> +---
>> >>  1 file changed, 29 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
>> >> b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> >> index d85ee0b..7faf1f7 100755
>> >> --- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> >> +++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> >> @@ -565,6 +565,7 @@ MvI2cStartRequest (
>> >>UINTN Transmitted;
>> >>I2C_MASTER_CONTEXT *I2cMasterContext = I2C_SC_FROM_MASTER(This);
>> >>EFI_I2C_OPERATION *Operation;
>> >> +  EFI_STATUS Status = EFI_SUCCESS;
>> >>
>> >>ASSERT (RequestPacket != NULL);
>> >>ASSERT (I2cMasterContext != NULL);
>> >> @@ -574,35 +575,58 @@ MvI2cStartRequest (
>> >>  ReadMode = Operation->Flags & I2C_FLAG_READ;
>> >>
>> >>  if (Count == 0) {
>> >> -  MvI2cStart ( I2cMasterContext,
>> >> +  Status = MvI2cStart (I2cMasterContext,
>> >> (SlaveAddress << 1) | ReadMode,
>> >> I2C_TRANSFER_TIMEOUT
>> >
>> > Much as I appreciate seeing this form of the code, since it simplifies
>> > seeing the functional changes, this does cause those lines left
>> > unchanges to no longer conform to coding style.
>> > Can you please adjust throughout for a v2?
>> >
>>
>> No problem. I of course saw style violations, but I gave up on them
>> for "no mix of functional improvements and style cleanups" contraint
>> :) I will correct the modified function calls.
>
> Clarification: this is and has always been _unrelated_ style cleanups.
> Any statement that is actually being modified should be conformant
> afterwards.
>

Ok, thanks for clarification.

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

Re: [edk2] [platforms: PATCH 02/10] Marvell/Drivers: MvI2cDxe: Fix returning status in MvI2cStartRequest

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:22:32PM +0200, Marcin Wojtas wrote:
> 2017-10-26 15:11 GMT+02:00 Leif Lindholm :
> > On Thu, Oct 26, 2017 at 03:19:29AM +0200, Marcin Wojtas wrote:
> >> In MvI2cStartRequest the status was assigned to the variable
> >> without dereferencing a pointer. Fix it.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marcin Wojtas 
> >> ---
> >>  Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
> >> b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> index 7faf1f7..8ed96f0 100755
> >> --- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> +++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> @@ -631,7 +631,7 @@ MvI2cStartRequest (
> >>}
> >>
> >>if (I2cStatus != NULL)
> >> -I2cStatus = EFI_SUCCESS;
> >> +*I2cStatus = Status;
> >
> > Oh, that's horrible! And only did not generate warnings because
> > EFI_SUCCESS is 0.
> 
> This parameter is 'optional', so me must have been also lucky not to
> use it in basic operation.
> 
> >
> > However, you also change from setting *I2cStatus to Status instead of
> > EFI_SUCCESS. This should be mentioned in commit message.
> >
> > /
> 
> We can leave EFI_SUCCESS, as it's the only option at this place. It
> was changed to Status, due to first patch of the series. I will leave
> the original and just modify *.

Yes, that works too - thanks!

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

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Marcin Wojtas]

2017-10-26 15:46 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 03:19:36AM +0200, Marcin Wojtas wrote:
>> Incorrectly the clock divisor was calculated relatively
>> to 255MHz instead of actual 400MHz.
>
> This describes the specific symptom, not the problem with the existing
> code.
>
>> Fix this.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c 
>> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> index ccbf355..0b9328b 100644
>> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
>> @@ -16,6 +16,7 @@
>>  **/
>>
>>  #include "SdMmcPciHcDxe.h"
>> +#include "XenonSdhci.h"
>>
>>  /**
>>Dump the content of SD/MMC host controller's Capability Register.
>> @@ -703,9 +704,8 @@ SdMmcHcClockSupply (
>>//
>>// Calculate a divisor for SD clock frequency
>>//
>> -  ASSERT (Capability.BaseClkFreq != 0);
>>
>> -  BaseClkFreq = Capability.BaseClkFreq;
>
> Why is Capability.BaseClkFreq the wrong frequency to use?
>

The Capability.BaseClkFreq is UINT8 and can hold up to 0xff -> 255MHz.
An alternative would be change this generic type to UINT16 and update
field properly during initialization - do you prefer that?

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

Re: [edk2] [platforms: PATCH 01/10] Marvell/Drivers: MvI2cDxe: Abort transaction immediately upon fail

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:36PM +0200, Marcin Wojtas wrote:
> Hi Leif,
> 
> 2017-10-26 14:51 GMT+02:00 Leif Lindholm :
> > On Thu, Oct 26, 2017 at 03:19:28AM +0200, Marcin Wojtas wrote:
> >> From: David Greeson 
> >>
> >> Although the I2C transaction routines were prepared to
> >> return their status, they were never used. This could
> >> cause bus lock-up e.g. in case of failing to send a
> >> slave address, the data transfer was attempted to be
> >> continued anyway.
> >>
> >> This patch fixes faulty behavior by checking transaction
> >> status and stopping it immediately, once the fail
> >> is detected.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: David Greeson 
> >> [Style adjustment and cleanup]
> >> Signed-off-by: Marcin Wojtas 
> >> ---
> >>  Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 34 +---
> >>  1 file changed, 29 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
> >> b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> index d85ee0b..7faf1f7 100755
> >> --- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> +++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
> >> @@ -565,6 +565,7 @@ MvI2cStartRequest (
> >>UINTN Transmitted;
> >>I2C_MASTER_CONTEXT *I2cMasterContext = I2C_SC_FROM_MASTER(This);
> >>EFI_I2C_OPERATION *Operation;
> >> +  EFI_STATUS Status = EFI_SUCCESS;
> >>
> >>ASSERT (RequestPacket != NULL);
> >>ASSERT (I2cMasterContext != NULL);
> >> @@ -574,35 +575,58 @@ MvI2cStartRequest (
> >>  ReadMode = Operation->Flags & I2C_FLAG_READ;
> >>
> >>  if (Count == 0) {
> >> -  MvI2cStart ( I2cMasterContext,
> >> +  Status = MvI2cStart (I2cMasterContext,
> >> (SlaveAddress << 1) | ReadMode,
> >> I2C_TRANSFER_TIMEOUT
> >
> > Much as I appreciate seeing this form of the code, since it simplifies
> > seeing the functional changes, this does cause those lines left
> > unchanges to no longer conform to coding style.
> > Can you please adjust throughout for a v2?
> >
> 
> No problem. I of course saw style violations, but I gave up on them
> for "no mix of functional improvements and style cleanups" contraint
> :) I will correct the modified function calls.

Clarification: this is and has always been _unrelated_ style cleanups.
Any statement that is actually being modified should be conformant
afterwards.

Thanks.

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

Re: [edk2] [platforms: PATCH 10/10] Marvell/Drivers: XenonDxe: Do not modify FIFO default values

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:37AM +0200, Marcin Wojtas wrote:
> Changing controller's FIFO default values is not necessary and
> possibly can cause instabilities, when using some devices.
> Disable the modification and rely on initial settings.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c | 16 
>  1 file changed, 16 deletions(-)
> 
> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c 
> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
> index 31f207e..6bbe5bc 100755
> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/XenonSdhci.c
> @@ -44,20 +44,6 @@ XenonReadVersion (
>SdMmcHcRwMmio (PciIo, SD_BAR_INDEX, SD_MMC_HC_CTRL_VER, TRUE, 
> SDHC_REG_SIZE_2B, ControllerVersion);
>  }
>  
> -STATIC
> -VOID
> -XenonSetFifo (
> -  IN EFI_PCI_IO_PROTOCOL   *PciIo
> -  )
> -{
> -  UINTN Data;
> -
> -  // Set FIFO_RTC, FIFO_WTC, FIFO_CS and FIFO_PDLVMC
> -  Data = SDHC_SLOT_FIFO_DEFAULT_CONFIG;
> -
> -  SdMmcHcRwMmio (PciIo, SD_BAR_INDEX, SDHC_SLOT_FIFO_CTRL, FALSE, 
> SDHC_REG_SIZE_4B, );
> -}
> -
>  // Auto Clock Gating
>  STATIC
>  VOID
> @@ -634,8 +620,6 @@ XenonInit (
>// Read XENON version
>XenonReadVersion (PciIo, >ControllerVersion);
>  
> -  XenonSetFifo (PciIo);
> -
>// Disable auto clock generator
>XenonSetAcg (PciIo, FALSE);
>  
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 09/10] Marvell/Drivers: XenonDxe: Fix base clock frequency

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:36AM +0200, Marcin Wojtas wrote:
> Incorrectly the clock divisor was calculated relatively
> to 255MHz instead of actual 400MHz.

This describes the specific symptom, not the problem with the existing
code.

> Fix this.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c 
> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> index ccbf355..0b9328b 100644
> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/SdMmcPciHci.c
> @@ -16,6 +16,7 @@
>  **/
>  
>  #include "SdMmcPciHcDxe.h"
> +#include "XenonSdhci.h"
>  
>  /**
>Dump the content of SD/MMC host controller's Capability Register.
> @@ -703,9 +704,8 @@ SdMmcHcClockSupply (
>//
>// Calculate a divisor for SD clock frequency
>//
> -  ASSERT (Capability.BaseClkFreq != 0);
>  
> -  BaseClkFreq = Capability.BaseClkFreq;

Why is Capability.BaseClkFreq the wrong frequency to use?

/
Leif

> +  BaseClkFreq = XENON_MMC_MAX_CLK / 1000 / 1000;
>if (ClockFreq == 0) {
>  return EFI_INVALID_PARAMETER;
>}
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 08/10] Marvell/Drivers: XenonDxe: Fix UHS signalling mode setting

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:35AM +0200, Marcin Wojtas wrote:
> This patch fixes incorrect settings for UHS mode in
> SD_MMC_HC_HOST_CTRL2 register. This field should be set to
> 
> 0x4 for DDR52
> 0x2 for SDR50
> 0x1 for SDR25
> 0x0 for others.
> 
> This way EmmcSwitchToHighSpeed function is on par with Linux
> set_uhs_signaling routine in the Xenon driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c 
> b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
> index 3f73194..4d4833f 100755
> --- a/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
> +++ b/Platform/Marvell/Drivers/SdMmc/XenonDxe/EmmcDevice.c
> @@ -772,6 +772,8 @@ EmmcSwitchToHighSpeed (
>if (IsDdr) {
>  HostCtrl2 = BIT2;
>} else if (ClockFreq == 52) {
> +HostCtrl2 = BIT1;
> +  } else if (ClockFreq == 26) {

This patch adds previously missing handling of SDR25 (I guess).
Please reflect this in commit message.

/
Leif

>  HostCtrl2 = BIT0;
>} else {
>  HostCtrl2 = 0;
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 07/10] Marvell/Drivers: Pp2Dxe: Change settings for the always-up link

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:34AM +0200, Marcin Wojtas wrote:
> Currently initial forcing link status happened for all ports, not only
> marked as 'always-up'. Although this didn't actually matter for the MAC
> settings, because MAC is automatically updated with PHY HW polling
> feature of the controller, perform mv_gop110_fl_cfg only when
> the appropriate flag is true. Also in such case, force the link as up,
> using a new library routine.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c | 31 
>  Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h |  7 +
>  Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c   |  6 +++-
>  3 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c 
> b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
> index 53154db..e3ddc58 100644
> --- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
> +++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.c
> @@ -4804,6 +4804,37 @@ MvGop110PortEventsMask (
>return 0;
>  }
>  
> +/*
> + * Sets "Force Link Pass" and "Do Not Force Link Fail" bits.
> + * This function should only be called when the port is disabled.
> + */
> +VOID
> +MvGop110GmacForceLinkModeSet(
> +  IN PP2DXE_PORT *Port,
> +  IN BOOLEAN ForceLinkUp,
> +  IN BOOLEAN ForceLinkDown)
> +{
> +  UINT32 RegVal;
> +
> +  /* Can't force link pass and link fail at the same time */

Then why pass two parameters to the function?
The function is called ForceLink.
Have one ForceLinkUp BOOL parameter, and force up if TRUE and down if
FALSE.

> +  if ((ForceLinkUp) && (ForceLinkDown))
> +return;
> +
> +  RegVal = MvGop110GmacRead (Port, MVPP2_PORT_AUTO_NEG_CFG_REG);
> +
> +  if (ForceLinkUp)

Always {} with if/else (throughout).

/
Leif

> +RegVal |= MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_UP_MASK;
> +  else
> +RegVal &= ~MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_UP_MASK;
> +
> +  if (ForceLinkDown)
> +RegVal |= MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_DOWN_MASK;
> +  else
> +RegVal &= ~MVPP2_PORT_AUTO_NEG_CFG_FORCE_LINK_DOWN_MASK;
> +
> +  MvGop110GmacWrite (Port, MVPP2_PORT_AUTO_NEG_CFG_REG, RegVal);
> +}
> +
>  INT32
>  MvGop110FlCfg (
>IN PP2DXE_PORT *Port
> diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h 
> b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
> index a7011f7..2938777 100644
> --- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
> +++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Mvpp2Lib.h
> @@ -504,6 +504,13 @@ MvGop110XlgPortLinkEventMask (
>IN PP2DXE_PORT *Port
>);
>  
> +VOID
> +MvGop110GmacForceLinkModeSet (
> +  IN PP2DXE_PORT *Port,
> +  IN BOOLEAN ForceLinkUp,
> +  IN BOOLEAN ForceLinkDown
> +  );
> +
>  INT32
>  MvGop110FlCfg (
>IN PP2DXE_PORT *Port
> diff --git a/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c 
> b/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
> index 2827976..94a2988 100644
> --- a/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
> +++ b/Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.c
> @@ -1310,7 +1310,11 @@ Pp2DxeInitialiseController (
>  NetCompConfig |= MvpPp2xGop110NetcCfgCreate(>Port);
>  
>  MvGop110PortInit(>Port);
> -MvGop110FlCfg(>Port);
> +
> +if (Pp2Context->Port.AlwaysUp == TRUE) {
> +  MvGop110GmacForceLinkModeSet (>Port, TRUE, FALSE);
> +  MvGop110FlCfg (>Port);
> +}
>  
>  Status = gBS->CreateEvent (
>   EVT_SIGNAL_EXIT_BOOT_SERVICES,
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to CALLBACK.

[Yao, Jiewen]

Hi Laszlo
I have discussed this with Mike Kinney offline and some Microsoft engineers.

We believe the impact of BME disable is different with the impact of SEV.

For SEV, if a DMA buffer is in transition when SEV bit change, the DMA will 
still be active, but the content is different. It will bring wrong data from 
device perspective.

For BME, if a DMA buffer is in transition when BME is clear, the DMA will be 
stopped immediately. The device only sees the DMA transition is abort. But 
there is no wrong data transmitted.

Because of above reason, we think it is OK to let PCI bus driver to clear BME 
bit even there is active DMA transaction.

Thank you
Yao Jiewen


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 9:07 PM
> To: Zeng, Star ; Yao, Jiewen ;
> edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> 
> On 10/26/17 10:10, Zeng, Star wrote:
> > Is it security reason when IOMMU disabled and Bus Master not disabled?
> 
> No, I don't think there is a security issue here.
> 
> But, my previous assessment about VTdDxe was indeed wrong -- there may
> be a *correctness* issue.
> 
> Namely, if the IOMMU is de-activated by VTdDxe before PCI drivers abort
> pending DMA, then live system RAM references in the devices may become
> bogus. This is not a security issue (because de-activating the IOMMU
> will grant the devices access to all of the system RAM anyway), instead
> it's a correctness problem: DMA read/write may now be directed to the
> wrong spots in RAM (if the IOMMU mappings were not 1:1 previously).
> 
> So, I agree that PCI drivers should get a chance to abort pending DMA
> first, before the IOMMU driver removes the mappings.
> 
> > Could our code have a central place to disable Bus Master? For example
> PciBusDxe?
> 
> No, I don't think PciBusDxe is a good idea. Higher-level PCI drivers
> might want to do one-shot bus master DMA operations in their own EBS
> callbacks. If PciBusDxe's callback ran first, then these higher-level
> drivers would break.
> 
> For the SEV IOMMU driver, we solved the problem in commit 7aee391fa3d0
> ("OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()",
> 2017-09-07). I think the same could be applied to VTdDxe.
> 
> 
> Another idea (suggested / supported by Ard) was to modify the edk2
> ExitBootServices() implementation. In CoreExitBootServices()
> [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c], we could signal a special
> edk2 IOMMU event group, right after signaling
> "gEfiEventExitBootServicesGuid":
> 
>   //
>   // Notify other drivers that we are exiting boot services.
>   //
>   CoreNotifySignalList ();
> 
>   [HERE]
> 
>   //
>   // Report that ExitBootServices() has been called
>   //
>   REPORT_STATUS_CODE (
> EFI_PROGRESS_CODE,
> (EFI_SOFTWARE_EFI_BOOT_SERVICE |
> EFI_SW_BS_PC_EXIT_BOOT_SERVICES)
> );
> 
> This would ensure that the IOMMU callback ran last.
> 
> 
> Yet another idea (from Jiewen I think?) was to catch the
> EFI_SW_BS_PC_EXIT_BOOT_SERVICES status code in the IOMMU driver. I
> didn't like the idea because (IMO) it put too many requirements on
> platforms.
> 
> Thanks,
> Laszlo
> 
> 
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, October 26, 2017 3:53 PM
> > To: Zeng, Star ; Yao, Jiewen ;
> edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu 
> > Subject: Re: [PATCH] IntelSiliconPkg/VTdDxe: Change EBS Event TPL to
> CALLBACK.
> >
> > On 10/26/17 08:54, Zeng, Star wrote:
> >> Ok, please add more description into the commit log, for example, "PCI 
> >> device
> should disable BME at NOTIFY", etc.
> >
> > Last time we discussed this question, the consensus was that edk2 should not
> present any requirement for PCI drivers that is not required by the UEFI spec.
> UEFI drivers for PCI devices come from third parties as well, and those 
> drivers will
> only care about the UEFI spec (as they should), not about edk2.
> >
> > In fact, I think this additional requirement is not necessary:
> >
> > * In the earlier discussion (for the SEV IoMmuDxe in OVMF), it was really
> necessary to delay the IoMmuDxe ExitBootServices() callback after all the PCI
> driver callbacks. The reason for this was that the IoMmuDxe
> > ExitBootServices() callback was going to *lock down* all RAM from devices, 
> > and
> pending DMA had to be aborted before this lock-down.
> >
> > * In comparison, the VTdDxe callback at EBS does the opposite: it 
> > "disable[s]
> the protection and allow[s] all DMA access", in Jiewen's words from up-thread.
> So, IMO, neither the PCI driver requirement, nor this patch, are necessary --
> there is never an IOMMU state that conflicts with a 

Re: [edk2] [platforms: PATCH 06/10] Marvell/Library: MppLib: Take 0xFF placeholders into account

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:33AM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> The MppSel definition PCDs contain 0xFF placeholders for values that
> should be left untouched. MppLib needs to be taught how to take those
> into account.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Library/MppLib/MppLib.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/Platform/Marvell/Library/MppLib/MppLib.c 
> b/Platform/Marvell/Library/MppLib/MppLib.c
> index 383c820..9e42f08 100644
> --- a/Platform/Marvell/Library/MppLib/MppLib.c
> +++ b/Platform/Marvell/Library/MppLib/MppLib.c
> @@ -79,18 +79,22 @@ SetRegisterValue (
>BOOLEAN ReverseFlag
>)
>  {
> -  UINT32 i, j, CtrlVal;
> +  UINT32 i, j, CtrlVal, CtrlMask;
>INTN Sign;
>  
>Sign = ReverseFlag ? -1 : 1;
>  
>for (i = 0; i < RegCount; i++) {
>  CtrlVal = 0;
> +CtrlMask = 0;
>  for (j = 0; j < MPP_PINS_PER_REG; j++) {
> -  CtrlVal |= MPP_PIN_VAL(7 * (UINTN) ReverseFlag + j * Sign,
> -MppRegPcd[i][7 * (UINTN) ReverseFlag + j * Sign]);
> +  if (MppRegPcd[i][7 * (UINTN) ReverseFlag + j * Sign] != 0xff) {

This addition makes an already messy situation worse.
Can we have a descriptively named temporary variable for
"7 * (UINTN) ReverseFlag + j * Sign"?

/
Leif

> +CtrlVal |= MPP_PIN_VAL(7 * (UINTN) ReverseFlag + j * Sign,
> +  MppRegPcd[i][7 * (UINTN) ReverseFlag + j * Sign]);
> +CtrlMask |= MPP_PIN_VAL(7 * (UINTN) ReverseFlag + j * Sign, 0xf);
> +  }
>  }
> -MmioWrite32 (BaseAddr + 4 * i * Sign, CtrlVal);
> +MmioAndThenOr32 (BaseAddr + 4 * i * Sign, ~CtrlMask, CtrlVal);
>}
>  }
>  
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 05/10] Marvell/Library: MppLib: Disable the stack protector

[Ard Biesheuvel]

On 26 October 2017 at 14:26, Leif Lindholm  wrote:
> On Thu, Oct 26, 2017 at 03:19:32AM +0200, Marcin Wojtas wrote:
>> From: Ard Biesheuvel 
>>
>> MppLib may be used very early (in SEC), at which point stack protection
>> measures are more likely to cause harm than help, given that not even
>> the UART has been configured to the point where we can complain usefully.
>> So just disable it.
>
> It may. But it is also used by PlatInitDxe.
> Can we use different build options for SEC and later phases?
>

No, libraries are only built a single time during the build, and
linked into every module that depends on them. This is the same issue
we had with -mstrict-align.


>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Library/MppLib/MppLib.inf | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Platform/Marvell/Library/MppLib/MppLib.inf 
>> b/Platform/Marvell/Library/MppLib/MppLib.inf
>> index 2de9cd0..1268542 100644
>> --- a/Platform/Marvell/Library/MppLib/MppLib.inf
>> +++ b/Platform/Marvell/Library/MppLib/MppLib.inf
>> @@ -106,3 +106,6 @@
>>gMarvellTokenSpaceGuid.PcdChip3MppSel7
>>
>>gMarvellTokenSpaceGuid.PcdPciESdhci
>> +
>> +[BuildOptions]
>> +  *_*_*_CC_FLAGS = -fno-stack-protector
>> --
>> 2.7.4
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 05/10] Marvell/Library: MppLib: Disable the stack protector

[Leif Lindholm]

On Thu, Oct 26, 2017 at 03:19:32AM +0200, Marcin Wojtas wrote:
> From: Ard Biesheuvel 
> 
> MppLib may be used very early (in SEC), at which point stack protection
> measures are more likely to cause harm than help, given that not even
> the UART has been configured to the point where we can complain usefully.
> So just disable it.

It may. But it is also used by PlatInitDxe.
Can we use different build options for SEC and later phases?

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Library/MppLib/MppLib.inf | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Platform/Marvell/Library/MppLib/MppLib.inf 
> b/Platform/Marvell/Library/MppLib/MppLib.inf
> index 2de9cd0..1268542 100644
> --- a/Platform/Marvell/Library/MppLib/MppLib.inf
> +++ b/Platform/Marvell/Library/MppLib/MppLib.inf
> @@ -106,3 +106,6 @@
>gMarvellTokenSpaceGuid.PcdChip3MppSel7
>  
>gMarvellTokenSpaceGuid.PcdPciESdhci
> +
> +[BuildOptions]
> +  *_*_*_CC_FLAGS = -fno-stack-protector
> -- 
> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Laszlo Ersek]

Hi Jian,

On 10/26/17 09:38, Wang, Jian J wrote:
> Thanks for the feedback.
> 
>> -Original Message-
>> From: Yao, Jiewen
>> Sent: Thursday, October 26, 2017 2:49 PM
>> To: Wang, Jian J ; edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Wolman, Ayellet
>> ; Dong, Eric ; Zeng, Star
>> ; Yao, Jiewen 
>> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
>>
>> That is great work. Jian.
>>
>> Some suggestion for your consideration:
>>
>> 0) I suggest add Laszlo to review SMM part, and add Ruiyu to review
>> SMM_MEMORY_ATTRIBUTE_PROTOCOL.
>>
> 
> Ok, already pinged them.
> 
>> 1) Would you please mention what test we have done for this feature?
>> Such as OVMF/realPlatform? IA32/X64?
>>
> 
> I did following test:
> 
> Boot to shell (OVMF/Intel platform) (both IA32 and X64)
> Boot to Fedora 25 (64 only)

May I ask if you used KVM virtualization (i.e., a Linux host computer)
for this?

https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

> Windows 10 boot loader has a limit of 512-memory-descriptor, which will
> cause boot failure. This is due to a fact that enabling this feature will 
> cause
> more memory fragments (pool memory). Since this is a debug feature, I suppose
> this is an acceptable result.

This feature is large; I can't even attempt to review it in the time
that I could allocate to it.

However, I would like to regression test it (thank you Jiewen for the
reference!) Preferably, given that a v4 is already planned, I should
test v4.

If you can post v4 on Oct 27th (tomorrow), I'll make an effort to test
it in the afternoon / evening, on the 27th. (Please CC me.) Next week I
will be mostly inactive on edk2-devel -- I wouldn't like to block your
work, but I also wouldn't like an OVMF regression.

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

Re: [edk2] [platforms: PATCH 02/10] Marvell/Drivers: MvI2cDxe: Fix returning status in MvI2cStartRequest

[Marcin Wojtas]

2017-10-26 15:11 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 03:19:29AM +0200, Marcin Wojtas wrote:
>> In MvI2cStartRequest the status was assigned to the variable
>> without dereferencing a pointer. Fix it.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
>> b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> index 7faf1f7..8ed96f0 100755
>> --- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> +++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> @@ -631,7 +631,7 @@ MvI2cStartRequest (
>>}
>>
>>if (I2cStatus != NULL)
>> -I2cStatus = EFI_SUCCESS;
>> +*I2cStatus = Status;
>
> Oh, that's horrible! And only did not generate warnings because
> EFI_SUCCESS is 0.

This parameter is 'optional', so me must have been also lucky not to
use it in basic operation.

>
> However, you also change from setting *I2cStatus to Status instead of
> EFI_SUCCESS. This should be mentioned in commit message.
>
> /

We can leave EFI_SUCCESS, as it's the only option at this place. It
was changed to Status, due to first patch of the series. I will leave
the original and just modify *.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 01/10] Marvell/Drivers: MvI2cDxe: Abort transaction immediately upon fail

[Marcin Wojtas]

Hi Leif,

2017-10-26 14:51 GMT+02:00 Leif Lindholm :
> On Thu, Oct 26, 2017 at 03:19:28AM +0200, Marcin Wojtas wrote:
>> From: David Greeson 
>>
>> Although the I2C transaction routines were prepared to
>> return their status, they were never used. This could
>> cause bus lock-up e.g. in case of failing to send a
>> slave address, the data transfer was attempted to be
>> continued anyway.
>>
>> This patch fixes faulty behavior by checking transaction
>> status and stopping it immediately, once the fail
>> is detected.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: David Greeson 
>> [Style adjustment and cleanup]
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c | 34 +---
>>  1 file changed, 29 insertions(+), 5 deletions(-)
>>
>> diff --git a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c 
>> b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> index d85ee0b..7faf1f7 100755
>> --- a/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> +++ b/Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
>> @@ -565,6 +565,7 @@ MvI2cStartRequest (
>>UINTN Transmitted;
>>I2C_MASTER_CONTEXT *I2cMasterContext = I2C_SC_FROM_MASTER(This);
>>EFI_I2C_OPERATION *Operation;
>> +  EFI_STATUS Status = EFI_SUCCESS;
>>
>>ASSERT (RequestPacket != NULL);
>>ASSERT (I2cMasterContext != NULL);
>> @@ -574,35 +575,58 @@ MvI2cStartRequest (
>>  ReadMode = Operation->Flags & I2C_FLAG_READ;
>>
>>  if (Count == 0) {
>> -  MvI2cStart ( I2cMasterContext,
>> +  Status = MvI2cStart (I2cMasterContext,
>> (SlaveAddress << 1) | ReadMode,
>> I2C_TRANSFER_TIMEOUT
>
> Much as I appreciate seeing this form of the code, since it simplifies
> seeing the functional changes, this does cause those lines left
> unchanges to no longer conform to coding style.
> Can you please adjust throughout for a v2?
>

No problem. I of course saw style violations, but I gave up on them
for "no mix of functional improvements and style cleanups" contraint
:) I will correct the modified function calls.

>>   );
>>  } else if (!(Operation->Flags & I2C_FLAG_NORESTART)) {
>> -  MvI2cRepeatedStart ( I2cMasterContext,
>> +  Status = MvI2cRepeatedStart (I2cMasterContext,
>> (SlaveAddress << 1) | ReadMode,
>> I2C_TRANSFER_TIMEOUT
>>   );
>>  }
>>
>> +/* I2C transaction was aborted, so stop further transactions */
>> +if (EFI_ERROR (Status)) {
>> +  MvI2cStop (I2cMasterContext);
>> +  break;
>> +}
>> +
>> +/*
>> + * If sending the slave address was successful,
>> + * proceed to read or write section.
>> + */
>>  if (ReadMode) {
>> -  MvI2cRead ( I2cMasterContext,
>> +  Status = MvI2cRead (I2cMasterContext,
>>Operation->Buffer,
>>Operation->LengthInBytes,
>>,
>>Count == 1,
>>I2C_TRANSFER_TIMEOUT
>>   );
>> +  Operation->LengthInBytes = Transmitted;
>>  } else {
>> -  MvI2cWrite ( I2cMasterContext,
>> +  Status = MvI2cWrite (I2cMasterContext,
>> Operation->Buffer,
>> Operation->LengthInBytes,
>> ,
>> I2C_TRANSFER_TIMEOUT
>>);
>> +  Operation->LengthInBytes = Transmitted;
>>  }
>> +
>> +/*
>> + * The I2C read or write transaction failed.
>> + * Stop the I2C transaction.
>> + */
>> +if (EFI_ERROR (Status)) {
>> +  MvI2cStop (I2cMasterContext);
>> +  break;
>> +}
>> +
>> +/* Check if there is any more data to be sent */
>>  if (Count == RequestPacket->OperationCount - 1) {
>> -  MvI2cStop ( I2cMasterContext );
>> +  MvI2cStop (I2cMasterContext);
>
> Can you simply drop this non-functional change?
> I'd prefer the non-adherence to coding-style over a misleading
> history.
>

Right, I saw it after sending - I was cleaning dirty patch and
splitting into 3, this line got here by mistake.

> No objection to functional aspects of this patch.

Ok, thanks!

Marcin

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