[edk2] [patch 2/6] MdePkg: Add TPM TIS definition.

[jiewen yao]

TPM TIS (TPM Interface Specification) is TCG standard.
Add definition here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 MdePkg/Include/IndustryStandard/TpmTis.h | 183 +++
 1 file changed, 183 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/TpmTis.h

diff --git a/MdePkg/Include/IndustryStandard/TpmTis.h 
b/MdePkg/Include/IndustryStandard/TpmTis.h
new file mode 100644
index 000..519fa79
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/TpmTis.h
@@ -0,0 +1,183 @@
+/** @file
+  TPM Interface Specification definition.
+  It covers both TPM1.2 and TPM2.0.
+
+Copyright (c) 2016, 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.
+
+**/
+
+#ifndef _TPM_TIS_H_
+#define _TPM_TIS_H_
+
+//
+// Set structure alignment to 1-byte
+//
+#pragma pack (1)
+
+//
+// Register set map as specified in TIS specification Chapter 10
+//
+typedef struct {
+  ///
+  /// Used to gain ownership for this particular port.
+  ///
+  UINT8 Access; // 0
+  UINT8 Reserved1[7];   // 1
+  ///
+  /// Controls interrupts.
+  ///
+  UINT32IntEnable;  // 8
+  ///
+  /// SIRQ vector to be used by the TPM.
+  ///
+  UINT8 IntVector;  // 0ch
+  UINT8 Reserved2[3];   // 0dh
+  ///
+  /// What caused interrupt.
+  ///
+  UINT32IntSts; // 10h
+  ///
+  /// Shows which interrupts are supported by that particular TPM.
+  ///
+  UINT32IntfCapability; // 14h
+  ///
+  /// Status Register. Provides status of the TPM.
+  ///
+  UINT8 Status; // 18h
+  ///
+  /// Number of consecutive writes that can be done to the TPM.
+  ///
+  UINT16BurstCount; // 19h
+  UINT8 Reserved3[9];
+  ///
+  /// Read or write FIFO, depending on transaction.
+  ///
+  UINT32DataFifo;   // 24h
+  UINT8 Reserved4[0xed8];   // 28h
+  ///
+  /// Vendor ID
+  ///
+  UINT16Vid;// 0f00h
+  ///
+  /// Device ID
+  ///
+  UINT16Did;// 0f02h
+  ///
+  /// Revision ID
+  ///
+  UINT8 Rid;// 0f04h
+  UINT8 Reserved[0x7b]; // 0f05h
+  ///
+  /// Alias to I/O legacy space.
+  ///
+  UINT32LegacyAddress1; // 0f80h
+  ///
+  /// Additional 8 bits for I/O legacy space extension.
+  ///
+  UINT32LegacyAddress1Ex;   // 0f84h
+  ///
+  /// Alias to second I/O legacy space.
+  ///
+  UINT32LegacyAddress2; // 0f88h
+  ///
+  /// Additional 8 bits for second I/O legacy space extension.
+  ///
+  UINT32LegacyAddress2Ex;   // 0f8ch
+  ///
+  /// Vendor-defined configuration registers.
+  ///
+  UINT8 VendorDefined[0x70];// 0f90h
+} TIS_PC_REGISTERS;
+
+//
+// Restore original structure alignment
+//
+#pragma pack ()
+
+//
+// Define pointer types used to access TIS registers on PC
+//
+typedef TIS_PC_REGISTERS  *TIS_PC_REGISTERS_PTR;
+
+//
+// Define bits of ACCESS and STATUS registers
+//
+
+///
+/// This bit is a 1 to indicate that the other bits in this register are valid.
+///
+#define TIS_PC_VALIDBIT7
+///
+/// Indicate that this locality is active.
+///
+#define TIS_PC_ACC_ACTIVE   BIT5
+///
+/// Set to 1 to indicate that this locality had the TPM taken away while
+/// this locality had the TIS_PC_ACC_ACTIVE bit set.
+///
+#define TIS_PC_ACC_SEIZED   BIT4
+///
+/// Set to 1 to indicate that TPM MUST reset the
+/// TIS_PC_ACC_ACTIVE bit and remove ownership for localities less than the
+/// locality that is writing this bit.
+///
+#define TIS_PC_ACC_SEIZEBIT3
+///
+/// When this bit is 1, another locality is requesting usage of the TPM.
+///
+#define TIS_PC_ACC_PENDIND  BIT2
+///
+/// Set to 1 to indicate that this locality is requesting to use TPM.
+///
+#define TIS_PC_ACC_RQUUSE   BIT1
+///
+/// A value of 1 indicates that a T/OS has not been established on the platform
+///
+#define TIS_PC_ACC_ESTABLISHBIT0
+
+///
+/// This field indicates that STS_DATA and STS_EXPECT are valid
+///
+#define TIS_PC_STS_VA

[edk2] [patch 5/6] SecurityPkg: Add TPM PTP detection in TPM12 device lib.

[jiewen yao]

The TPM RequestUseTpm API can only set register to
use the hardware, but it can not be used to distinguish
TPM12 or TPM2 device.
TPM PTP defines same address with TIS, so we need
detect the TPM device is PTP or TIS in RequestUseTpm.
Also, Tcg2Config driver call RequestUseTpm to detect
TPM hardware device. So we have to add check here.
There is no need to support PTP CRB style SubmitCommand(),
because TPM2 device can not accept TPM12 style command.

This patch also uses TpmTis.h instead of duplicate
definition.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c | 281 ++
 1 file changed, 122 insertions(+), 159 deletions(-)

diff --git a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c 
b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
index b8d13aa..eaaf065 100644
--- a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
+++ b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
@@ -1,7 +1,7 @@
 /** @file
   TIS (TPM Interface Specification) functions used by TPM1.2.
   
-Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials 
 are licensed and made available under the terms and conditions of the BSD 
License 
@@ -23,164 +23,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
-//
-// Set structure alignment to 1-byte
-//
-#pragma pack (1)
-
-//
-// Register set map as specified in TIS specification Chapter 10
-//
-typedef struct {
-  ///
-  /// Used to gain ownership for this particular port.
-  ///
-  UINT8 Access; // 0
-  UINT8 Reserved1[7];   // 1
-  ///
-  /// Controls interrupts.
-  ///
-  UINT32IntEnable;  // 8
-  ///
-  /// SIRQ vector to be used by the TPM.
-  ///
-  UINT8 IntVector;  // 0ch
-  UINT8 Reserved2[3];   // 0dh
-  ///
-  /// What caused interrupt.
-  ///
-  UINT32IntSts; // 10h
-  ///
-  /// Shows which interrupts are supported by that particular TPM.
-  ///
-  UINT32IntfCapability; // 14h
-  ///
-  /// Status Register. Provides status of the TPM.
-  ///
-  UINT8 Status; // 18h
-  ///
-  /// Number of consecutive writes that can be done to the TPM.
-  ///
-  UINT16BurstCount; // 19h
-  UINT8 Reserved3[9];
-  ///
-  /// Read or write FIFO, depending on transaction.
-  ///
-  UINT32DataFifo;   // 24h
-  UINT8 Reserved4[0xed8];   // 28h
-  ///
-  /// Vendor ID
-  ///
-  UINT16Vid;// 0f00h
-  ///
-  /// Device ID
-  ///
-  UINT16Did;// 0f02h
-  ///
-  /// Revision ID
-  ///
-  UINT8 Rid;// 0f04h
-  ///
-  /// TCG defined configuration registers.
-  ///
-  UINT8 TcgDefined[0x7b];   // 0f05h
-  ///
-  /// Alias to I/O legacy space.
-  ///
-  UINT32LegacyAddress1; // 0f80h
-  ///
-  /// Additional 8 bits for I/O legacy space extension.
-  ///
-  UINT32LegacyAddress1Ex;   // 0f84h
-  ///
-  /// Alias to second I/O legacy space.
-  ///
-  UINT32LegacyAddress2; // 0f88h
-  ///
-  /// Additional 8 bits for second I/O legacy space extension.
-  ///
-  UINT32LegacyAddress2Ex;   // 0f8ch
-  ///
-  /// Vendor-defined configuration registers.
-  ///
-  UINT8 VendorDefined[0x70];// 0f90h
-} TIS_PC_REGISTERS;
-
-//
-// Restore original structure alignment
-//
-#pragma pack ()
-
-//
-// Define pointer types used to access TIS registers on PC
-//
-typedef TIS_PC_REGISTERS  *TIS_PC_REGISTERS_PTR;
-
-//
-// Define bits of ACCESS and STATUS registers
-//
-
-///
-/// This bit is a 1 to indicate that the other bits in this register are valid.
-///
-#define TIS_PC_VALIDBIT7
-///
-/// Indicate that this locality is active.
-///
-#define TIS_PC_ACC_ACTIVE   BIT5
-///
-/// Set to 1 to indicate that this locality had the TPM taken away while
-/// this locality had the TIS_PC_ACC_ACTIVE bit set.
-///
-#define TIS_PC_ACC_SEIZED   BIT4
-///
-/// Set to 1 to indicate that TPM MUST reset the
-/// TIS_PC_ACC_ACTIVE bit and remove ownership for localities less than the
-/// locality that is writing this bit.
-///
-#define TIS_PC_ACC_SEIZEBIT3
-///
-/// When this bit is 1, another locality is requesting us

[edk2] [patch 4/6] SecurityPkg: Add TPM PTP support in TCG2 SMM.

[jiewen yao]

TPM2 hardware may support PTP FIFO/TIS interface
or PTP CRB interface. The original ACPI table only
handles PTP FIFO/TIS interface. This patch adds
PTP CRB interface support.
The current logic is that SMM driver will runtime
detect TPM device interface (CRB or FIFO/TIS) and
publish TPM2 table based on result.

It is compatible for old TPM2 FIFO/TIS device and
new TPM2 CRB device.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c   | 64 -
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h   |  5 ++-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf |  4 ++-
 3 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
index 503cc18..dab1f53 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c
@@ -9,7 +9,7 @@
 
   PhysicalPresenceCallback() and MemoryClearCallback() will receive untrusted 
input and do some check.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 
@@ -22,6 +22,48 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "Tcg2Smm.h"
 
+typedef enum {
+  PtpInterfaceTis,
+  PtpInterfaceFifo,
+  PtpInterfaceCrb,
+  PtpInterfaceMax,
+} PTP_INTERFACE_TYPE;
+
+/**
+  Return PTP interface type.
+
+  @param[in] RegisterPointer to PTP register.
+
+  @return PTP interface type.
+**/
+PTP_INTERFACE_TYPE
+GetPtpInterface (
+  IN VOID *Register
+  )
+{
+  PTP_CRB_INTERFACE_IDENTIFIER  InterfaceId;
+  PTP_FIFO_INTERFACE_CAPABILITY InterfaceCapability;
+
+  //
+  // Check interface id
+  //
+  InterfaceId.Uint32 = MmioRead32 ((UINTN)&((PTP_CRB_REGISTERS 
*)Register)->InterfaceId);
+  InterfaceCapability.Uint32 = MmioRead32 ((UINTN)&((PTP_FIFO_REGISTERS 
*)Register)->InterfaceCapability);
+
+  if ((InterfaceId.Bits.InterfaceType == 
PTP_INTERFACE_IDENTIFIER_INTERFACE_TYPE_CRB) &&
+  (InterfaceId.Bits.InterfaceVersion == 
PTP_INTERFACE_IDENTIFIER_INTERFACE_VERSION_CRB) &&
+  (InterfaceId.Bits.CapCRB != 0)) {
+return PtpInterfaceCrb;
+  }
+  if ((InterfaceId.Bits.InterfaceType == 
PTP_INTERFACE_IDENTIFIER_INTERFACE_TYPE_FIFO) &&
+  (InterfaceId.Bits.InterfaceVersion == 
PTP_INTERFACE_IDENTIFIER_INTERFACE_VERSION_FIFO) &&
+  (InterfaceId.Bits.CapFIFO != 0) &&
+  (InterfaceCapability.Bits.InterfaceVersion == 
INTERFACE_CAPABILITY_INTERFACE_VERSION_PTP)) {
+return PtpInterfaceFifo;
+  }
+  return PtpInterfaceTis;
+}
+
 EFI_TPM2_ACPI_TABLE  mTpm2AcpiTemplate = {
   {
 EFI_ACPI_5_0_TRUSTED_COMPUTING_PLATFORM_2_TABLE_SIGNATURE,
@@ -288,6 +330,8 @@ PublishTpm2 (
   EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
   UINTN  TableKey;
   UINT64 OemTableId;
+  EFI_TPM2_ACPI_CONTROL_AREA *ControlArea;
+  PTP_INTERFACE_TYPE InterfaceType;
 
   //
   // Measure to PCR[0] with event EV_POST_CODE ACPI DATA
@@ -301,6 +345,24 @@ PublishTpm2 (
 sizeof(mTpm2AcpiTemplate)
 );
 
+  InterfaceType = GetPtpInterface ((VOID *) (UINTN) PcdGet64 
(PcdTpmBaseAddress));
+  switch (InterfaceType) {
+  case PtpInterfaceCrb:
+mTpm2AcpiTemplate.StartMethod = 
EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTERFACE;
+mTpm2AcpiTemplate.AddressOfControlArea = PcdGet64 (PcdTpmBaseAddress) + 
0x40;
+ControlArea = (EFI_TPM2_ACPI_CONTROL_AREA 
*)(UINTN)mTpm2AcpiTemplate.AddressOfControlArea;
+ControlArea->CommandSize  = 0xF80;
+ControlArea->ResponseSize = 0xF80;
+ControlArea->Command  = PcdGet64 (PcdTpmBaseAddress) + 0x80;
+ControlArea->Response = PcdGet64 (PcdTpmBaseAddress) + 0x80;
+break;
+  case PtpInterfaceFifo:
+  case PtpInterfaceTis:
+break;
+  default:
+break;
+  }
+
   CopyMem (mTpm2AcpiTemplate.Header.OemId, PcdGetPtr (PcdAcpiDefaultOemId), 
sizeof (mTpm2AcpiTemplate.Header.OemId));
   OemTableId = PcdGet64 (PcdAcpiDefaultOemTableId);
   CopyMem (&mTpm2AcpiTemplate.Header.OemTableId, &OemTableId, sizeof (UINT64));
diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h 
b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
index ebd71ed..62374a2 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h
@@ -1,7 +1,7 @@
 /** @file
   The header file for Tcg2 SMM driver.
   
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 
@@ -37,6 +37,9 @@ WI

[edk2] [patch 6/6] SecurityPkg: Add TPM PTP support in TCG2 Config.

[jiewen yao]

This patch add PTP CRB support in BIOS Setup.
It can:
1) Display the PTP capability (TIS/FIFO/CRB)
2) Display the PTP current interface (TIS/FIFO/CRB)
3) Let user select CRB/FIFO, if supported.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr|  28 ++-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c|  31 ++--
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf |   4 +-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c  | 221 ++-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigNvData.h|  22 ++-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigStrings.uni |  20 +-
 6 files changed, 299 insertions(+), 27 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr 
b/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
index b350444..a72f824 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr
@@ -1,7 +1,7 @@
 /** @file
   VFR file used by the TCG2 configuration component.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 
@@ -51,6 +51,32 @@ formset
 option text = STRING_TOKEN(STR_TCG2_TPM_2_0_DTPM), value = 
TPM_DEVICE_2_0_DTPM, flags = RESET_REQUIRED;
 endoneof;
 
+suppressif ideqvallist TCG2_CONFIGURATION.TpmDevice == TPM_DEVICE_NULL 
TPM_DEVICE_1_2;
+text
+  help   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_STATE_HELP),
+  text   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_STATE_PROMPT),
+text   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_STATE_CONTENT);
+
+text
+  help   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_CAPABILITY_HELP),
+  text   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_CAPABILITY_PROMPT),
+text   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_CAPABILITY_CONTENT);
+
+suppressif ideqval 
TCG2_CONFIGURATION_INFO.TpmDeviceInterfacePtpFifoSupported == 0
+OR ideqval 
TCG2_CONFIGURATION_INFO.TpmDeviceInterfacePtpCrbSupported == 0;
+oneof varid  = TCG2_CONFIGURATION_INFO.TpmDeviceInterfaceAttempt,
+  questionid = KEY_TPM_DEVICE_INTERFACE,
+  prompt = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_PROMPT),
+  help   = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_HELP),
+  flags  = INTERACTIVE,
+option text = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_TIS), 
 value = TPM_DEVICE_INTERFACE_TIS,  flags = RESET_REQUIRED;
+option text = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_PTP_FIFO),
 value = TPM_DEVICE_INTERFACE_PTP_FIFO, flags = RESET_REQUIRED;
+option text = STRING_TOKEN(STR_TCG2_DEVICE_INTERFACE_PTP_CRB), 
 value = TPM_DEVICE_INTERFACE_PTP_CRB,  flags = DEFAULT | MANUFACTURING | 
RESET_REQUIRED;
+endoneof;
+endif;
+
+endif;
+
 subtitle text = STRING_TOKEN(STR_NULL);
 
 suppressif ideqvallist TCG2_CONFIGURATION.TpmDevice == TPM_DEVICE_NULL 
TPM_DEVICE_1_2;
diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c 
b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
index 8813683..968670f 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c
@@ -1,7 +1,7 @@
 /** @file
   The module entry point for Tcg2 configuration module.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 
@@ -159,20 +159,6 @@ Tcg2ConfigDriverEntryPoint (
   UpdateDefaultPCRBanks (Tcg2ConfigBin + sizeof(UINT32), 
ReadUnaligned32((UINT32 *)Tcg2ConfigBin) - sizeof(UINT32), 
CurrentActivePCRBanks);
 
   //
-  // Save to variable so platform driver can get it.
-  //
-  Status = gRT->SetVariable (
-  TCG2_STORAGE_NAME,
-  &gTcg2ConfigFormSetGuid,
-  EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS,
-  sizeof(Tcg2Configuration),
-  &Tcg2Configuration
-  );
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "Tcg2ConfigDriver: Fail to set TCG2_STORAGE_NAME\n"));
-  }
-
-  //
   // Sync data from PCD to variable, so that we do not need detect again in S3 
phase.
   //
   Tcg2DeviceDetection.TpmDeviceDetected = TPM_DEVICE_NULL;
@@ -184,6 +170,7 @@ Tcg2ConfigDriverEntryPoint (
   }
 
   PrivateData->TpmDeviceDetected = Tcg2DeviceDetection.TpmDeviceDetected;
+  Tcg2Configuration.TpmDevice = Tcg2DeviceDetection.TpmDeviceDetected;
 
   //
   // Save to variable so platform d

[edk2] [patch 0/6] Add TPM PTP CRB support.

[jiewen yao]

This series patches enable TPM PTP CRB support in EDKII.
TPM PTP (Platform TPM Profile) is TCG standard.
It covers both FIFO/TIS and CRB (Command-Response-Buffer).

jiewen yao (6):
  MdePkg: Add TPM PTP definition.
  MdePkg: Add TPM TIS definition.
  SecurityPkg: Add TPM PTP support in TPM2 device lib.
  SecurityPkg: Add TPM PTP support in TCG2 SMM.
  SecurityPkg: Add TPM PTP detection in TPM12 device lib.
  SecurityPkg: Add TPM PTP support in TCG2 Config.

 MdePkg/Include/IndustryStandard/TpmPtp.h   | 522 
 MdePkg/Include/IndustryStandard/TpmTis.h   | 183 +++
 SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c  | 281 +--
 .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf|  10 +-
 .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni|  11 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c|  15 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf  |  10 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.uni  |  11 +-
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c| 537 +
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Tis.c| 169 +--
 SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr  |  28 +-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c  |  31 +-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf   |   4 +-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c| 221 -
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigNvData.h  |  22 +-
 SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigStrings.uni   |  20 +-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c  |  64 ++-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.h  |   5 +-
 SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf|   4 +-
 19 files changed, 1775 insertions(+), 373 deletions(-)
 create mode 100644 MdePkg/Include/IndustryStandard/TpmPtp.h
 create mode 100644 MdePkg/Include/IndustryStandard/TpmTis.h
 create mode 100644 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c

-- 
1.9.5.msysgit.0

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

[edk2] [patch 1/6] MdePkg: Add TPM PTP definition.

[jiewen yao]

TPM PTP (Platform TPM Profile) is TCG standard.
Add definition here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 MdePkg/Include/IndustryStandard/TpmPtp.h | 522 +++
 1 file changed, 522 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/TpmPtp.h

diff --git a/MdePkg/Include/IndustryStandard/TpmPtp.h 
b/MdePkg/Include/IndustryStandard/TpmPtp.h
new file mode 100644
index 000..0796512
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/TpmPtp.h
@@ -0,0 +1,522 @@
+/** @file
+  Platform TPM Profile Specification definition for TPM2.0.
+  It covers both FIFO and CRB interface.
+
+Copyright (c) 2016, 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.
+
+**/
+
+#ifndef _TPM_PTP_H_
+#define _TPM_PTP_H_
+
+//
+// PTP FIFO definition
+//
+
+//
+// Set structure alignment to 1-byte
+//
+#pragma pack (1)
+
+//
+// Register set map as specified in PTP specification Chapter 5
+//
+typedef struct {
+  ///
+  /// Used to gain ownership for this particular port.
+  ///
+  UINT8 Access; // 0
+  UINT8 Reserved1[7];   // 1
+  ///
+  /// Controls interrupts.
+  ///
+  UINT32IntEnable;  // 8
+  ///
+  /// SIRQ vector to be used by the TPM.
+  ///
+  UINT8 IntVector;  // 0ch
+  UINT8 Reserved2[3];   // 0dh
+  ///
+  /// What caused interrupt.
+  ///
+  UINT32IntSts; // 10h
+  ///
+  /// Shows which interrupts are supported by that particular TPM.
+  ///
+  UINT32InterfaceCapability;// 14h
+  ///
+  /// Status Register. Provides status of the TPM.
+  ///
+  UINT8 Status; // 18h
+  ///
+  /// Number of consecutive writes that can be done to the TPM.
+  ///
+  UINT16BurstCount; // 19h
+  ///
+  /// Additional Status Register.
+  ///
+  UINT8 StatusEx;   // 1Bh
+  UINT8 Reserved3[8];
+  ///
+  /// Read or write FIFO, depending on transaction.
+  ///
+  UINT32DataFifo;   // 24h
+  UINT8 Reserved4[8];   // 28h
+  ///
+  /// Used to identify the Interface types supported by the TPM.
+  ///
+  UINT32InterfaceId;// 30h
+  UINT8 Reserved5[0x4c];// 34h
+  ///
+  /// Extended ReadFIFO or WriteFIFO, depending on the current bus cycle (read 
or write)
+  ///
+  UINT32XDataFifo;  // 80h
+  UINT8 Reserved6[0xe7c];   // 84h
+  ///
+  /// Vendor ID
+  ///
+  UINT16Vid;// 0f00h
+  ///
+  /// Device ID
+  ///
+  UINT16Did;// 0f02h
+  ///
+  /// Revision ID
+  ///
+  UINT8 Rid;// 0f04h
+  UINT8 Reserved[0xfb]; // 0f05h
+} PTP_FIFO_REGISTERS;
+
+//
+// Restore original structure alignment
+//
+#pragma pack ()
+
+//
+// Define pointer types used to access TIS registers on PC
+//
+typedef PTP_FIFO_REGISTERS  *PTP_FIFO_REGISTERS_PTR;
+
+//
+// Define bits of FIFO Interface Identifier Register
+//
+typedef union {
+  struct {
+UINT32   InterfaceType:4;
+UINT32   InterfaceVersion:4;
+UINT32   CapLocality:1;
+UINT32   Reserved1:2;
+UINT32   CapDataXferSizeSupport:2;
+UINT32   CapFIFO:1;
+UINT32   CapCRB:1;
+UINT32   CapIFRes:2;
+UINT32   InterfaceSelector:2;
+UINT32   IntfSelLock:1;
+UINT32   Reserved2:4;
+UINT32   Reserved3:8;
+  } Bits;
+  UINT32   Uint32;
+} PTP_FIFO_INTERFACE_IDENTIFIER;
+
+//
+// Define bits of FIFO Interface Capability Register
+//
+typedef union {
+  struct {
+UINT32   DataAvailIntSupport:1;
+UINT32   StsValidIntSupport:1;
+UINT32   LocalityChangeIntSupport:1;
+UINT32   InterruptLevelHigh:1;
+UINT32   InterruptLevelLow:1;
+UINT32   InterruptEdgeRising:1;
+UINT32   InterruptEdgeFalling:1;
+UINT32   CommandReadyIntSupport:1;
+UINT32   BurstCountStatic:1;
+UINT32   DataTransferSizeSupport:2;
+UINT32   Reserved:17;
+UINT32   InterfaceVersion:3;
+UINT32   Reserved2:1;
+  } Bits;
+  UINT32   Uint32;
+} PTP_FIFO_INTERFACE_CAPABILITY;
+
+///
+/// InterfaceVersion
+///
+#define INTERFACE_CAPABILITY_INTE

Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address

[洪銘駿]

Thanks Michael, Siyuan and Samer.

We have used the Pcd to decide the type for Dhcp server and the setting is 
DUID-LLT to meet the requirement from customer datacenter, unfortunately, their 
environment only supports DUID-LL(T), the DUID-UUID is not a accepted type in 
their usage and they even cannot move the setting to DUID-UUID since the PXE 
environment has been used by many products with a lot of systems on-line, not 
possible to do the change only for the project that created with multi-network 
devices. So this is the problem what we have and must to come out a way to 
generate DUID-LL(T) per own MAC address to meet the mechanism of customer DC.
  
gEfiNetworkPkgTokenSpaceGuid.PcdDhcp6UidType|1|UINT8|0x1001

About this requirement which is violate the RFC, we didn't got the detail 
answer from customer but it's a true requirement for us now.

Thanks,
Jim

-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com] 
Sent: Friday, January 22, 2016 11:13 AM
To: mc...@ipxe.org; siyuan...@intel.com
Cc: edk2-devel@lists.01.org; Jim Hung (洪銘駿)
Subject: RE: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

A while ago, a change was added to EDK2 to introduce a Pcd to select either 
DUID-LLT or DUID-UUID. Did you look at modifying that PCD?



Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-Original Message-
From: Fu, Siyuan [siyuan...@intel.com]
Received: Thursday, 21 Jan 2016, 8:59PM
To: Michael Brown [mc...@ipxe.org]
CC: edk2-devel@lists.01.org [edk2-devel@lists.01.org]; Jim Hung (洪銘駿) 
{[jim.h...@quantatw.com]
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

Thanks Michael, maybe use UUID is a good way to solve this issue. But I still 
curious why the server has such requirement which is apparent violate the RFC 
requirement. Could you provide more details?

Best Regards
Siyuan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Brown
Sent: Thursday, January 21, 2016 10:49 PM
To: "Jim Hung (洪銘駿)" ; edk2-devel@lists.01.org
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
> There is one network issue in customer datacenter, the 
> “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source 
> network device if multi LANs on the system. And, this cause the PXE boot 
> failure at customer datacenter environment.
>
> On our system, it has two network devices, one is Intel NIC, the other is 
> Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to 
> generate the DULD-LLT. However at customer Data Center, they do NOT accept 
> this. Each interface needs to generate their DUID-LL(T) based on their own 
> LL. This means that they must use their own MAC address. Both interface will 
> have different DUIL-LL(T), which is technically against the RFC here.
>
> Can you please help to check how networkstack driver could be supported on 
> this requirement?

We have encountered exactly the same problem in iPXE.  We decided to adopt the 
solution proposed by RFC6355: we use DUID-UUID rather than any of the 
DUID-LL(T) variants.  This is the only sensible way in which we can hope to 
make the same choice of DUID as the loaded operating system.

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

[edk2] [patch 3/6] SecurityPkg: Add TPM PTP support in TPM2 device lib.

[jiewen yao]

TPM2 hardware may support PTP FIFO/TIS interface
or PTP CRB interface. The original lib only handles
PTP FIFO/TIS interface. This patch adds PTP CRB
interface support.
The current logic is that lib will runtime detect
TPM device interface (CRB or FIFO/TIS) and call
proper function to access hardware.

It is compatible for old TPM2 FIFO/TIS device and
new TPM2 CRB device.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
CC: "Zhang, Chao B" 
---
 .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf|  10 +-
 .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni|  11 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c|  15 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf  |  10 +-
 .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.uni  |  11 +-
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c| 537 +
 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Tis.c| 169 +--
 7 files changed, 579 insertions(+), 184 deletions(-)
 create mode 100644 SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c

diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf 
b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
index 2d41e7c..976972d 100644
--- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
+++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
@@ -1,11 +1,12 @@
 ## @file
-#  Provides TPM 2.0 TIS functions for DTPM
+#  Provides TPM 2.0 TIS/PTP functions for DTPM
 #  
-#  This library implements TIS (TPM Interface Specification) functions which 
is 
-#  used for every TPM 2.0 command. Choosing this library means platform uses 
and 
+#  This library implements TIS (TPM Interface Specification) and
+#  PTP (Platform TPM Profile) functions which is
+#  used for every TPM 2.0 command. Choosing this library means platform uses 
and
 #  only uses TPM 2.0 DTPM device.
 #
-# Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2013 - 2016, 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
@@ -32,6 +33,7 @@
 
 [Sources]
   Tpm2Tis.c
+  Tpm2Ptp.c
   Tpm2DeviceLibDTpm.c
 
 [Packages]
diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni 
b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni
index 1f3709c..94180ff 100644
--- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni
+++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.uni
@@ -1,11 +1,12 @@
 // /** @file
-// Provides TPM 2.0 TIS functions for DTPM
+// Provides TPM 2.0 TIS/PTP functions for DTPM
 //
-// This library implements TIS (TPM Interface Specification) functions which is
+// This library implements TIS (TPM Interface Specification) and
+// PTP (Platform TPM Profile) functions which is
 // used for every TPM 2.0 command. Choosing this library means platform uses 
and
 // only uses TPM 2.0 DTPM device.
 //
-// Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.
+// Copyright (c) 2013 - 2016, 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
@@ -17,7 +18,7 @@
 // **/
 
 
-#string STR_MODULE_ABSTRACT #language en-US "Provides TPM 2.0 TIS 
functions for DTPM"
+#string STR_MODULE_ABSTRACT #language en-US "Provides TPM 2.0 
TIS/PTP functions for DTPM"
 
-#string STR_MODULE_DESCRIPTION  #language en-US "This library 
implements TIS (TPM Interface Specification) functions which is used for every 
TPM 2.0 command. Choosing this library means platform uses and only uses TPM 
2.0 DTPM device."
+#string STR_MODULE_DESCRIPTION  #language en-US "This library 
implements TIS (TPM Interface Specification) and PTP (Platform TPM Profile) 
functions which is used for every TPM 2.0 command. Choosing this library means 
platform uses and only uses TPM 2.0 DTPM device."
 
diff --git a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c 
b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
index 6a6a042..a50d266 100644
--- a/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
+++ b/SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c
@@ -3,7 +3,7 @@
   It can be registered to Tpm2 Device router, to be active TPM2 engine,
   based on platform setting.
 
-Copyright (c) 2013, Intel Corporation. All rights reserved. 
+Copyright (c) 2013 - 2016, 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
@@ -22,6 +22,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #incl

Re: [edk2] [PATCH v2] NetworkPkg:Fix Network memory leak when calling GetModeData interface

[Fu, Siyuan]

Hi, Lubo

1.
Below lines in Ip6Dxe/ComponentName.c changes original If condition is 
incorrect. The first else means Status is an EFI error, so we shouldn't check 
the IsStarted flag.
-  if (!EFI_ERROR (Status) && Ip6ModeData.IsStarted) {
-Status = NetLibIp6ToStr (&Ip6ModeData.ConfigData.StationAddress, Address, 
sizeof(Address));
-if (EFI_ERROR (Status)) {
-  return Status;
+  if (!EFI_ERROR (Status)) {
+if (Ip6ModeData.AddressList != NULL) {
+  FreePool (Ip6ModeData.AddressList);
...
   } else if (!Ip6ModeData.IsStarted) {
 UnicodeSPrint (HandleName, sizeof(HandleName), L"IPv6(Not started)");
   } else {

2.
In TcpMisc.c the code doesn't check the return status, and not initialize the 
Ip6Mode , so the Ip6Mode may not contains meaningful value. 

Best Regards
Siyuan

-Original Message-
From: Zhang, Lubo 
Sent: Friday, January 22, 2016 12:23 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [PATCH v2] NetworkPkg:Fix Network memory leak when calling GetModeData 
interface

v2:
* Check for NULL pointer before Free them.

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Dhcp6Dxe/ComponentName.c|  9 -
 NetworkPkg/DnsDxe/ComponentName.c  | 14 
 NetworkPkg/DnsDxe/DnsImpl.c| 32 ++---
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  7 +++-
 NetworkPkg/Ip6Dxe/ComponentName.c  | 64 --
 NetworkPkg/IpSecDxe/IkeService.c   | 25 +
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c   | 23 
 NetworkPkg/TcpDxe/TcpMisc.c| 24 +
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  7 +++-
 NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  | 24 +
 10 files changed, 203 insertions(+), 26 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/ComponentName.c 
b/NetworkPkg/Dhcp6Dxe/ComponentName.c
index 927a7fe..c34681d 100644
--- a/NetworkPkg/Dhcp6Dxe/ComponentName.c
+++ b/NetworkPkg/Dhcp6Dxe/ComponentName.c
@@ -284,11 +284,18 @@ UpdateName (
 if (Dhcp6ModeData.Ia->State > Dhcp6Rebinding) {
   return EFI_DEVICE_ERROR;
 }
 HandleName = mDhcp6ControllerName[Dhcp6ModeData.Ia->State];
   }
-  
+
+  if (Dhcp6ModeData.Ia != NULL) {
+FreePool (Dhcp6ModeData.Ia);
+  }
+  if (Dhcp6ModeData.ClientId != NULL) {
+FreePool (Dhcp6ModeData.ClientId);
+  }
+
   Status = AddUnicodeString2 (
  "eng",
  gDhcp6ComponentName.SupportedLanguages,
  &gDhcp6ControllerNameTable,
  HandleName,
diff --git a/NetworkPkg/DnsDxe/ComponentName.c 
b/NetworkPkg/DnsDxe/ComponentName.c
index d95ed92..8dcf280 100644
--- a/NetworkPkg/DnsDxe/ComponentName.c
+++ b/NetworkPkg/DnsDxe/ComponentName.c
@@ -209,10 +209,17 @@ UpdateDns4Name (
 ModeData.DnsConfigData.StationIp.Addr[2],
 ModeData.DnsConfigData.StationIp.Addr[3],
 ModeData.DnsConfigData.LocalPort
 );
 
+  if (ModeData.DnsCacheList != NULL) {
+FreePool (ModeData.DnsCacheList);
+  }
+  if (ModeData.DnsServerList != NULL) {
+FreePool (ModeData.DnsServerList);
+  }
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
@@ -279,10 +286,17 @@ UpdateDns6Name (
 L"DNSv6 (StationIp=%s, LocalPort=%d)",
 Address,
 ModeData.DnsConfigData.LocalPort
 );
 
+  if (ModeData.DnsCacheList != NULL) {
+FreePool (ModeData.DnsCacheList);
+  }
+  if (ModeData.DnsServerList != NULL) {
+FreePool (ModeData.DnsServerList);
+  }
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index 
71dacce..3afd6a5 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -616,15 +616,39 @@ Dns6GetMapping (
   }
 
   while (!EFI_ERROR (gBS->CheckEvent (Service->TimerToGetMap))) {
 Udp->Poll (Udp);
 
-if (!EFI_ERROR (Udp->GetModeData (Udp, NULL, &Ip6Mode, NULL, NULL)) &&
-Ip6Mode.IsConfigured) {
+if (!EFI_ERROR (Udp->GetModeData (Udp, NULL, &Ip6Mode, NULL, NULL))) {
+  if (Ip6Mode.AddressList != NULL) {
+FreePool (Ip6Mode.AddressList);
+  }
 
-  Udp->Configure (Udp, NULL);
-  return (BOOLEAN) (Udp->Configure (Udp, UdpCfgData) == EFI_SUCCESS);
+  if (Ip6Mode.GroupTable != NULL) {
+FreePool (Ip6Mode.GroupTable);
+  }
+
+  if (Ip6Mode.RouteTable != NULL) {
+FreePool (Ip6Mode.RouteTable);
+  }
+
+  if (Ip6Mode.NeighborCache != NULL) {
+FreePool (Ip6Mode.NeighborCache);
+  }
+
+  if (Ip6Mode.PrefixTable != NULL) {
+FreePool (Ip6Mode.PrefixTabl

[edk2] [PATCH v2] NetworkPkg:Fix Network memory leak when calling GetModeData interface

[Zhang Lubo]

v2:
* Check for NULL pointer before Free them.

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode
data structure. It's callers responsibility to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Dhcp6Dxe/ComponentName.c|  9 -
 NetworkPkg/DnsDxe/ComponentName.c  | 14 
 NetworkPkg/DnsDxe/DnsImpl.c| 32 ++---
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  7 +++-
 NetworkPkg/Ip6Dxe/ComponentName.c  | 64 --
 NetworkPkg/IpSecDxe/IkeService.c   | 25 +
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c   | 23 
 NetworkPkg/TcpDxe/TcpMisc.c| 24 +
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  7 +++-
 NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  | 24 +
 10 files changed, 203 insertions(+), 26 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/ComponentName.c 
b/NetworkPkg/Dhcp6Dxe/ComponentName.c
index 927a7fe..c34681d 100644
--- a/NetworkPkg/Dhcp6Dxe/ComponentName.c
+++ b/NetworkPkg/Dhcp6Dxe/ComponentName.c
@@ -284,11 +284,18 @@ UpdateName (
 if (Dhcp6ModeData.Ia->State > Dhcp6Rebinding) {
   return EFI_DEVICE_ERROR;
 }
 HandleName = mDhcp6ControllerName[Dhcp6ModeData.Ia->State];
   }
-  
+
+  if (Dhcp6ModeData.Ia != NULL) {
+FreePool (Dhcp6ModeData.Ia);
+  }
+  if (Dhcp6ModeData.ClientId != NULL) {
+FreePool (Dhcp6ModeData.ClientId);
+  }
+
   Status = AddUnicodeString2 (
  "eng",
  gDhcp6ComponentName.SupportedLanguages,
  &gDhcp6ControllerNameTable,
  HandleName,
diff --git a/NetworkPkg/DnsDxe/ComponentName.c 
b/NetworkPkg/DnsDxe/ComponentName.c
index d95ed92..8dcf280 100644
--- a/NetworkPkg/DnsDxe/ComponentName.c
+++ b/NetworkPkg/DnsDxe/ComponentName.c
@@ -209,10 +209,17 @@ UpdateDns4Name (
 ModeData.DnsConfigData.StationIp.Addr[2],
 ModeData.DnsConfigData.StationIp.Addr[3],
 ModeData.DnsConfigData.LocalPort
 );
 
+  if (ModeData.DnsCacheList != NULL) {
+FreePool (ModeData.DnsCacheList);
+  }
+  if (ModeData.DnsServerList != NULL) {
+FreePool (ModeData.DnsServerList);
+  }
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
@@ -279,10 +286,17 @@ UpdateDns6Name (
 L"DNSv6 (StationIp=%s, LocalPort=%d)",
 Address,
 ModeData.DnsConfigData.LocalPort
 );
 
+  if (ModeData.DnsCacheList != NULL) {
+FreePool (ModeData.DnsCacheList);
+  }
+  if (ModeData.DnsServerList != NULL) {
+FreePool (ModeData.DnsServerList);
+  }
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c
index 71dacce..3afd6a5 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -616,15 +616,39 @@ Dns6GetMapping (
   }
 
   while (!EFI_ERROR (gBS->CheckEvent (Service->TimerToGetMap))) {
 Udp->Poll (Udp);
 
-if (!EFI_ERROR (Udp->GetModeData (Udp, NULL, &Ip6Mode, NULL, NULL)) &&
-Ip6Mode.IsConfigured) {
+if (!EFI_ERROR (Udp->GetModeData (Udp, NULL, &Ip6Mode, NULL, NULL))) {
+  if (Ip6Mode.AddressList != NULL) {
+FreePool (Ip6Mode.AddressList);
+  }
 
-  Udp->Configure (Udp, NULL);
-  return (BOOLEAN) (Udp->Configure (Udp, UdpCfgData) == EFI_SUCCESS);
+  if (Ip6Mode.GroupTable != NULL) {
+FreePool (Ip6Mode.GroupTable);
+  }
+
+  if (Ip6Mode.RouteTable != NULL) {
+FreePool (Ip6Mode.RouteTable);
+  }
+
+  if (Ip6Mode.NeighborCache != NULL) {
+FreePool (Ip6Mode.NeighborCache);
+  }
+
+  if (Ip6Mode.PrefixTable != NULL) {
+FreePool (Ip6Mode.PrefixTable);
+  }
+
+  if (Ip6Mode.IcmpTypeList != NULL) {
+FreePool (Ip6Mode.IcmpTypeList);
+  }
+
+  if (Ip6Mode.IsConfigured) {
+Udp->Configure (Udp, NULL);
+return (BOOLEAN) (Udp->Configure (Udp, UdpCfgData) == EFI_SUCCESS);
+  }
 }
   }
 
   return FALSE;
 }
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c 
b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
index e5cf894..01f65f0 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
@@ -972,12 +972,17 @@ ON_EXIT:
   if (EFI_ERROR (Status)) {
 Dhcp6->Stop (Dhcp6);
 Dhcp6->Configure (Dhcp6, NULL);
   } else {
 ZeroMem (&Config, sizeof (EFI_DHCP6_CONFIG_DATA));
-ZeroMem (&Mode, sizeof (EFI_DHCP6_MODE_DATA));
 Dhcp6->Configure (Dhcp6, &Config);
+if (Mode.ClientId != NULL) {
+  FreePool (Mode.ClientId);
+}
+if (Mode.Ia != NULL) {
+  FreePool (Mode.Ia);
+}
   }
 
   return Status; 
 
 }
diff --git a/NetworkPkg/Ip6Dxe/ComponentName.c 
b/NetworkPkg/Ip6Dxe/ComponentName.

Re: [edk2] [Patch 2/2] NetworkPkg: Replace the internal function with exposed one

[Hegde, Nagaraj P]

For the series of patches
Reviewed-by: Hegde Nagaraj P 

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Thursday, January 21, 2016 11:24 PM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P; Ye Ting; Fu Siyuan
Subject: [Patch 2/2] NetworkPkg: Replace the internal function with exposed one

This patch is used to replace the internal function with the exposed one 
defined in NetLib.h.

Cc: Hegde Nagaraj P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/DnsDxe/DnsImpl.c | 63 -
 NetworkPkg/DnsDxe/DnsImpl.h | 19 -
 NetworkPkg/DnsDxe/DnsProtocol.c |  6 ++--
 3 files changed, 9 insertions(+), 79 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index 
71dacce..77e6496 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -1012,65 +1012,10 @@ AddDns6ServerIp (
   
   return EFI_SUCCESS;
 }
 
 /**
-  Fill QName for IP querying. QName is a domain name represented as
-  a sequence of labels, where each label consists of a length octet
-  followed by that number of octets. The domain name terminates with
-  the zero length octet for the null label of the root. Caller should
-  take responsibility to the buffer in QName.
-
-  @param  HostName  Queried HostName
-
-  @retval NULL  Failed to fill QName.
-  @return   QName filled successfully.
-
-**/
-CHAR8 *
-EFIAPI
-DnsFillinQNameForQueryIp (
-  IN  CHAR16  *HostName
-  )
-{
-  CHAR8 *QueryName;
-  CHAR8 *Header;
-  CHAR8 *Tail;
-  UINTN Len;
-  UINTN Index;
-
-  QueryName  = NULL;
-  Header = NULL;
-  Tail   = NULL;
-
-  QueryName = AllocateZeroPool (DNS_DEFAULT_BLKSIZE);
-  if (QueryName == NULL) {
-return NULL;
-  }
-
-  Header = QueryName;
-  Tail = Header + 1;
-  Len = 0;
-  for (Index = 0; HostName[Index] != 0; Index++) {
-*Tail = (CHAR8) HostName[Index];
-if (*Tail == '.') {
-  *Header = (CHAR8) Len;
-  Header = Tail;
-  Tail ++;
-  Len = 0;
-} else {
-  Tail++;
-  Len++;
-}
-  }
-  *Header = (CHAR8) Len;
-  *Tail = 0;
-
-  return QueryName;
-}
-
-/**
   Find out whether the response is valid or invalid.
 
   @param  TokensMap   All DNS transmittal Tokens entry.  
   @param  Identification  Identification for queried packet.  
   @param  TypeType for queried packet.
@@ -1780,12 +1725,16 @@ ConstructDNSQuery (
   )
 {
   NET_FRAGMENTFrag;
   DNS_HEADER  *DnsHeader;
   DNS_QUERY_SECTION   *DnsQuery;
-
-  Frag.Bulk = AllocatePool (DNS_DEFAULT_BLKSIZE * sizeof (UINT8));
+
+  //
+  // Messages carried by UDP are restricted to 512 bytes (not counting 
+ the IP  // or UDP headers).
+  //
+  Frag.Bulk = AllocatePool (DNS_MAX_BLKSIZE * sizeof (UINT8));
   if (Frag.Bulk == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
 
   //
diff --git a/NetworkPkg/DnsDxe/DnsImpl.h b/NetworkPkg/DnsDxe/DnsImpl.h index 
72b85cb..e286064 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.h
+++ b/NetworkPkg/DnsDxe/DnsImpl.h
@@ -85,11 +85,10 @@ extern EFI_DNS6_PROTOCOL mDns6Protocol;
 #define DNS_STATE_CONFIGED   1
 #define DNS_STATE_DESTROY2
 
 #define DNS_DEFAULT_TIMEOUT  2
 #define DNS_DEFAULT_RETRY3
-#define DNS_DEFAULT_BLKSIZE  512
 
 #define DNS_TIME_TO_GETMAP   5
 
 #pragma pack(1)
 
@@ -555,28 +554,10 @@ AddDns6ServerIp (
   IN LIST_ENTRY*Dns6ServerList,
   IN EFI_IPv6_ADDRESS   ServerIp
   );
 
 /**
-  Fill QName for IP querying. QName is a domain name represented as
-  a sequence of labels, where each label consists of a length octet
-  followed by that number of octets. The domain name terminates with
-  the zero length octet for the null label of the root.
-
-  @param  HostName  Queried HostName
-
-  @retval NULL  Failed to fill QName.
-  @return   QName filled successfully.
-
-**/
-CHAR8 *
-EFIAPI
-DnsFillinQNameForQueryIp (
-  IN  CHAR16  *HostName
-  );
-
-/**
   Find out whether the response is valid or invalid.
 
   @param  TokensMap   All DNS transmittal Tokens entry.  
   @param  Identification  Identification for queried packet.  
   @param  TypeType for queried packet.
diff --git a/NetworkPkg/DnsDxe/DnsProtocol.c b/NetworkPkg/DnsDxe/DnsProtocol.c 
index a3f3de9..3093535 100644
--- a/NetworkPkg/DnsDxe/DnsProtocol.c
+++ b/NetworkPkg/DnsDxe/DnsProtocol.c
@@ -1,9 +1,9 @@
 /** @file
 Implementation of EFI_DNS4_PROTOCOL and EFI_DNS6_PROTOCOL interfaces.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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 

Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address

[El-Haj-Mahmoud, Samer]

A while ago, a change was added to EDK2 to introduce a Pcd to select either 
DUID-LLT or DUID-UUID. Did you look at modifying that PCD?



Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-Original Message-
From: Fu, Siyuan [siyuan...@intel.com]
Received: Thursday, 21 Jan 2016, 8:59PM
To: Michael Brown [mc...@ipxe.org]
CC: edk2-devel@lists.01.org [edk2-devel@lists.01.org]; Jim Hung (洪銘駿) 
{[jim.h...@quantatw.com]
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

Thanks Michael, maybe use UUID is a good way to solve this issue. But I still 
curious why the server has such requirement which is apparent violate the RFC 
requirement. Could you provide more details?

Best Regards
Siyuan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Brown
Sent: Thursday, January 21, 2016 10:49 PM
To: "Jim Hung (洪銘駿)" ; edk2-devel@lists.01.org
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
> There is one network issue in customer datacenter, the 
> “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source 
> network device if multi LANs on the system. And, this cause the PXE boot 
> failure at customer datacenter environment.
>
> On our system, it has two network devices, one is Intel NIC, the other is 
> Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to 
> generate the DULD-LLT. However at customer Data Center, they do NOT accept 
> this. Each interface needs to generate their DUID-LL(T) based on their own 
> LL. This means that they must use their own MAC address. Both interface will 
> have different DUIL-LL(T), which is technically against the RFC here.
>
> Can you please help to check how networkstack driver could be supported on 
> this requirement?

We have encountered exactly the same problem in iPXE.  We decided to adopt the 
solution proposed by RFC6355: we use DUID-UUID rather than any of the 
DUID-LL(T) variants.  This is the only sensible way in which we can hope to 
make the same choice of DUID as the loaded operating system.

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

Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address

[Fu, Siyuan]

Thanks Michael, maybe use UUID is a good way to solve this issue. But I still 
curious why the server has such requirement which is apparent violate the RFC 
requirement. Could you provide more details?

Best Regards
Siyuan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Brown
Sent: Thursday, January 21, 2016 10:49 PM
To: "Jim Hung (洪銘駿)" ; edk2-devel@lists.01.org
Subject: Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per 
own MAC address

On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:
> There is one network issue in customer datacenter, the 
> “ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source 
> network device if multi LANs on the system. And, this cause the PXE boot 
> failure at customer datacenter environment.
>
> On our system, it has two network devices, one is Intel NIC, the other is 
> Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to 
> generate the DULD-LLT. However at customer Data Center, they do NOT accept 
> this. Each interface needs to generate their DUID-LL(T) based on their own 
> LL. This means that they must use their own MAC address. Both interface will 
> have different DUIL-LL(T), which is technically against the RFC here.
>
> Can you please help to check how networkstack driver could be supported on 
> this requirement?

We have encountered exactly the same problem in iPXE.  We decided to adopt the 
solution proposed by RFC6355: we use DUID-UUID rather than any of the 
DUID-LL(T) variants.  This is the only sensible way in which we can hope to 
make the same choice of DUID as the loaded operating system.

Michael
___
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] NetworkPkg:Fix Network memory leak when calling GetModeData interface

[Zhang, Lubo]

Thank you  for your comments, I will make a new patch to fix the issue.

-Original Message-
From: Fu, Siyuan 
Sent: Friday, January 22, 2016 9:45 AM
To: Zhang, Lubo; edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: RE: [patch] NetworkPkg:Fix Network memory leak when calling 
GetModeData interface

Hi, Lubo

Some comments as below:
1.
Dhcp6Dxe,DnsDxe\ComponentName.c
HttpBootDxe\HttpBootDhcp6.c
UefiPxeBcDxe\PxeBcDhcp6.c
Check for NULL pointer before free it.
2. 
DnsDxe\DnsImpl.c
Ip6Dxe\ComponentName.c
Mtftp6Dxe\Mtftp6Support.c
There is memory leak if GetModeData return SUCCESS but IsConfigured is 
False.
3.
IpSecDxe\IkeService.c
Mtftp6Dxe\Mtftp6Support.c
Ip6ModeData is not initialized but used in ON_EXIT.
4. 
  // The caller is responsible for freeing the reference buffer The comments 
seems redundant. It's just one line FreePool.

Siyuan

-Original Message-
From: Zhang, Lubo
Sent: Thursday, January 21, 2016 10:07 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [patch] NetworkPkg:Fix Network memory leak when calling GetModeData 
interface

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Dhcp6Dxe/ComponentName.c|  7 ++-
 NetworkPkg/DnsDxe/ComponentName.c  | 11 +++
 NetworkPkg/DnsDxe/DnsDhcp.c| 13 -
 NetworkPkg/DnsDxe/DnsImpl.c| 35 ++
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  6 +-
 NetworkPkg/Ip6Dxe/ComponentName.c  | 27 ++
 NetworkPkg/IpSecDxe/IkeService.c   | 27 ++
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c   | 26 +
 NetworkPkg/TcpDxe/TcpMisc.c| 30 -
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  7 ++-
 NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  | 34 +++--
 11 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/ComponentName.c 
b/NetworkPkg/Dhcp6Dxe/ComponentName.c
index 927a7fe..e46106d 100644
--- a/NetworkPkg/Dhcp6Dxe/ComponentName.c
+++ b/NetworkPkg/Dhcp6Dxe/ComponentName.c
@@ -284,11 +284,16 @@ UpdateName (
 if (Dhcp6ModeData.Ia->State > Dhcp6Rebinding) {
   return EFI_DEVICE_ERROR;
 }
 HandleName = mDhcp6ControllerName[Dhcp6ModeData.Ia->State];
   }
-  
+  //
+  // The caller is responsible for freeing the reference buffer  // 
+ FreePool (Dhcp6ModeData.ClientId);  FreePool (Dhcp6ModeData.Ia);
+
   Status = AddUnicodeString2 (
  "eng",
  gDhcp6ComponentName.SupportedLanguages,
  &gDhcp6ControllerNameTable,
  HandleName,
diff --git a/NetworkPkg/DnsDxe/ComponentName.c 
b/NetworkPkg/DnsDxe/ComponentName.c
index d95ed92..1efd425 100644
--- a/NetworkPkg/DnsDxe/ComponentName.c
+++ b/NetworkPkg/DnsDxe/ComponentName.c
@@ -209,10 +209,16 @@ UpdateDns4Name (
 ModeData.DnsConfigData.StationIp.Addr[2],
 ModeData.DnsConfigData.StationIp.Addr[3],
 ModeData.DnsConfigData.LocalPort
 );
 
+  //
+  // The caller is responsible for freeing the reference buffer  // 
+ FreePool (ModeData.DnsCacheList);  FreePool (ModeData.DnsServerList);
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
@@ -278,10 +284,15 @@ UpdateDns6Name (
 sizeof (HandleName), 
 L"DNSv6 (StationIp=%s, LocalPort=%d)",
 Address,
 ModeData.DnsConfigData.LocalPort
 );
+  //
+  // The caller is responsible for freeing the reference buffer  // 
+ FreePool (ModeData.DnsServerList);  FreePool (ModeData.DnsCacheList);
 
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c index 
6b409ba..71fb698 100644
--- a/NetworkPkg/DnsDxe/DnsDhcp.c
+++ b/NetworkPkg/DnsDxe/DnsDhcp.c
@@ -131,11 +131,22 @@ DnsStartIp4(
 
 while (!Timeout) {
   Ip4->Poll (Ip4);
   
   if (!EFI_ERROR (Ip4->GetModeData (Ip4, &Ip4Mode, NULL, NULL)) && 
-  Ip4Mode.IsConfigured) {   
+  Ip4Mode.IsConfigured) { 
+if (Ip4Mode.GroupTable != NULL) {
+  FreePool (Ip4Mode.GroupTable);
+}
+
+if (Ip4Mode.RouteTable != NULL) {
+  FreePool (Ip4Mode.RouteTable);
+}
+
+if (Ip4Mode.IcmpTypeList != NULL) {
+  FreePool (Ip4Mode.IcmpTypeList);
+}
 break;
   }
 }
 
 if (Timeout) {
diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index 
71dacce..e5cbfc6 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl

Re: [edk2] [patch] NetworkPkg:Fix Network memory leak when calling GetModeData interface

[Fu, Siyuan]

Hi, Lubo

Some comments as below:
1.
Dhcp6Dxe,DnsDxe\ComponentName.c
HttpBootDxe\HttpBootDhcp6.c
UefiPxeBcDxe\PxeBcDhcp6.c
Check for NULL pointer before free it.
2. 
DnsDxe\DnsImpl.c
Ip6Dxe\ComponentName.c
Mtftp6Dxe\Mtftp6Support.c
There is memory leak if GetModeData return SUCCESS but IsConfigured is 
False.
3.
IpSecDxe\IkeService.c
Mtftp6Dxe\Mtftp6Support.c
Ip6ModeData is not initialized but used in ON_EXIT.
4. 
  // The caller is responsible for freeing the reference buffer
The comments seems redundant. It's just one line FreePool.

Siyuan

-Original Message-
From: Zhang, Lubo 
Sent: Thursday, January 21, 2016 10:07 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [patch] NetworkPkg:Fix Network memory leak when calling GetModeData 
interface

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Dhcp6Dxe/ComponentName.c|  7 ++-
 NetworkPkg/DnsDxe/ComponentName.c  | 11 +++
 NetworkPkg/DnsDxe/DnsDhcp.c| 13 -
 NetworkPkg/DnsDxe/DnsImpl.c| 35 ++
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  6 +-
 NetworkPkg/Ip6Dxe/ComponentName.c  | 27 ++
 NetworkPkg/IpSecDxe/IkeService.c   | 27 ++
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c   | 26 +
 NetworkPkg/TcpDxe/TcpMisc.c| 30 -
 NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  7 ++-
 NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  | 34 +++--
 11 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/NetworkPkg/Dhcp6Dxe/ComponentName.c 
b/NetworkPkg/Dhcp6Dxe/ComponentName.c
index 927a7fe..e46106d 100644
--- a/NetworkPkg/Dhcp6Dxe/ComponentName.c
+++ b/NetworkPkg/Dhcp6Dxe/ComponentName.c
@@ -284,11 +284,16 @@ UpdateName (
 if (Dhcp6ModeData.Ia->State > Dhcp6Rebinding) {
   return EFI_DEVICE_ERROR;
 }
 HandleName = mDhcp6ControllerName[Dhcp6ModeData.Ia->State];
   }
-  
+  //
+  // The caller is responsible for freeing the reference buffer  //  
+ FreePool (Dhcp6ModeData.ClientId);  FreePool (Dhcp6ModeData.Ia);
+
   Status = AddUnicodeString2 (
  "eng",
  gDhcp6ComponentName.SupportedLanguages,
  &gDhcp6ControllerNameTable,
  HandleName,
diff --git a/NetworkPkg/DnsDxe/ComponentName.c 
b/NetworkPkg/DnsDxe/ComponentName.c
index d95ed92..1efd425 100644
--- a/NetworkPkg/DnsDxe/ComponentName.c
+++ b/NetworkPkg/DnsDxe/ComponentName.c
@@ -209,10 +209,16 @@ UpdateDns4Name (
 ModeData.DnsConfigData.StationIp.Addr[2],
 ModeData.DnsConfigData.StationIp.Addr[3],
 ModeData.DnsConfigData.LocalPort
 );
 
+  //
+  // The caller is responsible for freeing the reference buffer  //  
+ FreePool (ModeData.DnsCacheList);  FreePool (ModeData.DnsServerList);
+
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
   
@@ -278,10 +284,15 @@ UpdateDns6Name (
 sizeof (HandleName), 
 L"DNSv6 (StationIp=%s, LocalPort=%d)",
 Address,
 ModeData.DnsConfigData.LocalPort
 );
+  //
+  // The caller is responsible for freeing the reference buffer  //  
+ FreePool (ModeData.DnsServerList);  FreePool (ModeData.DnsCacheList);
 
   if (gDnsControllerNameTable != NULL) {
 FreeUnicodeStringTable (gDnsControllerNameTable);
 gDnsControllerNameTable = NULL;
   }
diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c index 
6b409ba..71fb698 100644
--- a/NetworkPkg/DnsDxe/DnsDhcp.c
+++ b/NetworkPkg/DnsDxe/DnsDhcp.c
@@ -131,11 +131,22 @@ DnsStartIp4(
 
 while (!Timeout) {
   Ip4->Poll (Ip4);
   
   if (!EFI_ERROR (Ip4->GetModeData (Ip4, &Ip4Mode, NULL, NULL)) && 
-  Ip4Mode.IsConfigured) {   
+  Ip4Mode.IsConfigured) { 
+if (Ip4Mode.GroupTable != NULL) {
+  FreePool (Ip4Mode.GroupTable);
+}
+
+if (Ip4Mode.RouteTable != NULL) {
+  FreePool (Ip4Mode.RouteTable);
+}
+
+if (Ip4Mode.IcmpTypeList != NULL) {
+  FreePool (Ip4Mode.IcmpTypeList);
+}
 break;
   }
 }
 
 if (Timeout) {
diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index 
71dacce..e5cbfc6 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -568,10 +568,21 @@ Dns4GetMapping (
   while (!EFI_ERROR (gBS->CheckEvent (Service->TimerToGetMap))) {
 Udp->Poll (Udp);
 
 if (!EFI_ERROR (Udp->GetModeData (Udp, NULL, &Ip4Mode, NULL, NULL)) &&
 Ip4Mode.IsConfigured) {
+  if (Ip4Mode.GroupTable != NULL) {
+FreePool (Ip4Mode.Gro

Re: [edk2] [patch] MdeModulePkg:Fix Network memory leak when calling GetModeData interface

[Fu, Siyuan]

Hi, Lubo

Pls ignore my previous mail.
I just checked UEFI spec, it didn't mentioned the GroupTable, RouteTable and 
IcmpTypeList should be freed by caller. So I think we shouldn't make this 
change.

Siyuan

-Original Message-
From: Fu, Siyuan 
Sent: Friday, January 22, 2016 9:26 AM
To: Zhang, Lubo ; edk2-devel@lists.01.org
Cc: Ye, Ting ; Wu, Jiaxin 
Subject: RE: [patch] MdeModulePkg:Fix Network memory leak when calling 
GetModeData interface

Patch is good to me. Please also update the copyright year when commit it.

Reviewed-by: Siyuan Fu 



-Original Message-
From: Zhang, Lubo 
Sent: Thursday, January 21, 2016 10:11 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [patch] MdeModulePkg:Fix Network memory leak when calling GetModeData 
interface

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c  | 12 
 MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c | 14 +-
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c 
b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
index cc93c2b..8227283 100644
--- a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
+++ b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
@@ -1764,10 +1764,22 @@ IpIoConfigIp (
   &Ip4ModeData, 
   NULL, 
   NULL
   );
 
+if (Ip4ModeData.GroupTable != NULL) {
+  FreePool (Ip4ModeData.GroupTable);
+}
+
+if (Ip4ModeData.RouteTable != NULL) {
+  FreePool (Ip4ModeData.RouteTable);
+}
+
+if (Ip4ModeData.IcmpTypeList != NULL) {
+  FreePool (Ip4ModeData.IcmpTypeList);
+}
+
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) 
IpConfigData)->StationAddress, &Ip4ModeData.ConfigData.StationAddress);
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) IpConfigData)->SubnetMask, 
&Ip4ModeData.ConfigData.SubnetMask);
 }
 
   CopyMem (
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
index 2ccfb3c..23af45c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
@@ -261,11 +261,11 @@ UpdateName (
   //
   Status = Ip4->GetModeData (Ip4, &Ip4ModeData, NULL, NULL);
   if (EFI_ERROR (Status)) {
 return Status;
   }
-
+  
   if (!Ip4ModeData.IsStarted || !Ip4ModeData.IsConfigured) {
 UnicodeSPrint (HandleName, sizeof (HandleName), L"IPv4 (Not started)");
   } else {
 UnicodeSPrint (HandleName, sizeof (HandleName),
   L"IPv4 (SrcIP=%d.%d.%d.%d)",
@@ -274,10 +274,22 @@ UpdateName (
   Ip4ModeData.ConfigData.StationAddress.Addr[2],
   Ip4ModeData.ConfigData.StationAddress.Addr[3]
   );
   }
 
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
+
   if (gIp4ControllerNameTable != NULL) {
 FreeUnicodeStringTable (gIp4ControllerNameTable);
 gIp4ControllerNameTable = NULL;
   }
   Status = AddUnicodeString2 (
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 76c140d..bd2530e 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -262,10 +262,21 @@ PxeBcDriverBindingStart (
   if (EFI_ERROR (Status)) {
 goto ON_ERROR;
   }
 
   Private->Ip4MaxPacketSize = Ip4ModeData.MaxPacketSize;
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
 
   Status = NetLibCreateServiceChild (
  ControllerHandle,
  This->DriverBindingHandle,
  &gEfiMtftp4ServiceBindingProtocolGuid,
--
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] MdeModulePkg:Fix Network memory leak when calling GetModeData interface

[Zhang, Lubo]

I will update the copyright year when I commit it, thanks.

-Original Message-
From: Fu, Siyuan 
Sent: Friday, January 22, 2016 9:26 AM
To: Zhang, Lubo; edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: RE: [patch] MdeModulePkg:Fix Network memory leak when calling 
GetModeData interface

Patch is good to me. Please also update the copyright year when commit it.

Reviewed-by: Siyuan Fu 



-Original Message-
From: Zhang, Lubo 
Sent: Thursday, January 21, 2016 10:11 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [patch] MdeModulePkg:Fix Network memory leak when calling GetModeData 
interface

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c  | 12 
 MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c | 14 +-
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c 
b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
index cc93c2b..8227283 100644
--- a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
+++ b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
@@ -1764,10 +1764,22 @@ IpIoConfigIp (
   &Ip4ModeData, 
   NULL, 
   NULL
   );
 
+if (Ip4ModeData.GroupTable != NULL) {
+  FreePool (Ip4ModeData.GroupTable);
+}
+
+if (Ip4ModeData.RouteTable != NULL) {
+  FreePool (Ip4ModeData.RouteTable);
+}
+
+if (Ip4ModeData.IcmpTypeList != NULL) {
+  FreePool (Ip4ModeData.IcmpTypeList);
+}
+
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) 
IpConfigData)->StationAddress, &Ip4ModeData.ConfigData.StationAddress);
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) IpConfigData)->SubnetMask, 
&Ip4ModeData.ConfigData.SubnetMask);
 }
 
   CopyMem (
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
index 2ccfb3c..23af45c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
@@ -261,11 +261,11 @@ UpdateName (
   //
   Status = Ip4->GetModeData (Ip4, &Ip4ModeData, NULL, NULL);
   if (EFI_ERROR (Status)) {
 return Status;
   }
-
+  
   if (!Ip4ModeData.IsStarted || !Ip4ModeData.IsConfigured) {
 UnicodeSPrint (HandleName, sizeof (HandleName), L"IPv4 (Not started)");
   } else {
 UnicodeSPrint (HandleName, sizeof (HandleName),
   L"IPv4 (SrcIP=%d.%d.%d.%d)",
@@ -274,10 +274,22 @@ UpdateName (
   Ip4ModeData.ConfigData.StationAddress.Addr[2],
   Ip4ModeData.ConfigData.StationAddress.Addr[3]
   );
   }
 
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
+
   if (gIp4ControllerNameTable != NULL) {
 FreeUnicodeStringTable (gIp4ControllerNameTable);
 gIp4ControllerNameTable = NULL;
   }
   Status = AddUnicodeString2 (
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 76c140d..bd2530e 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -262,10 +262,21 @@ PxeBcDriverBindingStart (
   if (EFI_ERROR (Status)) {
 goto ON_ERROR;
   }
 
   Private->Ip4MaxPacketSize = Ip4ModeData.MaxPacketSize;
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
 
   Status = NetLibCreateServiceChild (
  ControllerHandle,
  This->DriverBindingHandle,
  &gEfiMtftp4ServiceBindingProtocolGuid,
--
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] MdeModulePkg:Fix Network memory leak when calling GetModeData interface

[Fu, Siyuan]

Patch is good to me. Please also update the copyright year when commit it.

Reviewed-by: Siyuan Fu 



-Original Message-
From: Zhang, Lubo 
Sent: Thursday, January 21, 2016 10:11 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Wu, Jiaxin 

Subject: [patch] MdeModulePkg:Fix Network memory leak when calling GetModeData 
interface

Multiple network protocols have a GetModeData() interface, which may allocate 
memory resource in the return mode data structure. It's callers responsibility 
to free these buffers.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c  | 12 
 MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c | 14 +-
 MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c | 11 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c 
b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
index cc93c2b..8227283 100644
--- a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
+++ b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
@@ -1764,10 +1764,22 @@ IpIoConfigIp (
   &Ip4ModeData, 
   NULL, 
   NULL
   );
 
+if (Ip4ModeData.GroupTable != NULL) {
+  FreePool (Ip4ModeData.GroupTable);
+}
+
+if (Ip4ModeData.RouteTable != NULL) {
+  FreePool (Ip4ModeData.RouteTable);
+}
+
+if (Ip4ModeData.IcmpTypeList != NULL) {
+  FreePool (Ip4ModeData.IcmpTypeList);
+}
+
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) 
IpConfigData)->StationAddress, &Ip4ModeData.ConfigData.StationAddress);
 IP4_COPY_ADDRESS (&((EFI_IP4_CONFIG_DATA*) IpConfigData)->SubnetMask, 
&Ip4ModeData.ConfigData.SubnetMask);
 }
 
   CopyMem (
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
index 2ccfb3c..23af45c 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/ComponentName.c
@@ -261,11 +261,11 @@ UpdateName (
   //
   Status = Ip4->GetModeData (Ip4, &Ip4ModeData, NULL, NULL);
   if (EFI_ERROR (Status)) {
 return Status;
   }
-
+  
   if (!Ip4ModeData.IsStarted || !Ip4ModeData.IsConfigured) {
 UnicodeSPrint (HandleName, sizeof (HandleName), L"IPv4 (Not started)");
   } else {
 UnicodeSPrint (HandleName, sizeof (HandleName),
   L"IPv4 (SrcIP=%d.%d.%d.%d)",
@@ -274,10 +274,22 @@ UpdateName (
   Ip4ModeData.ConfigData.StationAddress.Addr[2],
   Ip4ModeData.ConfigData.StationAddress.Addr[3]
   );
   }
 
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
+
   if (gIp4ControllerNameTable != NULL) {
 FreeUnicodeStringTable (gIp4ControllerNameTable);
 gIp4ControllerNameTable = NULL;
   }
   Status = AddUnicodeString2 (
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c 
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
index 76c140d..bd2530e 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDriver.c
@@ -262,10 +262,21 @@ PxeBcDriverBindingStart (
   if (EFI_ERROR (Status)) {
 goto ON_ERROR;
   }
 
   Private->Ip4MaxPacketSize = Ip4ModeData.MaxPacketSize;
+  if (Ip4ModeData.GroupTable != NULL) {
+FreePool (Ip4ModeData.GroupTable);
+  }
+
+  if (Ip4ModeData.RouteTable != NULL) {
+FreePool (Ip4ModeData.RouteTable);
+  }
+
+  if (Ip4ModeData.IcmpTypeList != NULL) {
+FreePool (Ip4ModeData.IcmpTypeList);  }
 
   Status = NetLibCreateServiceChild (
  ControllerHandle,
  This->DriverBindingHandle,
  &gEfiMtftp4ServiceBindingProtocolGuid,
--
1.9.5.msysgit.1

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

Re: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a bug?

[王晓峰]

Star，
   Thanks for explanation








At 2016-01-22 08:49:08, "Zeng, Star"  wrote:
>Oh, yes, you are right. BootScriptWriteSmbusExecute will use definitions from 
>Smbus.h and SmbusLib.h, So we could not remove them from 
>InternalS3SaveState.h. But no SmbusLib interface will be consumed by 
>S3SaveStateDxe directly, so SmbusLib is not listed in S3SaveStateDxe.inf, that 
>is expected.
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 王晓峰
>Sent: Thursday, January 21, 2016 7:48 PM
>To: Zeng, Star
>Cc: edk2-devel@lists.01.org
>Subject: Re: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is 
>it a bug?
>
>HI  Star,
>   I tried to remove SmbusLib.h from InternalS3SaveState.h., there will be 
> build errors.Smbus related logic exists in S3SaveState.c
>
>
>
>
>
>
>
>
>At 2016-01-21 18:09:41, "Zeng, Star"  wrote:
>>It is just to include header file, I believe it could be removed from 
>>InternalS3SaveState.h.
>>What libraries a driver will link is not determined by source files, but inf 
>>file ( S3SaveStateDxe.inf)?
>>
>>Why does S3SaveStateDxe.inf finally link SmbusLib, it is because 
>>S3SaveStateDxe.inf link S3BootScriptLib(I guess you are using 
>>DxeS3BootScriptLib.inf in MdeModulePkg) and S3BootScriptLib link SmbusLib.
>>
>>You may could check the PCD usage in your SmbusLib instance.
>>
>>Thanks,
>>Star
>>From: 王晓峰 [mailto:winggundu...@163.com] 
>>Sent: Thursday, January 21, 2016 5:40 PM
>>To: edk2-de...@ml01.01.org
>>Cc: Zeng, Star
>>Subject: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it 
>>a bug?
>>
>>Hi All,
>>I meet a issue that there is a get PCD assert for  S3SaveStateDxe.inf. It 
>> is strange that I seached all the library and their child library in  
>> S3SaveStateDxe.inf , no PCD found related to this issue
>>
>>[LibraryClasses]
>>  UefiBootServicesTableLib
>>  MemoryAllocationLib
>>  UefiDriverEntryPoint
>>  BaseMemoryLib
>>  BaseLib
>>  S3BootScriptLib
>>
>>   Then I found in InternalS3SaveState.h, It directly include SmbusLib 
>>   #include 
>>
>>   I am not sure whether it is a bug that SmbusLib should also be in 
>> S3SaveStateDxe.inf . But after I change SmbusLib instance to Null the PCD 
>> issue is solved. It seems build tool for PCD cannot caclulate the PCD 
>> introduced by such way.
>>
>> 
>___
>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] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a bug?

[Zeng, Star]

Oh, yes, you are right. BootScriptWriteSmbusExecute will use definitions from 
Smbus.h and SmbusLib.h, So we could not remove them from InternalS3SaveState.h. 
But no SmbusLib interface will be consumed by S3SaveStateDxe directly, so 
SmbusLib is not listed in S3SaveStateDxe.inf, that is expected.

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 王晓峰
Sent: Thursday, January 21, 2016 7:48 PM
To: Zeng, Star
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is 
it a bug?

HI  Star,
   I tried to remove SmbusLib.h from InternalS3SaveState.h., there will be 
build errors.Smbus related logic exists in S3SaveState.c








At 2016-01-21 18:09:41, "Zeng, Star"  wrote:
>It is just to include header file, I believe it could be removed from 
>InternalS3SaveState.h.
>What libraries a driver will link is not determined by source files, but inf 
>file ( S3SaveStateDxe.inf)?
>
>Why does S3SaveStateDxe.inf finally link SmbusLib, it is because 
>S3SaveStateDxe.inf link S3BootScriptLib(I guess you are using 
>DxeS3BootScriptLib.inf in MdeModulePkg) and S3BootScriptLib link SmbusLib.
>
>You may could check the PCD usage in your SmbusLib instance.
>
>Thanks,
>Star
>From: 王晓峰 [mailto:winggundu...@163.com] 
>Sent: Thursday, January 21, 2016 5:40 PM
>To: edk2-de...@ml01.01.org
>Cc: Zeng, Star
>Subject: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it 
>a bug?
>
>Hi All,
>I meet a issue that there is a get PCD assert for  S3SaveStateDxe.inf. It 
> is strange that I seached all the library and their child library in  
> S3SaveStateDxe.inf , no PCD found related to this issue
>
>[LibraryClasses]
>  UefiBootServicesTableLib
>  MemoryAllocationLib
>  UefiDriverEntryPoint
>  BaseMemoryLib
>  BaseLib
>  S3BootScriptLib
>
>   Then I found in InternalS3SaveState.h, It directly include SmbusLib 
>   #include 
>
>   I am not sure whether it is a bug that SmbusLib should also be in 
> S3SaveStateDxe.inf . But after I change SmbusLib instance to Null the PCD 
> issue is solved. It seems build tool for PCD cannot caclulate the PCD 
> introduced by such way.
>
> 
___
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 v2 00/14] ShellPkg: BCFG dump improvements

[Laszlo Ersek]

On 01/21/16 21:35, Ryan Harkin wrote:
> On 21 January 2016 at 18:51, Laszlo Ersek  wrote:
>> On 01/21/16 19:25, Carsey, Jaben wrote:
>>> For series. Reviewed-by: Jaben Carsey 
>>
>> Thanks much; series committed as SVN r19706..r19719, inclusive.
>>
> Sorry, I wanted to give you a Reviewed-by and Tested-by by got
> distracted by the SerialDxe stuff.  Still, Jaben sorted you out.
> 
> Many thanks for taking care of this.
> 
> 
>> I'm unsure whom we should ping for refreshing the binaries under
>> ShellBinPkg/ -- although I guess this is not very urgent.
>>
> 
> Leif seems to take care of the ARM ones.  Qiu Shumin
>  does X64 and Ia32.

Thanks Ryan -- Leif, Shumin, please build & check in new shell binaries
if you deem it appropriate.

Thanks!
Laszlo

 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Thursday, January 21, 2016 9:07 AM
 To: edk2-devel-01 
 Cc: Carsey, Jaben ; Ryan Harkin
 
 Subject: [PATCH v2 00/14] ShellPkg: BCFG dump improvements
 Importance: High

 Version 2 of .

 Changes relative to v1:

 - Bump the minor version numbers in the INF files of
   UefiShellBcfgCommandLib, UefiShellCommandLib,
   UefiShellDebug1CommandsLib [Jaben].

   For the first of these, a final patch has been added.

   For the last two, because they are affected together by a single code
   movement patch, that patch has been extended with the INF changes.

 - Replace "UefiShellBcfgCommandLib" with "BcfgDisplayDump()" in most of
   the subject lines, so that it's clear a given patch affects only the
   "bcfg dump" subcommand, not the entirety of "bcfg" [Laszlo]

 - The above are also marked on each patch, as notes.

 - No functional changes.

 Public branch:
 .

 Cc: Jaben Carsey 
 Cc: Ryan Harkin 

 Thanks
 Laszlo

 Laszlo Ersek (14):
   ShellPkg: BcfgDisplayDump(): update whitespace & layout
   ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens
   ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]
   ShellPkg: BcfgDisplayDump(): accumulate errors
   ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot and co.
   ShellPkg: BcfgDisplayDump(): address FilePathListLength by name
   ShellPkg: BcfgDisplayDump(): call Description[Size] by name
   ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication
   ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly
   ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData
   ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site
   ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal
   ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()
   ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING

  ShellPkg/Include/Library/ShellCommandLib.h
  |  16 +++
  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
 | 103 
  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 |   2 +-
  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
 |   4 +-
  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c
  |
 69 +
  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf  
  |   2
 +-

 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
 b.c   |  70 -

 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
 b.h   |  16 ---

 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
 b.inf |   2 +-
  9 files changed, 150 insertions(+), 134 deletions(-)

 --
 1.8.3.1
>>>
>>

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

Re: [edk2] [PATCH v2 00/14] ShellPkg: BCFG dump improvements

[Ryan Harkin]

On 21 January 2016 at 18:51, Laszlo Ersek  wrote:
> On 01/21/16 19:25, Carsey, Jaben wrote:
>> For series. Reviewed-by: Jaben Carsey 
>
> Thanks much; series committed as SVN r19706..r19719, inclusive.
>
Sorry, I wanted to give you a Reviewed-by and Tested-by by got
distracted by the SerialDxe stuff.  Still, Jaben sorted you out.

Many thanks for taking care of this.


> I'm unsure whom we should ping for refreshing the binaries under
> ShellBinPkg/ -- although I guess this is not very urgent.
>

Leif seems to take care of the ARM ones.  Qiu Shumin
 does X64 and Ia32.

> Cheers!
> Laszlo
>
>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Thursday, January 21, 2016 9:07 AM
>>> To: edk2-devel-01 
>>> Cc: Carsey, Jaben ; Ryan Harkin
>>> 
>>> Subject: [PATCH v2 00/14] ShellPkg: BCFG dump improvements
>>> Importance: High
>>>
>>> Version 2 of .
>>>
>>> Changes relative to v1:
>>>
>>> - Bump the minor version numbers in the INF files of
>>>   UefiShellBcfgCommandLib, UefiShellCommandLib,
>>>   UefiShellDebug1CommandsLib [Jaben].
>>>
>>>   For the first of these, a final patch has been added.
>>>
>>>   For the last two, because they are affected together by a single code
>>>   movement patch, that patch has been extended with the INF changes.
>>>
>>> - Replace "UefiShellBcfgCommandLib" with "BcfgDisplayDump()" in most of
>>>   the subject lines, so that it's clear a given patch affects only the
>>>   "bcfg dump" subcommand, not the entirety of "bcfg" [Laszlo]
>>>
>>> - The above are also marked on each patch, as notes.
>>>
>>> - No functional changes.
>>>
>>> Public branch:
>>> .
>>>
>>> Cc: Jaben Carsey 
>>> Cc: Ryan Harkin 
>>>
>>> Thanks
>>> Laszlo
>>>
>>> Laszlo Ersek (14):
>>>   ShellPkg: BcfgDisplayDump(): update whitespace & layout
>>>   ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens
>>>   ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]
>>>   ShellPkg: BcfgDisplayDump(): accumulate errors
>>>   ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot and co.
>>>   ShellPkg: BcfgDisplayDump(): address FilePathListLength by name
>>>   ShellPkg: BcfgDisplayDump(): call Description[Size] by name
>>>   ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication
>>>   ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly
>>>   ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData
>>>   ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site
>>>   ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal
>>>   ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()
>>>   ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING
>>>
>>>  ShellPkg/Include/Library/ShellCommandLib.h 
>>> |  16 +++
>>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> | 103 
>>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>>> |   2 +-
>>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
>>> |   4 +-
>>>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c 
>>> |
>>> 69 +
>>>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf   
>>> |   2
>>> +-
>>>
>>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>>> b.c   |  70 -
>>>
>>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>>> b.h   |  16 ---
>>>
>>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>>> b.inf |   2 +-
>>>  9 files changed, 150 insertions(+), 134 deletions(-)
>>>
>>> --
>>> 1.8.3.1
>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 20:47, Ryan Harkin wrote:
> On 21 January 2016 at 18:14, Laszlo Ersek  wrote:
>> On 01/21/16 18:57, Ryan Harkin wrote:
>>> On 21 January 2016 at 17:19, Laszlo Ersek  wrote:
>>
 Ryan, can you please test the following configuration:
 - your PCD update in place, but this three-part series of mine
   *reverted*

 This should break the cursor movement keys again, and also break the
 function keys, despite the escape sequences being correct (thanks to
 your PCD update). This would answer Ray's question.

>>>
>>> I'm happy to give this a go.  But I'm having trouble returning to a
>>> setup where the cursor keys are broken at all.  I've reverted the PCD
>>> setting and F9 no longer works, but ...  I don't know what I'm doing
>>> wrong.  I think I need to take a break from it for 1/2 hour and come
>>> back to work it out.  I'm pretty sure I've cleaned the repo and
>>> flushed the builds... it's weird.
>>>
>>> I'll report back soon.
>>
>> Right, I proposed the opposite config for testing -- *keep* the PCD changes, 
>> and revert the series in your local tree whose thread we're conducting this 
>> discussion in. :)
>>
> 
> I wasn't clear - I reverted your three patches:
> 
>> #1: revert 31ae446 MdeModulePkg: TerminalDxe: select the UART's default 
>> receive FIFO depth
>> #2: revert ea01261 MdeModulePkg: SerialDxe: sync EFI_SERIAL_IO_MODE.Timeout 
>> with the spec
>> #3: revert c0beed6 MdeModulePkg: SerialDxe: lay out mSerialIoMode 
>> initializer more nicely
>>
> 
> ... and cursor keys still worked on the serial port.  So I reverted
> the PCD changes too.  And cursor keys kept on working.
> 
> Now that I've worked out what was happening, let me first do your test
> before I explain why the X Files came to visit.
> 
> Using pure upstream EDK2 code:
> 
> 1) No SerialDxe patches and no PCD fix
> This means no cursor keys.
> 
> 2) Using the PCD fix only
> 
> I made this change:
> 
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()"
> +  
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"^M
> +  
> gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"^M
> 
> And it fails to boot, giving this error message:
> 
> Fail to start the console with the Device Path
> 'VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)'.
> (Error 'Not Found')
> 
> I guess there's something missing in the upstream .DSC file :-(
> 
> So I went back to using OpenPlatformPkg - but without building Shell
> from source.
> 
> And it doesn't work.
> 
> 3) I add back in your 3 SerialDxe patches
> The serial port comes back to life.
> 
> 
> 
> 
>> (Although I find it somewhat flattering that I apparently fixed the cursor 
>> keys so well that they *cannot* be broken, even if you try! ;))
> 
> :-)
> 
> So I've worked out what my anomaly was.
> 
> It turns out that having this patch in my tree also fixes cursor keys
> on the serial port, but not function keys like F9.  No, I have no clue
> what this patch has to do with the serial port, other than I am
> testing the cursor keys AFTER Shell has run, so the latest version of
> Shell could be doing something funky with the serial port setup.  Like
> changing the FIFO length.
> 
> commit eaa23c12db4d32879bb4a6f826d7e003936e11df
> Author: Ryan Harkin 
> Date:   Thu Jan 21 08:32:11 2016 +
> 
> Platforms/ARM: fvp: build Shell from source
> 
> Rather than use a pre-built Shell binary, build the Shell from source.
> 
> This allows the developer to debug and fix bugs in Shell, as well as
> test the latest source code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ryan Harkin 
> ---
>  Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf |  2 +-
>  Platforms/ARM/VExpress/ArmVExpress.dsc.inc | 19 +++
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
> b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
> index e3ff0cc..a1ae35a 100644
> --- a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
> +++ b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
> @@ -214,7 +214,7 @@ FvNameGuid = 87940482-fc81-41c3-87e6-399cf85ac8a0
>#
># UEFI application (Shell Embedded Boot Loader)
>#
> -  INF ShellBinPkg/UefiShell/UefiShell.inf
> +  INF ShellPkg/Application/Shell/Shell.inf^M
> 
>#
># Bds
> diff --git a/Platforms/ARM/VExpress/ArmVExpress.dsc.inc
> b/Platforms/ARM/VExpress/ArmVExpress.ds

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 18:14, Laszlo Ersek  wrote:
> On 01/21/16 18:57, Ryan Harkin wrote:
>> On 21 January 2016 at 17:19, Laszlo Ersek  wrote:
>
>>> Ryan, can you please test the following configuration:
>>> - your PCD update in place, but this three-part series of mine
>>>   *reverted*
>>>
>>> This should break the cursor movement keys again, and also break the
>>> function keys, despite the escape sequences being correct (thanks to
>>> your PCD update). This would answer Ray's question.
>>>
>>
>> I'm happy to give this a go.  But I'm having trouble returning to a
>> setup where the cursor keys are broken at all.  I've reverted the PCD
>> setting and F9 no longer works, but ...  I don't know what I'm doing
>> wrong.  I think I need to take a break from it for 1/2 hour and come
>> back to work it out.  I'm pretty sure I've cleaned the repo and
>> flushed the builds... it's weird.
>>
>> I'll report back soon.
>
> Right, I proposed the opposite config for testing -- *keep* the PCD changes, 
> and revert the series in your local tree whose thread we're conducting this 
> discussion in. :)
>

I wasn't clear - I reverted your three patches:

> #1: revert 31ae446 MdeModulePkg: TerminalDxe: select the UART's default 
> receive FIFO depth
> #2: revert ea01261 MdeModulePkg: SerialDxe: sync EFI_SERIAL_IO_MODE.Timeout 
> with the spec
> #3: revert c0beed6 MdeModulePkg: SerialDxe: lay out mSerialIoMode initializer 
> more nicely
>

... and cursor keys still worked on the serial port.  So I reverted
the PCD changes too.  And cursor keys kept on working.

Now that I've worked out what was happening, let me first do your test
before I explain why the X Files came to visit.

Using pure upstream EDK2 code:

1) No SerialDxe patches and no PCD fix
This means no cursor keys.

2) Using the PCD fix only

I made this change:

-  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()"
+  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"^M
+  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"^M

And it fails to boot, giving this error message:

Fail to start the console with the Device Path
'VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)'.
(Error 'Not Found')

I guess there's something missing in the upstream .DSC file :-(

So I went back to using OpenPlatformPkg - but without building Shell
from source.

And it doesn't work.

3) I add back in your 3 SerialDxe patches
The serial port comes back to life.




> (Although I find it somewhat flattering that I apparently fixed the cursor 
> keys so well that they *cannot* be broken, even if you try! ;))

:-)

So I've worked out what my anomaly was.

It turns out that having this patch in my tree also fixes cursor keys
on the serial port, but not function keys like F9.  No, I have no clue
what this patch has to do with the serial port, other than I am
testing the cursor keys AFTER Shell has run, so the latest version of
Shell could be doing something funky with the serial port setup.  Like
changing the FIFO length.

commit eaa23c12db4d32879bb4a6f826d7e003936e11df
Author: Ryan Harkin 
Date:   Thu Jan 21 08:32:11 2016 +

Platforms/ARM: fvp: build Shell from source

Rather than use a pre-built Shell binary, build the Shell from source.

This allows the developer to debug and fix bugs in Shell, as well as
test the latest source code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin 
---
 Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf |  2 +-
 Platforms/ARM/VExpress/ArmVExpress.dsc.inc | 19 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
index e3ff0cc..a1ae35a 100644
--- a/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
+++ b/Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf
@@ -214,7 +214,7 @@ FvNameGuid = 87940482-fc81-41c3-87e6-399cf85ac8a0
   #
   # UEFI application (Shell Embedded Boot Loader)
   #
-  INF ShellBinPkg/UefiShell/UefiShell.inf
+  INF ShellPkg/Application/Shell/Shell.inf^M

   #
   # Bds
diff --git a/Platforms/ARM/VExpress/ArmVExpress.dsc.inc
b/Platforms/ARM/VExpress/ArmVExpress.dsc.inc
index 86bad01..d6b02b9 100644
--- a/Platforms/ARM/VExpress/ArmVExpress.dsc.inc
+++ b/Platforms/ARM/VExpress/ArmVExpress.dsc.inc
@@ -483,3 +483,22 @@

   # Legacy Linux Loader
   ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+^M
+  #^M
+  # UEFI applicat

Re: [edk2] [PATCH v2 00/14] ShellPkg: BCFG dump improvements

[Laszlo Ersek]

On 01/21/16 19:25, Carsey, Jaben wrote:
> For series. Reviewed-by: Jaben Carsey 

Thanks much; series committed as SVN r19706..r19719, inclusive.

I'm unsure whom we should ping for refreshing the binaries under
ShellBinPkg/ -- although I guess this is not very urgent.

Cheers!
Laszlo

> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, January 21, 2016 9:07 AM
>> To: edk2-devel-01 
>> Cc: Carsey, Jaben ; Ryan Harkin
>> 
>> Subject: [PATCH v2 00/14] ShellPkg: BCFG dump improvements
>> Importance: High
>>
>> Version 2 of .
>>
>> Changes relative to v1:
>>
>> - Bump the minor version numbers in the INF files of
>>   UefiShellBcfgCommandLib, UefiShellCommandLib,
>>   UefiShellDebug1CommandsLib [Jaben].
>>
>>   For the first of these, a final patch has been added.
>>
>>   For the last two, because they are affected together by a single code
>>   movement patch, that patch has been extended with the INF changes.
>>
>> - Replace "UefiShellBcfgCommandLib" with "BcfgDisplayDump()" in most of
>>   the subject lines, so that it's clear a given patch affects only the
>>   "bcfg dump" subcommand, not the entirety of "bcfg" [Laszlo]
>>
>> - The above are also marked on each patch, as notes.
>>
>> - No functional changes.
>>
>> Public branch:
>> .
>>
>> Cc: Jaben Carsey 
>> Cc: Ryan Harkin 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (14):
>>   ShellPkg: BcfgDisplayDump(): update whitespace & layout
>>   ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens
>>   ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]
>>   ShellPkg: BcfgDisplayDump(): accumulate errors
>>   ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot and co.
>>   ShellPkg: BcfgDisplayDump(): address FilePathListLength by name
>>   ShellPkg: BcfgDisplayDump(): call Description[Size] by name
>>   ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication
>>   ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly
>>   ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData
>>   ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site
>>   ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal
>>   ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()
>>   ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING
>>
>>  ShellPkg/Include/Library/ShellCommandLib.h 
>> |  16 +++
>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>> | 103 
>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>> |   2 +-
>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
>> |   4 +-
>>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c |
>> 69 +
>>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf   
>> |   2
>> +-
>>
>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>> b.c   |  70 -
>>
>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>> b.h   |  16 ---
>>
>> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
>> b.inf |   2 +-
>>  9 files changed, 150 insertions(+), 134 deletions(-)
>>
>> --
>> 1.8.3.1
> 

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

Re: [edk2] [PATCH v2 00/14] ShellPkg: BCFG dump improvements

[Carsey, Jaben]

For series. Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 21, 2016 9:07 AM
> To: edk2-devel-01 
> Cc: Carsey, Jaben ; Ryan Harkin
> 
> Subject: [PATCH v2 00/14] ShellPkg: BCFG dump improvements
> Importance: High
> 
> Version 2 of .
> 
> Changes relative to v1:
> 
> - Bump the minor version numbers in the INF files of
>   UefiShellBcfgCommandLib, UefiShellCommandLib,
>   UefiShellDebug1CommandsLib [Jaben].
> 
>   For the first of these, a final patch has been added.
> 
>   For the last two, because they are affected together by a single code
>   movement patch, that patch has been extended with the INF changes.
> 
> - Replace "UefiShellBcfgCommandLib" with "BcfgDisplayDump()" in most of
>   the subject lines, so that it's clear a given patch affects only the
>   "bcfg dump" subcommand, not the entirety of "bcfg" [Laszlo]
> 
> - The above are also marked on each patch, as notes.
> 
> - No functional changes.
> 
> Public branch:
> .
> 
> Cc: Jaben Carsey 
> Cc: Ryan Harkin 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (14):
>   ShellPkg: BcfgDisplayDump(): update whitespace & layout
>   ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens
>   ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]
>   ShellPkg: BcfgDisplayDump(): accumulate errors
>   ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot and co.
>   ShellPkg: BcfgDisplayDump(): address FilePathListLength by name
>   ShellPkg: BcfgDisplayDump(): call Description[Size] by name
>   ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication
>   ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly
>   ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData
>   ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site
>   ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal
>   ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()
>   ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING
> 
>  ShellPkg/Include/Library/ShellCommandLib.h | 
>  16 +++
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> | 103 
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
> |   2 +-
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
> |   4 +-
>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c |
> 69 +
>  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf   | 
>   2
> +-
> 
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.c   |  70 -
> 
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.h   |  16 ---
> 
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.inf |   2 +-
>  9 files changed, 150 insertions(+), 134 deletions(-)
> 
> --
> 1.8.3.1

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

Re: [edk2] [PATCH v2 01/14] ShellPkg: BcfgDisplayDump(): update whitespace & layout

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 21, 2016 9:07 AM
> To: edk2-devel-01 
> Cc: Carsey, Jaben ; Ryan Harkin
> 
> Subject: [PATCH v2 01/14] ShellPkg: BcfgDisplayDump(): update whitespace &
> layout
> Importance: High
> 
> This patch incurs no functional changes, it just modifies some whitespace,
> so we can separate these non-functional changes from the functional
> changes in the next patches.
> 
> Cc: Jaben Carsey 
> Cc: Ryan Harkin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> - clarify in the subject that the patch affects only the "bcfg dump"
>   subcommand, not all of "bcfg"
> 
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 20
> ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index 142504a..f6f4ab3 100644
> --- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> +++
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> @@ -1043,14 +1043,14 @@ BcfgDisplayDump(
>IN CONST BOOLEAN  VerboseOutput
>)
>  {
> -  EFI_STATUS  Status;
> -  UINT8   *Buffer;
> -  UINTN   BufferSize;
> -  CHAR16  VariableName[12];
> -  UINTN   LoopVar;
> -  UINTN   LoopVar2;
> -  CHAR16  *DevPathString;
> -  VOID*DevPath;
> +  EFI_STATUS  Status;
> +  UINT8   *Buffer;
> +  UINTN   BufferSize;
> +  CHAR16  VariableName[12];
> +  UINTN   LoopVar;
> +  UINTN   LoopVar2;
> +  CHAR16  *DevPathString;
> +  VOID*DevPath;
> 
>if (OrderCount == 0) {
>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE),
> gShellBcfgHiiHandle, L"bcfg");
> @@ -1058,8 +1058,8 @@ BcfgDisplayDump(
>}
> 
>for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
> -Buffer  = NULL;
> -BufferSize  = 0;
> +Buffer= NULL;
> +BufferSize= 0;
>  UnicodeSPrint(VariableName, sizeof(VariableName), L"%s%04x", Op,
> CurrentOrder[LoopVar]);
> 
>  Status = gRT->GetVariable(
> --
> 1.8.3.1
> 

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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 18:57, Ryan Harkin wrote:
> On 21 January 2016 at 17:19, Laszlo Ersek  wrote:

>> Ryan, can you please test the following configuration:
>> - your PCD update in place, but this three-part series of mine
>>   *reverted*
>>
>> This should break the cursor movement keys again, and also break the
>> function keys, despite the escape sequences being correct (thanks to
>> your PCD update). This would answer Ray's question.
>>
> 
> I'm happy to give this a go.  But I'm having trouble returning to a
> setup where the cursor keys are broken at all.  I've reverted the PCD
> setting and F9 no longer works, but ...  I don't know what I'm doing
> wrong.  I think I need to take a break from it for 1/2 hour and come
> back to work it out.  I'm pretty sure I've cleaned the repo and
> flushed the builds... it's weird.
> 
> I'll report back soon.

Right, I proposed the opposite config for testing -- *keep* the PCD changes, 
and revert the series in your local tree whose thread we're conducting this 
discussion in. :)

#1: revert 31ae446 MdeModulePkg: TerminalDxe: select the UART's default receive 
FIFO depth
#2: revert ea01261 MdeModulePkg: SerialDxe: sync EFI_SERIAL_IO_MODE.Timeout 
with the spec
#3: revert c0beed6 MdeModulePkg: SerialDxe: lay out mSerialIoMode initializer 
more nicely

(Although I find it somewhat flattering that I apparently fixed the cursor keys 
so well that they *cannot* be broken, even if you try! ;))

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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 17:19, Laszlo Ersek  wrote:
> On 01/21/16 18:02, Ryan Harkin wrote:
>> On 21 January 2016 at 16:05, Laszlo Ersek  wrote:
>>> On 01/21/16 13:57, Ryan Harkin wrote:
 On 21 January 2016 at 11:46, Laszlo Ersek  wrote:
> adding Roy
>
> On 01/21/16 10:51, Ryan Harkin wrote:
>> Hi Ray,
>>
>> On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
>>> It makes sense that F2 to F9 behaves like ESC because
>>> the Serial device doesn't have enough buffer (FIFO)
>>> to hold all the escape sequence keys.
>>>
>>> Because the certain platform cannot handle escape
>>> sequence keys like F2-F9 or cursor movement, I
>>> think it's reasonable to use a bigger FIFO other 1
>>> in that certain platform.
>>>
>>
>> I should have mentioned that I'm using Laszlo's recent SerialDxe patch
>> series to fix the cursor keys.  That should leave me with enough FIFO
>> to handle the function keys.
>
> I think that's a different issue. The file
>
>   MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>
> starts with a table, in a comment, that explains the escape sequences
> that TerminalDxe expects and decodes for the various function keys,
> dependent on the terminal type selected.
>
> In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
> Apparently, for me F9 generates
>
>   ESC [ 20~
>
> which doesn't match any column (= any terminal type known to
> TerminalDxe) in the F9 row of the table.
>
> The above escape sequence seems to come from my terminfo database; at
> least when I run "infocmp" from the same xterm, the output contains
>
>   kf9=\E[20~
>
> So, when I use the QEMU serial console, F9 doesn't work for me either.
> It works if I use the graphical console and the emulated USB or PS/2
> keyboard.
>
> ... Hm, maybe the recently added TTYTERMTYPE could handle these escape
> sequences:
>
> commit 014f93acab63e8e72f2113d8090c550e05c16c93
> Author: Roy Franz 
> Date:   Thu Jul 9 06:24:20 2015 +
>
> Accept VT220 DEL and function keys for TTY terminal type
>
> In the Intel BDS, you can configure your terminal type, in
>
> Boot Maintenance Manager
>   Console Options
> COM Attribute Setup Page
>   

 This is where I stumble... with or without your patch, this list is
 empty on FVP.

 Going here:

  Boot Maintenance Manager
Console Options
  Console Input Device Select

 ... only gives me one option:

  VenHw(D3987D4B-971A-435F-8 [X]
CAF-4967EB627241)/Uart(384
00,8,N,1)/VenPcAnsi()

 ... and it gets that from my .dsc file:

 Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc:181:
 gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"

 38400?  Ouch.
>>>
>>> (1) Actually, it's quite good that you located this in your DSC file. It
>>> is used in
>>>
>>>   ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>>>
>>> I think if you replace
>>>
>>>   VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()
>>>
>>> in both
>>>
>>>   PcdDefaultConOutPaths
>>>   PcdDefaultConInPaths
>>>
>>> with
>>>
>>>   
>>> VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
>>>
>>> IOW, if you bump the baud rate to 115200, plus replace VenPcAnsi() with
>>> VenMsg(...), then it should work.
>>>
>>
>> OK, you're on a roll with this stuff!  After applying that change, the
>> F9 key works.  Thanks again!
>
> Heh, great :) Thank Roy for implementing TtyTerm :)
>
>> And now that you've shown me how to default to a sensible terminal
>> type, my backspace key also works.  It's a miracle!
>
> Awesome. :)
>
> Now, let's return to the question originally asked by Ray (scroll down a
> bit please):
>
>>
>>
>>
>>> (2) The first GUID (in VenHw()) is the FILE_GUID of SerialDxe.
>>>
>>> The second GUID (in VenMsg()) is from
>>> "MdeModulePkg/Include/Guid/TtyTerm.h"; it identifies the TtyTerm type.
>>>
>>> Normally there should be a more textual-looking shorthand for that
>>> VenMsg(), like VenPcAnsi(). However, because TtyTerm is not standardized
>>> in the UEFI spec, the shorthand formatting could not be added to
>>> MdePkg/Library/UefiDevicePathLib -- packages under MdePkg follow
>>> standards strictly.
>>>
>>> (3) We more or less patched the same for ArmVirtQemu (please refer to
>>> git commit a51c1699), but differently. That difference is due to the
>>> fact that ArmVirtQemu uses its own, independent PlatformBdsLib instance
>>> ("ArmVirtPkg/Library/PlatformIntelBdsLib"). Hence a51c1699 isn't
>>> portable to "ArmPlatformPkg/Library/PlatformIntelBdsLib", which is used
>>> by FVP. But the metho

[edk2] [Patch 1/2] MdeModulePkg: Define one function to create DNS QName

[Jiaxin Wu]

This patch is used to define a general function to create
DNS QName.
QName is a domain name represented as a sequence
of labels, where each label consists of a length octet
followed by that number of octets. The domain name terminates
with the zero length octet for the null label of the root.

Cc: Hegde Nagaraj P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Include/Library/NetLib.h  | 21 +++
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 58 +-
 2 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Include/Library/NetLib.h 
b/MdeModulePkg/Include/Library/NetLib.h
index e4456fa..a257815 100644
--- a/MdeModulePkg/Include/Library/NetLib.h
+++ b/MdeModulePkg/Include/Library/NetLib.h
@@ -35,10 +35,11 @@ typedef UINT16  TCP_PORTNO;
 #define  EFI_IP_PROTO_UDP  0x11
 #define  EFI_IP_PROTO_TCP  0x06
 #define  EFI_IP_PROTO_ICMP 0x01
 #define  IP4_PROTO_IGMP0x02
 #define  IP6_ICMP  58
+#define  DNS_MAX_BLKSIZE   512
 
 //
 // The address classification
 //
 #define  IP4_ADDR_CLASSA   1
@@ -2154,6 +2155,26 @@ EFI_STATUS
 EFIAPI
 NetLibGetSystemGuid (
   OUT EFI_GUID  *SystemGuid
   );
 
+/**
+  Create Dns QName according the queried domain name. 
+  QName is a domain name represented as a sequence of labels, 
+  where each label consists of a length octet followed by that 
+  number of octets. The domain name terminates with the zero 
+  length octet for the null label of the root. Caller should 
+  take responsibility to the buffer in QName.
+
+  @param  StringThe pointer to the queried Ascii string.  
+
+  @retval NULL  Failed to fill QName.
+  @return   QName filled successfully.
+  
+**/ 
+CHAR8 *
+EFIAPI
+NetLibCreateDnsQName (
+  IN  CHAR16  *DomainName
+  );
+
 #endif
diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index e112d45..dd67a1c 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -1,9 +1,9 @@
 /** @file
   Network library.
 
-Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 2016, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP
 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
@@ -3324,5 +3324,61 @@ NetLibGetSystemGuid (
   }
 } while (TRUE);
   } while (Smbios.Raw < SmbiosEnd.Raw);
   return EFI_NOT_FOUND;
 }
+
+/**
+  Create Dns QName according the queried domain name. 
+  QName is a domain name represented as a sequence of labels, 
+  where each label consists of a length octet followed by that 
+  number of octets. The domain name terminates with the zero 
+  length octet for the null label of the root. Caller should 
+  take responsibility to the buffer in QName.
+
+  @param  StringThe pointer to the queried Ascii string.  
+
+  @retval NULL  Failed to fill QName.
+  @return   QName filled successfully.
+  
+**/ 
+CHAR8 *
+EFIAPI
+NetLibCreateDnsQName (
+  IN  CHAR16  *DomainName
+  )
+{
+  CHAR8 *QueryName;
+  CHAR8 *Header;
+  CHAR8 *Tail;
+  UINTN Len;
+  UINTN Index;
+
+  QueryName  = NULL;
+  Header = NULL;
+  Tail   = NULL;
+
+  QueryName = AllocateZeroPool (DNS_MAX_BLKSIZE);
+  if (QueryName == NULL) {
+return NULL;
+  }
+  
+  Header = QueryName;
+  Tail = Header + 1;
+  Len = 0;
+  for (Index = 0; DomainName[Index] != 0; Index++) {
+*Tail = (CHAR8) DomainName[Index];
+if (*Tail == '.') {
+  *Header = (CHAR8) Len;
+  Header = Tail;
+  Tail ++;
+  Len = 0;
+} else {
+  Tail++;
+  Len++;
+}
+  }
+  *Header = (CHAR8) Len;
+  *Tail = 0;
+
+  return QueryName;
+}
\ No newline at end of file
-- 
1.9.5.msysgit.1

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

[edk2] [Patch 2/2] NetworkPkg: Replace the internal function with exposed one

[Jiaxin Wu]

This patch is used to replace the internal function with
the exposed one defined in NetLib.h.

Cc: Hegde Nagaraj P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/DnsDxe/DnsImpl.c | 63 -
 NetworkPkg/DnsDxe/DnsImpl.h | 19 -
 NetworkPkg/DnsDxe/DnsProtocol.c |  6 ++--
 3 files changed, 9 insertions(+), 79 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c
index 71dacce..77e6496 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -1012,65 +1012,10 @@ AddDns6ServerIp (
   
   return EFI_SUCCESS;
 }
 
 /**
-  Fill QName for IP querying. QName is a domain name represented as 
-  a sequence of labels, where each label consists of a length octet 
-  followed by that number of octets. The domain name terminates with 
-  the zero length octet for the null label of the root. Caller should 
-  take responsibility to the buffer in QName.
-
-  @param  HostName  Queried HostName
-
-  @retval NULL  Failed to fill QName.
-  @return   QName filled successfully.
-  
-**/ 
-CHAR8 *
-EFIAPI
-DnsFillinQNameForQueryIp (
-  IN  CHAR16  *HostName
-  )
-{
-  CHAR8 *QueryName;
-  CHAR8 *Header;
-  CHAR8 *Tail;
-  UINTN Len;
-  UINTN Index;
-
-  QueryName  = NULL;
-  Header = NULL;
-  Tail   = NULL;
-
-  QueryName = AllocateZeroPool (DNS_DEFAULT_BLKSIZE);
-  if (QueryName == NULL) {
-return NULL;
-  }
-  
-  Header = QueryName;
-  Tail = Header + 1;
-  Len = 0;
-  for (Index = 0; HostName[Index] != 0; Index++) {
-*Tail = (CHAR8) HostName[Index];
-if (*Tail == '.') {
-  *Header = (CHAR8) Len;
-  Header = Tail;
-  Tail ++;
-  Len = 0;
-} else {
-  Tail++;
-  Len++;
-}
-  }
-  *Header = (CHAR8) Len;
-  *Tail = 0;
-
-  return QueryName;
-}
-
-/**
   Find out whether the response is valid or invalid.
 
   @param  TokensMap   All DNS transmittal Tokens entry.  
   @param  Identification  Identification for queried packet.  
   @param  TypeType for queried packet.
@@ -1780,12 +1725,16 @@ ConstructDNSQuery (
   )
 {
   NET_FRAGMENTFrag;
   DNS_HEADER  *DnsHeader;
   DNS_QUERY_SECTION   *DnsQuery;
-  
-  Frag.Bulk = AllocatePool (DNS_DEFAULT_BLKSIZE * sizeof (UINT8));
+
+  //
+  // Messages carried by UDP are restricted to 512 bytes (not counting the IP
+  // or UDP headers).
+  //
+  Frag.Bulk = AllocatePool (DNS_MAX_BLKSIZE * sizeof (UINT8));
   if (Frag.Bulk == NULL) {
 return EFI_OUT_OF_RESOURCES;
   }
 
   //
diff --git a/NetworkPkg/DnsDxe/DnsImpl.h b/NetworkPkg/DnsDxe/DnsImpl.h
index 72b85cb..e286064 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.h
+++ b/NetworkPkg/DnsDxe/DnsImpl.h
@@ -85,11 +85,10 @@ extern EFI_DNS6_PROTOCOL mDns6Protocol;
 #define DNS_STATE_CONFIGED   1
 #define DNS_STATE_DESTROY2
 
 #define DNS_DEFAULT_TIMEOUT  2
 #define DNS_DEFAULT_RETRY3
-#define DNS_DEFAULT_BLKSIZE  512
 
 #define DNS_TIME_TO_GETMAP   5
 
 #pragma pack(1)
 
@@ -555,28 +554,10 @@ AddDns6ServerIp (
   IN LIST_ENTRY*Dns6ServerList,
   IN EFI_IPv6_ADDRESS   ServerIp
   );
 
 /**
-  Fill QName for IP querying. QName is a domain name represented as 
-  a sequence of labels, where each label consists of a length octet 
-  followed by that number of octets. The domain name terminates with 
-  the zero length octet for the null label of the root.
-
-  @param  HostName  Queried HostName
-
-  @retval NULL  Failed to fill QName.
-  @return   QName filled successfully.
-  
-**/ 
-CHAR8 *
-EFIAPI
-DnsFillinQNameForQueryIp (
-  IN  CHAR16  *HostName
-  );
-
-/**
   Find out whether the response is valid or invalid.
 
   @param  TokensMap   All DNS transmittal Tokens entry.  
   @param  Identification  Identification for queried packet.  
   @param  TypeType for queried packet.
diff --git a/NetworkPkg/DnsDxe/DnsProtocol.c b/NetworkPkg/DnsDxe/DnsProtocol.c
index a3f3de9..3093535 100644
--- a/NetworkPkg/DnsDxe/DnsProtocol.c
+++ b/NetworkPkg/DnsDxe/DnsProtocol.c
@@ -1,9 +1,9 @@
 /** @file
 Implementation of EFI_DNS4_PROTOCOL and EFI_DNS6_PROTOCOL interfaces.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2016, 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
 
@@ -442,11 +442,11 @@ Dns4HostNameToIp (
   TokenEntry->Token = Token;
 
   //
   // Construct QName.
   //
-  QueryName = DnsFillinQNameForQueryIp (TokenEntry->QueryHostName);
+  QueryName = NetLibCreateDnsQName (Token

[edk2] [Patch 0/2] Expose one function defined in DnsDxe to NetLib

[Jiaxin Wu]

The series of patches are used to expose one function defined in 
DnsDxe to NetLib.

Cc: Hegde Nagaraj P 
Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (2):
  MdeModulePkg: Define a general function to create DNS QName
  NetworkPkg: Replace the internal function with exposed one

 MdeModulePkg/Include/Library/NetLib.h  | 21 ++
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 58 ++-
 NetworkPkg/DnsDxe/DnsImpl.c| 63 +++---
 NetworkPkg/DnsDxe/DnsImpl.h| 19 -
 NetworkPkg/DnsDxe/DnsProtocol.c|  6 +--
 5 files changed, 87 insertions(+), 80 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 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 17:44, Leif Lindholm  wrote:
> On Thu, Jan 21, 2016 at 05:36:41PM +, Ryan Harkin wrote:
>> On 21 January 2016 at 17:32, Leif Lindholm  wrote:
>> > On Thu, Jan 21, 2016 at 06:19:22PM +0100, Laszlo Ersek wrote:
>> >> Anyway, another question (for the ArmPlatformPkg maintainers as well):
>> >> do you guys think that the PCD update in question should be commited to
>> >> the repo, for the FVP (and maybe Foundation) DSC files? After all those
>> >> are mostly used from GNU/Linux graphical terminals, for which Roy
>> >> implemented TtyTerm.
>> >>
>> >> If that makes sense to you guys, perhaps Ryan can post the patch.
>> >
>> > Yeah, I've been waiting for a good natural point at which to
>> > (potentially) cause breakage, and this seeems like one. So I'm happy
>> > for that change to happen. Unless Ryan disagrees?
>>
>> Er, well, I sent you a patch series to remove FVP from ArmPlatformPkg
>> and to add it to OpenPlatformPkg...  but I'm stacking these changes up
>> for OpenPlatformPkg as I work through the issues.
>
> Yes, I know (and I like it, but I'm spending the week at a powerpoint
> festival).

Lucky you ;-)

> But I still think it's at least partially your call even
> for OpenPlatformPkg.

I don't think we should add patches to change FVP or Juno in
ArmPlatformPkg.  I'm happy to queue up some patches for
OpenPlatformPkg.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Leif Lindholm]

On Thu, Jan 21, 2016 at 05:36:41PM +, Ryan Harkin wrote:
> On 21 January 2016 at 17:32, Leif Lindholm  wrote:
> > On Thu, Jan 21, 2016 at 06:19:22PM +0100, Laszlo Ersek wrote:
> >> Anyway, another question (for the ArmPlatformPkg maintainers as well):
> >> do you guys think that the PCD update in question should be commited to
> >> the repo, for the FVP (and maybe Foundation) DSC files? After all those
> >> are mostly used from GNU/Linux graphical terminals, for which Roy
> >> implemented TtyTerm.
> >>
> >> If that makes sense to you guys, perhaps Ryan can post the patch.
> >
> > Yeah, I've been waiting for a good natural point at which to
> > (potentially) cause breakage, and this seeems like one. So I'm happy
> > for that change to happen. Unless Ryan disagrees?
> 
> Er, well, I sent you a patch series to remove FVP from ArmPlatformPkg
> and to add it to OpenPlatformPkg...  but I'm stacking these changes up
> for OpenPlatformPkg as I work through the issues.

Yes, I know (and I like it, but I'm spending the week at a powerpoint
festival). But I still think it's at least partially your call even
for OpenPlatformPkg.

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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 17:32, Leif Lindholm  wrote:
> On Thu, Jan 21, 2016 at 06:19:22PM +0100, Laszlo Ersek wrote:
>> Anyway, another question (for the ArmPlatformPkg maintainers as well):
>> do you guys think that the PCD update in question should be commited to
>> the repo, for the FVP (and maybe Foundation) DSC files? After all those
>> are mostly used from GNU/Linux graphical terminals, for which Roy
>> implemented TtyTerm.
>>
>> If that makes sense to you guys, perhaps Ryan can post the patch.
>
> Yeah, I've been waiting for a good natural point at which to
> (potentially) cause breakage, and this seeems like one. So I'm happy
> for that change to happen. Unless Ryan disagrees?
>

Er, well, I sent you a patch series to remove FVP from ArmPlatformPkg
and to add it to OpenPlatformPkg...  but I'm stacking these changes up
for OpenPlatformPkg as I work through the issues.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Leif Lindholm]

On Thu, Jan 21, 2016 at 06:19:22PM +0100, Laszlo Ersek wrote:
> Anyway, another question (for the ArmPlatformPkg maintainers as well):
> do you guys think that the PCD update in question should be commited to
> the repo, for the FVP (and maybe Foundation) DSC files? After all those
> are mostly used from GNU/Linux graphical terminals, for which Roy
> implemented TtyTerm.
> 
> If that makes sense to you guys, perhaps Ryan can post the patch.

Yeah, I've been waiting for a good natural point at which to
(potentially) cause breakage, and this seeems like one. So I'm happy
for that change to happen. Unless Ryan disagrees?

Regards,

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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 18:02, Ryan Harkin wrote:
> On 21 January 2016 at 16:05, Laszlo Ersek  wrote:
>> On 01/21/16 13:57, Ryan Harkin wrote:
>>> On 21 January 2016 at 11:46, Laszlo Ersek  wrote:
 adding Roy

 On 01/21/16 10:51, Ryan Harkin wrote:
> Hi Ray,
>
> On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
>> It makes sense that F2 to F9 behaves like ESC because
>> the Serial device doesn't have enough buffer (FIFO)
>> to hold all the escape sequence keys.
>>
>> Because the certain platform cannot handle escape
>> sequence keys like F2-F9 or cursor movement, I
>> think it's reasonable to use a bigger FIFO other 1
>> in that certain platform.
>>
>
> I should have mentioned that I'm using Laszlo's recent SerialDxe patch
> series to fix the cursor keys.  That should leave me with enough FIFO
> to handle the function keys.

 I think that's a different issue. The file

   MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h

 starts with a table, in a comment, that explains the escape sequences
 that TerminalDxe expects and decodes for the various function keys,
 dependent on the terminal type selected.

 In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
 Apparently, for me F9 generates

   ESC [ 20~

 which doesn't match any column (= any terminal type known to
 TerminalDxe) in the F9 row of the table.

 The above escape sequence seems to come from my terminfo database; at
 least when I run "infocmp" from the same xterm, the output contains

   kf9=\E[20~

 So, when I use the QEMU serial console, F9 doesn't work for me either.
 It works if I use the graphical console and the emulated USB or PS/2
 keyboard.

 ... Hm, maybe the recently added TTYTERMTYPE could handle these escape
 sequences:

 commit 014f93acab63e8e72f2113d8090c550e05c16c93
 Author: Roy Franz 
 Date:   Thu Jul 9 06:24:20 2015 +

 Accept VT220 DEL and function keys for TTY terminal type

 In the Intel BDS, you can configure your terminal type, in

 Boot Maintenance Manager
   Console Options
 COM Attribute Setup Page
   
>>>
>>> This is where I stumble... with or without your patch, this list is
>>> empty on FVP.
>>>
>>> Going here:
>>>
>>>  Boot Maintenance Manager
>>>Console Options
>>>  Console Input Device Select
>>>
>>> ... only gives me one option:
>>>
>>>  VenHw(D3987D4B-971A-435F-8 [X]
>>>CAF-4967EB627241)/Uart(384
>>>00,8,N,1)/VenPcAnsi()
>>>
>>> ... and it gets that from my .dsc file:
>>>
>>> Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc:181:
>>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"
>>>
>>> 38400?  Ouch.
>>
>> (1) Actually, it's quite good that you located this in your DSC file. It
>> is used in
>>
>>   ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>>
>> I think if you replace
>>
>>   VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()
>>
>> in both
>>
>>   PcdDefaultConOutPaths
>>   PcdDefaultConInPaths
>>
>> with
>>
>>   
>> VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
>>
>> IOW, if you bump the baud rate to 115200, plus replace VenPcAnsi() with
>> VenMsg(...), then it should work.
>>
> 
> OK, you're on a roll with this stuff!  After applying that change, the
> F9 key works.  Thanks again!

Heh, great :) Thank Roy for implementing TtyTerm :)

> And now that you've shown me how to default to a sensible terminal
> type, my backspace key also works.  It's a miracle!

Awesome. :)

Now, let's return to the question originally asked by Ray (scroll down a
bit please):

> 
> 
> 
>> (2) The first GUID (in VenHw()) is the FILE_GUID of SerialDxe.
>>
>> The second GUID (in VenMsg()) is from
>> "MdeModulePkg/Include/Guid/TtyTerm.h"; it identifies the TtyTerm type.
>>
>> Normally there should be a more textual-looking shorthand for that
>> VenMsg(), like VenPcAnsi(). However, because TtyTerm is not standardized
>> in the UEFI spec, the shorthand formatting could not be added to
>> MdePkg/Library/UefiDevicePathLib -- packages under MdePkg follow
>> standards strictly.
>>
>> (3) We more or less patched the same for ArmVirtQemu (please refer to
>> git commit a51c1699), but differently. That difference is due to the
>> fact that ArmVirtQemu uses its own, independent PlatformBdsLib instance
>> ("ArmVirtPkg/Library/PlatformIntelBdsLib"). Hence a51c1699 isn't
>> portable to "ArmPlatformPkg/Library/PlatformIntelBdsLib", which is used
>> by FVP. But the method described in (1) should work for you.
>>
>> Thanks
>> Laszlo
>>
>>>
>>>
 Set COM Terminal Type

 But, there are two problems with that:
 - it doesn't seem to know about

[edk2] [PATCH v2 14/14] ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING

[Laszlo Ersek]

The changes due to the previous patches should be reflected in a higher
minor version number.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Suggested-by: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2 [Jaben]

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
index bacaeec..44c8b7e 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
@@ -17,7 +17,7 @@ [Defines]
   BASE_NAME  = UefiShellBcfgCommandLib
   FILE_GUID  = F6A3BF5D-4095-4E4F-9670-408770C2DBDF
   MODULE_TYPE= UEFI_DRIVER
-  VERSION_STRING = 1.0
+  VERSION_STRING = 1.1
   LIBRARY_CLASS  = BcfgCommandLib|UEFI_APPLICATION UEFI_DRIVER
 
 [Sources.common]
-- 
1.8.3.1

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

[edk2] [PATCH v2 09/14] ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly

[Laszlo Ersek]

Eliminate some more repeated pointer arithmetic.

This patch too is only refactoring.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 10 
--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index d109ca2..ca7ecd1 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1055,6 +1055,7 @@ BcfgDisplayDump(
   EFI_LOAD_OPTION *LoadOption;
   CHAR16  *Description;
   UINTN   DescriptionSize;
+  UINTN   OptionalDataOffset;
 
   if (OrderCount == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
gShellBcfgHiiHandle, L"bcfg");  
@@ -1118,6 +1119,10 @@ BcfgDisplayDump(
   FilePathList = (UINT8 *)Description + DescriptionSize;
   DevPathString = ConvertDevicePathToText(FilePathList, TRUE, FALSE);
 }
+
+OptionalDataOffset = sizeof *LoadOption + DescriptionSize +
+ LoadOption->FilePathListLength;
+
 ShellPrintHiiEx(
   -1,
   -1,
@@ -1128,9 +1133,10 @@ BcfgDisplayDump(
   VariableName,
   Description,
   DevPathString,
-  (DescriptionSize + LoadOption->FilePathListLength + 6) <= 
BufferSize?L'N':L'Y');
+  OptionalDataOffset <= BufferSize ? L'N' : L'Y'
+  );
 if (VerboseOutput) {
-  for (LoopVar2 = (DescriptionSize + LoadOption->FilePathListLength + 
6);LoopVar2https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 13/14] ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()

[Laszlo Ersek]

The DumpHex() function produces very friendly output (known from DMPSTORE,
for example); let's use it with "BCFG -v" as well.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 21 
+++-
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 64e4270..6a078d8 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1048,7 +1048,6 @@ BcfgDisplayDump(
   UINTN   BufferSize;
   CHAR16  VariableName[12];
   UINTN   LoopVar;
-  UINTN   LoopVar2;
   CHAR16  *DevPathString;
   VOID*FilePathList;
   UINTN   Errors;
@@ -1135,19 +1134,13 @@ BcfgDisplayDump(
   DevPathString,
   OptionalDataOffset >= BufferSize ? L'N' : L'Y'
   );
-if (VerboseOutput) {
-  for (LoopVar2 = OptionalDataOffset; LoopVar2 < BufferSize; LoopVar2++){
-ShellPrintEx(
-  -1,
-  -1,
-  L"%02x",
-  Buffer[LoopVar2]);
-  }
-  ShellPrintEx(
--1,
--1,
-NULL,
-L"\r\n");
+if (VerboseOutput && (OptionalDataOffset < BufferSize)) {
+  DumpHex (
+2,   // Indent
+0,   // Offset (displayed)
+BufferSize - OptionalDataOffset, // DataSize
+Buffer + OptionalDataOffset  // UserData
+);
 }
 
 Cleanup:
-- 
1.8.3.1


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

[edk2] [PATCH v2 05/14] ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot#### and co.

[Laszlo Ersek]

"3.1.1 Boot Manager Programming" in the UEFI 2.5 spec mandates that
Boot and similar options contain EFI_LOAD_OPTION structures. The
EFI_LOAD_OPTION structure encodes the fixed initial part of the payload,
and we can (and should) use it to enforce a minimum size for variable
contents.

This patch is meant as a safety improvement.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c   | 19 
+++
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni |  1 +
 2 files changed, 20 insertions(+)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 36d04d4..9955c9e 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1052,6 +1052,7 @@ BcfgDisplayDump(
   CHAR16  *DevPathString;
   VOID*DevPath;
   UINTN   Errors;
+  EFI_LOAD_OPTION *LoadOption;
 
   if (OrderCount == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
gShellBcfgHiiHandle, L"bcfg");  
@@ -1090,6 +1091,24 @@ BcfgDisplayDump(
   goto Cleanup;
 }
 
+//
+// We expect the Attributes, FilePathListLength, and L'\0'-terminated
+// Description fields to be present.
+//
+if (BufferSize < sizeof *LoadOption + sizeof (CHAR16)) {
+  ShellPrintHiiEx (
+-1,
+-1,
+NULL,
+STRING_TOKEN (STR_BCFG_VAR_CORRUPT),
+gShellBcfgHiiHandle,
+L"bcfg",
+VariableName
+);
+  ++Errors;
+  goto Cleanup;
+}
+
 if ((*(UINT16*)(Buffer+4)) != 0) {
   DevPath = AllocateZeroPool(*(UINT16*)(Buffer+4));
   if (DevPath != NULL) {
diff --git 
a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
index 25bd138..282494b 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
@@ -37,6 +37,7 @@
 #string STR_GEN_OUT_MEM   #language en-US "%H%s%N: Memory allocation 
was not successful.\r\n"
 #string STR_BCFG_WRITE_FAIL   #language en-US "%H%s%N: Unable to write to 
'%H%s%N'\r\n"
 #string STR_BCFG_READ_FAIL#language en-US "%H%s%N: Unable to read from 
'%H%s%N'\r\n"
+#string STR_BCFG_VAR_CORRUPT  #language en-US "%H%s%N: Variable '%H%s%N' 
corrupt.\r\n"
 #string STR_BCFG_HANDLE   #language en-US "%H%s%N: The handle 
[%H%02x%N] does not have DevicePath.\r\n"
 #string STR_BCFG_FILE #language en-US "%H%s%N: The file '%H%s%N' 
matches multiple files.\r\n"
 #string STR_BCFG_FILE_OPEN#language en-US "%H%s%N: The file '%H%s%N' 
did not open.\r\n"
-- 
1.8.3.1


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

[edk2] [PATCH v2 10/14] ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData

[Laszlo Ersek]

In this cleaned up form of BcfgDisplayDump(), it is easier to see that the

  OptionalDataOffset <= BufferSize

expression, used to report whether optional data are *absent*, is
incorrect. For any well-formed EFI_LOAD_OPTION, this inequality always
holds.

Optional data are present exactly if

  OptionalDataOffset < BufferSize

therefore the absence condition is the negation of the above,

  OptionalDataOffset >= BufferSize

This patch fixes the bug where BCFG always reports "Optional- N", even if
optional data exist.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index ca7ecd1..028f852 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1133,7 +1133,7 @@ BcfgDisplayDump(
   VariableName,
   Description,
   DevPathString,
-  OptionalDataOffset <= BufferSize ? L'N' : L'Y'
+  OptionalDataOffset >= BufferSize ? L'N' : L'Y'
   );
 if (VerboseOutput) {
   for (LoopVar2 = OptionalDataOffset; LoopVar2 < BufferSize; LoopVar2++){
-- 
1.8.3.1


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

[edk2] [PATCH v2 12/14] ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal

[Laszlo Ersek]

The UEFI Shell specification classifies shell commands into various shell
levels / profiles.

Currently the DumpHex() internal function is only used by commands that
belong to the Debug1 profile exclusively (i.e., they are not required to
be present in other than Debug1 profiles):
- SMBIOSVIEW
- PCI
- DMPSTORE
- DMEM
- DBLK

In the next patch, we'd like to call DumpHex() from BCFG as well. However,
BCFG is not only required to be present in the Debug1 profile; the
Install1 profile contains BCFG as well. For this reason, move DumpHex()
from UefiShellDebug1CommandsLib to the more generic UefiShellCommandLib,
which "Provides interface to shell internal functions for shell commands".
The matching header file is "ShellPkg/Include/Library/ShellCommandLib.h".

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- bump minor version numbers for UefiShellCommandLib and
  UefiShellDebug1CommandsLib [Jaben]

 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf   |  
2 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf |  
2 +-
 ShellPkg/Include/Library/ShellCommandLib.h | 
16 +
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h   | 
16 -
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c | 
69 +++
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c   | 
70 
 6 files changed, 87 insertions(+), 88 deletions(-)

diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf 
b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
index 1de5299..e111e8d 100644
--- a/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
+++ b/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
@@ -18,7 +18,7 @@ [Defines]
   BASE_NAME  = UefiShellCommandLib
   FILE_GUID  = 5C12F31F-EBAC-466e-A400-FCA8C9EA3A05
   MODULE_TYPE= UEFI_DRIVER
-  VERSION_STRING = 1.0
+  VERSION_STRING = 1.1
   LIBRARY_CLASS  = ShellCommandLib|UEFI_APPLICATION 
UEFI_DRIVER DXE_RUNTIME_DRIVER
   CONSTRUCTOR= ShellCommandLibConstructor
   DESTRUCTOR = ShellCommandLibDestructor
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
index cfbf001..8104b9a 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
@@ -17,7 +17,7 @@ [Defines]
   BASE_NAME  = UefiShellDebug1CommandsLib
   FILE_GUID  = 90330D51-A99B-4cc8-A2EB-AE22542A3F45
   MODULE_TYPE= UEFI_APPLICATION
-  VERSION_STRING = 1.1
+  VERSION_STRING = 1.2
   LIBRARY_CLASS  = NULL|UEFI_APPLICATION UEFI_DRIVER
   CONSTRUCTOR= UefiShellDebug1CommandsLibConstructor
   DESTRUCTOR = UefiShellDebug1CommandsLibDestructor
diff --git a/ShellPkg/Include/Library/ShellCommandLib.h 
b/ShellPkg/Include/Library/ShellCommandLib.h
index 53a56ae..0dd66c2f 100644
--- a/ShellPkg/Include/Library/ShellCommandLib.h
+++ b/ShellPkg/Include/Library/ShellCommandLib.h
@@ -685,4 +685,20 @@ FreeBufferList (
   IN BUFFER_LIST *List
   );
 
+/**
+  Function printing hex output to the console.
+
+  @param[in] Indent   Number of spaces to indent.
+  @param[in] Offset   Offset to start with.
+  @param[in] DataSize Length of data.
+  @param[in] UserData Pointer to some data.
+**/
+VOID
+DumpHex (
+  IN UINTNIndent,
+  IN UINTNOffset,
+  IN UINTNDataSize,
+  IN VOID *UserData
+  );
+
 #endif //_SHELL_COMMAND_LIB_
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
index ec15155..6e018a6 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h
@@ -62,22 +62,6 @@
 externEFI_HANDLEgShellDebug1HiiHandle;
 
 /**
-  Function printing hex output to the console.
-
-  @param[in] Indent   Number of spaces to indent.
-  @param[in] Offset   Offset to start with.
-  @param[in] DataSize Length of data.
-  @param[in] UserData Pointer to some data.
-**/
-VOID
-DumpHex (
-  IN UINTNIndent,
-  IN UINTNOffset,
-  IN UINTNDataSize,
-  IN VOID *UserData
-  );
-
-/**
   Function returns a system configuration table that is stored in the
   EFI System Table based on the provided GUID.
 
diff --git a/Sh

[edk2] [PATCH v2 11/14] ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site

[Laszlo Ersek]

This is likely a copy & paste error from the preceding ShellPrintHiiEx()
function call. ShellPrintEx() takes no Language parameter, so remove the
NULL argument, which is currently misinterpreted as a format string.

This bug prevents the hexdump of optional data even when -v is passed to
BCFG, and optional data exist.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 028f852..64e4270 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1140,7 +1140,6 @@ BcfgDisplayDump(
 ShellPrintEx(
   -1,
   -1,
-  NULL,
   L"%02x",
   Buffer[LoopVar2]);
   }
-- 
1.8.3.1


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

[edk2] [PATCH v2 07/14] ShellPkg: BcfgDisplayDump(): call Description[Size] by name

[Laszlo Ersek]

Introduce two more helper variables to avoid repeated pointer arithmetic.

This patch is not supposed to change behavior.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 15 
++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index b08aac1..aac85d3 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1053,6 +1053,8 @@ BcfgDisplayDump(
   VOID*DevPath;
   UINTN   Errors;
   EFI_LOAD_OPTION *LoadOption;
+  CHAR16  *Description;
+  UINTN   DescriptionSize;
 
   if (OrderCount == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
gShellBcfgHiiHandle, L"bcfg");  
@@ -1108,12 +1110,15 @@ BcfgDisplayDump(
   ++Errors;
   goto Cleanup;
 }
-LoadOption = (EFI_LOAD_OPTION *)Buffer;
+
+LoadOption  = (EFI_LOAD_OPTION *)Buffer;
+Description = (CHAR16 *)(&LoadOption->FilePathListLength + 1);
+DescriptionSize = StrSize (Description);
 
 if (LoadOption->FilePathListLength != 0) {
   DevPath = AllocateZeroPool(LoadOption->FilePathListLength);
   if (DevPath != NULL) {
-CopyMem(DevPath, Buffer+6+StrSize((CHAR16*)(Buffer+6)), 
LoadOption->FilePathListLength);
+CopyMem(DevPath, Buffer+6+DescriptionSize, 
LoadOption->FilePathListLength);
 DevPathString = ConvertDevicePathToText(DevPath, TRUE, FALSE);
   }
 }
@@ -1125,11 +1130,11 @@ BcfgDisplayDump(
   gShellBcfgHiiHandle,
   LoopVar,
   VariableName,
-  (CHAR16*)(Buffer+6),
+  Description,
   DevPathString,
-  (StrSize((CHAR16*)(Buffer+6)) + LoadOption->FilePathListLength + 6) <= 
BufferSize?L'N':L'Y');
+  (DescriptionSize + LoadOption->FilePathListLength + 6) <= 
BufferSize?L'N':L'Y');
 if (VerboseOutput) {
-  for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) + 
LoadOption->FilePathListLength + 6);LoopVar2FilePathListLength + 
6);LoopVar2https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 04/14] ShellPkg: BcfgDisplayDump(): accumulate errors

[Laszlo Ersek]

Don't exit the command immediately when a variable access fails; continue
processing after printing the error message. Let the final return status
reflect any encountered errors.

This patch is intended as a functional improvement.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 9 
+++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index f5ae7bc..36d04d4 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1051,12 +1051,15 @@ BcfgDisplayDump(
   UINTN   LoopVar2;
   CHAR16  *DevPathString;
   VOID*DevPath;
+  UINTN   Errors;
 
   if (OrderCount == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
gShellBcfgHiiHandle, L"bcfg");  
 return (SHELL_SUCCESS);
   }
 
+  Errors = 0;
+
   for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
 Buffer= NULL;
 BufferSize= 0;
@@ -1083,7 +1086,8 @@ BcfgDisplayDump(
 
 if (EFI_ERROR(Status) || Buffer == NULL) {
   ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_READ_FAIL), 
gShellBcfgHiiHandle, L"bcfg", VariableName);  
-  return (SHELL_INVALID_PARAMETER);
+  ++Errors;
+  goto Cleanup;
 }
 
 if ((*(UINT16*)(Buffer+4)) != 0) {
@@ -1120,6 +1124,7 @@ BcfgDisplayDump(
 L"\r\n");
 }
 
+Cleanup:
 if (Buffer != NULL) {
   FreePool(Buffer);
 }
@@ -1130,7 +1135,7 @@ BcfgDisplayDump(
   FreePool(DevPathString);
 }
   }
-  return (SHELL_SUCCESS);
+  return (Errors > 0) ? SHELL_INVALID_PARAMETER : SHELL_SUCCESS;
 }
 
 /**
-- 
1.8.3.1


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

[edk2] [PATCH v2 08/14] ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication

[Laszlo Ersek]

Copying and releasing each EFI_LOAD_OPTION.FilePathList under the name
DevPath is wasteful -- we only need FilePathList for a single conversion
to text. Do it directly from the EFI_LOAD_OPTION object.

This patch is not supposed to change observable behavior.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 13 
+++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index aac85d3..d109ca2 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1050,7 +1050,7 @@ BcfgDisplayDump(
   UINTN   LoopVar;
   UINTN   LoopVar2;
   CHAR16  *DevPathString;
-  VOID*DevPath;
+  VOID*FilePathList;
   UINTN   Errors;
   EFI_LOAD_OPTION *LoadOption;
   CHAR16  *Description;
@@ -1066,7 +1066,6 @@ BcfgDisplayDump(
   for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
 Buffer= NULL;
 BufferSize= 0;
-DevPath   = NULL;
 DevPathString = NULL;
 
 UnicodeSPrint(VariableName, sizeof(VariableName), L"%s%04x", Op, 
CurrentOrder[LoopVar]);
@@ -1116,11 +1115,8 @@ BcfgDisplayDump(
 DescriptionSize = StrSize (Description);
 
 if (LoadOption->FilePathListLength != 0) {
-  DevPath = AllocateZeroPool(LoadOption->FilePathListLength);
-  if (DevPath != NULL) {
-CopyMem(DevPath, Buffer+6+DescriptionSize, 
LoadOption->FilePathListLength);
-DevPathString = ConvertDevicePathToText(DevPath, TRUE, FALSE);
-  }
+  FilePathList = (UINT8 *)Description + DescriptionSize;
+  DevPathString = ConvertDevicePathToText(FilePathList, TRUE, FALSE);
 }
 ShellPrintHiiEx(
   -1,
@@ -1153,9 +1149,6 @@ Cleanup:
 if (Buffer != NULL) {
   FreePool(Buffer);
 }
-if (DevPath != NULL) {
-  FreePool(DevPath);
-}
 if (DevPathString != NULL) {
   FreePool(DevPathString);
 }
-- 
1.8.3.1


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

[edk2] [PATCH v2 01/14] ShellPkg: BcfgDisplayDump(): update whitespace & layout

[Laszlo Ersek]

This patch incurs no functional changes, it just modifies some whitespace,
so we can separate these non-functional changes from the functional
changes in the next patches.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 20 
++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 142504a..f6f4ab3 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1043,14 +1043,14 @@ BcfgDisplayDump(
   IN CONST BOOLEAN  VerboseOutput
   )
 {
-  EFI_STATUS  Status;
-  UINT8   *Buffer;
-  UINTN   BufferSize;
-  CHAR16  VariableName[12];
-  UINTN   LoopVar;
-  UINTN   LoopVar2;
-  CHAR16  *DevPathString;
-  VOID*DevPath;
+  EFI_STATUS  Status;
+  UINT8   *Buffer;
+  UINTN   BufferSize;
+  CHAR16  VariableName[12];
+  UINTN   LoopVar;
+  UINTN   LoopVar2;
+  CHAR16  *DevPathString;
+  VOID*DevPath;
 
   if (OrderCount == 0) {
 ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
gShellBcfgHiiHandle, L"bcfg");  
@@ -1058,8 +1058,8 @@ BcfgDisplayDump(
   }
 
   for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
-Buffer  = NULL;
-BufferSize  = 0;
+Buffer= NULL;
+BufferSize= 0;
 UnicodeSPrint(VariableName, sizeof(VariableName), L"%s%04x", Op, 
CurrentOrder[LoopVar]);
 
 Status = gRT->GetVariable(
-- 
1.8.3.1


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

[edk2] [PATCH v2 06/14] ShellPkg: BcfgDisplayDump(): address FilePathListLength by name

[Laszlo Ersek]

The Buffer variable points at the beginning of an EFI_LOAD_OPTION
structure. We might as well address the "FilePathListLength" member by
name, rather than with *(UINT16*)(Buffer+4).

This patch is not supposed to change behavior.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 11 
++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index 9955c9e..b08aac1 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1108,11 +1108,12 @@ BcfgDisplayDump(
   ++Errors;
   goto Cleanup;
 }
+LoadOption = (EFI_LOAD_OPTION *)Buffer;
 
-if ((*(UINT16*)(Buffer+4)) != 0) {
-  DevPath = AllocateZeroPool(*(UINT16*)(Buffer+4));
+if (LoadOption->FilePathListLength != 0) {
+  DevPath = AllocateZeroPool(LoadOption->FilePathListLength);
   if (DevPath != NULL) {
-CopyMem(DevPath, Buffer+6+StrSize((CHAR16*)(Buffer+6)), 
*(UINT16*)(Buffer+4));
+CopyMem(DevPath, Buffer+6+StrSize((CHAR16*)(Buffer+6)), 
LoadOption->FilePathListLength);
 DevPathString = ConvertDevicePathToText(DevPath, TRUE, FALSE);
   }
 }
@@ -1126,9 +1127,9 @@ BcfgDisplayDump(
   VariableName,
   (CHAR16*)(Buffer+6),
   DevPathString,
-  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) <= 
BufferSize?L'N':L'Y');
+  (StrSize((CHAR16*)(Buffer+6)) + LoadOption->FilePathListLength + 6) <= 
BufferSize?L'N':L'Y');
 if (VerboseOutput) {
-  for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 
6);LoopVar2FilePathListLength + 6);LoopVar2https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 00/14] ShellPkg: BCFG dump improvements

[Laszlo Ersek]

Version 2 of .

Changes relative to v1:

- Bump the minor version numbers in the INF files of
  UefiShellBcfgCommandLib, UefiShellCommandLib,
  UefiShellDebug1CommandsLib [Jaben].

  For the first of these, a final patch has been added.

  For the last two, because they are affected together by a single code
  movement patch, that patch has been extended with the INF changes.

- Replace "UefiShellBcfgCommandLib" with "BcfgDisplayDump()" in most of
  the subject lines, so that it's clear a given patch affects only the
  "bcfg dump" subcommand, not the entirety of "bcfg" [Laszlo]

- The above are also marked on each patch, as notes.

- No functional changes.

Public branch:
.

Cc: Jaben Carsey 
Cc: Ryan Harkin 

Thanks
Laszlo

Laszlo Ersek (14):
  ShellPkg: BcfgDisplayDump(): update whitespace & layout
  ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens
  ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]
  ShellPkg: BcfgDisplayDump(): accumulate errors
  ShellPkg: BcfgDisplayDump(): enforce minimum size for Boot and co.
  ShellPkg: BcfgDisplayDump(): address FilePathListLength by name
  ShellPkg: BcfgDisplayDump(): call Description[Size] by name
  ShellPkg: BcfgDisplayDump(): eliminate FilePathList duplication
  ShellPkg: BcfgDisplayDump(): calculate OptionalDataOffset explicitly
  ShellPkg: BcfgDisplayDump(): fix reporting of OptionalData
  ShellPkg: BcfgDisplayDump(): fix ShellPrintEx() call site
  ShellPkg: elevate DumpHex() from Debug1-internal to generic-internal
  ShellPkg: BcfgDisplayDump(): print optional data with DumpHex()
  ShellPkg: UefiShellBcfgCommandLib: bump VERSION_STRING

 ShellPkg/Include/Library/ShellCommandLib.h |  
16 +++
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 
103 
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf   |   
2 +-
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni   |   
4 +-
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c |  
69 +
 ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf   |   
2 +-
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c   |  
70 -
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h   |  
16 ---
 ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf |   
2 +-
 9 files changed, 150 insertions(+), 134 deletions(-)

-- 
1.8.3.1

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

[edk2] [PATCH v2 02/14] ShellPkg: UefiShellBcfgCommandLib: drop unused string tokens

[Laszlo Ersek]

STR_GEN_PROBLEM_VAL, STR_GEN_TOO_MANY, and STR_BCFG_LOCATION_RANGE are not
used in the C source code. Remove them to decrease clutter.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni | 3 ---
 1 file changed, 3 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
index b680a48..25bd138 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.uni
@@ -27,13 +27,11 @@
 
 #string STR_GEN_NO_MEM#language en-US "%H%s%N: Memory is not 
available.\r\n"
 #string STR_GEN_PROBLEM   #language en-US "%H%s%N: Unknown flag - 
'%H%s%N'\r\n"
-#string STR_GEN_PROBLEM_VAL   #language en-US "%H%s%N: Bad value - 
'%H%s%N' for flag - '%H%s%N'\r\n"
 #string STR_GEN_NO_VALUE  #language en-US "%H%s%N: Missing argument 
for flag - '%H%s%N'\r\n"
 #string STR_GEN_PARAM_INV #language en-US "%H%s%N: Invalid argument - 
'%H%s%N'\r\n"
 #string STR_GEN_NO_DRIVER_BOOT#language en-US "%H%s%N: Driver or Boot must 
be selected.\r\n"
 #string STR_GEN_BOOT_ONLY #language en-US "%H%s%N: Boot must be 
selected for hot key options.\r\n"
 #string STR_GEN_TOO_FEW   #language en-US "%H%s%N: Too few 
arguments.\r\n"
-#string STR_GEN_TOO_MANY  #language en-US "%H%s%N: Too many 
arguments.\r\n"
 #string STR_GEN_FILE_OPEN_FAIL#language en-US "%H%s%N: Cannot open file - 
'%H%s%N'\r\n"
 #string STR_GEN_FIND_FAIL #language en-US "%H%s%N: File not found - 
'%H%s%N'\r\n"
 #string STR_GEN_OUT_MEM   #language en-US "%H%s%N: Memory allocation 
was not successful.\r\n"
@@ -50,7 +48,6 @@
 #string STR_BCFG_NUMB_RANGE   #language en-US "%H%s%N: Numbers must be 
under %d.\r\n"
 #string STR_BCFG_NONE #language en-US "No options found.\r\n"
 
-#string STR_BCFG_LOCATION_RANGE   #language en-US "target location must be <= 
%d.\r\n"
 #string STR_BCFG_LOAD_OPTIONS #language en-US "Option: %B%02x%N. Variable: 
%B%-11s%N\r\n"
   "  Desc- %s\r\n"
   "  DevPath - %s\r\n"
-- 
1.8.3.1


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

[edk2] [PATCH v2 03/14] ShellPkg: BcfgDisplayDump(): hoist NULL-init of DevPath[String]

[Laszlo Ersek]

It will help with error handling if we move these initializations near the
top of the loop body.

This patch is not supposed to change behavior.

Cc: Jaben Carsey 
Cc: Ryan Harkin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- clarify in the subject that the patch affects only the "bcfg dump"
  subcommand, not all of "bcfg"

 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 10 
--
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
index f6f4ab3..f5ae7bc 100644
--- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
+++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
@@ -1060,6 +1060,9 @@ BcfgDisplayDump(
   for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
 Buffer= NULL;
 BufferSize= 0;
+DevPath   = NULL;
+DevPathString = NULL;
+
 UnicodeSPrint(VariableName, sizeof(VariableName), L"%s%04x", Op, 
CurrentOrder[LoopVar]);
 
 Status = gRT->GetVariable(
@@ -1085,15 +1088,10 @@ BcfgDisplayDump(
 
 if ((*(UINT16*)(Buffer+4)) != 0) {
   DevPath = AllocateZeroPool(*(UINT16*)(Buffer+4));
-  if (DevPath == NULL) {
-DevPathString = NULL;
-  } else {
+  if (DevPath != NULL) {
 CopyMem(DevPath, Buffer+6+StrSize((CHAR16*)(Buffer+6)), 
*(UINT16*)(Buffer+4));
 DevPathString = ConvertDevicePathToText(DevPath, TRUE, FALSE);
   }
-} else {
-  DevPath   = NULL;
-  DevPathString = NULL;
 }
 ShellPrintHiiEx(
   -1,
-- 
1.8.3.1


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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 16:05, Laszlo Ersek  wrote:
> On 01/21/16 13:57, Ryan Harkin wrote:
>> On 21 January 2016 at 11:46, Laszlo Ersek  wrote:
>>> adding Roy
>>>
>>> On 01/21/16 10:51, Ryan Harkin wrote:
 Hi Ray,

 On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
> It makes sense that F2 to F9 behaves like ESC because
> the Serial device doesn't have enough buffer (FIFO)
> to hold all the escape sequence keys.
>
> Because the certain platform cannot handle escape
> sequence keys like F2-F9 or cursor movement, I
> think it's reasonable to use a bigger FIFO other 1
> in that certain platform.
>

 I should have mentioned that I'm using Laszlo's recent SerialDxe patch
 series to fix the cursor keys.  That should leave me with enough FIFO
 to handle the function keys.
>>>
>>> I think that's a different issue. The file
>>>
>>>   MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>>>
>>> starts with a table, in a comment, that explains the escape sequences
>>> that TerminalDxe expects and decodes for the various function keys,
>>> dependent on the terminal type selected.
>>>
>>> In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
>>> Apparently, for me F9 generates
>>>
>>>   ESC [ 20~
>>>
>>> which doesn't match any column (= any terminal type known to
>>> TerminalDxe) in the F9 row of the table.
>>>
>>> The above escape sequence seems to come from my terminfo database; at
>>> least when I run "infocmp" from the same xterm, the output contains
>>>
>>>   kf9=\E[20~
>>>
>>> So, when I use the QEMU serial console, F9 doesn't work for me either.
>>> It works if I use the graphical console and the emulated USB or PS/2
>>> keyboard.
>>>
>>> ... Hm, maybe the recently added TTYTERMTYPE could handle these escape
>>> sequences:
>>>
>>> commit 014f93acab63e8e72f2113d8090c550e05c16c93
>>> Author: Roy Franz 
>>> Date:   Thu Jul 9 06:24:20 2015 +
>>>
>>> Accept VT220 DEL and function keys for TTY terminal type
>>>
>>> In the Intel BDS, you can configure your terminal type, in
>>>
>>> Boot Maintenance Manager
>>>   Console Options
>>> COM Attribute Setup Page
>>>   
>>
>> This is where I stumble... with or without your patch, this list is
>> empty on FVP.
>>
>> Going here:
>>
>>  Boot Maintenance Manager
>>Console Options
>>  Console Input Device Select
>>
>> ... only gives me one option:
>>
>>  VenHw(D3987D4B-971A-435F-8 [X]
>>CAF-4967EB627241)/Uart(384
>>00,8,N,1)/VenPcAnsi()
>>
>> ... and it gets that from my .dsc file:
>>
>> Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc:181:
>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"
>>
>> 38400?  Ouch.
>
> (1) Actually, it's quite good that you located this in your DSC file. It
> is used in
>
>   ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
>
> I think if you replace
>
>   VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()
>
> in both
>
>   PcdDefaultConOutPaths
>   PcdDefaultConInPaths
>
> with
>
>   
> VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)
>
> IOW, if you bump the baud rate to 115200, plus replace VenPcAnsi() with
> VenMsg(...), then it should work.
>

OK, you're on a roll with this stuff!  After applying that change, the
F9 key works.  Thanks again!

And now that you've shown me how to default to a sensible terminal
type, my backspace key also works.  It's a miracle!



> (2) The first GUID (in VenHw()) is the FILE_GUID of SerialDxe.
>
> The second GUID (in VenMsg()) is from
> "MdeModulePkg/Include/Guid/TtyTerm.h"; it identifies the TtyTerm type.
>
> Normally there should be a more textual-looking shorthand for that
> VenMsg(), like VenPcAnsi(). However, because TtyTerm is not standardized
> in the UEFI spec, the shorthand formatting could not be added to
> MdePkg/Library/UefiDevicePathLib -- packages under MdePkg follow
> standards strictly.
>
> (3) We more or less patched the same for ArmVirtQemu (please refer to
> git commit a51c1699), but differently. That difference is due to the
> fact that ArmVirtQemu uses its own, independent PlatformBdsLib instance
> ("ArmVirtPkg/Library/PlatformIntelBdsLib"). Hence a51c1699 isn't
> portable to "ArmPlatformPkg/Library/PlatformIntelBdsLib", which is used
> by FVP. But the method described in (1) should work for you.
>
> Thanks
> Laszlo
>
>>
>>
>>> Set COM Terminal Type
>>>
>>> But, there are two problems with that:
>>> - it doesn't seem to know about TTYTERMTYPE
>>> - if you change the setting, you can only commit it with F10,
>>>   apparently, which doesn't work to begin with.
>>>   ... Wait, if you keep exiting the dialogs (not discarding the
>>>   changes!), ultimately it will ask you about saving changes.
>>>
>>> If you apply the attached patch, you should be able to select VT_TTY in

Re: [edk2] [PATCH] [ShellPkg] fix operator

[Carsey, Jaben]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, January 21, 2016 8:13 AM
> To: Carsey, Jaben ; Ryan Harkin
> 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [PATCH] [ShellPkg] fix operator
> Importance: High
> 
> On 01/21/16 16:50, Carsey, Jaben wrote:
> >
> >
> >> -Original Message-
> >> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> >> Sent: Thursday, January 21, 2016 12:47 AM
> >> To: Laszlo Ersek 
> >> Cc: Carsey, Jaben ; edk2-devel@lists.01.org
>  >> de...@ml01.01.org>
> >> Subject: Re: [PATCH] [ShellPkg] fix operator
> >> Importance: High
> >>
> >> On 21 January 2016 at 01:01, Laszlo Ersek  wrote:
> >>> On 01/20/16 23:18, Ryan Harkin wrote:
> 
>  On 20 Jan 2016 21:23, "Carsey, Jaben"   > wrote:
> >
> > I will wait.
> >
> > -Jaben
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com
> >> ]
> >> Sent: Wednesday, January 20, 2016 1:21 PM
> >> To: Carsey, Jaben   >; edk2-de...@ml01.01.org
>  
> >> Cc: ryan.har...@linaro.org 
> >> Subject: Re: [PATCH] [ShellPkg] fix operator
> >> Importance: High
> >>
> >> On 01/20/16 22:09, jaben carsey wrote:
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: jaben carsey   >
> >>> ---
> >>>
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> |
> >> 4
> >> ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git
> >>
> >> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>
> >> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> index 142504a..77e2374 100644
> >>> ---
> >>
> >> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> +++
> >>
> >> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> @@ -2,7 +2,7 @@
> >>>Main file for BCFG command.
> >>>
> >>>(C) Copyright 2014-2015 Hewlett-Packard Development Company,
> >> L.P.
> >>> -  Copyright (c) 2010 - 2015, Intel Corporation. All rights
>  reserved.
> >>> +  Copyright (c) 2010 - 2016, 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
> >>> @@ -1105,7 +1105,7 @@ BcfgDisplayDump(
> >>>VariableName,
> >>>(CHAR16*)(Buffer+6),
> >>>DevPathString,
> >>> -  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) <=
> >> BufferSize?L'N':L'Y');
> >>> +  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) >=
> >> BufferSize?L'N':L'Y');
> >>>  if (VerboseOutput) {
> >>>for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) +
>  *(UINT16*)(Buffer+4)
> >> + 6);LoopVar2 >>>  ShellPrintEx(
> >>>
> >>
> >> This patch is good, but I'd like to send a bit more comprehensive
> >> cleanup soon, if you are okay with that.
> >>
> 
>  Indeed, so far we've only discussed the bug when dumping the optional
>  data, although it looks like Laszlo has worked that out pretty well.
> 
>  But we haven't discussed the problems I'm having with setting the
>  optional data with the same command.  I'll look tomorrow.
> >>>
> >>> As Jaben indicated meanwhile, beside the genuine issues with the BCFG
> >>> implementation (patch series coming up soon), your command line was
> >>> incorrect. According to the UEFI Shell specification, the -opt flag
> >>> takes the following form:
> >>>
>  [-opt # [[filename]|[”data”]]
> >>>
> >>> That is, the first argument after -opt identifies the Boot or
> >>> Driver option numerically whose optional data you wish to modify.
> >>>
> >>> This might be somewhat awkward when you *add* the option in question
> in
> >>> the exact same BCFG command, but that's how it is. I think you can also
> >>> modify the optional data for an existent Boot or Driver option,
> >>> with just -opt, I think. In fact, I'm not sure if -opt is supposed to
> >>> work *together* with any of the "add" commands!
> >>>
> >>> Then, the question becomes if you want to load the optional data from a
> >>> file, or specify it directly on the command line. For the latter case,
> >>> the quotes are mandatory, and the argument will be encoded as an
> >>> L'\0'-terminated UCS-2 (i.e., CHAR16) string.
> >>>
> >>> (If you look at the BCFG synopsys in the UEFI shell spec,

Re: [edk2] [PATCH] [ShellPkg] fix operator

[Laszlo Ersek]

On 01/21/16 16:50, Carsey, Jaben wrote:
> 
> 
>> -Original Message-
>> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
>> Sent: Thursday, January 21, 2016 12:47 AM
>> To: Laszlo Ersek 
>> Cc: Carsey, Jaben ; edk2-devel@lists.01.org > de...@ml01.01.org>
>> Subject: Re: [PATCH] [ShellPkg] fix operator
>> Importance: High
>>
>> On 21 January 2016 at 01:01, Laszlo Ersek  wrote:
>>> On 01/20/16 23:18, Ryan Harkin wrote:

 On 20 Jan 2016 21:23, "Carsey, Jaben" >>> > wrote:
>
> I will wait.
>
> -Jaben
>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com
>> ]
>> Sent: Wednesday, January 20, 2016 1:21 PM
>> To: Carsey, Jaben >>> >; edk2-de...@ml01.01.org
 
>> Cc: ryan.har...@linaro.org 
>> Subject: Re: [PATCH] [ShellPkg] fix operator
>> Importance: High
>>
>> On 01/20/16 22:09, jaben carsey wrote:
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: jaben carsey >>> >
>>> ---
>>>
 ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c |
>> 4
>> ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git
>>
>> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>
>> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> index 142504a..77e2374 100644
>>> ---
>>
>> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> +++
>>
>> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> @@ -2,7 +2,7 @@
>>>Main file for BCFG command.
>>>
>>>(C) Copyright 2014-2015 Hewlett-Packard Development Company,
>> L.P.
>>> -  Copyright (c) 2010 - 2015, Intel Corporation. All rights
 reserved.
>>> +  Copyright (c) 2010 - 2016, 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
>>> @@ -1105,7 +1105,7 @@ BcfgDisplayDump(
>>>VariableName,
>>>(CHAR16*)(Buffer+6),
>>>DevPathString,
>>> -  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) <=
>> BufferSize?L'N':L'Y');
>>> +  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) >=
>> BufferSize?L'N':L'Y');
>>>  if (VerboseOutput) {
>>>for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) +
 *(UINT16*)(Buffer+4)
>> + 6);LoopVar2>>  ShellPrintEx(
>>>
>>
>> This patch is good, but I'd like to send a bit more comprehensive
>> cleanup soon, if you are okay with that.
>>

 Indeed, so far we've only discussed the bug when dumping the optional
 data, although it looks like Laszlo has worked that out pretty well.

 But we haven't discussed the problems I'm having with setting the
 optional data with the same command.  I'll look tomorrow.
>>>
>>> As Jaben indicated meanwhile, beside the genuine issues with the BCFG
>>> implementation (patch series coming up soon), your command line was
>>> incorrect. According to the UEFI Shell specification, the -opt flag
>>> takes the following form:
>>>
 [-opt # [[filename]|[”data”]]
>>>
>>> That is, the first argument after -opt identifies the Boot or
>>> Driver option numerically whose optional data you wish to modify.
>>>
>>> This might be somewhat awkward when you *add* the option in question in
>>> the exact same BCFG command, but that's how it is. I think you can also
>>> modify the optional data for an existent Boot or Driver option,
>>> with just -opt, I think. In fact, I'm not sure if -opt is supposed to
>>> work *together* with any of the "add" commands!
>>>
>>> Then, the question becomes if you want to load the optional data from a
>>> file, or specify it directly on the command line. For the latter case,
>>> the quotes are mandatory, and the argument will be encoded as an
>>> L'\0'-terminated UCS-2 (i.e., CHAR16) string.
>>>
>>> (If you look at the BCFG synopsys in the UEFI shell spec, you can see
>>> that the quotes around -opt's "data" argument are typeset differently
>>> from the quotes around the various "desc" arguments!)
>>>
>>> Now, the trick is that ye olde ASCII quotation marks, expected by the
>>> BCFG command for the second form above, coincide with the UEFI Shell's
>>> *general* quoting. See "3.4.3 Quoting" in the UEFI Shell spec:
>>>
 To include a double-quotation mark inside of a quoted string, use ^".
>>>
>>> For testing, I listed the drivers with the "drivers" command. In the
>>> output, I randomly pick

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 13:57, Ryan Harkin wrote:
> On 21 January 2016 at 11:46, Laszlo Ersek  wrote:
>> adding Roy
>>
>> On 01/21/16 10:51, Ryan Harkin wrote:
>>> Hi Ray,
>>>
>>> On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
 It makes sense that F2 to F9 behaves like ESC because
 the Serial device doesn't have enough buffer (FIFO)
 to hold all the escape sequence keys.

 Because the certain platform cannot handle escape
 sequence keys like F2-F9 or cursor movement, I
 think it's reasonable to use a bigger FIFO other 1
 in that certain platform.

>>>
>>> I should have mentioned that I'm using Laszlo's recent SerialDxe patch
>>> series to fix the cursor keys.  That should leave me with enough FIFO
>>> to handle the function keys.
>>
>> I think that's a different issue. The file
>>
>>   MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>>
>> starts with a table, in a comment, that explains the escape sequences
>> that TerminalDxe expects and decodes for the various function keys,
>> dependent on the terminal type selected.
>>
>> In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
>> Apparently, for me F9 generates
>>
>>   ESC [ 20~
>>
>> which doesn't match any column (= any terminal type known to
>> TerminalDxe) in the F9 row of the table.
>>
>> The above escape sequence seems to come from my terminfo database; at
>> least when I run "infocmp" from the same xterm, the output contains
>>
>>   kf9=\E[20~
>>
>> So, when I use the QEMU serial console, F9 doesn't work for me either.
>> It works if I use the graphical console and the emulated USB or PS/2
>> keyboard.
>>
>> ... Hm, maybe the recently added TTYTERMTYPE could handle these escape
>> sequences:
>>
>> commit 014f93acab63e8e72f2113d8090c550e05c16c93
>> Author: Roy Franz 
>> Date:   Thu Jul 9 06:24:20 2015 +
>>
>> Accept VT220 DEL and function keys for TTY terminal type
>>
>> In the Intel BDS, you can configure your terminal type, in
>>
>> Boot Maintenance Manager
>>   Console Options
>> COM Attribute Setup Page
>>   
> 
> This is where I stumble... with or without your patch, this list is
> empty on FVP.
> 
> Going here:
> 
>  Boot Maintenance Manager
>Console Options
>  Console Input Device Select
> 
> ... only gives me one option:
> 
>  VenHw(D3987D4B-971A-435F-8 [X]
>CAF-4967EB627241)/Uart(384
>00,8,N,1)/VenPcAnsi()
> 
> ... and it gets that from my .dsc file:
> 
> Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc:181:
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"
> 
> 38400?  Ouch.

(1) Actually, it's quite good that you located this in your DSC file. It
is used in

  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c

I think if you replace

  VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi()

in both

  PcdDefaultConOutPaths
  PcdDefaultConInPaths

with

  
VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)

IOW, if you bump the baud rate to 115200, plus replace VenPcAnsi() with
VenMsg(...), then it should work.

(2) The first GUID (in VenHw()) is the FILE_GUID of SerialDxe.

The second GUID (in VenMsg()) is from
"MdeModulePkg/Include/Guid/TtyTerm.h"; it identifies the TtyTerm type.

Normally there should be a more textual-looking shorthand for that
VenMsg(), like VenPcAnsi(). However, because TtyTerm is not standardized
in the UEFI spec, the shorthand formatting could not be added to
MdePkg/Library/UefiDevicePathLib -- packages under MdePkg follow
standards strictly.

(3) We more or less patched the same for ArmVirtQemu (please refer to
git commit a51c1699), but differently. That difference is due to the
fact that ArmVirtQemu uses its own, independent PlatformBdsLib instance
("ArmVirtPkg/Library/PlatformIntelBdsLib"). Hence a51c1699 isn't
portable to "ArmPlatformPkg/Library/PlatformIntelBdsLib", which is used
by FVP. But the method described in (1) should work for you.

Thanks
Laszlo

> 
> 
>> Set COM Terminal Type
>>
>> But, there are two problems with that:
>> - it doesn't seem to know about TTYTERMTYPE
>> - if you change the setting, you can only commit it with F10,
>>   apparently, which doesn't work to begin with.
>>   ... Wait, if you keep exiting the dialogs (not discarding the
>>   changes!), ultimately it will ask you about saving changes.
>>
>> If you apply the attached patch, you should be able to select VT_TTY in
>> the above menu option, in the Intel BDS. After that (possibly after a
>> reboot), F9 should also start to work. Can you test this?
>>
> 
> I think your patch is good, though.  I despair that you had to change
> the code from 4 to 5 when you updated the data.  I remember discussing
> this with Roy when he was making his TTY changes elsewhere too.  I
> makes me weak...
> 
>> Thanks
>> Laszlo
>>
>>>
>>>
 Regards,
 Ray
>>>

Re: [edk2] [PATCH] [ShellPkg] fix operator

[Carsey, Jaben]

> -Original Message-
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Thursday, January 21, 2016 12:47 AM
> To: Laszlo Ersek 
> Cc: Carsey, Jaben ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [PATCH] [ShellPkg] fix operator
> Importance: High
> 
> On 21 January 2016 at 01:01, Laszlo Ersek  wrote:
> > On 01/20/16 23:18, Ryan Harkin wrote:
> >>
> >> On 20 Jan 2016 21:23, "Carsey, Jaben"  >> > wrote:
> >>>
> >>> I will wait.
> >>>
> >>> -Jaben
> >>>
> >>> > -Original Message-
> >>> > From: Laszlo Ersek [mailto:ler...@redhat.com
> ]
> >>> > Sent: Wednesday, January 20, 2016 1:21 PM
> >>> > To: Carsey, Jaben  >> >; edk2-de...@ml01.01.org
> >> 
> >>> > Cc: ryan.har...@linaro.org 
> >>> > Subject: Re: [PATCH] [ShellPkg] fix operator
> >>> > Importance: High
> >>> >
> >>> > On 01/20/16 22:09, jaben carsey wrote:
> >>> > > Contributed-under: TianoCore Contribution Agreement 1.0
> >>> > > Signed-off-by: jaben carsey  >> >
> >>> > > ---
> >>> > >
> >> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c |
> 4
> >>> > ++--
> >>> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> >>> > >
> >>> > > diff --git
> >>> >
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> >
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> > > index 142504a..77e2374 100644
> >>> > > ---
> >>> >
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> > > +++
> >>> >
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> >>> > > @@ -2,7 +2,7 @@
> >>> > >Main file for BCFG command.
> >>> > >
> >>> > >(C) Copyright 2014-2015 Hewlett-Packard Development Company,
> >>> > L.P.
> >>> > > -  Copyright (c) 2010 - 2015, Intel Corporation. All rights
> >> reserved.
> >>> > > +  Copyright (c) 2010 - 2016, 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
> >>> > > @@ -1105,7 +1105,7 @@ BcfgDisplayDump(
> >>> > >VariableName,
> >>> > >(CHAR16*)(Buffer+6),
> >>> > >DevPathString,
> >>> > > -  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) <=
> >>> > BufferSize?L'N':L'Y');
> >>> > > +  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) >=
> >>> > BufferSize?L'N':L'Y');
> >>> > >  if (VerboseOutput) {
> >>> > >for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) +
> >> *(UINT16*)(Buffer+4)
> >>> > + 6);LoopVar2 >>> > >  ShellPrintEx(
> >>> > >
> >>> >
> >>> > This patch is good, but I'd like to send a bit more comprehensive
> >>> > cleanup soon, if you are okay with that.
> >>> >
> >>
> >> Indeed, so far we've only discussed the bug when dumping the optional
> >> data, although it looks like Laszlo has worked that out pretty well.
> >>
> >> But we haven't discussed the problems I'm having with setting the
> >> optional data with the same command.  I'll look tomorrow.
> >
> > As Jaben indicated meanwhile, beside the genuine issues with the BCFG
> > implementation (patch series coming up soon), your command line was
> > incorrect. According to the UEFI Shell specification, the -opt flag
> > takes the following form:
> >
> >> [-opt # [[filename]|[”data”]]
> >
> > That is, the first argument after -opt identifies the Boot or
> > Driver option numerically whose optional data you wish to modify.
> >
> > This might be somewhat awkward when you *add* the option in question in
> > the exact same BCFG command, but that's how it is. I think you can also
> > modify the optional data for an existent Boot or Driver option,
> > with just -opt, I think. In fact, I'm not sure if -opt is supposed to
> > work *together* with any of the "add" commands!
> >
> > Then, the question becomes if you want to load the optional data from a
> > file, or specify it directly on the command line. For the latter case,
> > the quotes are mandatory, and the argument will be encoded as an
> > L'\0'-terminated UCS-2 (i.e., CHAR16) string.
> >
> > (If you look at the BCFG synopsys in the UEFI shell spec, you can see
> > that the quotes around -opt's "data" argument are typeset differently
> > from the quotes around the various "desc" arguments!)
> >
> > Now, the trick is that ye olde ASCII quotation marks, expected by the
> > BCFG command for the second form above, coincide with the UEFI Shell's
> > *general* quoting. See "3.4.3 Quoting" in the UEFI Shell spec:
> >
> >> To include a double-quotation mark inside of a quoted string, use ^".
> >
> > For testing, I listed the drivers with the "drivers" command. In the
> > 

Re: [edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address

[Michael Brown]

On 21/01/16 10:13, Jim Hung (洪銘駿) wrote:

There is one network issue in customer datacenter, the 
“ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source 
network device if multi LANs on the system. And, this cause the PXE boot 
failure at customer datacenter environment.

On our system, it has two network devices, one is Intel NIC, the other is 
Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to 
generate the DULD-LLT. However at customer Data Center, they do NOT accept 
this. Each interface needs to generate their DUID-LL(T) based on their own LL. 
This means that they must use their own MAC address. Both interface will have 
different DUIL-LL(T), which is technically against the RFC here.

Can you please help to check how networkstack driver could be supported on this 
requirement?


We have encountered exactly the same problem in iPXE.  We decided to 
adopt the solution proposed by RFC6355: we use DUID-UUID rather than any 
of the DUID-LL(T) variants.  This is the only sensible way in which we 
can hope to make the same choice of DUID as the loaded operating system.


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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 11:46, Laszlo Ersek  wrote:
> adding Roy
>
> On 01/21/16 10:51, Ryan Harkin wrote:
>> Hi Ray,
>>
>> On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
>>> It makes sense that F2 to F9 behaves like ESC because
>>> the Serial device doesn't have enough buffer (FIFO)
>>> to hold all the escape sequence keys.
>>>
>>> Because the certain platform cannot handle escape
>>> sequence keys like F2-F9 or cursor movement, I
>>> think it's reasonable to use a bigger FIFO other 1
>>> in that certain platform.
>>>
>>
>> I should have mentioned that I'm using Laszlo's recent SerialDxe patch
>> series to fix the cursor keys.  That should leave me with enough FIFO
>> to handle the function keys.
>
> I think that's a different issue. The file
>
>   MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h
>
> starts with a table, in a comment, that explains the escape sequences
> that TerminalDxe expects and decodes for the various function keys,
> dependent on the terminal type selected.
>
> In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
> Apparently, for me F9 generates
>
>   ESC [ 20~
>
> which doesn't match any column (= any terminal type known to
> TerminalDxe) in the F9 row of the table.
>
> The above escape sequence seems to come from my terminfo database; at
> least when I run "infocmp" from the same xterm, the output contains
>
>   kf9=\E[20~
>
> So, when I use the QEMU serial console, F9 doesn't work for me either.
> It works if I use the graphical console and the emulated USB or PS/2
> keyboard.
>
> ... Hm, maybe the recently added TTYTERMTYPE could handle these escape
> sequences:
>
> commit 014f93acab63e8e72f2113d8090c550e05c16c93
> Author: Roy Franz 
> Date:   Thu Jul 9 06:24:20 2015 +
>
> Accept VT220 DEL and function keys for TTY terminal type
>
> In the Intel BDS, you can configure your terminal type, in
>
> Boot Maintenance Manager
>   Console Options
> COM Attribute Setup Page
>   

This is where I stumble... with or without your patch, this list is
empty on FVP.

Going here:

 Boot Maintenance Manager
   Console Options
 Console Input Device Select

... only gives me one option:

 VenHw(D3987D4B-971A-435F-8 [X]
   CAF-4967EB627241)/Uart(384
   00,8,N,1)/VenPcAnsi()

... and it gets that from my .dsc file:

Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc:181:
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)"

38400?  Ouch.


> Set COM Terminal Type
>
> But, there are two problems with that:
> - it doesn't seem to know about TTYTERMTYPE
> - if you change the setting, you can only commit it with F10,
>   apparently, which doesn't work to begin with.
>   ... Wait, if you keep exiting the dialogs (not discarding the
>   changes!), ultimately it will ask you about saving changes.
>
> If you apply the attached patch, you should be able to select VT_TTY in
> the above menu option, in the Intel BDS. After that (possibly after a
> reboot), F9 should also start to work. Can you test this?
>

I think your patch is good, though.  I despair that you had to change
the code from 4 to 5 when you updated the data.  I remember discussing
this with Roy when he was making his TTY changes elsewhere too.  I
makes me weak...

> Thanks
> Laszlo
>
>>
>>
>>> Regards,
>>> Ray
>>>
>>>
>>> -Original Message-
>>> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
>>> Sent: Thursday, January 21, 2016 4:54 PM
>>> To: Laszlo Ersek 
>>> Cc: Ni, Ruiyu ; Leif Lindholm 
>>> ; edk2-de...@ml01.01.org; Zeng, Star 
>>> ; Ard Biesheuvel 
>>> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the 
>>> UART's default receive FIFO depth
>>>
>>> On 21 January 2016 at 08:42, Laszlo Ersek  wrote:
 On 01/21/16 09:20, Ryan Harkin wrote:
> On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
>> On 01/21/16 06:42, Ni, Ruiyu wrote:
>>> Laszlo,
>>> When I re-think about the cursor issue, I am curious whether the
>>> function keys (F1/F2/...) work well in your platform.
>>> I guess any keys that will translate to multiple bytes don't work.
>>> Correct?
>>
>> I never experienced this issue personally. Based on the original report,
>> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
>> So I hope the question about function keys can be answered by one of the
>> CC'd guys.
>>
>
> I don't know how to test F1/F2, etc. as I don't of any software that
> consumes them.  I'm currently using Intel BDS and that only appears to
> use cursor key, enter and regular ASCII printable characters.

 No, the Intel BDS is actually a good utility to test this. Go into one
 of the setup dialogs, and change something, then press F9 or F10 to save
 or throw away changes. (Writing from memory, so I'm not sure which does
 which, but you can definitely use those function keys 

Re: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a bug?

[王晓峰]

HI  Star,
   I tried to remove SmbusLib.h from InternalS3SaveState.h., there will be 
build errors.Smbus related logic exists in S3SaveState.c








At 2016-01-21 18:09:41, "Zeng, Star"  wrote:
>It is just to include header file, I believe it could be removed from 
>InternalS3SaveState.h.
>What libraries a driver will link is not determined by source files, but inf 
>file ( S3SaveStateDxe.inf)?
>
>Why does S3SaveStateDxe.inf finally link SmbusLib, it is because 
>S3SaveStateDxe.inf link S3BootScriptLib(I guess you are using 
>DxeS3BootScriptLib.inf in MdeModulePkg) and S3BootScriptLib link SmbusLib.
>
>You may could check the PCD usage in your SmbusLib instance.
>
>Thanks,
>Star
>From: 王晓峰 [mailto:winggundu...@163.com] 
>Sent: Thursday, January 21, 2016 5:40 PM
>To: edk2-de...@ml01.01.org
>Cc: Zeng, Star
>Subject: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it 
>a bug?
>
>Hi All,
>I meet a issue that there is a get PCD assert for  S3SaveStateDxe.inf. It 
> is strange that I seached all the library and their child library in  
> S3SaveStateDxe.inf , no PCD found related to this issue
>
>[LibraryClasses]
>  UefiBootServicesTableLib
>  MemoryAllocationLib
>  UefiDriverEntryPoint
>  BaseMemoryLib
>  BaseLib
>  S3BootScriptLib
>
>   Then I found in InternalS3SaveState.h, It directly include SmbusLib 
>   #include 
>
>   I am not sure whether it is a bug that SmbusLib should also be in 
> S3SaveStateDxe.inf . But after I change SmbusLib instance to Null the PCD 
> issue is solved. It seems build tool for PCD cannot caclulate the PCD 
> introduced by such way.
>
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

adding Roy

On 01/21/16 10:51, Ryan Harkin wrote:
> Hi Ray,
> 
> On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
>> It makes sense that F2 to F9 behaves like ESC because
>> the Serial device doesn't have enough buffer (FIFO)
>> to hold all the escape sequence keys.
>>
>> Because the certain platform cannot handle escape
>> sequence keys like F2-F9 or cursor movement, I
>> think it's reasonable to use a bigger FIFO other 1
>> in that certain platform.
>>
> 
> I should have mentioned that I'm using Laszlo's recent SerialDxe patch
> series to fix the cursor keys.  That should leave me with enough FIFO
> to handle the function keys.

I think that's a different issue. The file

  MdeModulePkg/Universal/Console/TerminalDxe/Terminal.h

starts with a table, in a comment, that explains the escape sequences
that TerminalDxe expects and decodes for the various function keys,
dependent on the terminal type selected.

In my xterm (on GNU/Linux), I entered "cat", and then pressed F9.
Apparently, for me F9 generates

  ESC [ 20~

which doesn't match any column (= any terminal type known to
TerminalDxe) in the F9 row of the table.

The above escape sequence seems to come from my terminfo database; at
least when I run "infocmp" from the same xterm, the output contains

  kf9=\E[20~

So, when I use the QEMU serial console, F9 doesn't work for me either.
It works if I use the graphical console and the emulated USB or PS/2
keyboard.

... Hm, maybe the recently added TTYTERMTYPE could handle these escape
sequences:

commit 014f93acab63e8e72f2113d8090c550e05c16c93
Author: Roy Franz 
Date:   Thu Jul 9 06:24:20 2015 +

Accept VT220 DEL and function keys for TTY terminal type

In the Intel BDS, you can configure your terminal type, in

Boot Maintenance Manager
  Console Options
COM Attribute Setup Page
  
Set COM Terminal Type

But, there are two problems with that:
- it doesn't seem to know about TTYTERMTYPE
- if you change the setting, you can only commit it with F10,
  apparently, which doesn't work to begin with.
  ... Wait, if you keep exiting the dialogs (not discarding the
  changes!), ultimately it will ask you about saving changes.

If you apply the attached patch, you should be able to select VT_TTY in
the above menu option, in the Intel BDS. After that (possibly after a
reboot), F9 should also start to work. Can you test this?

Thanks
Laszlo

> 
> 
>> Regards,
>> Ray
>>
>>
>> -Original Message-
>> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
>> Sent: Thursday, January 21, 2016 4:54 PM
>> To: Laszlo Ersek 
>> Cc: Ni, Ruiyu ; Leif Lindholm 
>> ; edk2-de...@ml01.01.org; Zeng, Star 
>> ; Ard Biesheuvel 
>> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's 
>> default receive FIFO depth
>>
>> On 21 January 2016 at 08:42, Laszlo Ersek  wrote:
>>> On 01/21/16 09:20, Ryan Harkin wrote:
 On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
> On 01/21/16 06:42, Ni, Ruiyu wrote:
>> Laszlo,
>> When I re-think about the cursor issue, I am curious whether the
>> function keys (F1/F2/...) work well in your platform.
>> I guess any keys that will translate to multiple bytes don't work.
>> Correct?
>
> I never experienced this issue personally. Based on the original report,
> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
> So I hope the question about function keys can be answered by one of the
> CC'd guys.
>

 I don't know how to test F1/F2, etc. as I don't of any software that
 consumes them.  I'm currently using Intel BDS and that only appears to
 use cursor key, enter and regular ASCII printable characters.
>>>
>>> No, the Intel BDS is actually a good utility to test this. Go into one
>>> of the setup dialogs, and change something, then press F9 or F10 to save
>>> or throw away changes. (Writing from memory, so I'm not sure which does
>>> which, but you can definitely use those function keys on at least some
>>> of the forms.)
>>>
>>
>> Ha! Foiled by my terminal - F10 opens the menu bar in the terminal
>> app.  I'm not sure F9 "Reset to Defaults".  I was adding a new boot
>> option, and on the "Modify Boot Option Description" page, ESC and F2
>> to F9 all do the same thing: drop me back to the previous page where I
>> can choose the file I want to boot.  The "Input the description" field
>> isn't reset and retains the text I've typed into it.
>>
>>
>>> Thanks
>>> Laszlo
>>>


>> But I never heard of such issue in X86 platforms so far even the
>> IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
>> as 1.
>> Is it because your platform uses a very higher baud rate?
>> Or the time handler (supposed to be triggered every 0.02s) isn't
>> triggered every 0.02s but a longer time?
>
> No clue, sorry. All we determined was that the FIFO depth of 1 caused
> the PL011Uart library to disable queueing on the device completely.
> Appar

[edk2] Help: NetworkStack requirement to generate DUID-LL(T) per own MAC address

[洪銘駿]

Hi Sir,

Here is the BIOS engineer from Quanta Computer Inc., there is a requirement 
from our customer regarding networkstack driver, can you please help on this?

Issue:
There is one network issue in customer datacenter, the 
“ClientID/DUID/Link-Layer Address” is not bundled with the MAC from source 
network device if multi LANs on the system. And, this cause the PXE boot 
failure at customer datacenter environment.

On our system, it has two network devices, one is Intel NIC, the other is 
Mellanox NIC, from RFC mentioned, either one MAC of both NICs can be used to 
generate the DULD-LLT. However at customer Data Center, they do NOT accept 
this. Each interface needs to generate their DUID-LL(T) based on their own LL. 
This means that they must use their own MAC address. Both interface will have 
different DUIL-LL(T), which is technically against the RFC here.

Can you please help to check how networkstack driver could be supported on this 
requirement?


https://tools.ietf.org/html/rfc3315#section-9
9.2. DUID Based on Link-layer 
Address Plus Time [DUID-LLT]

This type of DUID consists of a two octet type field containing the
value 1, a two octet hardware type code, four octets containing a
time value, followed by link-layer address of any one network
interface that is connected to the DHCP device at the time that the
DUID is generated.

The choice of network interface can be completely arbitrary, as long
as that interface provides a globally unique link-layer address for
the link type, and the same DUID-LLT SHOULD be used in configuring
all network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID-LLT.


Thanks,
Jim

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

Re: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a bug?

[Zeng, Star]

It is just to include header file, I believe it could be removed from 
InternalS3SaveState.h.
What libraries a driver will link is not determined by source files, but inf 
file ( S3SaveStateDxe.inf)?

Why does S3SaveStateDxe.inf finally link SmbusLib, it is because 
S3SaveStateDxe.inf link S3BootScriptLib(I guess you are using 
DxeS3BootScriptLib.inf in MdeModulePkg) and S3BootScriptLib link SmbusLib.

You may could check the PCD usage in your SmbusLib instance.

Thanks,
Star
From: 王晓峰 [mailto:winggundu...@163.com] 
Sent: Thursday, January 21, 2016 5:40 PM
To: edk2-de...@ml01.01.org
Cc: Zeng, Star
Subject: [edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a 
bug?

Hi All,
    I meet a issue that there is a get PCD assert for  S3SaveStateDxe.inf. It 
is strange that I seached all the library and their child library in  
S3SaveStateDxe.inf , no PCD found related to this issue

[LibraryClasses]
  UefiBootServicesTableLib
  MemoryAllocationLib
  UefiDriverEntryPoint
  BaseMemoryLib
  BaseLib
  S3BootScriptLib

   Then I found in InternalS3SaveState.h, It directly include SmbusLib 
   #include 

   I am not sure whether it is a bug that SmbusLib should also be in 
S3SaveStateDxe.inf . But after I change SmbusLib instance to Null the PCD issue 
is solved. It seems build tool for PCD cannot caclulate the PCD introduced by 
such way.

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

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

Hi Ray,

On 21 January 2016 at 09:44, Ni, Ruiyu  wrote:
> It makes sense that F2 to F9 behaves like ESC because
> the Serial device doesn't have enough buffer (FIFO)
> to hold all the escape sequence keys.
>
> Because the certain platform cannot handle escape
> sequence keys like F2-F9 or cursor movement, I
> think it's reasonable to use a bigger FIFO other 1
> in that certain platform.
>

I should have mentioned that I'm using Laszlo's recent SerialDxe patch
series to fix the cursor keys.  That should leave me with enough FIFO
to handle the function keys.


> Regards,
> Ray
>
>
> -Original Message-
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Thursday, January 21, 2016 4:54 PM
> To: Laszlo Ersek 
> Cc: Ni, Ruiyu ; Leif Lindholm ; 
> edk2-de...@ml01.01.org; Zeng, Star ; Ard Biesheuvel 
> 
> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's 
> default receive FIFO depth
>
> On 21 January 2016 at 08:42, Laszlo Ersek  wrote:
>> On 01/21/16 09:20, Ryan Harkin wrote:
>>> On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
 On 01/21/16 06:42, Ni, Ruiyu wrote:
> Laszlo,
> When I re-think about the cursor issue, I am curious whether the
> function keys (F1/F2/...) work well in your platform.
> I guess any keys that will translate to multiple bytes don't work.
> Correct?

 I never experienced this issue personally. Based on the original report,
 it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
 So I hope the question about function keys can be answered by one of the
 CC'd guys.

>>>
>>> I don't know how to test F1/F2, etc. as I don't of any software that
>>> consumes them.  I'm currently using Intel BDS and that only appears to
>>> use cursor key, enter and regular ASCII printable characters.
>>
>> No, the Intel BDS is actually a good utility to test this. Go into one
>> of the setup dialogs, and change something, then press F9 or F10 to save
>> or throw away changes. (Writing from memory, so I'm not sure which does
>> which, but you can definitely use those function keys on at least some
>> of the forms.)
>>
>
> Ha! Foiled by my terminal - F10 opens the menu bar in the terminal
> app.  I'm not sure F9 "Reset to Defaults".  I was adding a new boot
> option, and on the "Modify Boot Option Description" page, ESC and F2
> to F9 all do the same thing: drop me back to the previous page where I
> can choose the file I want to boot.  The "Input the description" field
> isn't reset and retains the text I've typed into it.
>
>
>> Thanks
>> Laszlo
>>
>>>
>>>
> But I never heard of such issue in X86 platforms so far even the
> IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
> as 1.
> Is it because your platform uses a very higher baud rate?
> Or the time handler (supposed to be triggered every 0.02s) isn't
> triggered every 0.02s but a longer time?

 No clue, sorry. All we determined was that the FIFO depth of 1 caused
 the PL011Uart library to disable queueing on the device completely.
 Apparently, for handling isolated scan codes, no FIFO logic is necessary
 on the PL011Uart. (And isolated keystrokes did work well, only bursts of
 scan codes didn't.)

>>>
>>> I don't know if it's related, but when looking into why copy/paste
>>> doesn't work past one FIFO length, another Linaro team proposed that
>>> the timeout was too short for our baud rate.  I never managed to get
>>> this to work by changing the timeout.
>>>
 Thanks
 Laszlo

>
> Regards,
> Ray
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Laszlo Ersek
> Sent: Thursday, January 21, 2016 11:23 AM
> To: Ni, Ruiyu 
> Cc: Leif Lindholm ; edk2-de...@ml01.01.org; 
> Ryan Harkin ; Zeng, Star ; 
> Ard Biesheuvel 
> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the 
> UART's default receive FIFO depth
>
> On 01/21/16 03:20, Ni, Ruiyu wrote:
>> Laszlo,
>> I may not agree with your change to the Terminal driver.
>> Firstly it's not a good code practice to not preserve the other fields 
>> when changing
>> the time out value. People may forget that the FIFO depth was changed in 
>> Terminal
>> driver after a long enough period.
>
> I don't understand this argument. People may forget anything at all;
> that's why they should look at the code.
>
> Do you mean that the receive FIFO depth parameter should be changed in a
> different / separate SetAttributes() call, in the BindingStart()
> function of the terminal driver? I.e., independently of the Timeout 
> setting?
>
>> Secondly your change resets the FIFO depth but
>> it's possible that the device may not in the default FIFO depth which 
>> may bring
>> functionality issue.
>
> I think I disagree. The serial I

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ni, Ruiyu]

It makes sense that F2 to F9 behaves like ESC because
the Serial device doesn't have enough buffer (FIFO)
to hold all the escape sequence keys.

Because the certain platform cannot handle escape
sequence keys like F2-F9 or cursor movement, I
think it's reasonable to use a bigger FIFO other 1
in that certain platform.

Regards,
Ray


-Original Message-
From: Ryan Harkin [mailto:ryan.har...@linaro.org] 
Sent: Thursday, January 21, 2016 4:54 PM
To: Laszlo Ersek 
Cc: Ni, Ruiyu ; Leif Lindholm ; 
edk2-de...@ml01.01.org; Zeng, Star ; Ard Biesheuvel 

Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's 
default receive FIFO depth

On 21 January 2016 at 08:42, Laszlo Ersek  wrote:
> On 01/21/16 09:20, Ryan Harkin wrote:
>> On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
>>> On 01/21/16 06:42, Ni, Ruiyu wrote:
 Laszlo,
 When I re-think about the cursor issue, I am curious whether the
 function keys (F1/F2/...) work well in your platform.
 I guess any keys that will translate to multiple bytes don't work.
 Correct?
>>>
>>> I never experienced this issue personally. Based on the original report,
>>> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
>>> So I hope the question about function keys can be answered by one of the
>>> CC'd guys.
>>>
>>
>> I don't know how to test F1/F2, etc. as I don't of any software that
>> consumes them.  I'm currently using Intel BDS and that only appears to
>> use cursor key, enter and regular ASCII printable characters.
>
> No, the Intel BDS is actually a good utility to test this. Go into one
> of the setup dialogs, and change something, then press F9 or F10 to save
> or throw away changes. (Writing from memory, so I'm not sure which does
> which, but you can definitely use those function keys on at least some
> of the forms.)
>

Ha! Foiled by my terminal - F10 opens the menu bar in the terminal
app.  I'm not sure F9 "Reset to Defaults".  I was adding a new boot
option, and on the "Modify Boot Option Description" page, ESC and F2
to F9 all do the same thing: drop me back to the previous page where I
can choose the file I want to boot.  The "Input the description" field
isn't reset and retains the text I've typed into it.


> Thanks
> Laszlo
>
>>
>>
 But I never heard of such issue in X86 platforms so far even the
 IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
 as 1.
 Is it because your platform uses a very higher baud rate?
 Or the time handler (supposed to be triggered every 0.02s) isn't
 triggered every 0.02s but a longer time?
>>>
>>> No clue, sorry. All we determined was that the FIFO depth of 1 caused
>>> the PL011Uart library to disable queueing on the device completely.
>>> Apparently, for handling isolated scan codes, no FIFO logic is necessary
>>> on the PL011Uart. (And isolated keystrokes did work well, only bursts of
>>> scan codes didn't.)
>>>
>>
>> I don't know if it's related, but when looking into why copy/paste
>> doesn't work past one FIFO length, another Linaro team proposed that
>> the timeout was too short for our baud rate.  I never managed to get
>> this to work by changing the timeout.
>>
>>> Thanks
>>> Laszlo
>>>

 Regards,
 Ray

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Laszlo Ersek
 Sent: Thursday, January 21, 2016 11:23 AM
 To: Ni, Ruiyu 
 Cc: Leif Lindholm ; edk2-de...@ml01.01.org; Ryan 
 Harkin ; Zeng, Star ; Ard 
 Biesheuvel 
 Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the 
 UART's default receive FIFO depth

 On 01/21/16 03:20, Ni, Ruiyu wrote:
> Laszlo,
> I may not agree with your change to the Terminal driver.
> Firstly it's not a good code practice to not preserve the other fields 
> when changing
> the time out value. People may forget that the FIFO depth was changed in 
> Terminal
> driver after a long enough period.

 I don't understand this argument. People may forget anything at all;
 that's why they should look at the code.

 Do you mean that the receive FIFO depth parameter should be changed in a
 different / separate SetAttributes() call, in the BindingStart()
 function of the terminal driver? I.e., independently of the Timeout 
 setting?

> Secondly your change resets the FIFO depth but
> it's possible that the device may not in the default FIFO depth which may 
> bring
> functionality issue.

 I think I disagree. The serial IO protocol is not a service
 binding-style protocol, so when you open it with the BY_DRIVER
 attribute, and another agent already has it open with the BY_DRIVER
 attribute, EFI_ACCESS_DENIED is returned. This means in practice that
 TerminalDxe gets exclusive access to the underlying Serial IO protocol,
 and it can configure it whichever way it sees suit

[edk2] S3SaveStateDxe.inf doesn't explicitly include SmbusLib, is it a bug?

[王晓峰]

Hi All,
I meet a issue that there is a get PCD assert for  S3SaveStateDxe.inf. It 
is strange that I seached all the library and their child library in  
S3SaveStateDxe.inf , no PCD found related to this issue


[LibraryClasses]
  UefiBootServicesTableLib
  MemoryAllocationLib
  UefiDriverEntryPoint
  BaseMemoryLib
  BaseLib
  S3BootScriptLib


   Then I found in InternalS3SaveState.h, It directly include SmbusLib 
   #include 


   I am not sure whether it is a bug that SmbusLib should also be in 
S3SaveStateDxe.inf . But after I change SmbusLib instance to Null the PCD issue 
is solved. It seems build tool for PCD cannot caclulate the PCD introduced by 
such way.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 04/13] ShellPkg: UefiShellBcfgCommandLib: accumulate errors

[Ryan Harkin]

On 21 January 2016 at 08:47, Laszlo Ersek  wrote:
> On 01/21/16 09:24, Ryan Harkin wrote:
>> Hi Laszlo,
>>
>> This series is looking great so far, I have yet to test it as I need
>> to set my platform up to build Shell before I can do that, however,
>> I've had a review of the patches and the only thing I've noticed so
>> far is
>>
>> On 21 January 2016 at 01:11, Laszlo Ersek  wrote:
>>> Don't exit the command immediately when a variable access fails; continue
>>> processing after printing the error message. Let the final return status
>>> reflect any encountered errors.
>>>
>>> This patch is intended as a functional improvement.
>>>
>>> Cc: Jaben Carsey 
>>> Cc: Ryan Harkin 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Laszlo Ersek 
>>> ---
>>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 9 
>>> +++--
>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git 
>>> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
>>> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> index f5ae7bc..36d04d4 100644
>>> --- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> +++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> @@ -1051,12 +1051,15 @@ BcfgDisplayDump(
>>>UINTN   LoopVar2;
>>>CHAR16  *DevPathString;
>>>VOID*DevPath;
>>> +  UINTN   Errors;
>>>
>>>if (OrderCount == 0) {
>>>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
>>> gShellBcfgHiiHandle, L"bcfg");
>>>  return (SHELL_SUCCESS);
>>>}
>>>
>>> +  Errors = 0;
>>> +
>>>for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
>>>  Buffer= NULL;
>>>  BufferSize= 0;
>>> @@ -1083,7 +1086,8 @@ BcfgDisplayDump(
>>>
>>>  if (EFI_ERROR(Status) || Buffer == NULL) {
>>>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_READ_FAIL), 
>>> gShellBcfgHiiHandle, L"bcfg", VariableName);
>>> -  return (SHELL_INVALID_PARAMETER);
>>> +  ++Errors;
>>> +  goto Cleanup;
>>
>> Does this goto mean that we exit immediately and don't continue
>> accumulating errors?
>>
>> A subsequent patch, "ShellPkg: UefiShellBcfgCommandLib: enforce
>> minimum size for Boot and co.", also add a "goto Cleanup;".
>>
>> Should this be a "continue;"?
>
> In both cases, the loop is continued. The Cleanup label is within the
> loop body. The cleanup actions are repeated for each iteration of the
> body, at the end of the body, because Buffer and DevPathString (and
> originally, DevPath too) are allocated and released for each processed
> variable separately.
>

Yes, I can see this now.  Sorry for the noise.


> Unfortunately, this is not really well visible from the patches only;
> reviewing this series requires opening the full source file (and,
> perhaps, advancing with the application of the patches as you advance
> with the review, in order to have a fresh context to review the next
> patch against).
>

I actually did that too, but simply missed the nesting when looking at
the full file.  I guess I mistakenly assumed that because it was a
goto, the label was at the end of the function, outside the loop.


> I seriously considered formatting all patches in this series with the
> --function-context option ("Show whole surrounding functions of
> changes"), but when I tried it, it just generated a bunch of clutter. So
> I didn't use --function-context ultimately.
>

I don't think that would have helped me ;-)

Cheers,
Ryan.


> Cheers!
> Laszlo
>
>>
>>>  }
>>>
>>>  if ((*(UINT16*)(Buffer+4)) != 0) {
>>> @@ -1120,6 +1124,7 @@ BcfgDisplayDump(
>>>  L"\r\n");
>>>  }
>>>
>>> +Cleanup:
>>>  if (Buffer != NULL) {
>>>FreePool(Buffer);
>>>  }
>>> @@ -1130,7 +1135,7 @@ BcfgDisplayDump(
>>>FreePool(DevPathString);
>>>  }
>>>}
>>> -  return (SHELL_SUCCESS);
>>> +  return (Errors > 0) ? SHELL_INVALID_PARAMETER : SHELL_SUCCESS;
>>>  }
>>>
>>>  /**
>>> --
>>> 1.8.3.1
>>>
>>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 08:42, Laszlo Ersek  wrote:
> On 01/21/16 09:20, Ryan Harkin wrote:
>> On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
>>> On 01/21/16 06:42, Ni, Ruiyu wrote:
 Laszlo,
 When I re-think about the cursor issue, I am curious whether the
 function keys (F1/F2/...) work well in your platform.
 I guess any keys that will translate to multiple bytes don't work.
 Correct?
>>>
>>> I never experienced this issue personally. Based on the original report,
>>> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
>>> So I hope the question about function keys can be answered by one of the
>>> CC'd guys.
>>>
>>
>> I don't know how to test F1/F2, etc. as I don't of any software that
>> consumes them.  I'm currently using Intel BDS and that only appears to
>> use cursor key, enter and regular ASCII printable characters.
>
> No, the Intel BDS is actually a good utility to test this. Go into one
> of the setup dialogs, and change something, then press F9 or F10 to save
> or throw away changes. (Writing from memory, so I'm not sure which does
> which, but you can definitely use those function keys on at least some
> of the forms.)
>

Ha! Foiled by my terminal - F10 opens the menu bar in the terminal
app.  I'm not sure F9 "Reset to Defaults".  I was adding a new boot
option, and on the "Modify Boot Option Description" page, ESC and F2
to F9 all do the same thing: drop me back to the previous page where I
can choose the file I want to boot.  The "Input the description" field
isn't reset and retains the text I've typed into it.


> Thanks
> Laszlo
>
>>
>>
 But I never heard of such issue in X86 platforms so far even the
 IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
 as 1.
 Is it because your platform uses a very higher baud rate?
 Or the time handler (supposed to be triggered every 0.02s) isn't
 triggered every 0.02s but a longer time?
>>>
>>> No clue, sorry. All we determined was that the FIFO depth of 1 caused
>>> the PL011Uart library to disable queueing on the device completely.
>>> Apparently, for handling isolated scan codes, no FIFO logic is necessary
>>> on the PL011Uart. (And isolated keystrokes did work well, only bursts of
>>> scan codes didn't.)
>>>
>>
>> I don't know if it's related, but when looking into why copy/paste
>> doesn't work past one FIFO length, another Linaro team proposed that
>> the timeout was too short for our baud rate.  I never managed to get
>> this to work by changing the timeout.
>>
>>> Thanks
>>> Laszlo
>>>

 Regards,
 Ray

 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
 Laszlo Ersek
 Sent: Thursday, January 21, 2016 11:23 AM
 To: Ni, Ruiyu 
 Cc: Leif Lindholm ; edk2-de...@ml01.01.org; Ryan 
 Harkin ; Zeng, Star ; Ard 
 Biesheuvel 
 Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the 
 UART's default receive FIFO depth

 On 01/21/16 03:20, Ni, Ruiyu wrote:
> Laszlo,
> I may not agree with your change to the Terminal driver.
> Firstly it's not a good code practice to not preserve the other fields 
> when changing
> the time out value. People may forget that the FIFO depth was changed in 
> Terminal
> driver after a long enough period.

 I don't understand this argument. People may forget anything at all;
 that's why they should look at the code.

 Do you mean that the receive FIFO depth parameter should be changed in a
 different / separate SetAttributes() call, in the BindingStart()
 function of the terminal driver? I.e., independently of the Timeout 
 setting?

> Secondly your change resets the FIFO depth but
> it's possible that the device may not in the default FIFO depth which may 
> bring
> functionality issue.

 I think I disagree. The serial IO protocol is not a service
 binding-style protocol, so when you open it with the BY_DRIVER
 attribute, and another agent already has it open with the BY_DRIVER
 attribute, EFI_ACCESS_DENIED is returned. This means in practice that
 TerminalDxe gets exclusive access to the underlying Serial IO protocol,
 and it can configure it whichever way it sees suitable.

 (Same as when a BlockIO or other driver sits atop of a PciIo instance --
 we don't care what state the underlying PciIo instance might be at that
 point; we'll just set it up the way we need it for implementing BlockIo
 on top.)

> I have offline talked with Star and have understood the intention of the 
> change.
> How about we create a new PCD PcdUartDefaultReceiveFifoDepth and change 
> the SerialDxe
> driver to use the PCD value in its entrypoint and Reset() function? So 
> that any platform can
> override the default PCD in platform DSC.

 Sure, technically that could work. But if you 

Re: [edk2] [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

[Yao, Jiewen]

Yes. Thanks for the reminder.

-Original Message-
From: Zhang, Chao B 
Sent: Thursday, January 21, 2016 4:49 PM
To: Yao, Jiewen; edk2-de...@ml01.01.org
Subject: RE: [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

Jiewen:
   Please also update copyright.
   Reviewed-by: Chao Zhang 





Thanks & Best regards
Chao Zhang


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, January 21, 2016 4:41 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

The Tcg2Smm follows TCG PPI 1.3 specification.
This patch updates the ASL code string to 1.3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl 
index 80dfb3b..776f43e 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -187,7 +187,7 @@ DefinitionBlock (
 //
 // a) Get Physical Presence Interface Version
 //
-Return ("1.2")
+Return ("1.3")
   }
   Case (2)
   {
--
1.9.5.msysgit.0

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

Re: [edk2] [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

[Zhang, Chao B]

Jiewen:
   Please also update copyright.
   Reviewed-by: Chao Zhang 





Thanks & Best regards
Chao Zhang


-Original Message-
From: Yao, Jiewen 
Sent: Thursday, January 21, 2016 4:41 PM
To: edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

The Tcg2Smm follows TCG PPI 1.3 specification.
This patch updates the ASL code string to 1.3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl 
index 80dfb3b..776f43e 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -187,7 +187,7 @@ DefinitionBlock (
 //
 // a) Get Physical Presence Interface Version
 //
-Return ("1.2")
+Return ("1.3")
   }
   Case (2)
   {
--
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 04/13] ShellPkg: UefiShellBcfgCommandLib: accumulate errors

[Laszlo Ersek]

On 01/21/16 09:24, Ryan Harkin wrote:
> Hi Laszlo,
> 
> This series is looking great so far, I have yet to test it as I need
> to set my platform up to build Shell before I can do that, however,
> I've had a review of the patches and the only thing I've noticed so
> far is
> 
> On 21 January 2016 at 01:11, Laszlo Ersek  wrote:
>> Don't exit the command immediately when a variable access fails; continue
>> processing after printing the error message. Let the final return status
>> reflect any encountered errors.
>>
>> This patch is intended as a functional improvement.
>>
>> Cc: Jaben Carsey 
>> Cc: Ryan Harkin 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 9 
>> +++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
>> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>> index f5ae7bc..36d04d4 100644
>> --- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>> +++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>> @@ -1051,12 +1051,15 @@ BcfgDisplayDump(
>>UINTN   LoopVar2;
>>CHAR16  *DevPathString;
>>VOID*DevPath;
>> +  UINTN   Errors;
>>
>>if (OrderCount == 0) {
>>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
>> gShellBcfgHiiHandle, L"bcfg");
>>  return (SHELL_SUCCESS);
>>}
>>
>> +  Errors = 0;
>> +
>>for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
>>  Buffer= NULL;
>>  BufferSize= 0;
>> @@ -1083,7 +1086,8 @@ BcfgDisplayDump(
>>
>>  if (EFI_ERROR(Status) || Buffer == NULL) {
>>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_READ_FAIL), 
>> gShellBcfgHiiHandle, L"bcfg", VariableName);
>> -  return (SHELL_INVALID_PARAMETER);
>> +  ++Errors;
>> +  goto Cleanup;
> 
> Does this goto mean that we exit immediately and don't continue
> accumulating errors?
> 
> A subsequent patch, "ShellPkg: UefiShellBcfgCommandLib: enforce
> minimum size for Boot and co.", also add a "goto Cleanup;".
> 
> Should this be a "continue;"?

In both cases, the loop is continued. The Cleanup label is within the
loop body. The cleanup actions are repeated for each iteration of the
body, at the end of the body, because Buffer and DevPathString (and
originally, DevPath too) are allocated and released for each processed
variable separately.

Unfortunately, this is not really well visible from the patches only;
reviewing this series requires opening the full source file (and,
perhaps, advancing with the application of the patches as you advance
with the review, in order to have a fresh context to review the next
patch against).

I seriously considered formatting all patches in this series with the
--function-context option ("Show whole surrounding functions of
changes"), but when I tried it, it just generated a bunch of clutter. So
I didn't use --function-context ultimately.

Cheers!
Laszlo

> 
>>  }
>>
>>  if ((*(UINT16*)(Buffer+4)) != 0) {
>> @@ -1120,6 +1124,7 @@ BcfgDisplayDump(
>>  L"\r\n");
>>  }
>>
>> +Cleanup:
>>  if (Buffer != NULL) {
>>FreePool(Buffer);
>>  }
>> @@ -1130,7 +1135,7 @@ BcfgDisplayDump(
>>FreePool(DevPathString);
>>  }
>>}
>> -  return (SHELL_SUCCESS);
>> +  return (Errors > 0) ? SHELL_INVALID_PARAMETER : SHELL_SUCCESS;
>>  }
>>
>>  /**
>> --
>> 1.8.3.1
>>
>>

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

Re: [edk2] [PATCH] [ShellPkg] fix operator

[Ryan Harkin]

On 21 January 2016 at 01:01, Laszlo Ersek  wrote:
> On 01/20/16 23:18, Ryan Harkin wrote:
>>
>> On 20 Jan 2016 21:23, "Carsey, Jaben" > > wrote:
>>>
>>> I will wait.
>>>
>>> -Jaben
>>>
>>> > -Original Message-
>>> > From: Laszlo Ersek [mailto:ler...@redhat.com ]
>>> > Sent: Wednesday, January 20, 2016 1:21 PM
>>> > To: Carsey, Jaben > >; edk2-de...@ml01.01.org
>> 
>>> > Cc: ryan.har...@linaro.org 
>>> > Subject: Re: [PATCH] [ShellPkg] fix operator
>>> > Importance: High
>>> >
>>> > On 01/20/16 22:09, jaben carsey wrote:
>>> > > Contributed-under: TianoCore Contribution Agreement 1.0
>>> > > Signed-off-by: jaben carsey > >
>>> > > ---
>>> > >
>> ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 4
>>> > ++--
>>> > >  1 file changed, 2 insertions(+), 2 deletions(-)
>>> > >
>>> > > diff --git
>>> > a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> > b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> > > index 142504a..77e2374 100644
>>> > > ---
>>> > a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> > > +++
>>> > b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
>>> > > @@ -2,7 +2,7 @@
>>> > >Main file for BCFG command.
>>> > >
>>> > >(C) Copyright 2014-2015 Hewlett-Packard Development Company,
>>> > L.P.
>>> > > -  Copyright (c) 2010 - 2015, Intel Corporation. All rights
>> reserved.
>>> > > +  Copyright (c) 2010 - 2016, 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
>>> > > @@ -1105,7 +1105,7 @@ BcfgDisplayDump(
>>> > >VariableName,
>>> > >(CHAR16*)(Buffer+6),
>>> > >DevPathString,
>>> > > -  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) <=
>>> > BufferSize?L'N':L'Y');
>>> > > +  (StrSize((CHAR16*)(Buffer+6)) + *(UINT16*)(Buffer+4) + 6) >=
>>> > BufferSize?L'N':L'Y');
>>> > >  if (VerboseOutput) {
>>> > >for (LoopVar2 = (StrSize((CHAR16*)(Buffer+6)) +
>> *(UINT16*)(Buffer+4)
>>> > + 6);LoopVar2>> > >  ShellPrintEx(
>>> > >
>>> >
>>> > This patch is good, but I'd like to send a bit more comprehensive
>>> > cleanup soon, if you are okay with that.
>>> >
>>
>> Indeed, so far we've only discussed the bug when dumping the optional
>> data, although it looks like Laszlo has worked that out pretty well.
>>
>> But we haven't discussed the problems I'm having with setting the
>> optional data with the same command.  I'll look tomorrow.
>
> As Jaben indicated meanwhile, beside the genuine issues with the BCFG
> implementation (patch series coming up soon), your command line was
> incorrect. According to the UEFI Shell specification, the -opt flag
> takes the following form:
>
>> [-opt # [[filename]|[”data”]]
>
> That is, the first argument after -opt identifies the Boot or
> Driver option numerically whose optional data you wish to modify.
>
> This might be somewhat awkward when you *add* the option in question in
> the exact same BCFG command, but that's how it is. I think you can also
> modify the optional data for an existent Boot or Driver option,
> with just -opt, I think. In fact, I'm not sure if -opt is supposed to
> work *together* with any of the "add" commands!
>
> Then, the question becomes if you want to load the optional data from a
> file, or specify it directly on the command line. For the latter case,
> the quotes are mandatory, and the argument will be encoded as an
> L'\0'-terminated UCS-2 (i.e., CHAR16) string.
>
> (If you look at the BCFG synopsys in the UEFI shell spec, you can see
> that the quotes around -opt's "data" argument are typeset differently
> from the quotes around the various "desc" arguments!)
>
> Now, the trick is that ye olde ASCII quotation marks, expected by the
> BCFG command for the second form above, coincide with the UEFI Shell's
> *general* quoting. See "3.4.3 Quoting" in the UEFI Shell spec:
>
>> To include a double-quotation mark inside of a quoted string, use ^".
>
> For testing, I listed the drivers with the "drivers" command. In the
> output, I randomly picked "Usb Mass Storage Driver"; the associated
> handle was "95". So,
>
>> Shell> bcfg driver addh 0 95 "this is the desc"
>> Target = .
>> bcfg: Add Driver as 0
>>
>> Shell> bcfg driver -opt 0 "^"this is the data^""
>> [no feedback, just succeeds]
>
> Then, if you dump it with the series I'm about to post, you get:
>
>> Shell> bcfg driver dump -v
>> Option: 00. Variable: Driver
>>   Desc- this is the desc
>>   DevPath - 
>> MemoryMapped(0xB,0x90,0x11F)/FvFile(9FB4B4A7

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 09:20, Ryan Harkin wrote:
> On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
>> On 01/21/16 06:42, Ni, Ruiyu wrote:
>>> Laszlo,
>>> When I re-think about the cursor issue, I am curious whether the
>>> function keys (F1/F2/...) work well in your platform.
>>> I guess any keys that will translate to multiple bytes don't work.
>>> Correct?
>>
>> I never experienced this issue personally. Based on the original report,
>> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
>> So I hope the question about function keys can be answered by one of the
>> CC'd guys.
>>
> 
> I don't know how to test F1/F2, etc. as I don't of any software that
> consumes them.  I'm currently using Intel BDS and that only appears to
> use cursor key, enter and regular ASCII printable characters.

No, the Intel BDS is actually a good utility to test this. Go into one
of the setup dialogs, and change something, then press F9 or F10 to save
or throw away changes. (Writing from memory, so I'm not sure which does
which, but you can definitely use those function keys on at least some
of the forms.)

Thanks
Laszlo

> 
> 
>>> But I never heard of such issue in X86 platforms so far even the
>>> IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
>>> as 1.
>>> Is it because your platform uses a very higher baud rate?
>>> Or the time handler (supposed to be triggered every 0.02s) isn't
>>> triggered every 0.02s but a longer time?
>>
>> No clue, sorry. All we determined was that the FIFO depth of 1 caused
>> the PL011Uart library to disable queueing on the device completely.
>> Apparently, for handling isolated scan codes, no FIFO logic is necessary
>> on the PL011Uart. (And isolated keystrokes did work well, only bursts of
>> scan codes didn't.)
>>
> 
> I don't know if it's related, but when looking into why copy/paste
> doesn't work past one FIFO length, another Linaro team proposed that
> the timeout was too short for our baud rate.  I never managed to get
> this to work by changing the timeout.
> 
>> Thanks
>> Laszlo
>>
>>>
>>> Regards,
>>> Ray
>>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Laszlo Ersek
>>> Sent: Thursday, January 21, 2016 11:23 AM
>>> To: Ni, Ruiyu 
>>> Cc: Leif Lindholm ; edk2-de...@ml01.01.org; Ryan 
>>> Harkin ; Zeng, Star ; Ard 
>>> Biesheuvel 
>>> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the 
>>> UART's default receive FIFO depth
>>>
>>> On 01/21/16 03:20, Ni, Ruiyu wrote:
 Laszlo,
 I may not agree with your change to the Terminal driver.
 Firstly it's not a good code practice to not preserve the other fields 
 when changing
 the time out value. People may forget that the FIFO depth was changed in 
 Terminal
 driver after a long enough period.
>>>
>>> I don't understand this argument. People may forget anything at all;
>>> that's why they should look at the code.
>>>
>>> Do you mean that the receive FIFO depth parameter should be changed in a
>>> different / separate SetAttributes() call, in the BindingStart()
>>> function of the terminal driver? I.e., independently of the Timeout setting?
>>>
 Secondly your change resets the FIFO depth but
 it's possible that the device may not in the default FIFO depth which may 
 bring
 functionality issue.
>>>
>>> I think I disagree. The serial IO protocol is not a service
>>> binding-style protocol, so when you open it with the BY_DRIVER
>>> attribute, and another agent already has it open with the BY_DRIVER
>>> attribute, EFI_ACCESS_DENIED is returned. This means in practice that
>>> TerminalDxe gets exclusive access to the underlying Serial IO protocol,
>>> and it can configure it whichever way it sees suitable.
>>>
>>> (Same as when a BlockIO or other driver sits atop of a PciIo instance --
>>> we don't care what state the underlying PciIo instance might be at that
>>> point; we'll just set it up the way we need it for implementing BlockIo
>>> on top.)
>>>
 I have offline talked with Star and have understood the intention of the 
 change.
 How about we create a new PCD PcdUartDefaultReceiveFifoDepth and change 
 the SerialDxe
 driver to use the PCD value in its entrypoint and Reset() function? So 
 that any platform can
 override the default PCD in platform DSC.
>>>
>>> Sure, technically that could work. But if you look at the UEFI
>>> specification, the SerialIO protocol instance, produced by SerialDxe
>>> with such a PCD override, would not conform to the spec.
>>>
>>> (Similarly to the case when you change the already existing PCDs from
>>> their default values -- for example, if you change the baud rate PCD
>>> from 115200, then the resultant SerialIO protocol instance will *also*
>>> not conform.)
>>>

 Through this, we also limit the change to SerialDxe driver. After all 
 Terminal driver can start
 above any SerialIo instance, not just the one created 

[edk2] [patch] SecurityPkg: Update TCG PPI "1.3" for TCG2.

[jiewen yao]

The Tcg2Smm follows TCG PPI 1.3 specification.
This patch updates the ASL code string to 1.3.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" 
Cc: "Zhang, Chao B" 
---
 SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
index 80dfb3b..776f43e 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -187,7 +187,7 @@ DefinitionBlock (
 //
 // a) Get Physical Presence Interface Version
 //
-Return ("1.2")
+Return ("1.3")
   }
   Case (2)
   {
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH 04/13] ShellPkg: UefiShellBcfgCommandLib: accumulate errors

[Ryan Harkin]

Hi Laszlo,

This series is looking great so far, I have yet to test it as I need
to set my platform up to build Shell before I can do that, however,
I've had a review of the patches and the only thing I've noticed so
far is

On 21 January 2016 at 01:11, Laszlo Ersek  wrote:
> Don't exit the command immediately when a variable access fails; continue
> processing after printing the error message. Let the final return status
> reflect any encountered errors.
>
> This patch is intended as a functional improvement.
>
> Cc: Jaben Carsey 
> Cc: Ryan Harkin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 9 
> +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git 
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c 
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index f5ae7bc..36d04d4 100644
> --- a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> +++ b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> @@ -1051,12 +1051,15 @@ BcfgDisplayDump(
>UINTN   LoopVar2;
>CHAR16  *DevPathString;
>VOID*DevPath;
> +  UINTN   Errors;
>
>if (OrderCount == 0) {
>  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN(STR_BCFG_NONE), 
> gShellBcfgHiiHandle, L"bcfg");
>  return (SHELL_SUCCESS);
>}
>
> +  Errors = 0;
> +
>for (LoopVar = 0 ; LoopVar < OrderCount ; LoopVar++) {
>  Buffer= NULL;
>  BufferSize= 0;
> @@ -1083,7 +1086,8 @@ BcfgDisplayDump(
>
>  if (EFI_ERROR(Status) || Buffer == NULL) {
>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_BCFG_READ_FAIL), 
> gShellBcfgHiiHandle, L"bcfg", VariableName);
> -  return (SHELL_INVALID_PARAMETER);
> +  ++Errors;
> +  goto Cleanup;

Does this goto mean that we exit immediately and don't continue
accumulating errors?

A subsequent patch, "ShellPkg: UefiShellBcfgCommandLib: enforce
minimum size for Boot and co.", also add a "goto Cleanup;".

Should this be a "continue;"?

>  }
>
>  if ((*(UINT16*)(Buffer+4)) != 0) {
> @@ -1120,6 +1124,7 @@ BcfgDisplayDump(
>  L"\r\n");
>  }
>
> +Cleanup:
>  if (Buffer != NULL) {
>FreePool(Buffer);
>  }
> @@ -1130,7 +1135,7 @@ BcfgDisplayDump(
>FreePool(DevPathString);
>  }
>}
> -  return (SHELL_SUCCESS);
> +  return (Errors > 0) ? SHELL_INVALID_PARAMETER : SHELL_SUCCESS;
>  }
>
>  /**
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Ryan Harkin]

On 21 January 2016 at 08:14, Laszlo Ersek  wrote:
> On 01/21/16 06:42, Ni, Ruiyu wrote:
>> Laszlo,
>> When I re-think about the cursor issue, I am curious whether the
>> function keys (F1/F2/...) work well in your platform.
>> I guess any keys that will translate to multiple bytes don't work.
>> Correct?
>
> I never experienced this issue personally. Based on the original report,
> it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
> So I hope the question about function keys can be answered by one of the
> CC'd guys.
>

I don't know how to test F1/F2, etc. as I don't of any software that
consumes them.  I'm currently using Intel BDS and that only appears to
use cursor key, enter and regular ASCII printable characters.


>> But I never heard of such issue in X86 platforms so far even the
>> IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
>> as 1.
>> Is it because your platform uses a very higher baud rate?
>> Or the time handler (supposed to be triggered every 0.02s) isn't
>> triggered every 0.02s but a longer time?
>
> No clue, sorry. All we determined was that the FIFO depth of 1 caused
> the PL011Uart library to disable queueing on the device completely.
> Apparently, for handling isolated scan codes, no FIFO logic is necessary
> on the PL011Uart. (And isolated keystrokes did work well, only bursts of
> scan codes didn't.)
>

I don't know if it's related, but when looking into why copy/paste
doesn't work past one FIFO length, another Linaro team proposed that
the timeout was too short for our baud rate.  I never managed to get
this to work by changing the timeout.

> Thanks
> Laszlo
>
>>
>> Regards,
>> Ray
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Laszlo Ersek
>> Sent: Thursday, January 21, 2016 11:23 AM
>> To: Ni, Ruiyu 
>> Cc: Leif Lindholm ; edk2-de...@ml01.01.org; Ryan 
>> Harkin ; Zeng, Star ; Ard 
>> Biesheuvel 
>> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's 
>> default receive FIFO depth
>>
>> On 01/21/16 03:20, Ni, Ruiyu wrote:
>>> Laszlo,
>>> I may not agree with your change to the Terminal driver.
>>> Firstly it's not a good code practice to not preserve the other fields when 
>>> changing
>>> the time out value. People may forget that the FIFO depth was changed in 
>>> Terminal
>>> driver after a long enough period.
>>
>> I don't understand this argument. People may forget anything at all;
>> that's why they should look at the code.
>>
>> Do you mean that the receive FIFO depth parameter should be changed in a
>> different / separate SetAttributes() call, in the BindingStart()
>> function of the terminal driver? I.e., independently of the Timeout setting?
>>
>>> Secondly your change resets the FIFO depth but
>>> it's possible that the device may not in the default FIFO depth which may 
>>> bring
>>> functionality issue.
>>
>> I think I disagree. The serial IO protocol is not a service
>> binding-style protocol, so when you open it with the BY_DRIVER
>> attribute, and another agent already has it open with the BY_DRIVER
>> attribute, EFI_ACCESS_DENIED is returned. This means in practice that
>> TerminalDxe gets exclusive access to the underlying Serial IO protocol,
>> and it can configure it whichever way it sees suitable.
>>
>> (Same as when a BlockIO or other driver sits atop of a PciIo instance --
>> we don't care what state the underlying PciIo instance might be at that
>> point; we'll just set it up the way we need it for implementing BlockIo
>> on top.)
>>
>>> I have offline talked with Star and have understood the intention of the 
>>> change.
>>> How about we create a new PCD PcdUartDefaultReceiveFifoDepth and change the 
>>> SerialDxe
>>> driver to use the PCD value in its entrypoint and Reset() function? So that 
>>> any platform can
>>> override the default PCD in platform DSC.
>>
>> Sure, technically that could work. But if you look at the UEFI
>> specification, the SerialIO protocol instance, produced by SerialDxe
>> with such a PCD override, would not conform to the spec.
>>
>> (Similarly to the case when you change the already existing PCDs from
>> their default values -- for example, if you change the baud rate PCD
>> from 115200, then the resultant SerialIO protocol instance will *also*
>> not conform.)
>>
>>>
>>> Through this, we also limit the change to SerialDxe driver. After all 
>>> Terminal driver can start
>>> above any SerialIo instance, not just the one created by the 
>>> MdeModulePkg/Universal/SerialDxe.
>>
>> Yes, I fully agree that TerminalDxe should be able to work with any
>> SerialIO protocol instance, regardless of what UART driver produced it.
>>
>> However, the consequence that I draw from this requirement is different
>> from yours. My argument goes, if TerminalDxe cannot (and it should not)
>> assume anything particular about the underlying SerialIO protocol
>> instance, then what it *should* assume, is *only* what the U

Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's default receive FIFO depth

[Laszlo Ersek]

On 01/21/16 06:42, Ni, Ruiyu wrote:
> Laszlo,
> When I re-think about the cursor issue, I am curious whether the
> function keys (F1/F2/...) work well in your platform.
> I guess any keys that will translate to multiple bytes don't work.
> Correct?

I never experienced this issue personally. Based on the original report,
it emerged only on ARM FVP (which is a software emulator) and ARM Juno.
So I hope the question about function keys can be answered by one of the
CC'd guys.

> But I never heard of such issue in X86 platforms so far even the
> IsaSerialDxe driver in IntelFrameworkModulePkg uses FIFO depth
> as 1.
> Is it because your platform uses a very higher baud rate?
> Or the time handler (supposed to be triggered every 0.02s) isn't
> triggered every 0.02s but a longer time?

No clue, sorry. All we determined was that the FIFO depth of 1 caused
the PL011Uart library to disable queueing on the device completely.
Apparently, for handling isolated scan codes, no FIFO logic is necessary
on the PL011Uart. (And isolated keystrokes did work well, only bursts of
scan codes didn't.)

Thanks
Laszlo

> 
> Regards,
> Ray
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Thursday, January 21, 2016 11:23 AM
> To: Ni, Ruiyu 
> Cc: Leif Lindholm ; edk2-de...@ml01.01.org; Ryan 
> Harkin ; Zeng, Star ; Ard 
> Biesheuvel 
> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg: TerminalDxe: select the UART's 
> default receive FIFO depth
> 
> On 01/21/16 03:20, Ni, Ruiyu wrote:
>> Laszlo,
>> I may not agree with your change to the Terminal driver.
>> Firstly it's not a good code practice to not preserve the other fields when 
>> changing
>> the time out value. People may forget that the FIFO depth was changed in 
>> Terminal
>> driver after a long enough period.
> 
> I don't understand this argument. People may forget anything at all;
> that's why they should look at the code.
> 
> Do you mean that the receive FIFO depth parameter should be changed in a
> different / separate SetAttributes() call, in the BindingStart()
> function of the terminal driver? I.e., independently of the Timeout setting?
> 
>> Secondly your change resets the FIFO depth but
>> it's possible that the device may not in the default FIFO depth which may 
>> bring
>> functionality issue.
> 
> I think I disagree. The serial IO protocol is not a service
> binding-style protocol, so when you open it with the BY_DRIVER
> attribute, and another agent already has it open with the BY_DRIVER
> attribute, EFI_ACCESS_DENIED is returned. This means in practice that
> TerminalDxe gets exclusive access to the underlying Serial IO protocol,
> and it can configure it whichever way it sees suitable.
> 
> (Same as when a BlockIO or other driver sits atop of a PciIo instance --
> we don't care what state the underlying PciIo instance might be at that
> point; we'll just set it up the way we need it for implementing BlockIo
> on top.)
> 
>> I have offline talked with Star and have understood the intention of the 
>> change.
>> How about we create a new PCD PcdUartDefaultReceiveFifoDepth and change the 
>> SerialDxe
>> driver to use the PCD value in its entrypoint and Reset() function? So that 
>> any platform can
>> override the default PCD in platform DSC.
> 
> Sure, technically that could work. But if you look at the UEFI
> specification, the SerialIO protocol instance, produced by SerialDxe
> with such a PCD override, would not conform to the spec.
> 
> (Similarly to the case when you change the already existing PCDs from
> their default values -- for example, if you change the baud rate PCD
> from 115200, then the resultant SerialIO protocol instance will *also*
> not conform.)
> 
>>
>> Through this, we also limit the change to SerialDxe driver. After all 
>> Terminal driver can start
>> above any SerialIo instance, not just the one created by the 
>> MdeModulePkg/Universal/SerialDxe.
> 
> Yes, I fully agree that TerminalDxe should be able to work with any
> SerialIO protocol instance, regardless of what UART driver produced it.
> 
> However, the consequence that I draw from this requirement is different
> from yours. My argument goes, if TerminalDxe cannot (and it should not)
> assume anything particular about the underlying SerialIO protocol
> instance, then what it *should* assume, is *only* what the UEFI spec
> dictates about the SerialIO protocol defaults.
> 
> Those defaults include "receive FIFO depth = 1", at least right after
> Reset().
> 
> Since TerminalDxe knows for sure that "receive FIFO depth = 1" will not
> be appropriate for parsing escape sequences, it can be argued that
> TerminalDxe simply cannot avoid setting the receive FIFO depth to
> something more suitable than the spec-mandated default.
> 
> Anyway, I don't insist. The only reason I chimed in was that the UEFI
> spec explicitly regulates this question, as far as I could see, so we
> should try to conform in the reference