[edk2] [PATCH 1/1] SD : Continue setting up sd even if SD_HIGH_SPEED is not supported

2019-02-21 Thread tien . hock . loh
From: "Loh, Tien Hock" 

If SD doesn't support SD_HIGH_SPEED, function should still continue to
setup SD to go into 4 bits more if it is supported.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Loh Tien Hock 
---
 EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c 
b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
index f661a0c..8fd5c31 100755
--- a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
+++ b/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c
@@ -474,18 +474,17 @@ InitializeSdMmcDevice (
 
 if (!(Buffer[3] & SD_HIGH_SPEED_SUPPORTED)) {
   DEBUG ((DEBUG_ERROR, "%a : High Speed not supported by Card %r\n", 
__FUNCTION__, Status));
-  return Status;
 }
+else {
+  Speed = SD_HIGH_SPEED;
 
-Speed = SD_HIGH_SPEED;
-
-/* SD Switch, Mode:1, Group:0, Value:1 */
-CmdArg = CreateSwitchCmdArgument(1, 0, 1);
-Status = MmcHost->SendCommand (MmcHost, MMC_CMD6, CmdArg);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_ERROR, "%a (MMC_CMD6): Error and Status = %r\n", 
__FUNCTION__, Status));
-   return Status;
-} else {
+  /* SD Switch, Mode:1, Group:0, Value:1 */
+  CmdArg = CreateSwitchCmdArgument(1, 0, 1);
+  Status = MmcHost->SendCommand (MmcHost, MMC_CMD6, CmdArg);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a (MMC_CMD6): Error and Status = %r\n", 
__FUNCTION__, Status));
+return Status;
+  } else {
   Status = MmcHost->ReadBlockData (MmcHost, 0, SWITCH_CMD_DATA_LENGTH, 
Buffer);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a (MMC_CMD6): ReadBlockData Error and Status = 
%r\n", __FUNCTION__, Status));
@@ -495,6 +494,7 @@ InitializeSdMmcDevice (
   if ((Buffer[4] & SWITCH_CMD_SUCCESS_MASK) != 0x0100) {
 DEBUG((DEBUG_ERROR, "Problem switching SD card into high-speed 
mode\n"));
 return Status;
+}
   }
 }
   }
-- 
2.2.2

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


[edk2] [PATCH 4/4] EmbeddedPkg/DwEmmc: Check DMA completion in SendCommand

2019-02-21 Thread tien . hock . loh
From: "Loh, Tien Hock" 

DwEmmcReadBlockData and DwEmmcWriteBlockData needs to check for the
transfer completion before returning. This also adds error checking
to the DMA transfer.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Loh Tien Hock 
---
 EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
index c232309..baf299d 100644
--- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -563,8 +563,9 @@ DwEmmcReadBlockData (
   )
 {
   EFI_STATUS  Status;
-  UINT32  DescPages, CountPerPage, Count;
+  UINT32  DescPages, CountPerPage, Count, ErrMask;
   EFI_TPL Tpl;
+  UINTN Rintsts;
 
   Tpl = gBS->RaiseTPL (TPL_NOTIFY);
 
@@ -587,6 +588,18 @@ DwEmmcReadBlockData (
 DEBUG ((DEBUG_ERROR, "Failed to read data, mDwEmmcCommand:%x, 
mDwEmmcArgument:%x, Status:%r\n", mDwEmmcCommand, mDwEmmcArgument, Status));
 goto out;
   }
+
+  while(!((MmioRead32(DWEMMC_RINTSTS) & (DWEMMC_INT_DTO {
+Rintsts = MmioRead32 (DWEMMC_RINTSTS);
+  }
+  ErrMask = DWEMMC_INT_EBE | DWEMMC_INT_HLE | DWEMMC_INT_RTO |
+DWEMMC_INT_RCRC | DWEMMC_INT_RE | DWEMMC_INT_DCRC |
+DWEMMC_INT_DRT | DWEMMC_INT_SBE;
+
+  if (Rintsts & ErrMask) {
+Status = EFI_DEVICE_ERROR;
+goto out;
+  }
 out:
   // Restore Tpl
   gBS->RestoreTPL (Tpl);
@@ -602,8 +615,9 @@ DwEmmcWriteBlockData (
   )
 {
   EFI_STATUS  Status;
-  UINT32  DescPages, CountPerPage, Count;
+  UINT32  DescPages, CountPerPage, Count, ErrMask;
   EFI_TPL Tpl;
+  UINTN Rintsts;
 
   Tpl = gBS->RaiseTPL (TPL_NOTIFY);
 
@@ -626,6 +640,18 @@ DwEmmcWriteBlockData (
 DEBUG ((DEBUG_ERROR, "Failed to write data, mDwEmmcCommand:%x, 
mDwEmmcArgument:%x, Status:%r\n", mDwEmmcCommand, mDwEmmcArgument, Status));
 goto out;
   }
+
+  while(!((MmioRead32(DWEMMC_RINTSTS) & (DWEMMC_INT_DTO {
+Rintsts = MmioRead32 (DWEMMC_RINTSTS);
+  }
+  ErrMask = DWEMMC_INT_EBE | DWEMMC_INT_HLE | DWEMMC_INT_RTO |
+DWEMMC_INT_RCRC | DWEMMC_INT_RE | DWEMMC_INT_DCRC |
+DWEMMC_INT_DRT | DWEMMC_INT_SBE;
+
+  if (Rintsts & ErrMask) {
+Status = EFI_DEVICE_ERROR;
+goto out;
+  }
 out:
   // Restore Tpl
   gBS->RestoreTPL (Tpl);
-- 
2.2.2

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


[edk2] [PATCH 0/4] EmbeddedPkg/DwEmmc: Fix bugs causing DwEmmc to fail to initialize

2019-02-21 Thread tien . hock . loh
From: Loh Tien Hock 

This patch series fixes bugs with DwEmmc driver, namely:
* Added CMD6 handling
* Fixed workaround querying SendCommand using delays
* Fix DMA transfer length causing buffer underrun in FIFO
* Check DMA completion before returning from SendCommand

Loh, Tien Hock (4):
  EmbeddedPkg/DwEmmc: Remove unnecessary MicroSecondDelay
  EmbeddedPkg/DwEmmc: Fix SendCommand parameters
  EmbeddedPkg/DwEmmc: Fix DMA transfer length
  EmbeddedPkg/DwEmmc: Check DMA completion in SendCommand

 EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 122 +++---
 1 file changed, 95 insertions(+), 27 deletions(-)

-- 
2.2.2

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


[edk2] [PATCH 2/4] EmbeddedPkg/DwEmmc: Fix SendCommand parameters

2019-02-21 Thread tien . hock . loh
From: "Loh, Tien Hock" 

Only send BIT_CMD_CHECK_RESPONSE_CRC if MMC commands needs it.

Fixes parameters to ACMD6 where if CMD is application command, ie. CMD55 is
sent before ACMD6, to do response instead of data transfer.

Added CMD51 handling as CMD51 is a data transfer, and needs BIT_CMD_READ
and BIT_CMD_DATA_EXPECTED to be set.

Updates DwEmmcReceiveResponse to SendCommand only if IsPendingReadCommand
or IsPendingWriteCommand is true.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Loh Tien Hock 
---
 EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 59 +++
 1 file changed, 45 insertions(+), 14 deletions(-)

diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
index 6d0f472..600ab01 100644
--- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -45,6 +45,7 @@ DWEMMC_IDMAC_DESCRIPTOR   *gpIdmacDesc;
 EFI_GUID mDwEmmcDevicePathGuid = EFI_CALLER_ID_GUID;
 STATIC UINT32 mDwEmmcCommand;
 STATIC UINT32 mDwEmmcArgument;
+STATIC BOOLEAN mIsACmd = FALSE;
 
 EFI_STATUS
 DwEmmcReadBlockData (
@@ -321,68 +322,93 @@ DwEmmcSendCommand (
 break;
   case MMC_INDX(2):
 Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_LONG_RESPONSE |
-   BIT_CMD_CHECK_RESPONSE_CRC | BIT_CMD_SEND_INIT;
+   BIT_CMD_SEND_INIT;
 break;
   case MMC_INDX(3):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT |
BIT_CMD_SEND_INIT;
 break;
+  case MMC_INDX(6):
+if(mIsACmd) {
+  Cmd = BIT_CMD_RESPONSE_EXPECT ;
+}
+else {
+  Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_DATA_EXPECTED |
+BIT_CMD_READ;
+}
+break;
   case MMC_INDX(7):
 if (Argument)
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC;
+Cmd = BIT_CMD_RESPONSE_EXPECT;
 else
 Cmd = 0;
 break;
   case MMC_INDX(8):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
-   BIT_CMD_DATA_EXPECTED | BIT_CMD_READ |
+Cmd = BIT_CMD_RESPONSE_EXPECT |
BIT_CMD_WAIT_PRVDATA_COMPLETE;
 break;
   case MMC_INDX(9):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT |
BIT_CMD_LONG_RESPONSE;
 break;
   case MMC_INDX(12):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT  |
BIT_CMD_STOP_ABORT_CMD;
 break;
   case MMC_INDX(13):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT  |
BIT_CMD_WAIT_PRVDATA_COMPLETE;
 break;
   case MMC_INDX(16):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT  |
BIT_CMD_DATA_EXPECTED | BIT_CMD_READ |
BIT_CMD_WAIT_PRVDATA_COMPLETE;
 break;
   case MMC_INDX(17):
   case MMC_INDX(18):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT |
BIT_CMD_DATA_EXPECTED | BIT_CMD_READ |
BIT_CMD_WAIT_PRVDATA_COMPLETE;
 break;
   case MMC_INDX(24):
   case MMC_INDX(25):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT  |
BIT_CMD_DATA_EXPECTED | BIT_CMD_WRITE |
BIT_CMD_WAIT_PRVDATA_COMPLETE;
 break;
   case MMC_INDX(30):
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC |
+Cmd = BIT_CMD_RESPONSE_EXPECT  |
BIT_CMD_DATA_EXPECTED;
 break;
+  case MMC_INDX(51):
+Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_DATA_EXPECTED |
+   BIT_CMD_READ | BIT_CMD_WAIT_PRVDATA_COMPLETE;
+break;
   default:
-Cmd = BIT_CMD_RESPONSE_EXPECT | BIT_CMD_CHECK_RESPONSE_CRC;
+Cmd = BIT_CMD_RESPONSE_EXPECT ;
 break;
   }
 
   Cmd |= MMC_GET_INDX(MmcCmd) | BIT_CMD_USE_HOLD_REG | BIT_CMD_START;
+
+  if(MMC_INDX(55) == MMC_GET_INDX(MmcCmd))
+mIsACmd = TRUE;
+  else
+mIsACmd = FALSE;
+
+  if (!(MmcCmd & MMC_CMD_NO_CRC_RESPONSE)) {
+Cmd |= BIT_CMD_CHECK_RESPONSE_CRC;
+  }
+
   if (IsPendingReadCommand (Cmd) || IsPendingWriteCommand (Cmd)) {
 mDwEmmcCommand = Cmd;
 mDwEmmcArgument = Argument;
   } else {
+mDwEmmcCommand = Cmd;
+mDwEmmcArgument = Argument;
 Status = SendCommand (Cmd, Argument);
   }
+
   return Status;
 }
 
@@ -393,6 +419,11 @@ DwEmmcReceiveResponse (
   IN UINT32*Buffer
   )
 {
+  EFI_STATUS Status = EFI_SUCCESS;
+
+  if(IsPendingReadCommand (mDwEmmcCommand) || 
IsPendingWriteCommand(mDwEmmcCommand))
+Status = SendCommand (mDwEmmcCommand, mDwEmmcArgument);
+
   if (Buffer == NULL) {
 return EFI_INVALID_PARAMETER;
   }
@@ -410,7 +441,7 @@ DwEmmcReceiveResponse (
 Buffer[2] = MmioRead32 (DWEMMC_RESP2);
 Buffer[3] = MmioRead32 (DWEMMC_RESP3);
   }
-  return EFI_SUCCESS;
+  return Status;
 }
 
 VOID
-- 
2.2.2


[edk2] [PATCH 3/4] EmbeddedPkg/DwEmmc: Fix DMA transfer length

2019-02-21 Thread tien . hock . loh
From: "Loh, Tien Hock" 

DMA should not transfer more than requested length otherwise FIFO might run
into buffer underrun and causes errors in future transfers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Loh Tien Hock 
---
 EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
index 600ab01..c232309 100644
--- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -496,7 +496,13 @@ PrepareDmaData (
 
   Cnt = (Length + DWEMMC_DMA_BUF_SIZE - 1) / DWEMMC_DMA_BUF_SIZE;
   Blks = (Length + DWEMMC_BLOCK_SIZE - 1) / DWEMMC_BLOCK_SIZE;
-  Length = DWEMMC_BLOCK_SIZE * Blks;
+
+  if(Length < DWEMMC_BLOCK_SIZE) {
+Length = Length;
+  }
+  else {
+Length = DWEMMC_BLOCK_SIZE * Blks;
+  }
 
   for (Idx = 0; Idx < Cnt; Idx++) {
 (IdmacDesc + Idx)->Des0 = DWEMMC_IDMAC_DES0_OWN | DWEMMC_IDMAC_DES0_CH |
@@ -534,11 +540,18 @@ StartDma (
   Data |= DWEMMC_CTRL_INT_EN | DWEMMC_CTRL_DMA_EN | DWEMMC_CTRL_IDMAC_EN;
   MmioWrite32 (DWEMMC_CTRL, Data);
   Data = MmioRead32 (DWEMMC_BMOD);
+
   Data |= DWEMMC_IDMAC_ENABLE | DWEMMC_IDMAC_FB;
   MmioWrite32 (DWEMMC_BMOD, Data);
 
-  MmioWrite32 (DWEMMC_BLKSIZ, DWEMMC_BLOCK_SIZE);
-  MmioWrite32 (DWEMMC_BYTCNT, Length);
+  if(Length < DWEMMC_BLOCK_SIZE) {
+MmioWrite32 (DWEMMC_BLKSIZ, Length);
+MmioWrite32 (DWEMMC_BYTCNT, Length);
+  }
+  else {
+MmioWrite32 (DWEMMC_BLKSIZ, DWEMMC_BLOCK_SIZE);
+MmioWrite32 (DWEMMC_BYTCNT, Length);
+  }
 }
 
 EFI_STATUS
-- 
2.2.2

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


[edk2] [PATCH 1/4] EmbeddedPkg/DwEmmc: Remove unnecessary MicroSecondDelay

2019-02-21 Thread tien . hock . loh
From: "Loh, Tien Hock" 

Existing implementation checks for error regardless of if
DWEMMC_INT_CMD_DONE is set, causing the loop check to errors out
even when it shouldn't if the MicroSecondDelay doesn't do long
enough delays. This removes MicroSecondDelay and updates the
function to check for CMD_DONE before doing any error checking.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Loh Tien Hock 
---
 EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
index 0437e30..6d0f472 100644
--- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -290,17 +290,15 @@ SendCommand (
   ErrMask = DWEMMC_INT_EBE | DWEMMC_INT_HLE | DWEMMC_INT_RTO |
 DWEMMC_INT_RCRC | DWEMMC_INT_RE;
   ErrMask |= DWEMMC_INT_DCRC | DWEMMC_INT_DRT | DWEMMC_INT_SBE;
+
   do {
-MicroSecondDelay(500);
 Data = MmioRead32 (DWEMMC_RINTSTS);
-
-if (Data & ErrMask) {
-  return EFI_DEVICE_ERROR;
-}
-if (Data & DWEMMC_INT_DTO) { // Transfer Done
-  break;
-}
   } while (!(Data & DWEMMC_INT_CMD_DONE));
+
+  if (Data & ErrMask) {
+return EFI_DEVICE_ERROR;
+  }
+
   return EFI_SUCCESS;
 }
 
-- 
2.2.2

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


Re: [edk2] [Patch] BaseTools: Fix a bug about Structure PCD

2019-02-21 Thread Gao, Liming
Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Tuesday, February 19, 2019 9:30 PM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch] BaseTools: Fix a bug about Structure PCD
>
>BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1535
>If there is Hii Structure Pcd, build will fail, root cause is that
>there is an incorrect variable access method used in code.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
>b/BaseTools/Source/Python/Workspace/DscBuildData.py
>index e45beb3924..2e6eb16b08 100644
>--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
>@@ -2392,11 +2392,11 @@ class DscBuildData(PlatformBuildClassObject):
> skuinfo = Pcd.SkuInfoList[skuname]
> if skuinfo.VariableName:
> for defaultstore in skuinfo.DefaultStoreDict:
> pcddscrawdefaultvalue = 
> self.GetPcdDscRawDefaultValue(Pcd,
>skuname, defaultstore)
> if pcddscrawdefaultvalue:
>-Value = skuinfo[defaultstore]
>+Value = skuinfo.DefaultStoreDict[defaultstore]
> if "{CODE(" in Value:
> realvalue = Value.strip()[6:-2] # 
> "{CODE(").rstrip(")}"
> CApp += "static %s %s_%s_%s_%s_Value%s = 
> %s;\n" %
>(Pcd.BaseDatumType,Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skunam
>e,defaultstore,Demesion,realvalue)
> else:
> pcddscrawdefaultvalue = self.GetPcdDscRawDefaultValue(Pcd,
>skuname, TAB_DEFAULT_STORES_DEFAULT)
>--
>2.20.1.windows.1

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


Re: [edk2] [Patch V2] BaseTool: Fixed incremental rebuild issue.

2019-02-21 Thread Gao, Liming
Reviewed-by: Liming Gao 

>-Original Message-
>From: Feng, Bob C
>Sent: Wednesday, February 20, 2019 11:22 PM
>To: edk2-devel@lists.01.org
>Cc: Feng, Bob C ; Gao, Liming 
>Subject: [Patch V2] BaseTool: Fixed incremental rebuild issue.
>
>BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1540
>
>This issue in introduced by commit
>d943b0c339fe3d35ffdf9f580ccb7a55915c6854
>
>To convert bytes to string, we need to use bytes.decode()
>instead of using str(bytes).
>
>If the source file is not a txt file, ignore that file.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> BaseTools/Source/Python/AutoGen/GenMake.py  | 16 
> .../Source/Python/Workspace/DscBuildData.py | 17 -
> 2 files changed, 16 insertions(+), 17 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
>b/BaseTools/Source/Python/AutoGen/GenMake.py
>index 53c5b8577d..b441817b52 100644
>--- a/BaseTools/Source/Python/AutoGen/GenMake.py
>+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
>@@ -1043,18 +1043,18 @@ cleanlib:
> Fd.close()
> except BaseException as X:
> EdkLogger.error("build", FILE_OPEN_FAILURE, 
> ExtraData=F.Path +
>"\n\t" + str(X))
> if len(FileContent) == 0:
> continue
>-
>-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>-FileContent = FileContent.decode('utf-16')
>-else:
>-try:
>-FileContent = str(FileContent)
>-except:
>-pass
>+try:
>+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>+FileContent = FileContent.decode('utf-16')
>+else:
>+FileContent = FileContent.decode()
>+except:
>+# The file is not txt file. for example .mcb file
>+continue
> IncludedFileList = gIncludePattern.findall(FileContent)
>
> for Inc in IncludedFileList:
> Inc = Inc.strip()
> # if there's macro used to reference header file, expand 
> it
>diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
>b/BaseTools/Source/Python/Workspace/DscBuildData.py
>index 1ffefe6e7e..7221946062 100644
>--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
>@@ -153,19 +153,18 @@ def GetDependencyList(FileStack, SearchPathList):
> Fd.close()
>
> if len(FileContent) == 0:
> continue
>
>-if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>-FileContent = FileContent.decode('utf-16')
>-IncludedFileList = gIncludePattern.findall(FileContent)
>-else:
>-try:
>-FileContent = str(FileContent)
>-IncludedFileList = gIncludePattern.findall(FileContent)
>-except:
>-pass
>+try:
>+if FileContent[0] == 0xff or FileContent[0] == 0xfe:
>+FileContent = FileContent.decode('utf-16')
>+else:
>+FileContent = FileContent.decode()
>+except:
>+# The file is not txt file. for example .mcb file
>+continue
> IncludedFileList = gIncludePattern.findall(FileContent)
>
> for Inc in IncludedFileList:
> Inc = Inc.strip()
> Inc = os.path.normpath(Inc)
>--
>2.18.0.windows.1

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


Re: [edk2] [PATCH 0/3] Add SMM CET support

2019-02-21 Thread Gao, Liming
Acked-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Jiewen Yao
>Sent: Friday, February 22, 2019 12:16 PM
>To: edk2-devel@lists.01.org
>Cc: Dong, Eric ; Gao, Liming ;
>Yao, Jiewen ; Kinney, Michael D
>; Laszlo Ersek 
>Subject: [edk2] [PATCH 0/3] Add SMM CET support
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521
>
>This patch series implement add CET ShadowStack support for SMM.
>
>The CET document can be found at:
>https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-
>enforcement-technology-preview.pdf
>
>Patch 1 adds SSP (ShadowStackPointer) to JUMP_BUFFER.
>Patch 2 adds Control Protection exception (CP#) dump info.
>Patch 3 adds CET ShadowStack support in SMM.
>
>For more detail please refer to each patch.
>
>I also post all update to https://github.com/jyao1/edk2/tree/CET
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Eric Dong 
>Cc: Ray Ni 
>Cc: Laszlo Ersek 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yao Jiewen 
>
>Jiewen Yao (3):
>  MdePkg/BaseLib: Add Shadow Stack Support for X86.
>  UefiCpuPkg/ExceptionLib: Add CET support.
>  UefiCpuPkg/PiSmmCpu: Add Shadow Stack Support for X86 SMM.
>
> MdePkg/Include/Library/BaseLib.h  |   2 +
> MdePkg/Library/BaseLib/Ia32/LongJump.nasm |  18 ++-
> MdePkg/Library/BaseLib/Ia32/SetJump.nasm  |  17 ++-
> MdePkg/Library/BaseLib/X64/LongJump.nasm  |  20 ++-
> MdePkg/Library/BaseLib/X64/SetJump.nasm   |  17 ++-
> .../Include/Library/SmmCpuFeaturesLib.h   |  23 +++-
> .../CpuExceptionCommon.c  |   7 +-
> .../CpuExceptionCommon.h  |   3 +-
> .../Ia32/ArchExceptionHandler.c   |   5 +-
> .../X64/ArchExceptionHandler.c|   5 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm   |  37 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c  |  38 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm  |  98
>++-
> .../PiSmmCpuDxeSmm/Ia32/SmiException.nasm |   6 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c |  57 -
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c |  12 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c|  97
>--
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h| 103
>++-
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf  |   6 +-
> .../PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c   |  85
>-
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c|  18 ++-
> UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h|   4 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c|   4 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm|  38 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c   |  39 +-
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm   | 119
>+-
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c  |  58 -
> UefiCpuPkg/UefiCpuPkg.dec |  13 +-
> 28 files changed, 890 insertions(+), 59 deletions(-)
> create mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm
> create mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm
>
>--
>2.19.2.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] BaseTools:PackageDocumentTools import lib error occurs.

2019-02-21 Thread Fan, ZhijuX
Steps:
 1. Download edk2 tree
 2. Build BaseTools
 3. Go to edk2\BaseTools\Scripts\PackageDocumentTools
to run packagedoc_cli.py

An error occurs if relative imports are used when running
a file alone

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py   |  4 ++--
 .../plugins/EdkPlugins/edk2/model/baseobject.py| 10 +-
 .../PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py  |  4 ++--
 .../plugins/EdkPlugins/edk2/model/doxygengen.py|  8 
 .../plugins/EdkPlugins/edk2/model/doxygengen_spec.py   |  8 
 .../PackageDocumentTools/plugins/EdkPlugins/edk2/model/dsc.py  |  4 ++--
 .../PackageDocumentTools/plugins/EdkPlugins/edk2/model/inf.py  |  4 ++--
 7 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py 
b/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
index e404a07cd7..5c65842a72 100644
--- a/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
+++ b/BaseTools/Scripts/PackageDocumentTools/packagedoc_cli.py
@@ -16,8 +16,8 @@ from __future__ import print_function
 import os, sys, logging, traceback, subprocess
 from optparse import OptionParser
 
-from .plugins.EdkPlugins.edk2.model import baseobject
-from .plugins.EdkPlugins.edk2.model import doxygengen
+from plugins.EdkPlugins.edk2.model import baseobject
+from plugins.EdkPlugins.edk2.model import doxygengen
 
 gArchMarcoDict = {'ALL'  : 'MDE_CPU_IA32 MDE_CPU_X64 MDE_CPU_EBC 
MDE_CPU_IPF _MSC_EXTENSIONS __GNUC__ __INTEL_COMPILER',
   'IA32_MSFT': 'MDE_CPU_IA32 _MSC_EXTENSIONS',
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
index 0159bd5269..de15efd3f8 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
+++ 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/baseobject.py
@@ -10,12 +10,12 @@
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-from ...basemodel import ini
-from ...edk2.model import dsc
-from ...edk2.model import inf
-from ...edk2.model import dec
+from plugins.EdkPlugins.basemodel import ini
+from plugins.EdkPlugins.edk2.model import dsc
+from plugins.EdkPlugins.edk2.model import inf
+from plugins.EdkPlugins.edk2.model import dec
 import os
-from ...basemodel.message import *
+from plugins.EdkPlugins.basemodel.message import *
 
 class SurfaceObject(object):
 _objs = {}
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py
index 3d210f72ac..568076547b 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py
+++ 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/dec.py
@@ -11,9 +11,9 @@
 # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #
 
-from ...basemodel import ini
+from plugins.EdkPlugins.basemodel import ini
 import re, os
-from ...basemodel.message import *
+from plugins.EdkPlugins.basemodel.message import *
 
 class DECFile(ini.BaseINIFile):
 
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
index 9c299fbfc5..e31df262bc 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
+++ 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
@@ -16,7 +16,7 @@
 """This file produce action class to generate doxygen document for edk2 
codebase.
The action classes are shared by GUI and command line tools.
 """
-from ...basemodel import doxygen
+from plugins.EdkPlugins.basemodel import doxygen
 import os
 try:
 import wx
@@ -24,9 +24,9 @@ try:
 except:
 gInGui = False
 import re
-from ...edk2.model import inf
-from ...edk2.model import dec
-from ...basemodel.message import *
+from plugins.EdkPlugins.edk2.model import inf
+from plugins.EdkPlugins.edk2.model import dec
+from plugins.EdkPlugins.basemodel.message import *
 
 _ignore_dir = ['.svn', '_svn', 'cvs']
 _inf_key_description_mapping_table = {
diff --git 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen_spec.py
 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen_spec.py
index 3a862a92ea..279b7fb8d4 100644
--- 
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen_spec.py
+++ 
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen_spec.py
@@ -13,7 +13,7 @@
 # THE 

Re: [edk2] [Patch edk2 Wiki] Add three features for edk2-stable201903

2019-02-21 Thread Gao, Liming
Sorry for confuse. I just realize this patch wrongly remove SMM CET support in 
Q1 planning. This change is not in this patch scope. I will add back it. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Liming Gao
>Sent: Wednesday, February 13, 2019 12:24 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch edk2 Wiki] Add three features for edk2-stable201903
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Liming Gao 
>---
> EDK-II-Release-Planning.md | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning.md
>index f302be3..095da69 100644
>--- a/EDK-II-Release-Planning.md
>+++ b/EDK-II-Release-Planning.md
>@@ -24,7 +24,9 @@
> * [Remove PcdPeiCoreMaxXXX
>PCDs](https://bugzilla.tianocore.org/show_bug.cgi?id=1405)
> * [Remove unused tool logic in BaseTools
>C\Python](https://bugzilla.tianocore.org/show_bug.cgi?id=1350)
> * [BaseTools: Enable component override
>functionality](https://bugzilla.tianocore.org/show_bug.cgi?id=1449)
>-* [SMM CET support](https://bugzilla.tianocore.org/show_bug.cgi?id=1521)
>+* [Support PI1.7
>EFI_PEI_CORE_FV_LOCATION_PPI](https://bugzilla.tianocore.org/show_bug.
>cgi?id=1524)
>+* [Remove unused tool chain configuration in
>tools_def.template](https://bugzilla.tianocore.org/show_bug.cgi?id=1377)
>+* [BaseTools supports to the driver
>combination](https://bugzilla.tianocore.org/show_bug.cgi?id=1520)
> * Standalone MM build of authenticated variable stack (bugzilla link TBD)
> * TBD Bugzilla List
>
>--
>2.13.0.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and fix some bugs

2019-02-21 Thread Rebecca Cran via edk2-devel
Since the scripts in the PosixLike directory are very simple, convert
them to use /bin/sh, and move duplicated code into common files (one for
python scripts, one for C binaries).

Fix some bugs in edksetup.sh and BuildEnv: `test` uses single equals instead
of double equals, and should have a space before the ending bracket. Fix
some indentation, and if the user runs edksetup.sh with --help etc., quit
after displaying the help message.
---
 BaseTools/BinWrappers/PosixLike/BPDG  | 15 ++
 BaseTools/BinWrappers/PosixLike/Brotli| 30 ++-
 .../BinWrappers/PosixLike/BrotliCompress  | 12 
 BaseTools/BinWrappers/PosixLike/DevicePath| 30 ++-
 BaseTools/BinWrappers/PosixLike/Ecc   | 15 ++
 BaseTools/BinWrappers/PosixLike/EfiRom| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenCrc32  | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenDepex  | 15 ++
 BaseTools/BinWrappers/PosixLike/GenFds| 15 ++
 BaseTools/BinWrappers/PosixLike/GenFfs| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFv | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFw | 30 ++-
 .../BinWrappers/PosixLike/GenPatchPcdTable| 15 ++
 BaseTools/BinWrappers/PosixLike/GenSec| 30 ++-
 .../BinWrappers/PosixLike/GenerateCapsule | 15 ++
 BaseTools/BinWrappers/PosixLike/LzmaCompress  | 30 ++-
 .../BinWrappers/PosixLike/LzmaF86Compress |  2 +-
 BaseTools/BinWrappers/PosixLike/PatchPcdValue | 15 ++
 BaseTools/BinWrappers/PosixLike/Pkcs7Sign | 15 ++
 .../PosixLike/Rsa2048Sha256GenerateKeys   | 15 ++
 .../BinWrappers/PosixLike/Rsa2048Sha256Sign   | 15 ++
 BaseTools/BinWrappers/PosixLike/Split | 30 ++-
 BaseTools/BinWrappers/PosixLike/TargetTool| 15 ++
 BaseTools/BinWrappers/PosixLike/TianoCompress | 30 ++-
 BaseTools/BinWrappers/PosixLike/Trim  | 15 ++
 BaseTools/BinWrappers/PosixLike/UPT   | 15 ++
 BaseTools/BinWrappers/PosixLike/VfrCompile| 30 ++-
 BaseTools/BinWrappers/PosixLike/VolInfo   | 30 ++-
 BaseTools/BinWrappers/PosixLike/build | 15 ++
 BaseTools/BinWrappers/PosixLike/common.sh | 12 
 BaseTools/BinWrappers/PosixLike/commonbin.sh  | 28 +
 BaseTools/BuildEnv|  3 +-
 edksetup.sh   | 12 
 33 files changed, 110 insertions(+), 559 deletions(-)
 create mode 100644 BaseTools/BinWrappers/PosixLike/common.sh
 create mode 100644 BaseTools/BinWrappers/PosixLike/commonbin.sh

diff --git a/BaseTools/BinWrappers/PosixLike/BPDG 
b/BaseTools/BinWrappers/PosixLike/BPDG
index c894384908..a9da3afb4b 100755
--- a/BaseTools/BinWrappers/PosixLike/BPDG
+++ b/BaseTools/BinWrappers/PosixLike/BPDG
@@ -1,14 +1,3 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+#!/bin/sh
 
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python
-if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
-dir=$(dirname "$full_cmd")
-cmd=${full_cmd##*/}
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_exe:-python}" -m $cmd.$cmd "$@"
+. "$(dirname "$(realpath "$0")")/common.sh"
diff --git a/BaseTools/BinWrappers/PosixLike/Brotli 
b/BaseTools/BinWrappers/PosixLike/Brotli
index 0945d86d92..3dfa26e517 100755
--- a/BaseTools/BinWrappers/PosixLike/Brotli
+++ b/BaseTools/BinWrappers/PosixLike/Brotli
@@ -1,29 +1,3 @@
-#!/usr/bin/env bash
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
-dir=$(dirname "$full_cmd")
-cmd=${full_cmd##*/}
-
-if [ -n "$WORKSPACE" ] && [ -e "$WORKSPACE/Conf/BaseToolsCBinaries" ]
-then
-  exec "$WORKSPACE/Conf/BaseToolsCBinaries/$cmd"
-elif [ -n "$WORKSPACE" ] && [ -e "$EDK_TOOLS_PATH/Source/C" ]
-then
-  if [ ! -e "$EDK_TOOLS_PATH/Source/C/bin/$cmd" ]
-  then
-echo "BaseTools C Tool binary was not found ($cmd)"
-echo "You may need to run:"
-echo "  make -C $EDK_TOOLS_PATH/Source/C"
-  else
-exec "$EDK_TOOLS_PATH/Source/C/bin/$cmd" "$@"
-  fi
-elif [ -e "$dir/../../Source/C/bin/$cmd" ]
-then
-  exec "$dir/../../Source/C/bin/$cmd" "$@"
-else
-  echo "Unable to find the real '$cmd' to run"
-  echo "This message was printed by"
-  echo "  $0"
-  exit 127
-fi
+#!/bin/sh
 
+. "$(dirname "$(realpath "$0")")/commonbin.sh"
diff --git a/BaseTools/BinWrappers/PosixLike/BrotliCompress 
b/BaseTools/BinWrappers/PosixLike/BrotliCompress
index ea86705a28..7cb26a3659 100755
--- 

[edk2] [PATCH] BaseTools: Convert PosixLike scripts to sh, reduce duplication and fix some bugs in edksetup.sh and BuildEnv

2019-02-21 Thread Rebecca Cran via edk2-devel
To make it easier to use EDK2 on systems other than Linux, where the default 
shell might
not be bash, I'd like to convert the shell scripts to use POSIX sh where 
possible.

edksetup.sh and BuildEnv remain bash scripts, but I hope to convert them to sh 
in a future
changeset.

I did see the argument against using $0 in 
http://mywiki.wooledge.org/BashFAQ/028, but I'm
not sure anyone using EDK2 will run into problems the article describes.

I checked the scripts with shellcheck.


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


[edk2] [PATCH 1/2] ShellPkg/UefiShellAcpiViewCommandLib: Add a description in uni

2019-02-21 Thread Zhichao Gao
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1146

Add DSDT and SSDT description in the help information. Add a
note to clarify the use of -s option with indicated AcpiTable
type parameter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Jaben Carsey 
Cc: Liming Gao 
---
 .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
index 0762eeba53..183f761644 100644
--- 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
+++ 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
@@ -78,6 +78,7 @@
 "   APIC  - Multiple APIC Description Table (MADT)\r\n"
 "   BGRT  - Boot Graphics Resource Table\r\n"
 "   DBG2  - Debug Port Table 2\r\n"
+"   DSDT  - Differentiated System Description Table\r\n"
 "   FACP  - Fixed ACPI Description Table (FADT)\r\n"
 "   GTDT  - Generic Timer Description Table\r\n"
 "   IORT  - IO Remapping Table\r\n"
@@ -87,7 +88,12 @@
 "   SLIT  - System Locality Information Table\r\n"
 "   SPCR  - Serial Port Console Redirection Table\r\n"
 "   SRAT  - System Resource Affinity Table\r\n"
+"   SSDT  - Secondary SystemDescription Table\r\n"
 "   XSDT  - Extended System Description Table\r\n"
+"  3. -s option supports to display the specified AcpiTable type that 
presents\r\n"
+" in the system. The type which is not in the above list would only 
display\r\n"
+" the data and the ACPI table header of it. The type in the above list 
may\r\n"
+" display as the ACPI spec defined, such as the info of RSDP.\r\n"
 " \r\n"
 ".SH STANDARDS\r\n"
 " \r\n"
-- 
2.16.2.windows.1

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


[edk2] [PATCH 2/2] ShellPkg/UefiShellAcpiViewCommandLib: Change the description in uni

2019-02-21 Thread Zhichao Gao
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1153

The '-s' option of 'acpiview' do not support multiply
invocation options. So clarify it for users.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao 
Cc: Ray Ni 
Cc: Jaben Carsey 
Cc: Liming Gao 
---
 .../UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
index 183f761644..abae4424e5 100644
--- 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
+++ 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni
@@ -41,7 +41,8 @@
 ".SH OPTIONS\r\n"
 " \r\n"
 "  -l - Display list of installed ACPI Tables.\r\n"
-"  -s - Display only the specified AcpiTable type.\r\n"
+"  -s - Display only the specified AcpiTable type and only support single\r\n"
+"   invocation option.\r\n"
 " AcpiTable: The required ACPI Table type.\r\n"
 "  -d - Generate a binary file dump of the specified AcpiTable.\r\n"
 "  -c - Consistency checking (enabled by default).\r\n"
-- 
2.16.2.windows.1

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


[edk2] [PATCH 1/3] MdePkg/BaseLib: Add Shadow Stack Support for X86.

2019-02-21 Thread Jiewen Yao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521

This patch adds SSP - shadow stack pointer to JumpBuffer.
It will be used for the platform that enabled CET/ShadowStack.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yao Jiewen 
---
 MdePkg/Include/Library/BaseLib.h  |  2 ++
 MdePkg/Library/BaseLib/Ia32/LongJump.nasm | 18 +-
 MdePkg/Library/BaseLib/Ia32/SetJump.nasm  | 17 -
 MdePkg/Library/BaseLib/X64/LongJump.nasm  | 20 +++-
 MdePkg/Library/BaseLib/X64/SetJump.nasm   | 17 -
 5 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 9c42f82a7d..616ba2e95b 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -31,6 +31,7 @@ typedef struct {
   UINT32Ebp;
   UINT32Esp;
   UINT32Eip;
+  UINT32Ssp;
 } BASE_LIBRARY_JUMP_BUFFER;
 
 #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 4
@@ -54,6 +55,7 @@ typedef struct {
   UINT64Rip;
   UINT64MxCsr;
   UINT8 XmmBuffer[160]; ///< XMM6-XMM15.
+  UINT64Ssp;
 } BASE_LIBRARY_JUMP_BUFFER;
 
 #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 8
diff --git a/MdePkg/Library/BaseLib/Ia32/LongJump.nasm 
b/MdePkg/Library/BaseLib/Ia32/LongJump.nasm
index 7ef03462ee..e0f98c195e 100644
--- a/MdePkg/Library/BaseLib/Ia32/LongJump.nasm
+++ b/MdePkg/Library/BaseLib/Ia32/LongJump.nasm
@@ -1,6 +1,6 @@
 ;--
 ;
-; Copyright (c) 2006, Intel Corporation. All rights reserved.
+; Copyright (c) 2006 - 2019, 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
@@ -31,6 +31,22 @@
 ;--
 global ASM_PFX(InternalLongJump)
 ASM_PFX(InternalLongJump):
+
+mov eax, cr4
+bt  eax, 23; check if CET is enabled
+jnc CetDone
+
+mov edx, [esp + 4] ; edx = JumpBuffer
+mov edx, [edx + 24]; edx = target SSP
+DB  0xF3, 0x0F, 0x1E, 0xC8 ; READSSP EAX
+sub edx, eax   ; eax = delta
+mov eax, edx   ; eax = delta
+
+shr eax, 2 ; eax = delta/sizeof(UINT32)
+DB  0xF3, 0x0F, 0xAE, 0xE8 ; INCSSP EAX
+
+CetDone:
+
 pop eax ; skip return address
 pop edx ; edx <- JumpBuffer
 pop eax ; eax <- Value
diff --git a/MdePkg/Library/BaseLib/Ia32/SetJump.nasm 
b/MdePkg/Library/BaseLib/Ia32/SetJump.nasm
index 6d3a5a25bb..51e0d5351c 100644
--- a/MdePkg/Library/BaseLib/Ia32/SetJump.nasm
+++ b/MdePkg/Library/BaseLib/Ia32/SetJump.nasm
@@ -1,6 +1,6 @@
 ;--
 ;
-; Copyright (c) 2006, Intel Corporation. All rights reserved.
+; Copyright (c) 2006 - 2019, 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,21 @@ ASM_PFX(SetJump):
 pop ecx
 pop ecx ; ecx <- return address
 mov edx, [esp]
+
+xor eax, eax
+mov [edx + 24], eax; save 0 to SSP
+
+mov eax, cr4
+bt  eax, 23; check if CET is enabled
+jnc CetDone
+
+mov eax, 1
+DB  0xF3, 0x0F, 0xAE, 0xE8 ; INCSSP EAX to read original SSP
+DB  0xF3, 0x0F, 0x1E, 0xC8 ; READSSP EAX
+mov [edx + 0x24], eax  ; save SSP
+
+CetDone:
+
 mov [edx], ebx
 mov [edx + 4], esi
 mov [edx + 8], edi
diff --git a/MdePkg/Library/BaseLib/X64/LongJump.nasm 
b/MdePkg/Library/BaseLib/X64/LongJump.nasm
index 3bac27469e..5f3f07da07 100644
--- a/MdePkg/Library/BaseLib/X64/LongJump.nasm
+++ b/MdePkg/Library/BaseLib/X64/LongJump.nasm
@@ -1,6 +1,6 @@
 ;--
 ;
-; Copyright (c) 2006, Intel Corporation. All rights reserved.
+; Copyright (c) 2006 - 2019, 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 

[edk2] [PATCH 2/3] UefiCpuPkg/ExceptionLib: Add CET support.

2019-02-21 Thread Jiewen Yao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521

Add information dump for Control Protection exception.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yao Jiewen 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c| 7 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h| 3 ++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 5 +++--
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c  | 5 +++--
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
index 0576144a97..ca210d1de2 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
@@ -1,7 +1,7 @@
 /** @file
   CPU Exception Handler Library common functions.
 
-  Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2019, 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
@@ -20,7 +20,7 @@
 //
 // 1 means an error code will be pushed, otherwise 0
 //
-CONST UINT32 mErrorCodeFlag = 0x00027d00;
+CONST UINT32 mErrorCodeFlag = 0x00227d00;
 
 //
 // Define the maximum message length
@@ -49,7 +49,8 @@ CONST CHAR8 *mExceptionNameStr[] = {
   "#AC - Alignment Check",
   "#MC - Machine-Check",
   "#XM - SIMD floating-point",
-  "#VE - Virtualization"
+  "#VE - Virtualization",
+  "#CP - Control Protection"
 };
 
 #define EXCEPTION_KNOWN_NAME_NUM  (sizeof (mExceptionNameStr) / sizeof (CHAR8 
*))
diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 83e55ab828..edf46cb60d 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -1,7 +1,7 @@
 /** @file
   Common header file for CPU Exception Handler Library.
 
-  Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2019, 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
@@ -39,6 +39,7 @@
 #define IA32_PF_EC_RSVD BIT3
 #define IA32_PF_EC_ID   BIT4
 #define IA32_PF_EC_PK   BIT5
+#define IA32_PF_EC_SS   BIT6
 #define IA32_PF_EC_SGX  BIT15
 
 #include "ArchInterruptDefs.h"
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
index 531258610a..f3d993af75 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
@@ -1,7 +1,7 @@
 /** @file
   IA32 CPU Exception Handler functons.
 
-  Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2019, 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
@@ -326,13 +326,14 @@ DumpCpuContext (
   );
 if (ExceptionType == EXCEPT_IA32_PAGE_FAULT) {
   InternalPrintMessage (
-"  I:%x R:%x U:%x W:%x P:%x PK:%x S:%x",
+"  I:%x R:%x U:%x W:%x P:%x PK:%x SS:%x SGX:%x",
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID)   != 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_RSVD) != 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_US)   != 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_WR)   != 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_P)!= 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_PK)   != 
0,
+(SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_SS)   != 
0,
 (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_SGX)  != 0
 );
 }
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index d7e883d19a..0183239e59 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
@@ -1,7 +1,7 @@
 /** @file
   x64 

[edk2] [PATCH 3/3] UefiCpuPkg/PiSmmCpu: Add Shadow Stack Support for X86 SMM.

2019-02-21 Thread Jiewen Yao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521

We scan the SMM code with ROPgadget.
http://shell-storm.org/project/ROPgadget/
https://github.com/JonathanSalwan/ROPgadget/tree/master
This tool reports the gadget in SMM driver.

This patch enabled CET ShadowStack for X86 SMM.
If CET is supported, SMM will enable CET ShadowStack.
SMM CET will save the OS CET context at SmmEntry and
restore OS CET context at SmmExit.

Test:
1) test Intel internal platform (x64 only, CET enabled/disabled)
Boot test:
CET supported or not supported CPU
on CET supported platform
  CET enabled/disabled
  PcdCpuSmmCetEnable enabled/disabled
  Single core/Multiple core
  PcdCpuSmmStackGuard enabled/disabled
  PcdCpuSmmProfileEnable enabled/disabled
  PcdCpuSmmStaticPageTable enabled/disabled
CET exception test:
  #CF generated with PcdCpuSmmStackGuard enabled/disabled.
Other exception test:
  #PF for normal stack overflow
  #PF for NX protection
  #PF for RO protection
CET env test:
  Launch SMM in CET enabled/disabled environment (DXE) - no impact to DXE

The test case can be found at
https://github.com/jyao1/SecurityEx/tree/master/ControlFlowPkg

2) test ovmf (both IA32 and X64 SMM, CET disabled only)
test OvmfIa32/Ovmf3264, with -D SMM_REQUIRE.
  qemu-system-x86_64.exe -machine q35,smm=on -smp 4
-serial file:serial.log
-drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd
QEMU emulator version 3.1.0 (v3.1.0-11736-g7a30e7adb0-dirty)

3) not tested
IA32 CET enabled platform

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yao Jiewen 
---
 UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h |  23 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm|  37 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  38 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm   |  98 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.nasm   |   6 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c  |  57 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  12 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  97 ++--
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 103 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   6 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c |  85 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  18 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h |   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c |   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm |  38 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  39 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm| 119 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c   |  58 +-
 UefiCpuPkg/UefiCpuPkg.dec  |  13 ++-
 19 files changed, 808 insertions(+), 47 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
index 4478003467..aec24b5dda 100644
--- a/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/SmmCpuFeaturesLib.h
@@ -1,7 +1,7 @@
 /** @file
 Library that provides CPU specific functions to support the PiSmmCpuDxeSmm 
module.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2019, 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
@@ -160,14 +160,33 @@ SmmCpuFeaturesGetSmiHandlerSize (
   than zero and is called by the CPU that was elected as monarch during System
   Management Mode initialization.
 
+//
+// Append Shadow Stack after normal stack
+//
+// |= SmiStack
+// 
+--+---+
+// | Known Good Stack | Guard Page |SMM Stack | Known Good Shadow 
Stack | Guard Page |SMM Shadow Stack|
+// 
+--+---+
+// |   |PcdCpuSmmStackSize|
  |PcdCpuSmmShadowStackSize|
+// |< StackSize 
->|<- ShadowStackSize 
--->|
+// |   
   |
+// |< Processor N 
--->|
+// | low address (bottom)  
high address (top) |
+

[edk2] [PATCH 0/3] Add SMM CET support

2019-02-21 Thread Jiewen Yao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521

This patch series implement add CET ShadowStack support for SMM.

The CET document can be found at:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

Patch 1 adds SSP (ShadowStackPointer) to JUMP_BUFFER.
Patch 2 adds Control Protection exception (CP#) dump info.
Patch 3 adds CET ShadowStack support in SMM.

For more detail please refer to each patch. 

I also post all update to https://github.com/jyao1/edk2/tree/CET

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yao Jiewen 

Jiewen Yao (3):
  MdePkg/BaseLib: Add Shadow Stack Support for X86.
  UefiCpuPkg/ExceptionLib: Add CET support.
  UefiCpuPkg/PiSmmCpu: Add Shadow Stack Support for X86 SMM.

 MdePkg/Include/Library/BaseLib.h  |   2 +
 MdePkg/Library/BaseLib/Ia32/LongJump.nasm |  18 ++-
 MdePkg/Library/BaseLib/Ia32/SetJump.nasm  |  17 ++-
 MdePkg/Library/BaseLib/X64/LongJump.nasm  |  20 ++-
 MdePkg/Library/BaseLib/X64/SetJump.nasm   |  17 ++-
 .../Include/Library/SmmCpuFeaturesLib.h   |  23 +++-
 .../CpuExceptionCommon.c  |   7 +-
 .../CpuExceptionCommon.h  |   3 +-
 .../Ia32/ArchExceptionHandler.c   |   5 +-
 .../X64/ArchExceptionHandler.c|   5 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm   |  37 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c  |  38 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm  |  98 ++-
 .../PiSmmCpuDxeSmm/Ia32/SmiException.nasm |   6 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c |  57 -
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c |  12 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c|  97 --
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h| 103 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf  |   6 +-
 .../PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c   |  85 -
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c|  18 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h|   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c|   4 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm|  38 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c   |  39 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm   | 119 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c  |  58 -
 UefiCpuPkg/UefiCpuPkg.dec |  13 +-
 28 files changed, 890 insertions(+), 59 deletions(-)
 create mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm
 create mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm

-- 
2.19.2.windows.1

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


Re: [edk2] [Patch edk2 Wiki] Add ATA Security feature set support for edk2-stable201903

2019-02-21 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, February 21, 2019 2:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Gao, Liming 
> Subject: [Patch edk2 Wiki] Add ATA Security feature set support for 
> edk2-stable201903
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  EDK-II-Release-Planning.md | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning.md
> index 095da69..9244fc4 100644
> --- a/EDK-II-Release-Planning.md
> +++ b/EDK-II-Release-Planning.md
> @@ -27,6 +27,7 @@
>  * [Support PI1.7 
> EFI_PEI_CORE_FV_LOCATION_PPI](https://bugzilla.tianocore.org/show_bug.cgi?id=1524)
>  * [Remove unused tool chain configuration in 
> tools_def.template](https://bugzilla.tianocore.org/show_bug.cgi?id=1377)
>  * [BaseTools supports to the driver 
> combination](https://bugzilla.tianocore.org/show_bug.cgi?id=1520)
> +* [Add Security feature set support for ATA 
> devices](https://bugzilla.tianocore.org/show_bug.cgi?id=1529)
>  * Standalone MM build of authenticated variable stack (bugzilla link TBD)
>  * TBD Bugzilla List
> 
> --
> 2.12.0.windows.1

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


Re: [edk2] [PATCH V2] BaseTool/GenC: Fix build error when type is BASE or USER_DEFINED.

2019-02-21 Thread Feng, Bob C
Reviewed-by: Bob Feng  

-Original Message-
From: Yao, Jiewen 
Sent: Thursday, February 21, 2019 9:38 AM
To: edk2-devel@lists.01.org
Cc: Feng, Bob C ; Gao, Liming ; 
Zhu, Yonghong 
Subject: [PATCH V2] BaseTool/GenC: Fix build error when type is BASE or 
USER_DEFINED.

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

=
V2: (Feedback from Liming) Add filter for 1) below:
Only constructor/destructor with BASE type is included here.
The constructor/destructor with PEI/DXE/SMM type is still excluded to keep 
original behavior.

Test: NT32 build and boot successfully.

=

1) The GenC tool does not include the constructor/destructor for USER_DEFINED 
module. It should be included.
Only constructor/destructor with BASE type is included here.
The constructor/destructor with PEI/DXE/SMM type is still excluded to keep 
original behavior.

2) The GenC tool includes the UnloadImage code for BASE module.
It should NOT be included.

3) The GenC tool uses EFI_STATUS and ASSERT_EFI_ERROR for BASE type.
It should use RETURN_STATUS and ASSERT_RETURN_ERROR.

4) The GenC tool miss DebugLib.h for BASE or USER_DEFINED module AutoGen.c. 
Only Base.h is there. It should add Library/DebugLib.h.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao 
---
 BaseTools/Source/Python/AutoGen/GenC.py | 56 ++--
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 9700bf8527..a922464f56 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -684,7 +684,7 @@ ${Function} (
 gLibraryStructorCall = {
 SUP_MODULE_BASE  : TemplateString("""${BEGIN}
   Status = ${Function} ();
-  ASSERT_EFI_ERROR (Status);${END}
+  ASSERT_RETURN_ERROR (Status);${END}
 """),
 
 'PEI'   : TemplateString("""${BEGIN}
@@ -714,7 +714,7 @@ ProcessLibrary${Type}List (
   VOID
   )
 {
-${BEGIN}  EFI_STATUS  Status;
+${BEGIN}  RETURN_STATUS  Status;
 ${FunctionCall}${END}
 }
 """),
@@ -768,7 +768,7 @@ ${FunctionCall}${END}  gBasicHeaderFile = "Base.h"
 
 gModuleTypeHeaderFile = {
-SUP_MODULE_BASE  :   [gBasicHeaderFile],
+SUP_MODULE_BASE  :   [gBasicHeaderFile, "Library/DebugLib.h"],
 SUP_MODULE_SEC   :   ["PiPei.h", "Library/DebugLib.h"],
 SUP_MODULE_PEI_CORE  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeiCoreEntryPoint.h"],
 SUP_MODULE_PEIM  :   ["PiPei.h", "Library/DebugLib.h", 
"Library/PeimEntryPoint.h"],
@@ -782,7 +782,7 @@ gModuleTypeHeaderFile = {
 SUP_MODULE_SMM_CORE  :   ["PiDxe.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/UefiDriverEntryPoint.h"],
 SUP_MODULE_MM_STANDALONE :   ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmDriverEntryPoint.h"],
 SUP_MODULE_MM_CORE_STANDALONE :  ["PiMm.h", "Library/BaseLib.h", 
"Library/DebugLib.h", "Library/StandaloneMmCoreEntryPoint.h"],
-SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile]
+SUP_MODULE_USER_DEFINED  :   [gBasicHeaderFile, "Library/DebugLib.h"]
 }
 
 ## Autogen internal worker macro to define DynamicEx PCD name includes both 
the TokenSpaceGuidName @@ -1345,16 +1345,17 @@ def 
CreateLibraryConstructorCode(Info, AutoGenC, AutoGenH):
 if Lib.ModuleType in [SUP_MODULE_BASE, SUP_MODULE_SEC]:
 
ConstructorPrototypeString.Append(gLibraryStructorPrototype[SUP_MODULE_BASE].Replace(Dict))
 
ConstructorCallingString.Append(gLibraryStructorCall[SUP_MODULE_BASE].Replace(Dict))
-elif Lib.ModuleType in SUP_MODULE_SET_PEI:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['PEI'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['PEI'].Replace(Dict))
-elif Lib.ModuleType in [SUP_MODULE_DXE_CORE, SUP_MODULE_DXE_DRIVER, 
SUP_MODULE_DXE_SMM_DRIVER, SUP_MODULE_DXE_RUNTIME_DRIVER,
-SUP_MODULE_DXE_SAL_DRIVER, 
SUP_MODULE_UEFI_DRIVER, SUP_MODULE_UEFI_APPLICATION, SUP_MODULE_SMM_CORE]:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['DXE'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['DXE'].Replace(Dict))
-elif Lib.ModuleType in [SUP_MODULE_MM_STANDALONE, 
SUP_MODULE_MM_CORE_STANDALONE]:
-
ConstructorPrototypeString.Append(gLibraryStructorPrototype['MM'].Replace(Dict))
-
ConstructorCallingString.Append(gLibraryStructorCall['MM'].Replace(Dict))
+if Info.ModuleType not in [SUP_MODULE_BASE, SUP_MODULE_USER_DEFINED]:
+if Lib.ModuleType in SUP_MODULE_SET_PEI:
+
ConstructorPrototypeString.Append(gLibraryStructorPrototype['PEI'].Replace(Dict))
+
ConstructorCallingString.Append(gLibraryStructorCall['PEI'].Replace(Dict))
+ 

Re: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from Opal driver

2019-02-21 Thread Wu, Hao A
Thanks all,

Series pushed via commits:
94e0dd1afe53d23286968130d836ff0755c17c9b..a3efbc29c45183fe69bcb311c2d974ddc4e7c00a

Best Regards,
Hao Wu


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Thursday, February 21, 2019 8:24 AM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Wu, Hao A; Yao, Jiewen; Zeng, Star; Laszlo Ersek; Zhang, Chao
> B
> Subject: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from
> Opal driver
> 
> The series is also available at:
> https://github.com/hwu25/edk2/tree/opal_remodel_v6
> 
> V6 changes:
> For patch 6, rename driver internal function NvmeCheckHcDevicePath() to
> NvmeIsHcDevicePathValid().
> 
> For patch 7, add more comments for purpose of selective NVM Express
> controller initialization during S3 resume.
> 
> For patch 8:
> * Rename driver internal function AhciCheckHcDevicePath() to
>   AhciIsHcDevicePathValid();
> * Add more comments for purpose of selective port enumeration/
>   initialization on a ATA AHCI controller during S3 resume.
> 
> For patch 6~8, since no functional impact, I still keep the 'Reviewed-by'
> from Eric.
> 
> For patch 13, as suggested by Ray, simplifies the logic within PPI
> notification callback to directly use the PPI instance provided by the
> input parameter of callback function.
> 
> 
> V5 history:
> For patch 11, as suggested by Star:
> * Refine the UpdateLockBox() API description comment to be more precise;
> * Ensure the parameter for macro 'EFI_SIZE_TO_PAGES' is of type 'UINTN';
> 
> Since the changes are minor, I still keep the origin 'Reviewed-by' from
> Ray and the 'Acked-by' tag from Laszlo.
> 
> For patch 12, sync the UpdateLockBox() API description comment with the
> change made in patch 11.
> 
> Since the changes are minor, I still keep the origin 'Reviewed-by' from
> Laszlo an Ray.
> 
> For patch 13, additional handling logic to prevent NULL pointer
> de-reference, just as what has been done in commit
> d72d8561fbe03a64e01c2ad57a93777de4b9ae2f.
> 
> 
> V4 history:
> 
> As suggested by Laszlo, add a new patch to sync the API description
> comment for UpdateLockBox() in file
> "OvmfPkg/Library/LockBoxLib/LockBoxLib.c" with its counterparts in
> MdeModulePkg.
> 
> For patch 13 (compared with patch 12 in V3), minor type refinement in
> structure definition 'OPAL_DEVICE_LOCKBOX_DATA'.
> 
> V3 history:
> 
> For patch 2, reuse the definitions within AtaPassThru protocol header file
> to reduce code duplication.
> 
> For patch 4, add detailed comments to illustrate the content that will be
> stored in the newly introduced LockBox.
> 
> For patch 6, device path validity check refinement within function
> NvmeCheckHcDevicePath().
> 
> For patch 7:
> * Remove a redundant check within function NvmeS3SkipThisController();
> * Replace internal implementation of GetNextDevicePathInstance() with
>   GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.
> 
> For patch 8:
> * Device path validity check refinement within function
>   AhciCheckHcDevicePath();
> * Remove a redundant check within function AhciS3GetEumeratePorts();
> * Replace internal implementation of GetNextDevicePathInstance() with
>   GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.
> 
> For patch 11:
> * Remove the ASSERT() for memory allocation failure. Since error handling
>   codes already exist, no new code is added for this;
> * Refine the codes to only allocate new SMM buffer when the required
>   LockBox size is greater than the size of origin pages allocated;
> * Add additional parameter check for 'Offset' & 'Length' to prevent
>   potential numeric overflow.
> 
> 
> V2 history:
> 
> For patch 8, the new series removes the codes to produce the Block IO PPIs
> from the AhciPei driver.
> 
> The task to produce the Block IO services is out of the scope of BZ-1409
> (actually covered by BZ-1483). And we will later propose seperate patch(s)
> to address this.
> 
> V1 history:
> 
> For the below 2 types of storage device:
> 
> 1. NVM Express devices;
> 2. ATA hard disk devices working under AHCI mode.
> 
> the OpalPassword driver supports auto-unlocking those devices during S3
> resume.
> 
> Current implementation of the OpalPassword driver is handling the device
> initialization (using boot script to restore the host controller PCI
> configuration space also counts) in the PEI phase during S3 resume by
> itself.
> 
> Meanwhile, the NvmExpressPei driver in MdeModulePkg also handles the
> NVME
> device initialization during the PEI phase in order to produce the Block
> IO PPI.
> 
> Moreover, there is a Bugzilla request (BZ-1483) for adding the Block IO
> PPI support for ATA device as well. So there is likely to be an PEI driver
> for ATA device that will handle the ATA device initialization.
> 
> In order to remove code duplication, the series will split the S3 phase
> device initialization related codes out from the OpalPassword driver. And
> let 

[edk2] [PATCH v3 1/2] MdePkg: Implement SCSI commands for Security Protocol In/Out

2019-02-21 Thread Christopher J Zurcher
This patch implements the Security Protocol In and Security Protocol Out
commands in UefiScsiLib to prepare support for the Storage Security
Command Protocol.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher J Zurcher 
---
 MdePkg/Include/IndustryStandard/Scsi.h   |  48 +---
 MdePkg/Include/Library/UefiScsiLib.h | 126 ++-
 MdePkg/Include/Protocol/ScsiIo.h |   9 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 ++-
 4 files changed, 366 insertions(+), 22 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
b/MdePkg/Include/IndustryStandard/Scsi.h
index 213d8acc2d..59509a0256 100644
--- a/MdePkg/Include/IndustryStandard/Scsi.h
+++ b/MdePkg/Include/IndustryStandard/Scsi.h
@@ -1,7 +1,7 @@
 /** @file
   Support for SCSI-2 standard
 
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2019, 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
@@ -169,6 +169,12 @@
 #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
 #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
 
+//
+// Additional commands for Secure Transactions
+//
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_IN  0xa2
+#define EFI_SCSI_OP_SECURITY_PROTOCOL_OUT 0xb5
+
 //
 // SCSI Data Transfer Direction
 //
@@ -178,22 +184,30 @@
 //
 // Peripheral Device Type Definitions
 //
-#define EFI_SCSI_TYPE_DISK  0x00  ///< Direct-access device (e.g. 
magnetic disk)
-#define EFI_SCSI_TYPE_TAPE  0x01  ///< Sequential-access device (e.g. 
magnetic tape)
-#define EFI_SCSI_TYPE_PRINTER   0x02  ///< Printer device
-#define EFI_SCSI_TYPE_PROCESSOR 0x03  ///< Processor device
-#define EFI_SCSI_TYPE_WORM  0x04  ///< Write-once device (e.g. some 
optical disks)
-#define EFI_SCSI_TYPE_CDROM 0x05  ///< CD-ROM device
-#define EFI_SCSI_TYPE_SCANNER   0x06  ///< Scanner device
-#define EFI_SCSI_TYPE_OPTICAL   0x07  ///< Optical memory device (e.g. 
some optical disks)
-#define EFI_SCSI_TYPE_MEDIUMCHANGER 0x08  ///< Medium changer device (e.g. 
jukeboxes)
-#define EFI_SCSI_TYPE_COMMUNICATION 0x09  ///< Communications device
-#define EFI_SCSI_TYPE_ASCIT8_1  0x0A  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-#define EFI_SCSI_TYPE_ASCIT8_2  0x0B  ///< Defined by ASC IT8 (Graphic 
arts pre-press devices)
-//
-// 0Ch - 1Eh are reserved
-//
-#define EFI_SCSI_TYPE_UNKNOWN   0x1F  ///< Unknown or no device type
+#define EFI_SCSI_TYPE_DISK0x00  ///< Direct-access device (e.g. 
magnetic disk)
+#define EFI_SCSI_TYPE_TAPE0x01  ///< Sequential-access device 
(e.g. magnetic tape)
+#define EFI_SCSI_TYPE_PRINTER 0x02  ///< Printer device
+#define EFI_SCSI_TYPE_PROCESSOR   0x03  ///< Processor device
+#define EFI_SCSI_TYPE_WORM0x04  ///< Write-once device (e.g. some 
optical disks)
+#define EFI_SCSI_TYPE_CDROM   0x05  ///< CD/DVD device
+#define EFI_SCSI_TYPE_SCANNER 0x06  ///< Scanner device (obsolete)
+#define EFI_SCSI_TYPE_OPTICAL 0x07  ///< Optical memory device (e.g. 
some optical disks)
+#define EFI_SCSI_TYPE_MEDIUMCHANGER   0x08  ///< Medium changer device (e.g. 
jukeboxes)
+#define EFI_SCSI_TYPE_COMMUNICATION   0x09  ///< Communications device 
(obsolete)
+#define EFI_SCSI_TYPE_A   0x0A  ///< Obsolete
+#define EFI_SCSI_TYPE_B   0x0B  ///< Obsolete
+#define EFI_SCSI_TYPE_RAID0x0C  ///< Storage array controller 
device (e.g., RAID)
+#define EFI_SCSI_TYPE_SES 0x0D  ///< Enclosure services device
+#define EFI_SCSI_TYPE_RBC 0x0E  ///< Simplified direct-access 
device (e.g., magnetic disk)
+#define EFI_SCSI_TYPE_OCRW0x0F  ///< Optical card reader/writer 
device
+#define EFI_SCSI_TYPE_BRIDGE  0x10  ///< Bridge Controller Commands
+#define EFI_SCSI_TYPE_OSD 0x11  ///< Object-based Storage Device
+#define EFI_SCSI_TYPE_AUTOMATION  0x12  ///< Automation/Drive Interface
+#define EFI_SCSI_TYPE_SECURITYMANAGER 0x13  ///< Security manager device
+#define EFI_SCSI_TYPE_RESERVED_LOW0x14  ///< Reserved (low)
+#define EFI_SCSI_TYPE_RESERVED_HIGH   0x1D  ///< Reserved (high)
+#define EFI_SCSI_TYPE_WLUN0x1E  ///< Well known logical unit
+#define EFI_SCSI_TYPE_UNKNOWN 0x1F  ///< Unknown or no device type
 
 //
 // Page Codes for INQUIRY command
diff --git a/MdePkg/Include/Library/UefiScsiLib.h 
b/MdePkg/Include/Library/UefiScsiLib.h
index dbb248972b..594f495d7d 100644
--- a/MdePkg/Include/Library/UefiScsiLib.h
+++ b/MdePkg/Include/Library/UefiScsiLib.h
@@ -5,7 +5,7 @@
   for hard drive, CD and DVD devices that are the most common SCSI boot 
targets used by UEFI platforms.
 

[edk2] [PATCH v3 0/2] Add SCSI Support for Storage Security Command Protocol

2019-02-21 Thread Christopher J Zurcher
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546

V3 changes:
Initialize AlignedBuffer variable in ScsiDiskReceiveData and
ScsiDiskSendData functions. Remove redundant input validation and debug
message in ScsiDiskSendData.

V2 changes:
Split the patch into separate commits for separate packages.

To support RPMB access on UFS devices, support must be added to
the ScsiDiskDxe driver for the Storage Security Command Protocol.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 

Christopher J Zurcher (2):
  MdePkg: Implement SCSI commands for Security Protocol In/Out
  MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
 MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
 MdePkg/Include/Library/UefiScsiLib.h  | 126 +-
 MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 507 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 -
 10 files changed, 1061 insertions(+), 46 deletions(-)

-- 
2.16.2.windows.1

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


[edk2] [PATCH v3 2/2] MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol

2019-02-21 Thread Christopher J Zurcher
This patch implements the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL in the
ScsiDiskDxe driver.

Support is currently limited to the RPMB Well-known LUN for UFS devices.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Christopher J Zurcher 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 +++-
 MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |  14 +-
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 507 +-
 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
 6 files changed, 695 insertions(+), 24 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
index 14010802a8..2122aa4b01 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
@@ -3,7 +3,7 @@
 #  It detects the SCSI disk media and installs Block I/O and Block I/O2 
Protocol on
 #  the device handle.
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, 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
@@ -58,6 +58,7 @@
   gEfiBlockIoProtocolGuid   ## BY_START
   gEfiBlockIo2ProtocolGuid  ## BY_START
   gEfiEraseBlockProtocolGuid## BY_START
+  gEfiStorageSecurityCommandProtocolGuid## BY_START
   gEfiScsiIoProtocolGuid## TO_START
   gEfiScsiPassThruProtocolGuid  ## TO_START
   gEfiExtScsiPassThruProtocolGuid   ## TO_START
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
index bb6232676d..4731258018 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h
@@ -1,7 +1,7 @@
 /** @file
   Header file for SCSI Disk Driver.
 
-Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2019, 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
@@ -28,6 +28,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 
 #include 
@@ -44,6 +45,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define IS_DEVICE_FIXED(a)(a)->FixedDevice ? 1 : 0
 
+#define IS_ALIGNED(addr, size)(((UINTN) (addr) & (size - 1)) == 0)
+
+#define UFS_WLUN_RPMB 0xC4
+
 typedef struct {
   UINT32MaxLbaCnt;
   UINT32MaxBlkDespCnt;
@@ -57,6 +62,8 @@ typedef struct {
 
   EFI_HANDLEHandle;
 
+  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL   StorageSecurity;
+
   EFI_BLOCK_IO_PROTOCOL BlkIo;
   EFI_BLOCK_IO2_PROTOCOLBlkIo2;
   EFI_BLOCK_IO_MEDIABlkIoMedia;
@@ -101,6 +108,7 @@ typedef struct {
 #define SCSI_DISK_DEV_FROM_BLKIO(a)  CR (a, SCSI_DISK_DEV, BlkIo, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_BLKIO2(a)  CR (a, SCSI_DISK_DEV, BlkIo2, 
SCSI_DISK_DEV_SIGNATURE)
 #define SCSI_DISK_DEV_FROM_ERASEBLK(a)  CR (a, SCSI_DISK_DEV, EraseBlock, 
SCSI_DISK_DEV_SIGNATURE)
+#define SCSI_DISK_DEV_FROM_STORSEC(a)  CR (a, SCSI_DISK_DEV, StorageSecurity, 
SCSI_DISK_DEV_SIGNATURE)
 
 #define SCSI_DISK_DEV_FROM_DISKINFO(a) CR (a, SCSI_DISK_DEV, DiskInfo, 
SCSI_DISK_DEV_SIGNATURE)
 
@@ -644,6 +652,151 @@ ScsiDiskEraseBlocks (
   );
 
 
+/**
+  Send a security protocol command to a device that receives data and/or the 
result
+  of one or more commands sent by SendData.
+
+  The ReceiveData function sends a security protocol command to the given 
MediaId.
+  The security protocol command sent is defined by SecurityProtocolId and 
contains
+  the security protocol specific data SecurityProtocolSpecificData. The 
function
+  returns the data from the security protocol command in PayloadBuffer.
+
+  For devices supporting the SCSI command set, the security protocol command 
is sent
+  using the SECURITY PROTOCOL IN command defined in SPC-4.
+
+  If PayloadBufferSize is too small to store the available data from the 
security
+  protocol command, the function shall copy PayloadBufferSize bytes into the
+  PayloadBuffer and return EFI_WARN_BUFFER_TOO_SMALL.
+
+  If PayloadBuffer or PayloadTransferSize is NULL and PayloadBufferSize is 
non-zero,
+  the function shall return EFI_INVALID_PARAMETER.
+
+  If the given MediaId does not support 

Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

2019-02-21 Thread Bi, Dandan
Hi Laszlo,

Thanks for helping fix it.
Reviewed-by: Bi Dandan 


Thanks,
Dandan
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 21, 2019 6:41 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Wu, Hao A ;
> Wang, Jian J ; Ni, Ray ; Sean
> Brogan ; Zeng, Star 
> Subject: [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix
> LoadImage/StartImage status code rep.
> 
> In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there
> may be padding between the DataHeader and ReturnStatus members. The
> REPORT_STATUS_CODE_EX() macro starts populating the structure
> immediately after DataHeader, therefore the source data must provide for
> the padding.
> 
> Extract the BmReportLoadFailure() function from EfiBootManagerBoot(),
> prepare a zero padding (if any) in a temporary
> EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
> REPORT_STATUS_CODE_EX() macro invocation.
> 
> Cc: Dandan Bi 
> Cc: Hao Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Sean Brogan 
> Cc: Star Zeng 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
> Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v3:
> 
> - rename BmReportImageFailure() to BmReportLoadFailure() [Ray]
> 
> - eliminate PaddingStart and PaddingSize; zero out the full ExtendedData
>   struct [Ray]
> 
> - don't pick up Ard's R-b due to the change above being functional in
>   nature
> 
> v2:
> - new in v2
> 
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 65
> ++--
>  2 files changed, 48 insertions(+), 18 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> index 978fbff966f6..0fef63fceedf 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include   #include 
> #include 
> +#include 
>  #include 
> 
>  #include 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 9be1633b7480..02ff354ef6a3 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1667,6 +1667,51 @@ BmIsBootManagerMenuFilePath (
>return FALSE;
>  }
> 
> +/**
> +  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about
> +LoadImage() or
> +  StartImage() failure.
> +
> +  @param[in] ErrorCode  An Error Code in the Software Class, DXE Boot
> +Service Driver Subclass. ErrorCode will be used 
> to
> +compose the Value parameter for status code
> +reporting. Must be one of
> +EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> +EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
> +
> +  @param[in] FailureStatus  The failure status returned by the boot service
> +that should be reported.
> +**/
> +VOID
> +BmReportLoadFailure (
> +  IN UINT32 ErrorCode,
> +  IN EFI_STATUS FailureStatus
> +  )
> +{
> +  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
> +
> +  if (!ReportErrorCodeEnabled ()) {
> +return;
> +  }
> +
> +  ASSERT (
> +(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
> +(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
> +);
> +
> +  ZeroMem (, sizeof (ExtendedData));
> + ExtendedData.ReturnStatus = FailureStatus;
> +
> +  REPORT_STATUS_CODE_EX (
> +(EFI_ERROR_CODE | EFI_ERROR_MINOR),
> +(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
> +0,
> +NULL,
> +NULL,
> + + 1,
> +sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)
> +);
> +}
> +
>  /**
>Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
>also signals the EFI ready to boot event. If the device path for the option
> @@ -1822,15 +1867,7 @@ EfiBootManagerBoot (
>//
>// Report Status Code with the failure status to indicate that the 
> failure to
> load boot option
>//
> -  REPORT_STATUS_CODE_EX (
> -EFI_ERROR_CODE | EFI_ERROR_MINOR,
> -(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
> -0,
> -NULL,
> -NULL,
> -,
> -sizeof (EFI_STATUS)
> -);
> +  BmReportLoadFailure
> (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR,
> + Status);
>BootOption->Status = Status;
>//
>// Destroy the RAM disk
> @@ -1911,15 +1948,7 @@ EfiBootManagerBoot (
>  //
>  // Report Status Code with the failure status to indicate that boot 
> failure
>  //
> -REPORT_STATUS_CODE_EX (
> 

[edk2] [PATCH] IntelSiliconPkg/MicrocodeUpdate: Fix incorrect checksum issue

2019-02-21 Thread Chen A Chen
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020

The same issue has fixed in UefiCpuPkg/Microcode.c file.
Please reference b6f67b4d58b81f12f63f5f8c94cf8af3600297ab
to get more detail information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
---
 .../Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c   | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git 
a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c 
b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
index 9b5757da71..e45c7a8def 100644
--- a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
+++ b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
@@ -390,6 +390,7 @@ VerifyMicrocode (
   UINTN   DataSize;
   UINT32  CurrentRevision;
   PROCESSOR_INFO  *ProcessorInfo;
+  UINT32  InCompleteCheckSum32;
   UINT32  CheckSum32;
   UINTN   ExtendedTableLength;
   UINT32  ExtendedTableCount;
@@ -488,6 +489,10 @@ VerifyMicrocode (
 }
 return EFI_VOLUME_CORRUPTED;
   }
+  InCompleteCheckSum32 = CheckSum32;
+  InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorSignature.Uint32;
+  InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
+  InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
 
   //
   // Check ProcessorSignature/ProcessorFlags
@@ -522,7 +527,10 @@ VerifyMicrocode (
   } else {
 ExtendedTable = (CPU_MICROCODE_EXTENDED_TABLE 
*)(ExtendedTableHeader + 1);
 for (Index = 0; Index < ExtendedTableCount; Index++) {
-  CheckSum32 = CalculateSum32((UINT32 *)ExtendedTable, 
sizeof(CPU_MICROCODE_EXTENDED_TABLE));
+  CheckSum32 = InCompleteCheckSum32;
+  CheckSum32 += ExtendedTable->ProcessorSignature.Uint32;
+  CheckSum32 += ExtendedTable->ProcessorFlag;
+  CheckSum32 += ExtendedTable->Checksum;
   if (CheckSum32 != 0) {
 DEBUG((DEBUG_ERROR, "VerifyMicrocode - The checksum for 
ExtendedTable entry with index 0x%x is incorrect\n", Index));
   } else {
-- 
2.16.2.windows.1

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


[edk2] [PATCH] MdeModulePkg: Rename confusion function name

2019-02-21 Thread Chen A Chen
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1536

To avoid the confusion caused by function name,
rename EfiBootManagerGetNextFullDevicePath to
EfiBootManagerGetNextLoadOptionDevicePath.
As an API function should add EFIAPI prefix for this function.

Cc: Ray Ni 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
---
 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c | 2 +-
 MdeModulePkg/Include/Library/UefiBootManagerLib.h   | 3 ++-
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c| 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
index f6e46cbdb1..4ff69af1b4 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
@@ -355,7 +355,7 @@ GetEfiSysPartitionFromBootOptionFilePath (
   //
   do {
 PreFullPath = CurFullPath;
-CurFullPath = EfiBootManagerGetNextFullDevicePath (DevicePath, 
CurFullPath);
+CurFullPath = EfiBootManagerGetNextLoadOptionDevicePath (DevicePath, 
CurFullPath);
 
 if (PreFullPath != NULL) {
   FreePool (PreFullPath);
diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h 
b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
index 64347ff160..69678a62ca 100644
--- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
+++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
@@ -460,7 +460,8 @@ EfiBootManagerGetBootManagerMenu (
   Caller is responsible to free the memory.
 **/
 EFI_DEVICE_PATH_PROTOCOL *
-EfiBootManagerGetNextFullDevicePath (
+EFIAPI
+EfiBootManagerGetNextLoadOptionDevicePath (
   IN  EFI_DEVICE_PATH_PROTOCOL  *FilePath,
   IN  EFI_DEVICE_PATH_PROTOCOL  *FullPath
   );
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 9be1633b74..d5957db610 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2482,7 +2482,8 @@ EfiBootManagerGetBootManagerMenu (
   Caller is responsible to free the memory.
 **/
 EFI_DEVICE_PATH_PROTOCOL *
-EfiBootManagerGetNextFullDevicePath (
+EFIAPI
+EfiBootManagerGetNextLoadOptionDevicePath (
   IN  EFI_DEVICE_PATH_PROTOCOL  *FilePath,
   IN  EFI_DEVICE_PATH_PROTOCOL  *FullPath
   )
-- 
2.16.2.windows.1

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


Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence

2019-02-21 Thread Wu, Hao A
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: Friday, February 22, 2019 4:57 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Albecki, Mateusz
> Subject: Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix
> eMMC HS400 switch sequence
> 
> Hi Hao A,
> 
> On 2/20/19 2:11 AM, Wu, Hao A wrote:
> > Thanks Mateusz,
> >
> > Reviewed-by: Hao Wu 
> > And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
> 
> I think you mean "pushed 'after' commit
> 68c67d3a2a33261e41ff0123129b4e9759617f71".

Yes, the commit should have been 195f673f6270aaf73dd34b75f1da26451b63c316.
It is my mistake.

> 
> Commit 68c67d3a2a33261e41ff0123129b4e9759617f71 is:
> "BaseTools: Fixed a code bug for Pcd Array", while
> this patch is commited as 195f673f6270aaf73dd34b75f1da26451b63c316.
> 
> Now about this commit 195f673f6270aaf, I think you have an issue with
> your configuration, as the patch author was remplaced from:
> Albecki, Mateusz 
> to:
> Albecki, Mateusz  (FYDIBOHF23SPDLT)/cn=Recipients/cn=Albecki, Mateusz3be>

You are right, there is something wrong with my local settings when
abstracting the patch. Thanks for pointing out.

Best Regards,
Hao Wu

> 
> Regards,
> 
> Phil.
> 
> >
> > Best Regards,
> > Hao Wu
> >
> >
> >> -Original Message-
> >> From: Albecki, Mateusz
> >> Sent: Monday, February 18, 2019 7:12 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Albecki, Mateusz; Wu, Hao A
> >> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC
> HS400
> >> switch sequence
> >>
> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
> >>
> >> In eMMC HS400 switch sequence flow eMMC driver attempted
> >> to execute SEND_STATUS just after switching bus timing to high
> >> speed and before downgrading clock frequency to 52MHz. Since link
> >> was at that time in incorrect state SEND_STATUS was failing which
> >> made driver think switch to HS400 failed.
> >> This change makes driver always change clock frequency after
> >> switching bus timing and before executing SEND_STATUS.
> >>
> >> Cc: Hao Wu 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Albecki Mateusz 
> >> ---
> >>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
> >> +
> >>  1 file changed, 20 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> index 4ef849fd0962..15db8a87a5c4 100644
> >> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> >>  }
> >>
> >>  /**
> >> -  Switch the clock frequency to the specified value.
> >> +  Switch the bus timing and clock frequency.
> >>
> >>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> >> Controller
> >>Simplified Spec 3.0 Figure 3-3 for details.
> >> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
> >>
> >>  **/
> >>  EFI_STATUS
> >> -EmmcSwitchClockFreq (
> >> +EmmcSwitchBusTiming (
> >>IN EFI_PCI_IO_PROTOCOL*PciIo,
> >>IN EFI_SD_MMC_PASS_THRU_PROTOCOL  *PassThru,
> >>IN UINT8  Slot,
> >> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
> >>
> >>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
> >>if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >>  return Status;
> >>}
> >>
> >> -  Status = EmmcSendStatus (PassThru, Slot, Rca, );
> >> -  if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> >> with %r\n", Status));
> >> -return Status;
> >> -  }
> >> -  //
> >> -  // Check the switch operation is really successful or not.
> >> -  //
> >> -  if ((DevStatus & BIT7) != 0) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch
> operation
> >> fails as DevStatus is 0x%08x\n", DevStatus));
> >> -return EFI_DEVICE_ERROR;
> >> -  }
> >>//
> >>// Convert the clock freq unit from MHz to KHz.
> >>//
> >> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
> >>  return Status;
> >>}
> >>
> >> +  Status = EmmcSendStatus (PassThru, Slot, Rca, );
> >> +  if (EFI_ERROR (Status)) {
> >> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Send status fails
> >> with %r\n", Status));
> >> +return Status;
> >> +  }
> >> +  //
> >> +  // Check the switch operation is really successful or not.
> >> +  //
> >> +  if ((DevStatus & BIT7) != 0) {
> >> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: The switch
> operation
> >> fails as DevStatus is 0x%08x\n", DevStatus));
> >> +return EFI_DEVICE_ERROR;
> >> +  }
> >> +
> >>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> >>  Status 

[edk2] Configure bugs.tianocore.org as an alias for bugzilla.tianocore.org?

2019-02-21 Thread Rebecca Cran via edk2-devel
Could we allow people to access the Bugzilla tracker via 
bugs.tianocore.org (in addition to bugzilla.tianocore.org) please?


It looks like .tianocore.org (except www, bugzilla etc.) is 
configured as address 54.245.252.80, which just times out trying to 
access via http or https.



--
Rebecca Cran

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


[edk2] [PATCH] Maintainers.txt: Register myself as OvmfPkg/ArmVirtPkg reviewer

2019-02-21 Thread Philippe Mathieu-Daude
Part of my assignment is to review OVMF and ArmVirt patches,
having my address listed will help me to catch the related
patches.

Signed-off-by: Philippe Mathieu-Daude 
---
 Maintainers.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 7772926b2f..3c17038fab 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -82,6 +82,7 @@ M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Julien Grall 
(Xen modules)
+R: Philippe Mathieu-Daudé 
 
 BaseTools
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -225,6 +226,7 @@ R: Marc-André Lureau 
(TPM2 modules)
 R: Stefan Berger 
(TPM2 modules)
+R: Philippe Mathieu-Daudé 
 S: Maintained
 
 PcAtChipsetPkg
-- 
2.20.1

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


Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence

2019-02-21 Thread Philippe Mathieu-Daudé
Hi Hao A,

On 2/20/19 2:11 AM, Wu, Hao A wrote:
> Thanks Mateusz,
> 
> Reviewed-by: Hao Wu 
> And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.

I think you mean "pushed 'after' commit
68c67d3a2a33261e41ff0123129b4e9759617f71".

Commit 68c67d3a2a33261e41ff0123129b4e9759617f71 is:
"BaseTools: Fixed a code bug for Pcd Array", while
this patch is commited as 195f673f6270aaf73dd34b75f1da26451b63c316.

Now about this commit 195f673f6270aaf, I think you have an issue with
your configuration, as the patch author was remplaced from:
Albecki, Mateusz 
to:
Albecki, Mateusz 

Regards,

Phil.

> 
> Best Regards,
> Hao Wu
> 
> 
>> -Original Message-
>> From: Albecki, Mateusz
>> Sent: Monday, February 18, 2019 7:12 PM
>> To: edk2-devel@lists.01.org
>> Cc: Albecki, Mateusz; Wu, Hao A
>> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400
>> switch sequence
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
>>
>> In eMMC HS400 switch sequence flow eMMC driver attempted
>> to execute SEND_STATUS just after switching bus timing to high
>> speed and before downgrading clock frequency to 52MHz. Since link
>> was at that time in incorrect state SEND_STATUS was failing which
>> made driver think switch to HS400 failed.
>> This change makes driver always change clock frequency after
>> switching bus timing and before executing SEND_STATUS.
>>
>> Cc: Hao Wu 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Albecki Mateusz 
>> ---
>>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
>> +
>>  1 file changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> index 4ef849fd0962..15db8a87a5c4 100644
>> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
>>  }
>>
>>  /**
>> -  Switch the clock frequency to the specified value.
>> +  Switch the bus timing and clock frequency.
>>
>>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
>> Controller
>>Simplified Spec 3.0 Figure 3-3 for details.
>> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>>
>>  **/
>>  EFI_STATUS
>> -EmmcSwitchClockFreq (
>> +EmmcSwitchBusTiming (
>>IN EFI_PCI_IO_PROTOCOL*PciIo,
>>IN EFI_SD_MMC_PASS_THRU_PROTOCOL  *PassThru,
>>IN UINT8  Slot,
>> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
>>
>>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
>>if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to hstiming %d
>> fails with %r\n", HsTiming, Status));
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to hstiming %d
>> fails with %r\n", HsTiming, Status));
>>  return Status;
>>}
>>
>> -  Status = EmmcSendStatus (PassThru, Slot, Rca, );
>> -  if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
>> with %r\n", Status));
>> -return Status;
>> -  }
>> -  //
>> -  // Check the switch operation is really successful or not.
>> -  //
>> -  if ((DevStatus & BIT7) != 0) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
>> fails as DevStatus is 0x%08x\n", DevStatus));
>> -return EFI_DEVICE_ERROR;
>> -  }
>>//
>>// Convert the clock freq unit from MHz to KHz.
>>//
>> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
>>  return Status;
>>}
>>
>> +  Status = EmmcSendStatus (PassThru, Slot, Rca, );
>> +  if (EFI_ERROR (Status)) {
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Send status fails
>> with %r\n", Status));
>> +return Status;
>> +  }
>> +  //
>> +  // Check the switch operation is really successful or not.
>> +  //
>> +  if ((DevStatus & BIT7) != 0) {
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: The switch operation
>> fails as DevStatus is 0x%08x\n", DevStatus));
>> +return EFI_DEVICE_ERROR;
>> +  }
>> +
>>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
>>  Status = mOverride->NotifyPhase (
>>Private->ControllerHandle,
>> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>>}
>>
>>HsTiming = 1;
>> -  Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, 
>> Timing,
>> ClockFreq);
>> +  Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing, ClockFreq);
>>
>>return Status;
>>  }
>> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CLOCK_CTRL, sizeof
>> (ClockCtrl), );
>>
>>HsTiming = 2;
>> -  Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, 
>> Timing,
>> ClockFreq);
>> +  Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing, ClockFreq);
>>if (EFI_ERROR (Status)) {
>>  return Status;
>>}
>> @@ -937,7 +938,7 @@ 

Re: [edk2] [PATCH] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Laszlo Ersek
On 02/21/19 16:21, Julien Grall wrote:
> I don't watch much my Linaro e-mail anymore. So update my e-mail address
> from Linaro to the Arm one.
> 
> Contributed-under: Tianocore Contribution Agreement 1.1
> Signed-off-by: Julien Grall 
> ---
>  Maintainers.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3b2676bc32..1e3fdc1de9 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ ArmVirtPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
> -R: Julien Grall 
> +R: Julien Grall 
>  
>  BaseTools
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -217,7 +217,7 @@ M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
> -R: Julien Grall 
> +R: Julien Grall 
>  S: Maintained
>  
>  PcAtChipsetPkg
> 

Pushed as commit 98fc52c44eee.

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


Re: [edk2] [PATCH v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

2019-02-21 Thread Laszlo Ersek
On 02/21/19 13:28, Laszlo Ersek wrote:
> Previous version:
>   [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036495.html
> 
> Patch #1 in v2 is an iteration of the above. Patch #2 in v2 is new.
> 
> Cc: Andrew Fish 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Marc-André Lureau 
> Cc: Michael D Kinney 
> Cc: Stefan Berger 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (2):
>   Maintainers: add TPM2 reviewers for OvmfPkg
>   Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module
> reviewers
> 
>  Maintainers.txt | 7 +++
>  1 file changed, 7 insertions(+)
> 

Pushed as commit range 98fc52c44eee..94e0dd1afe53.

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


[edk2] [PATCH 2/2] DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

2019-02-21 Thread Ashish Singhal
Add support for 16550 UART to ACPI SPCR table as it is a
supported UART type by HLOS.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c
index 23d3a50..a4654ac 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c
@@ -189,6 +189,8 @@ BuildSpcrTable (
   (SerialPortInfo->PortSubtype !=
   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_SBSA_GENERIC_UART) &&
   (SerialPortInfo->PortSubtype !=
+  EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550) &&
+  (SerialPortInfo->PortSubtype !=
   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_DCC)) {
 Status = EFI_INVALID_PARAMETER;
 DEBUG ((
-- 
2.7.4

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


[edk2] [PATCH 1/2] DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX

2019-02-21 Thread Ashish Singhal
DynamicTableManagerDxe initialization fails if
gEdkiiDynamicTableFactoryProtocolGuid,
gEdkiiConfigurationManagerProtocolGuid and
gEfiAcpiTableProtocolGuid are not already available.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal 
---
 .../Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
index 2aeaf15..fef8b20 100644
--- a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
+++ b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
@@ -46,5 +46,7 @@
   gEdkiiDynamicTableFactoryProtocolGuid
 
 [Depex]
-  gEdkiiConfigurationManagerProtocolGuid
+  gEfiAcpiTableProtocolGuid AND
+  gEdkiiConfigurationManagerProtocolGuid AND
+  gEdkiiDynamicTableFactoryProtocolGuid
 
-- 
2.7.4

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


[edk2] [PATCH edk2-platforms v1 0/4] Platform/ARM: Updates corresponding to Dynamic Tables Framework changes

2019-02-21 Thread Sami Mujawar
The Dynamic tables framework has been updated to incorporated a series of
updates namely:
  * Resolving DEPEX order for modules.
  * Removing GIC Distributor ID

This patch series implement the corresponding changes required in the platform
Configuration Manager.

Note: This patch series is dependent on the patch series:
https://lists.01.org/pipermail/edk2-devel/2019-January/035611.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 

The changes can be seen at:
https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1

The corresponding edk2 code changes can be seen at:
https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1

Sami Mujawar (4):
  Platform/ARM: Juno: Configuration Manager depex
  Platform/ARM: FVP: Configuration Manager depex
  Platform/ARM: FVP: Config Mgr remove GICD ID
  Platform/ARM: Juno: Config Mgr remove GICD ID

 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
  | 1 -
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
  | 1 -
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 4 files changed, 4 insertions(+), 6 deletions(-)

-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH 0/2] DynamicTablesPkg Updates

2019-02-21 Thread Ashish Singhal
DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX

This patch adds appropriate dependencies to DynamicTableManagerDxe.
The initialization function fails if gEdkiiDynamicTableFactoryProtocolGuid
and gEdkiiConfigurationManagerProtocolGuid are not present already. Since
we are not relying on a callback but locating these in initialization, we
should add these dependencies. Towards the end of initialization function
where we build and install ACPI tables, we locate gEfiAcpiTableProtocolGuid
and return a failure is not present. We need to add approriate dependency
for this as well. Adding these proper dependencies would make the code not
rely on drivers forcefully dispatched in a particular order

DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

This patch adds support for 16550 UART in ACPI SPCR table. HLOS support for
this type of UART is already present.

Both the patches have been verified to work on hardware.

Ashish Singhal (2):
  DynamicTablesPkg/DynamicTableManagerDxe: Update DEPEX
  DynamicTablesPkg/AcpiSpcrLibArm: Support 16550 UART.

 .../Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 4 +++-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c  | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
2.7.4

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


[edk2] [PATCH edk2-platforms v1 2/4] Platform/ARM: FVP: Configuration Manager depex

2019-02-21 Thread Sami Mujawar
The Configuration Manager needs to be loaded before
other Dynamic Tables Framework Modules.

Fix the DEPEX section for Configuration Manager Dxe to
remove incorrect dependency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
index 
c4c8f462b8fa8ea718589f2265ae42953ac0a49a..299c61f10f6fe41060d648a6fadcc63c310108a9
 100644
--- 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
+++ 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 # Configuration Manager Dxe
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -76,4 +76,4 @@ [FixedPcd]
 [Pcd]
 
 [Depex]
-  gEdkiiDynamicTableFactoryProtocolGuid
+  TRUE
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH edk2-platforms v1 3/4] Platform/ARM: FVP: Config Mgr remove GICD ID

2019-02-21 Thread Sami Mujawar
According to ACPI 6.2 Specification - Errata A, 'One,
and only one, GIC distributor structure must be present
in the MADT for an ARM based system'. Accordingly the
CM_ARM_GICD_INFO structure has been updated to remove
the GicId field as this value is set to zero by the
MADT generator.

This update reflects the corresponding change required
to the Configuration Manager.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 
Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
66ee79341dfeceff1dc70c32b308056d87b99540..cdde32f6b43e876d8869941b4a11b0da8c72224e
 100644
--- 
a/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -116,7 +116,6 @@ EDKII_PLATFORM_REPOSITORY_INFO VExpressPlatRepositoryInfo = 
{
 
   // GIC Distributor Info
   {
-0,  // UINT32  GicId
 FixedPcdGet64 (PcdGicDistributorBase),  // UINT64  PhysicalBaseAddress
 0,  // UINT32  SystemVectorBase
 3   // UINT8   GicVersion
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH edk2-platforms v1 1/4] Platform/ARM: Juno: Configuration Manager depex

2019-02-21 Thread Sami Mujawar
The Configuration Manager needs to be loaded before
other Dynamic Tables Framework Modules.

Fix the DEPEX section for Configuration Manager Dxe to
remove incorrect dependency.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
index 
1491653ab8fe4d44ce11bdf9116f187cc3edf817..a8ef27108237d5cdf20166cffe7a348ebb2b2b12
 100644
--- 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
+++ 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Configuration Manager Dxe
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -83,4 +83,4 @@ [FixedPcd]
 [Pcd]
 
 [Depex]
-  gEdkiiDynamicTableFactoryProtocolGuid
+  TRUE
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH edk2-platforms v1 4/4] Platform/ARM: Juno: Config Mgr remove GICD ID

2019-02-21 Thread Sami Mujawar
According to ACPI 6.2 Specification - Errata A, 'One,
and only one, GIC distributor structure must be present
in the MADT for an ARM based system'. Accordingly the
CM_ARM_GICD_INFO structure has been updated to remove
the GicId field as this value is set to zero by the
MADT generator.

This update reflects the corresponding change required
to the Configuration Manager.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 
Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
index 
55f0984ee6741f5434dd1ec673281c78e2a576f2..444c1d95af27d938da76e00e41756b800b977589
 100644
--- 
a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
+++ 
b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
@@ -145,7 +145,6 @@ EDKII_PLATFORM_REPOSITORY_INFO 
ArmJunoPlatformRepositoryInfo = {
 
   // GIC Distributor Info
   {
-0,  // UINT32  GicId
 FixedPcdGet64 (PcdGicDistributorBase),  // UINT64  PhysicalBaseAddress
 0,  // UINT32  SystemVectorBase
 2   // UINT8   GicVersion
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH v1 6/6] DynamicTablesPkg: Minor updates and fix typos

2019-02-21 Thread Sami Mujawar
Minor updates to comments and typo fixes. Also removed
unused structure CM_ARM_CPU_INFO_LIST.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 66 
 1 file changed, 55 insertions(+), 11 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
73139eb3273e89205ef9e6bee67b1b842f7f516b..ec31c40449d0658f98a89ce0bb6f604b491f1f34
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -59,6 +59,8 @@ typedef enum ArmObjectID {
 
 /** A structure that describes the
 ARM Boot Architecture flags.
+
+ID: EArmObjBootArchInfo
 */
 typedef struct CmArmBootArchInfo {
   /** This is the ARM_BOOT_ARCH flags field of the FADT Table
@@ -71,13 +73,10 @@ typedef struct CmArmCpuInfo {
   // Reserved for use when SMBIOS tables are implemented
 } CM_ARM_CPU_INFO;
 
-typedef struct CmArmCpuInfoList {
-  UINT32 CpuCount;
-  CM_ARM_CPU_INFO  * CpuInfo;
-} CM_ARM_CPU_INFO_LIST;
-
 /** A structure that describes the
 Power Management Profile Information for the Platform.
+
+ID: EArmObjPowerManagementProfileInfo
 */
 typedef struct CmArmPowerManagementProfileInfo {
   /** This is the Preferred_PM_Profile field of the FADT Table
@@ -88,6 +87,8 @@ typedef struct CmArmPowerManagementProfileInfo {
 
 /** A structure that describes the
 GIC CPU Interface for the Platform.
+
+ID: EArmObjGicCInfo
 */
 typedef struct CmArmGicCInfo {
   /// The GIC CPU Interface number.
@@ -164,6 +165,8 @@ typedef struct CmArmGicCInfo {
 
 /** A structure that describes the
 GIC Distributor information for the Platform.
+
+ID: EArmObjGicDInfo
 */
 typedef struct CmArmGicDInfo {
   /// The Physical Base address for the GIC Distributor.
@@ -184,6 +187,8 @@ typedef struct CmArmGicDInfo {
 
 /** A structure that describes the
 GIC MSI Frame information for the Platform.
+
+ID: EArmObjGicMsiFrameInfo
 */
 typedef struct CmArmGicMsiFrameInfo {
   /// The GIC MSI Frame ID
@@ -207,6 +212,8 @@ typedef struct CmArmGicMsiFrameInfo {
 
 /** A structure that describes the
 GIC Redistributor information for the Platform.
+
+ID: EArmObjGicRedistributorInfo
 */
 typedef struct CmArmGicRedistInfo {
   /** The physical address of a page range
@@ -220,6 +227,8 @@ typedef struct CmArmGicRedistInfo {
 
 /** A structure that describes the
 GIC Interrupt Translation Service information for the Platform.
+
+ID: EArmObjGicItsInfo
 */
 typedef struct CmArmGicItsInfo {
   /// The GIC ITS ID
@@ -231,6 +240,9 @@ typedef struct CmArmGicItsInfo {
 
 /** A structure that describes the
 Serial Port information for the Platform.
+
+ID: EArmObjSerialConsolePortInfo or
+EArmObjSerialDebugPortInfo
 */
 typedef struct CmArmSerialPortInfo {
   /// The physical base address for the serial port
@@ -251,6 +263,8 @@ typedef struct CmArmSerialPortInfo {
 
 /** A structure that describes the
 Generic Timer information for the Platform.
+
+ID: EArmObjGenericTimerInfo
 */
 typedef struct CmArmGenericTimerInfo {
   /// The physical base address for the counter control frame
@@ -286,6 +300,8 @@ typedef struct CmArmGenericTimerInfo {
 
 /** A structure that describes the
 Platform Generic Block Timer Frame information for the Platform.
+
+ID: EArmObjGTBlockTimerFrameInfo
 */
 typedef struct CmArmGTBlockTimerFrameInfo {
   /// The Generic Timer frame number
@@ -321,6 +337,8 @@ typedef struct CmArmGTBlockTimerFrameInfo {
 
 /** A structure that describes the
 Platform Generic Block Timer information for the Platform.
+
+ID: EArmObjPlatformGTBlockInfo
 */
 typedef struct CmArmGTBlockInfo {
   /// The physical base address for the GT Block Timer structure
@@ -335,6 +353,8 @@ typedef struct CmArmGTBlockInfo {
 
 /** A structure that describes the
 SBSA Generic Watchdog information for the Platform.
+
+ID: EArmObjPlatformGenericWatchdogInfo
 */
 typedef struct CmArmGenericWatchdogInfo {
   /// The physical base address of the SBSA Watchdog control frame
@@ -354,6 +374,8 @@ typedef struct CmArmGenericWatchdogInfo {
 
 /** A structure that describes the
 PCI Configuration Space information for the Platform.
+
+ID: EArmObjPciConfigSpaceInfo
 */
 typedef struct CmArmPciConfigSpaceInfo {
   /// The physical base address for the PCI segment
@@ -371,6 +393,8 @@ typedef struct CmArmPciConfigSpaceInfo {
 
 /** A structure that describes the
 Hypervisor Vendor ID information for the Platform.
+
+ID: EArmObjHypervisorVendorIdentity
 */
 typedef struct CmArmHypervisorVendorId {
   /// The hypervisor Vendor ID
@@ -379,6 +403,8 @@ typedef struct CmArmHypervisorVendorId {
 
 /** A structure that describes the
 Fixed feature flags for the Platform.
+
+ID: EArmObjFixedFeatureFlags
 */
 typedef struct CmArmFixedFeatureFlags {
   /// The Fixed feature 

[edk2] [PATCH v1 3/6] DynamicTablesPkg: Add OEM Info

2019-02-21 Thread Sami Mujawar
Added option for OEMs to provide OEM Table ID and
OEM Revision for ACPI tables.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Include/Library/TableHelperLib.h|  4 +--
 DynamicTablesPkg/Include/StandardNameSpaceObjects.h  | 18 
++
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/McfgGenerator.c |  2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c |  2 +-
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c | 26 
++--
 10 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/DynamicTablesPkg/Include/Library/TableHelperLib.h 
b/DynamicTablesPkg/Include/Library/TableHelperLib.h
index 
3c4e1d23d2e6955388ab0b51fb57779f2225beb2..0f872bc3d08bf78e33bd8dab866e7bf57e00cb8c
 100644
--- a/DynamicTablesPkg/Include/Library/TableHelperLib.h
+++ b/DynamicTablesPkg/Include/Library/TableHelperLib.h
@@ -45,7 +45,7 @@ GetCgfMgrInfo (
   @param [in] Generator  Pointer to the ACPI table Generator.
   @param [in,out] AcpiHeader Pointer to the ACPI table header to be
  updated.
-  @param [in] Revision   Revision of the ACPI table.
+  @param [in] AcpiTableInfo  Pointer to the ACPI table info structure.
   @param [in] Length Length of the ACPI table.
 
   @retval EFI_SUCCESS   The ACPI table is updated successfully.
@@ -61,7 +61,7 @@ AddAcpiHeader (
   IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  * CONST CfgMgrProtocol,
   IN  CONST ACPI_TABLE_GENERATOR  * CONST Generator,
   IN OUT  EFI_ACPI_DESCRIPTION_HEADER * CONST AcpiHeader,
-  IN  CONST UINT32Revision,
+  IN  CONST CM_STD_OBJ_ACPI_TABLE_INFO* CONST AcpiTableInfo,
   IN  CONST UINT32Length
   );
 
diff --git a/DynamicTablesPkg/Include/StandardNameSpaceObjects.h 
b/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
index 
4377ee8f785399b02fec824f3a34d2f4ed3b1c01..58503858b27141cf7647a410c4b0b3fa574033de
 100644
--- a/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
@@ -93,6 +93,24 @@ typedef struct CmAStdObjAcpiTableInfo {
   /// Optional pointer to the ACPI table data
   EFI_ACPI_DESCRIPTION_HEADER  * AcpiTableData;
 
+  /// An OEM-supplied string that the OEM uses to identify the particular
+  /// data table. This field is particularly useful when defining a definition
+  /// block to distinguish definition block functions. The OEM assigns each
+  /// dissimilar table a new OEM Table ID.
+  /// This field could be constructed using the SIGNATURE_64() macro.
+  ///   e.g. SIGNATURE_64 ('A','R','M','H','G','T','D','T')
+  /// Note: If this field is not populated (has value of Zero), then the
+  /// Generators shall populate this information using part of the
+  /// CM_STD_OBJ_CONFIGURATION_MANAGER_INFO.OemId field and the
+  /// ACPI table signature.
+  UINT64 OemTableId;
+
+  /// An OEM-supplied revision number. Larger numbers are assumed to be
+  /// newer revisions.
+  /// Note: If this field is not populated (has value of Zero), then the
+  /// Generators shall populate this information using the revision of the
+  /// Configuration Manager (CM_STD_OBJ_CONFIGURATION_MANAGER_INFO.Revision).
+  UINT32 OemRevision;
 } CM_STD_OBJ_ACPI_TABLE_INFO;
 
 /** A structure used to describe the SMBIOS table generators to be invoked.
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
index 
e21e2b660634b1aedce8167b74573694d6df2a3b..697cfc46abaedf34d30abf26e7ebb2b4d271822a
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
@@ -342,7 +342,7 @@ BuildDbg2Table (
  CfgMgrProtocol,
  This,
  (EFI_ACPI_DESCRIPTION_HEADER*),
- AcpiTableInfo->AcpiTableRevision,
+ AcpiTableInfo,
  sizeof (DBG2_TABLE)
  );
   if (EFI_ERROR (Status)) {
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c
index 
62927b51d6d7c1585da1cb0d59785e2382639002..6699901b42a63a152027de59887ed097748ece91
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c
+++ 

[edk2] [PATCH v1 1/6] DynamicTablesPkg: Fix depex and protocol section

2019-02-21 Thread Sami Mujawar
Updated the DynamicTableFactoryDxe and DynamicTableManagerDxe
to setup the correct dependency order. Also updated the
Protocols section to reflect the protocols that are produced
or consumed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf |  
7 ++-
 DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 
11 +++
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf 
b/DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf
index 
740811d0fc0590543a62360e6753eb04fb675d70..02c907c38023e8b44829a38ed93436904d8cf3d3
 100644
--- a/DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf
+++ b/DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Module to manage the list of available table factories.
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -51,10 +51,7 @@ [FixedPcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdMaxCustomDTGenerators
 
 [Protocols]
-  gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
-  gEfiSmbiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
-  gEdkiiConfigurationManagerProtocolGuid
-  gEdkiiDynamicTableFactoryProtocolGuid
+  gEdkiiDynamicTableFactoryProtocolGuid # PRODUCES
 
 [Depex]
   TRUE
diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
index 
2aeaf15b157c0172c9cb073e55d789944a73e2ec..39b10b5536bc341dc253801b8ed7640a8b5d4217
 100644
--- a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
+++ b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 # Module that drives the table generation and installation process.
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -42,9 +42,12 @@ [LibraryClasses]
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
-  gEdkiiConfigurationManagerProtocolGuid
-  gEdkiiDynamicTableFactoryProtocolGuid
+
+  gEdkiiConfigurationManagerProtocolGuid# PROTOCOL ALWAYS_CONSUMED
+  gEdkiiDynamicTableFactoryProtocolGuid # PROTOCOL ALWAYS_CONSUMED
 
 [Depex]
-  gEdkiiConfigurationManagerProtocolGuid
+  gEfiAcpiTableProtocolGuid
+  AND gEdkiiConfigurationManagerProtocolGuid
+  AND gEdkiiDynamicTableFactoryProtocolGuid
 
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH v1 4/6] DynamicTablesPkg: DGB2: Update DBG2_DEBUG_PORT_DDI

2019-02-21 Thread Sami Mujawar
The DBG2_DEBUG_PORT_DDI() macro supports adding only one
Generic Base Address Register. Therefore, removed the
superfluous parameter NumReg and updated the macro to
use DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS which has
a value 1.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
index 
697cfc46abaedf34d30abf26e7ebb2b4d271822a..90380f48da017b257476ee63bcc1beae5efe1d65
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
@@ -97,14 +97,12 @@ typedef struct {
 /** A helper macro used for initializing the debug port device
 information structure.
 
-  @param [in]  NumReg   The number of generic address registers.
   @param [in]  SubType  The DBG Port SubType.
   @param [in]  UartBase The UART port base address.
   @param [in]  UartAddrLen  The UART port address range length.
   @param [in]  UartNameStr  The UART port name string.
 **/
 #define DBG2_DEBUG_PORT_DDI(  \
-  NumReg, \
   SubType,\
   UartBase,   \
   UartAddrLen,\
@@ -116,7 +114,7 @@ typedef struct {
   /* UINT16Length */  \
   sizeof (DBG2_DEBUG_DEVICE_INFORMATION), \
   /* UINT8 NumberofGenericAddressRegisters */ \
-  NumReg, \
+  DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS,   \
   /* UINT16NameSpaceStringLength */   \
   DBG2_NAMESPACESTRING_FIELD_SIZE,\
   /* UINT16NameSpaceStringOffset */   \
@@ -164,7 +162,6 @@ DBG2_TABLE AcpiDbg2 = {
  * Debug port 1
  */
 DBG2_DEBUG_PORT_DDI (
-  DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS,
   0,// {Template}: Serial Port Subtype
   0,// {Template}: Serial Port Base Address
   PL011_UART_LENGTH,
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH v1 2/6] DynamicTablesPkg: Rename enum used for ID Mapping

2019-02-21 Thread Sami Mujawar
Renamed the enum EArmObjIdMapping to EArmObjIdMappingArray
and updated the IORT generator accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h   | 2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
93cb6949f0eb2ac2ad3524494e4a14c7a6fab4b8..2adaa788083e4e15d049f5f6b6312f77f3c02488
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -52,7 +52,7 @@ typedef enum ArmObjectID {
   EArmObjSmmuV3,  ///< 22 - SMMUv3
   EArmObjPmcg,///< 23 - PMCG
   EArmObjGicItsIdentifierArray,   ///< 24 - GIC ITS Identifier Array
-  EArmObjIdMapping,   ///< 25 - ID Mapping
+  EArmObjIdMappingArray,  ///< 25 - ID Mapping Array
   EArmObjSmmuInterruptArray,  ///< 26 - SMMU Interrupt Array
   EArmObjMax
 } EARM_OBJECT_ID;
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
index 
a3ee60664ecbeb1b12b01683f838e11804884daf..b53c4bb47798d4ad441db1fe1b1e5b180e313403
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
@@ -44,7 +44,7 @@ Requirements:
   - EArmObjSmmuV3
   - EArmObjPmcg
   - EArmObjGicItsIdentifierArray
-  - EArmObjIdMapping
+  - EArmObjIdMappingArray
   - EArmObjGicItsIdentifierArray
 */
 
@@ -116,7 +116,7 @@ GET_OBJECT_LIST (
 */
 GET_OBJECT_LIST (
   EObjNameSpaceArm,
-  EArmObjIdMapping,
+  EArmObjIdMappingArray,
   CM_ARM_ID_MAPPING
   );
 
@@ -653,7 +653,7 @@ AddIdMappingArray (
   Generator = (ACPI_IORT_GENERATOR*)This;
 
   // Get the Id Mapping Array
-  Status = GetEArmObjIdMapping (
+  Status = GetEArmObjIdMappingArray (
  CfgMgrProtocol,
  IdMappingToken,
  ,
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH v1 0/6] DynamicTablesPkg: Framework updates and fixes

2019-02-21 Thread Sami Mujawar
This patch series updates the Dynamic Tables Framework to
incorporate the following changes:
  * Fix DEPEX to load modules in correct order.
  * Add options for OEMs to provide OEM Table ID and revision.
  * Update DBG2_DEBUG_PORT_DDI macro to remove unused parameter.
  * Remove GIC Distributor ID field.
  * Minor updates to comments and typo fixes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1

The corresponding edk2-platform code changes can be seen at:
https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1

Sami Mujawar (6):
  DynamicTablesPkg: Fix depex and protocol section
  DynamicTablesPkg: Rename enum used for ID Mapping
  DynamicTablesPkg: Add OEM Info
  DynamicTablesPkg: DGB2: Update DBG2_DEBUG_PORT_DDI
  DynamicTablesPkg: Remove GIC Distributor Id field
  DynamicTablesPkg: Minor updates and fix typos

 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf |  
7 +-
 DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf | 
11 +--
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 
73 +++-
 DynamicTablesPkg/Include/Library/TableHelperLib.h  |  
4 +-
 DynamicTablesPkg/Include/StandardNameSpaceObjects.h| 
18 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c   |  
7 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c   |  
8 +--
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c   |  
6 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/McfgGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c   |  
2 +-
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c   | 
26 +--
 13 files changed, 119 insertions(+), 49 deletions(-)

-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


[edk2] [PATCH v1 5/6] DynamicTablesPkg: Remove GIC Distributor Id field

2019-02-21 Thread Sami Mujawar
According to ACPI 6.2 Specification - Errata A, 'One,
and only one, GIC distributor structure must be present
in the MADT for an ARM based system'. Therefore,
the GIC Distributor ID field in the ACPI MADT GICD
substructure can be set to zero and there is no need
for the Configuration Manager to provide this information.

Update the CM_ARM_GICD_INFO structure to remove the GicId
field. Similarly update the MADT Generator to set the GicId
field in the GICD substructure to zero.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 
---
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h   | 5 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c | 4 +++-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
2adaa788083e4e15d049f5f6b6312f77f3c02488..73139eb3273e89205ef9e6bee67b1b842f7f516b
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -166,9 +166,6 @@ typedef struct CmArmGicCInfo {
 GIC Distributor information for the Platform.
 */
 typedef struct CmArmGicDInfo {
-  /// The GIC Distributor ID.
-  UINT32  GicId;
-
   /// The Physical Base address for the GIC Distributor.
   UINT64  PhysicalBaseAddress;
 
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c
index 
1ee0b9e006bfa00ea5bbf6aa64209dac244c90a0..6b89c3f65d36ff35fcfc81cdffdeae8e4306c976
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c
@@ -192,7 +192,9 @@ AddGICD (
   // UINT16 Reserved
   Gicd->Reserved1 = EFI_ACPI_RESERVED_WORD;
   // UINT32 Identifier
-  Gicd->GicId = GicDInfo->GicId;
+  // One, and only one, GIC distributor structure must be present
+  // in the MADT for an ARM based system
+  Gicd->GicId = 0;
   // UINT64 PhysicalBaseAddress
   Gicd->PhysicalBaseAddress = GicDInfo->PhysicalBaseAddress;
   // UINT32 VectorBase
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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


Re: [edk2] [PATCH v2 1/2] Maintainers: add TPM2 reviewers for OvmfPkg

2019-02-21 Thread Marc-André Lureau
Hi
On Thu, Feb 21, 2019 at 1:28 PM Laszlo Ersek  wrote:
>
> OVMF can be built with a significant amount of TPM2 code now; add
> Marc-André and Stefan as Reviewers for TPM2-related patches.
>
> Keep the list of "R" entries alphabetically sorted.
>
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Leif Lindholm 
> Cc: Marc-André Lureau 
> Cc: Michael D Kinney 
> Cc: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> Reviewed-by: Leif Lindholm 
> Reviewed-by: Stefan Berger 
> Acked-by: Ard Biesheuvel 
> Acked-by: Jordan Justen 

Reviewed-by: Marc-André Lureau 

> ---
>
> Notes:
> v2:
> - pick up feedback tags
> - describe the Reviewership scope, in the format seen under MdeModulePkg
>   [Marc-André]
>
>  Maintainers.txt | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3b2676bc32ea..e45b77039d67 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -218,6 +218,10 @@ M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
>  R: Julien Grall 
> +R: Marc-André Lureau 
> +   (TPM2 modules)
> +R: Stefan Berger 
> +   (TPM2 modules)
>  S: Maintained
>
>  PcAtChipsetPkg
> --
> 2.19.1.3.g30247aa5d201
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Julien Grall

Hi,

On 21/02/2019 16:47, Laszlo Ersek wrote:

On 02/21/19 16:21, Julien Grall wrote:

I don't watch much my Linaro e-mail anymore. So update my e-mail address
from Linaro to the Arm one.

Contributed-under: Tianocore Contribution Agreement 1.1
Signed-off-by: Julien Grall 
---
  Maintainers.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 3b2676bc32..1e3fdc1de9 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -80,7 +80,7 @@ ArmVirtPkg
  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
  M: Laszlo Ersek 
  M: Ard Biesheuvel 
-R: Julien Grall 
+R: Julien Grall 
  
  BaseTools

  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -217,7 +217,7 @@ M: Jordan Justen 
  M: Laszlo Ersek 
  M: Ard Biesheuvel 
  R: Anthony Perard 
-R: Julien Grall 
+R: Julien Grall 
  S: Maintained
  
  PcAtChipsetPkg




Acked-by: Laszlo Ersek 

Ard, I assume we'll push this before my

   [edk2] [PATCH v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

This patch is going to cause conflicts for my series, but I'll resolve
those when I push the series.


Thank you for resolving the conflicts.


Julien: can you please also ACK patch #2 of the series that I reference
above. If you are subscribed to the list with your @arm.com email
address, you should find it at least in your list folder (if not in your
inbox).


It is acked now.

Cheers,

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


Re: [edk2] [PATCH v2 2/2] Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module reviewers

2019-02-21 Thread Laszlo Ersek
On 02/21/19 17:49, Julien Grall wrote:
> Hi Laszlo,
> 
> On 21/02/2019 12:28, Laszlo Ersek wrote:
>> We can use the format introduced under MdeModulePkg to clarify the
>> reviewership scopes a little. This should decrease the review spam that
>> Xen reviewers get.
>>
>> Cc: Andrew Fish 
>> Cc: Anthony Perard 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Julien Grall 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>>  v2:
>>  - new in v2
>>
>>   Maintainers.txt | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/Maintainers.txt b/Maintainers.txt
>> index e45b77039d67..86f80b7d38a0 100644
>> --- a/Maintainers.txt
>> +++ b/Maintainers.txt
>> @@ -81,6 +81,7 @@ W:
>> https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>>   M: Laszlo Ersek 
>>   M: Ard Biesheuvel 
>>   R: Julien Grall 
>> +   (Xen modules)
>>     BaseTools
>>   W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
>> @@ -217,7 +218,9 @@ M: Jordan Justen 
>>   M: Laszlo Ersek 
>>   M: Ard Biesheuvel 
>>   R: Anthony Perard 
>> +   (Xen modules)
>>   R: Julien Grall 
>> +   (Xen modules)
>>   R: Marc-André Lureau 
>>  (TPM2 modules)
>>   R: Stefan Berger 
>>
> 
> Acked-by: Julien Grall 

Thanks!

(For readers not following the other thread: by the time I push this,
Maintainers.txt will refer to Julien's @arm.com email address. I'll
resolve the conflict, and there won't be a mismatch between the text
file contents and Julien's ACK.)

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


Re: [edk2] [PATCH v2 2/2] Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module reviewers

2019-02-21 Thread Julien Grall

Hi Laszlo,

On 21/02/2019 12:28, Laszlo Ersek wrote:

We can use the format introduced under MdeModulePkg to clarify the
reviewership scopes a little. This should decrease the review spam that
Xen reviewers get.

Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
 v2:
 - new in v2

  Maintainers.txt | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index e45b77039d67..86f80b7d38a0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -81,6 +81,7 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
  M: Laszlo Ersek 
  M: Ard Biesheuvel 
  R: Julien Grall 
+   (Xen modules)
  
  BaseTools

  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -217,7 +218,9 @@ M: Jordan Justen 
  M: Laszlo Ersek 
  M: Ard Biesheuvel 
  R: Anthony Perard 
+   (Xen modules)
  R: Julien Grall 
+   (Xen modules)
  R: Marc-André Lureau 
 (TPM2 modules)
  R: Stefan Berger 



Acked-by: Julien Grall 

Cheers,


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


Re: [edk2] [PATCH] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Laszlo Ersek
On 02/21/19 16:21, Julien Grall wrote:
> I don't watch much my Linaro e-mail anymore. So update my e-mail address
> from Linaro to the Arm one.
> 
> Contributed-under: Tianocore Contribution Agreement 1.1
> Signed-off-by: Julien Grall 
> ---
>  Maintainers.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3b2676bc32..1e3fdc1de9 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ ArmVirtPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
> -R: Julien Grall 
> +R: Julien Grall 
>  
>  BaseTools
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -217,7 +217,7 @@ M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
> -R: Julien Grall 
> +R: Julien Grall 
>  S: Maintained
>  
>  PcAtChipsetPkg
> 

Acked-by: Laszlo Ersek 

Ard, I assume we'll push this before my

  [edk2] [PATCH v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

This patch is going to cause conflicts for my series, but I'll resolve
those when I push the series.

Julien: can you please also ACK patch #2 of the series that I reference
above. If you are subscribed to the list with your @arm.com email
address, you should find it at least in your list folder (if not in your
inbox).

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


Re: [edk2] [PATCH] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 16:29, Julien Grall  wrote:
>
> I don't watch much my Linaro e-mail anymore. So update my e-mail address
> from Linaro to the Arm one.
>
> Contributed-under: Tianocore Contribution Agreement 1.1
> Signed-off-by: Julien Grall 

Acked-by: Ard Biesheuvel 

> ---
>  Maintainers.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3b2676bc32..1e3fdc1de9 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ ArmVirtPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
> -R: Julien Grall 
> +R: Julien Grall 
>
>  BaseTools
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -217,7 +217,7 @@ M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
> -R: Julien Grall 
> +R: Julien Grall 
>  S: Maintained
>
>  PcAtChipsetPkg
> --
> 2.11.0
>
> ___
> 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] Maintainers.txt: Update e-mail address for Julien Grall

2019-02-21 Thread Julien Grall
I don't watch much my Linaro e-mail anymore. So update my e-mail address
from Linaro to the Arm one.

Contributed-under: Tianocore Contribution Agreement 1.1
Signed-off-by: Julien Grall 
---
 Maintainers.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 3b2676bc32..1e3fdc1de9 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -80,7 +80,7 @@ ArmVirtPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
 M: Laszlo Ersek 
 M: Ard Biesheuvel 
-R: Julien Grall 
+R: Julien Grall 
 
 BaseTools
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -217,7 +217,7 @@ M: Jordan Justen 
 M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Anthony Perard 
-R: Julien Grall 
+R: Julien Grall 
 S: Maintained
 
 PcAtChipsetPkg
-- 
2.11.0

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


[edk2] [Patch V2] BaseTools: Correct the value assignment for StructurePcd

2019-02-21 Thread Feng, Bob C
This patch is to fix the code bug in StructurePcd overall
value assignment logic. If a Pcd Array size is fixed but the
size of actual value in Dsc or Dec is bigger than the Pcd
array size, the tool will report error about such setting and
stop build.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/Common/Misc.py|   1 +
 .../Python/Workspace/BuildClassObject.py  |  78 ---
 .../Source/Python/Workspace/DecBuildData.py   |   2 +-
 .../Source/Python/Workspace/DscBuildData.py   | 211 ++
 4 files changed, 218 insertions(+), 74 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index c7daf5417c..526aa2dd54 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -40,10 +40,11 @@ from Common.Parsing import GetSplitValueList
 from Common.LongFilePathSupport import OpenLongFilePath as open
 from Common.MultipleWorkspace import MultipleWorkspace as mws
 from CommonDataClass.Exceptions import BadExpression
 from Common.caching import cached_property
 
+ArrayIndex = re.compile("\[\s*[0-9a-fA-FxX]*\s*\]")
 ## Regular expression used to find out place holders in string template
 gPlaceholderPattern = re.compile("\$\{([^$()\s]+)\}", re.MULTILINE | 
re.UNICODE)
 
 ## regular expressions for map file processing
 startPatternGeneral = re.compile("^Start[' ']+Length[' ']+Name[' ']+Class")
diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py 
b/BaseTools/Source/Python/Workspace/BuildClassObject.py
index b82af49236..b50e250cfb 100644
--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
@@ -14,14 +14,16 @@
 from collections import OrderedDict, namedtuple
 from Common.DataType import *
 import collections
 import re
 from collections import OrderedDict
-from Common.Misc import CopyDict
+from Common.Misc import CopyDict,ArrayIndex
 import copy
+import Common.EdkLogger as EdkLogger
+from Common.BuildToolError import OPTION_VALUE_INVALID
 StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_\[\]]*$')
-ArrayIndex = re.compile("\[\s*[0-9a-fA-FxX]*\s*\]")
+
 ## PcdClassObject
 #
 # This Class is used for PcdObject
 #
 # @param object: Inherited from object class
@@ -66,44 +68,62 @@ class PcdClassObject(object):
 self.validateranges = validateranges if validateranges is not None 
else []
 self.validlists = validlists if validlists is not None else []
 self.expressions = expressions if expressions is not None else []
 self.DscDefaultValue = None
 self.DscRawValue = {}
+self.DscRawValueInfo = {}
 if IsDsc:
 self.DscDefaultValue = Value
 self.PcdValueFromComm = ""
 self.PcdValueFromFdf = ""
 self.CustomAttribute = {}
 self.UserDefinedDefaultStoresFlag = UserDefinedDefaultStoresFlag
 self._Capacity = None
 
 @property
 def Capacity(self):
-self._Capacity = []
-dimension = ArrayIndex.findall(self._DatumType)
-for item in dimension:
-maxsize = item.lstrip("[").rstrip("]").strip()
-if not maxsize:
-maxsize = "-1"
-maxsize = str(int(maxsize,16)) if maxsize.startswith(("0x","0X")) 
else maxsize
-self._Capacity.append(maxsize)
-if hasattr(self, "SkuOverrideValues"):
-for sku in self.SkuOverrideValues:
-for defaultstore in self.SkuOverrideValues[sku]:
-fields = self.SkuOverrideValues[sku][defaultstore]
-for demesionattr in fields:
-deme = ArrayIndex.findall(demesionattr)
-for i in range(len(deme)-1):
-if int(deme[i].lstrip("[").rstrip("]").strip()) > 
int(self._Capacity[i]):
-print ("error")
-if hasattr(self,"DefaultValues"):
-for demesionattr in self.DefaultValues:
-deme = ArrayIndex.findall(demesionattr)
-for i in range(len(deme)-1):
-if int(deme[i].lstrip("[").rstrip("]").strip()) > 
int(self._Capacity[i]):
-print ("error")
+if self._Capacity is None:
+self._Capacity = []
+dimension = ArrayIndex.findall(self._DatumType)
+for item in dimension:
+maxsize = item.lstrip("[").rstrip("]").strip()
+if not maxsize:
+maxsize = "-1"
+maxsize = str(int(maxsize,16)) if 
maxsize.startswith(("0x","0X")) else maxsize
+self._Capacity.append(maxsize)
+if hasattr(self, "SkuOverrideValues"):
+for sku in self.SkuOverrideValues:
+for defaultstore in self.SkuOverrideValues[sku]:
+fields = 

Re: [edk2] [PATCH v2 2/2] Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module reviewers

2019-02-21 Thread Anthony PERARD
On Thu, Feb 21, 2019 at 01:28:04PM +0100, Laszlo Ersek wrote:
> We can use the format introduced under MdeModulePkg to clarify the
> reviewership scopes a little. This should decrease the review spam that
> Xen reviewers get.
> 
> Cc: Andrew Fish 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> - new in v2
> 
>  Maintainers.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e45b77039d67..86f80b7d38a0 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -81,6 +81,7 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Julien Grall 
> +   (Xen modules)
>  
>  BaseTools
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -217,7 +218,9 @@ M: Jordan Justen 
>  M: Laszlo Ersek 
>  M: Ard Biesheuvel 
>  R: Anthony Perard 
> +   (Xen modules)
>  R: Julien Grall 
> +   (Xen modules)
>  R: Marc-André Lureau 
> (TPM2 modules)
>  R: Stefan Berger 

Acked-by: Anthony PERARD 

Thanks,

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


Re: [edk2] [PATCH v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 13:28, Laszlo Ersek  wrote:
>
> Previous version:
>   [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036495.html
>
> Patch #1 in v2 is an iteration of the above. Patch #2 in v2 is new.
>
> Cc: Andrew Fish 
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Leif Lindholm 
> Cc: Marc-André Lureau 
> Cc: Michael D Kinney 
> Cc: Stefan Berger 
>
> Thanks,
> Laszlo
>
> Laszlo Ersek (2):
>   Maintainers: add TPM2 reviewers for OvmfPkg
>   Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module
> reviewers
>

Acked-by: Ard Biesheuvel 
  (for the series)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2 1/2] Maintainers: add TPM2 reviewers for OvmfPkg

2019-02-21 Thread Laszlo Ersek
OVMF can be built with a significant amount of TPM2 code now; add
Marc-André and Stefan as Reviewers for TPM2-related patches.

Keep the list of "R" entries alphabetically sorted.

Cc: Andrew Fish 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Leif Lindholm 
Cc: Marc-André Lureau 
Cc: Michael D Kinney 
Cc: Stefan Berger 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Leif Lindholm 
Reviewed-by: Stefan Berger 
Acked-by: Ard Biesheuvel 
Acked-by: Jordan Justen 
---

Notes:
v2:
- pick up feedback tags
- describe the Reviewership scope, in the format seen under MdeModulePkg
  [Marc-André]

 Maintainers.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 3b2676bc32ea..e45b77039d67 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -218,6 +218,10 @@ M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Anthony Perard 
 R: Julien Grall 
+R: Marc-André Lureau 
+   (TPM2 modules)
+R: Stefan Berger 
+   (TPM2 modules)
 S: Maintained
 
 PcAtChipsetPkg
-- 
2.19.1.3.g30247aa5d201


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


[edk2] [PATCH v2 2/2] Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module reviewers

2019-02-21 Thread Laszlo Ersek
We can use the format introduced under MdeModulePkg to clarify the
reviewership scopes a little. This should decrease the review spam that
Xen reviewers get.

Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- new in v2

 Maintainers.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index e45b77039d67..86f80b7d38a0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -81,6 +81,7 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
 M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Julien Grall 
+   (Xen modules)
 
 BaseTools
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
@@ -217,7 +218,9 @@ M: Jordan Justen 
 M: Laszlo Ersek 
 M: Ard Biesheuvel 
 R: Anthony Perard 
+   (Xen modules)
 R: Julien Grall 
+   (Xen modules)
 R: Marc-André Lureau 
(TPM2 modules)
 R: Stefan Berger 
-- 
2.19.1.3.g30247aa5d201

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


[edk2] [PATCH v2 0/2] Maintainers: updates for ArmVirtPkg and OvmfPkg

2019-02-21 Thread Laszlo Ersek
Previous version:
  [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
  https://lists.01.org/pipermail/edk2-devel/2019-February/036495.html

Patch #1 in v2 is an iteration of the above. Patch #2 in v2 is new.

Cc: Andrew Fish 
Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Marc-André Lureau 
Cc: Michael D Kinney 
Cc: Stefan Berger 

Thanks,
Laszlo

Laszlo Ersek (2):
  Maintainers: add TPM2 reviewers for OvmfPkg
  Maintainers: specify the scope for OvmfPkg/ArmVirtPkg Xen module
reviewers

 Maintainers.txt | 7 +++
 1 file changed, 7 insertions(+)

-- 
2.19.1.3.g30247aa5d201

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


[edk2] [PATCH v3 3/5] OvmfPkg/PlatformBootManagerLib: display boot option loading/starting

2019-02-21 Thread Laszlo Ersek
Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

v2:

- Split the OvmfPkg/PlatformBootManagerLib change to a separate patch.

- Drop general messages from PlatformBootManagerAfterConsole(), which
  would report calls of EfiBootManagerRefreshAllBootOption(),
  RemoveStaleFvFileOptions(), and SetBootOrderFromQemu(). Those messages
  weren't really helpful for diagnosing boot problems.

 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 5d9b53bf2d1e..c41aaeef3fc3 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -58,6 +58,7 @@ [LibraryClasses]
   QemuBootOrderLib
   ReportStatusCodeLib
   UefiLib
+  PlatformBmPrintScLib
   Tcg2PhysicalPresenceLib
 
 [Pcd]
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index b2faa797c61b..12303fb0f1f3 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -1542,6 +1543,8 @@ PlatformBootManagerAfterConsole (
 
   RemoveStaleFvFileOptions ();
   SetBootOrderFromQemu ();
+
+  PlatformBmPrintScRegisterHandler ();
 }
 
 /**
-- 
2.19.1.3.g30247aa5d201


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


[edk2] [PATCH v3 4/5] ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE

2019-02-21 Thread Laszlo Ersek
The EFI_RETURN_STATUS_EXTENDED_DATA feature from PI-1.7
() enables platform code
to learn about boot option failures (loading and launching) via status
codes reported by the UEFI Boot Manager.

In commit 59541d41633c, we removed all status code support from
ArmVirtPkg. Reenable that support now, minimally, just to the extent so we
can benefit from the PI-1.7 feature mentioned above:

(1) Include the ReportStatusCodeRouterRuntimeDxe driver.

This driver produces two protocols, EFI_STATUS_CODE_PROTOCOL and
EFI_RSC_HANDLER_PROTOCOL. The former allows DXE phase modules and
runtime modules to report (produce) status codes. The latter allows
the same types of modules to register callbacks for status code
handling (consumption).

(Handler registration  occurs only at boot time. Status codes are
delivered to each handler at runtime as well, unless the handler is
unregistered at ExitBootServices().)

(2) Resolve ReportStatusCodeLib to a non-Null instance, for DXE_DRIVER
modules only. This way DXE_DRIVER modules that use the
REPORT_STATUS_CODE_EX() macro and friends will reach
EFI_STATUS_CODE_PROTOCOL from point (1).

(3) Set PcdReportStatusCodePropertyMask to 3 (the default value is 0).
This causes the REPORT_STATUS_CODE_EX() macro and friends to let
Progress Codes (bit#0) and Error Codes (bit#1) through to point (1).
Debug Codes (bit#2) are filtered out.

(4) Include no driver, for now, that registers any status code handler via
EFI_RSC_HANDLER_PROTOCOL, from point (1). Status codes that reach
ReportStatusCodeRouterRuntimeDxe will be thrown away.

(5) Modify only the ArmVirtQemu* platforms. A status code handler will
be added to "ArmVirtPkg/Library/PlatformBootManagerLib" in the next patch,
and this library instance is not consumed by ArmVirtXen.

Cc: Ard Biesheuvel 
Cc: Julien Grall 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

v2:
- new in v2

 ArmVirtPkg/ArmVirtQemu.dsc   | 10 ++
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 10 ++
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |  5 +
 3 files changed, 25 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8cc31fda7a37..ec97d5a14b3a 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -69,6 +69,9 @@ [LibraryClasses.common]
 [LibraryClasses.common.PEIM]
   
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
 
+[LibraryClasses.common.DXE_DRIVER]
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
@@ -155,6 +158,8 @@ [PcdsFixedAtBuild.common]
   gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
 !endif
 
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|3
+
 [PcdsFixedAtBuild.AARCH64]
   # Clearing BIT0 in this PCD prevents installing a 32-bit SMBIOS entry point,
   # if the entry point version is >= 3.0. AARCH64 OSes cannot assume the
@@ -304,6 +309,11 @@ [Components.common]
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
+  #
+  # Status Code Routing
+  #
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+
   #
   # Platform Driver
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index c3e0c9bf2549..e8c065229b21 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -66,6 +66,9 @@ [LibraryClasses.common]
   PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
 
+[LibraryClasses.common.DXE_DRIVER]
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
@@ -149,6 +152,8 @@ [PcdsFixedAtBuild.common]
   gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
 !endif
 
+  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|3
+
 [PcdsPatchableInModule.common]
   #
   # This will be overridden in the code
@@ -288,6 +293,11 @@ [Components.common]
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 
+  #
+  # Status Code Routing
+  #
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+
   #
   # Platform Driver
   #
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index dc6a0a2bcdc7..098d40b61b15 

[edk2] [PATCH v3 2/5] OvmfPkg: add library to track boot option loading/starting on the console

2019-02-21 Thread Laszlo Ersek
Introduce the Platform Boot Manager Print Status Code Library (for short,
PlatformBmPrintScLib) class for catching and printing the LoadImage() /
StartImage() preparations, and return statuses, that are reported by
UefiBootManagerLib.

In the primary library instance, catch only such status codes that
UefiBootManagerLib reports from the same module that contains
PlatformBmPrintScLib. The intent is to establish a reporting-printing
channel within BdsDxe, between UefiBootManagerLib and
PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
from UiApp's copy of UefiBootManagerLib.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:

- Refresh leading comment on HandleStatusCode(): the highest permitted
  TPL is TPL_CALLBACK. No code change.

- pick up Ard's R-b

v2:

- Split the status code handling to a separate library, so that it's
  easy to reuse in ArmVirtPkg.

- Rework the logic based on
   and
  , and follow Ray's
  advice in
  
:

  - The boot option details are fetched via BootCurrent.

  - For reporting LoadImage() and StartImage() preparations, replace the
originally proposed PcdDebugCodeOsLoaderDetail status code with the
existent (edk2-specific) PcdProgressCodeOsLoaderLoad and
PcdProgressCodeOsLoaderStart status codes.

  - For reporting LoadImage() and StartImage() return values, replace
the originally proposed PcdDebugCodeOsLoaderDetail status code with
the standard EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status codes.

  - For all four kinds of reports, replace the originally proposed "OS
Loader Detail" structure (and GUID) with the recently standardized
EFI_RETURN_STATUS_EXTENDED_DATA structure.

 OvmfPkg/OvmfPkg.dec   |   5 +
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/Include/Library/PlatformBmPrintScLib.h|  41 +++
 OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf |  66 +
 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c  | 310 

 7 files changed, 425 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 7666297cf8f1..e50c6179a249 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -45,6 +45,11 @@ [LibraryClasses]
   #  access.
   PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
 
+  ##  @libraryclass  Register a status code handler for printing the Boot
+  #  Manager's LoadImage() and StartImage() preparations, and
+  #  return codes, to the UEFI console.
+  PlatformBmPrintScLib|Include/Library/PlatformBmPrintScLib.h
+
   ##  @libraryclass  Access QEMU's firmware configuration interface
   #
   QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f9216af479f4..5b885590b275 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -348,6 +348,7 @@ [LibraryClasses.common.DXE_DRIVER]
   UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 1e470de74434..bbf0853ee6b9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -353,6 +353,7 @@ [LibraryClasses.common.DXE_DRIVER]
   UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc 

[edk2] [PATCH v3 5/5] ArmVirtPkg/PlatformBootManagerLib: display boot option loading/starting

2019-02-21 Thread Laszlo Ersek
Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.

Cc: Ard Biesheuvel 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 
---

Notes:
v3:
- pick up Ard's R-b

v2:
- new in v2

 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 1 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 3 +++
 4 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index ec97d5a14b3a..a77d71bcea36 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -58,6 +58,7 @@ [LibraryClasses.common]
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index e8c065229b21..1e5388ae708f 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -58,6 +58,7 @@ [LibraryClasses.common]
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 0cbc82f5d27d..9a8a70379e67 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -50,6 +50,7 @@ [LibraryClasses]
   DevicePathLib
   MemoryAllocationLib
   PcdLib
+  PlatformBmPrintScLib
   PrintLib
   QemuBootOrderLib
   QemuFwCfgLib
diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 534357eff46b..0e8d7501fb1d 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -833,6 +834,8 @@ PlatformBootManagerAfterConsole (
 
   RemoveStaleFvFileOptions ();
   SetBootOrderFromQemu ();
+
+  PlatformBmPrintScRegisterHandler ();
 }
 
 /**
-- 
2.19.1.3.g30247aa5d201

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


[edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

2019-02-21 Thread Laszlo Ersek
In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there may be
padding between the DataHeader and ReturnStatus members. The
REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
after DataHeader, therefore the source data must provide for the padding.

Extract the BmReportLoadFailure() function from EfiBootManagerBoot(),
prepare a zero padding (if any) in a temporary
EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
REPORT_STATUS_CODE_EX() macro invocation.

Cc: Dandan Bi 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Star Zeng 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---

Notes:
v3:

- rename BmReportImageFailure() to BmReportLoadFailure() [Ray]

- eliminate PaddingStart and PaddingSize; zero out the full ExtendedData
  struct [Ray]

- don't pick up Ard's R-b due to the change above being functional in
  nature

v2:
- new in v2

 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 65 ++--
 2 files changed, 48 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h 
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index 978fbff966f6..0fef63fceedf 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 9be1633b7480..02ff354ef6a3 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1667,6 +1667,51 @@ BmIsBootManagerMenuFilePath (
   return FALSE;
 }
 
+/**
+  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about LoadImage() or
+  StartImage() failure.
+
+  @param[in] ErrorCode  An Error Code in the Software Class, DXE Boot
+Service Driver Subclass. ErrorCode will be used to
+compose the Value parameter for status code
+reporting. Must be one of
+EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
+EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
+
+  @param[in] FailureStatus  The failure status returned by the boot service
+that should be reported.
+**/
+VOID
+BmReportLoadFailure (
+  IN UINT32 ErrorCode,
+  IN EFI_STATUS FailureStatus
+  )
+{
+  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
+
+  if (!ReportErrorCodeEnabled ()) {
+return;
+  }
+
+  ASSERT (
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
+);
+
+  ZeroMem (, sizeof (ExtendedData));
+  ExtendedData.ReturnStatus = FailureStatus;
+
+  REPORT_STATUS_CODE_EX (
+(EFI_ERROR_CODE | EFI_ERROR_MINOR),
+(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
+0,
+NULL,
+NULL,
+ + 1,
+sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)
+);
+}
+
 /**
   Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
   also signals the EFI ready to boot event. If the device path for the option
@@ -1822,15 +1867,7 @@ EfiBootManagerBoot (
   //
   // Report Status Code with the failure status to indicate that the 
failure to load boot option
   //
-  REPORT_STATUS_CODE_EX (
-EFI_ERROR_CODE | EFI_ERROR_MINOR,
-(EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
-0,
-NULL,
-NULL,
-,
-sizeof (EFI_STATUS)
-);
+  BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
   BootOption->Status = Status;
   //
   // Destroy the RAM disk
@@ -1911,15 +1948,7 @@ EfiBootManagerBoot (
 //
 // Report Status Code with the failure status to indicate that boot failure
 //
-REPORT_STATUS_CODE_EX (
-  EFI_ERROR_CODE | EFI_ERROR_MINOR,
-  (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
-  0,
-  NULL,
-  NULL,
-  ,
-  sizeof (EFI_STATUS)
-  );
+BmReportLoadFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
   }
   PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32) OptionNumber);
 
-- 
2.19.1.3.g30247aa5d201


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


[edk2] [PATCH v3 0/5] MdeModulePkg, OvmfPkg, ArmVirtPkg: more visible boot progress reporting

2019-02-21 Thread Laszlo Ersek
Repo:   https://github.com/lersek/edk2.git
Branch: boot_diags_v3

Addressing feedback for v2, which was posted at:

  https://lists.01.org/pipermail/edk2-devel/2019-February/036965.html
  20190220081644.8238-1-lersek@redhat.com">http://mid.mail-archive.com/20190220081644.8238-1-lersek@redhat.com

Changes are noted per patch.

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Dandan Bi 
Cc: Hao Wu 
Cc: Jian J Wang 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Ray Ni 
Cc: Sean Brogan 
Cc: Star Zeng 

Thanks!
Laszlo

Laszlo Ersek (5):
  MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code
rep.
  OvmfPkg: add library to track boot option loading/starting on the
console
  OvmfPkg/PlatformBootManagerLib: display boot option loading/starting
  ArmVirtPkg/ArmVirtQemu*: enable minimal Status Code Routing in DXE
  ArmVirtPkg/PlatformBootManagerLib: display boot option
loading/starting

 ArmVirtPkg/ArmVirtQemu.dsc   |  11 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc |   5 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc |  11 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |   3 +
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   1 +
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c |  65 ++--
 MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |   1 +
 OvmfPkg/Include/Library/PlatformBmPrintScLib.h   |  41 +++
 OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf|  66 
+
 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c | 310 

 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |   3 +
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf|   1 +
 OvmfPkg/OvmfPkg.dec  |   5 +
 OvmfPkg/OvmfPkgIa32.dsc  |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   1 +
 OvmfPkg/OvmfPkgX64.dsc   |   1 +
 16 files changed, 508 insertions(+), 18 deletions(-)
 create mode 100644 OvmfPkg/Include/Library/PlatformBmPrintScLib.h
 create mode 100644 
OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
 create mode 100644 OvmfPkg/Library/PlatformBmPrintScLib/StatusCodeHandler.c

-- 
2.19.1.3.g30247aa5d201

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


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 10:33, Zeng, Star  wrote:
>
> On 2019/2/21 17:11, Ard Biesheuvel wrote:
> > On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:
> >>
> >> On 02/20/19 13:23, Ard Biesheuvel wrote:
> >>> On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  
> >>> wrote:
> 
>  hi Ard,
>  On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
>   wrote:
> >
> > Hello Jagadeesh,
> >
> > On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  
> > wrote:
> >>
> >> In preparation for providing a standalone MM based non-secure variable
> >> runtime driver, factor out some portions that are specific to the
> >> traditional driver, mainly related to locating variable arch protocol
> >> and variable write arch protocol, which are not required to be located
> >> when using standalone MM based secure variable implementation.
> >>
> >
> > While i think this change is correct from a technical perspective, I
> > don't think this is the right approach.
> >
>  these changes are mandatory, this is one of the possible solution.
> 
> > It was a deliberate decision to expose the MM services in a way that
> > only the producer of the communication protocol is aware of the
> > implementation details, i.e., whether it is backed by tradtional MM or
> > standalone MM.
> >
>  can you please provide more details on how "exposing the MM services"
>  will help to resolve the issue here. if this helps, definitely i will 
>  use that.
> 
> >>>
> >>> Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> >>> and ask them their opinion.
> >>>
> >>> Currently, the DXE runtime driver that produces the architectural
> >>> varstore protocols that are based on communication with MM components
> >>> living elsewhere, rely on the EFI protocol database for sequencing.
> >>> I.e., after dispatch, they wait for certain protocols to be installed
> >>> into the DXE protocol database by the SMM drivers before proceeding to
> >>> install the variable arch protocols.
> >>>
> >>> This does not work for standalone MM, since it has no access to the
> >>> DXE protocol database, nor is it needed, since it may be assumed that
> >>> the MM execution context is fully configured by the time the DXE phase
> >>> starts.
> >>>
> >>> Jagadeesh's proposal is to factor this out, and create two different
> >>> .INFs to build the same DXE runtime driver in two different ways. This
> >>> defeats the purpose of having an abstract MM communication protocol,
> >>> so it is something I would like to avoid. On the other hand, is it not
> >>> obvious how to parameterize this requirement in another way.
> >>>
> >>> For the moment, I could live with putting this into a library, and
> >>> leave it up to the platform to ensure the combination of the library
> >>> resolution with the driver that produces the MM communicate protocol
> >>> is a sane one.
> >>>
> >>> Any thoughts?
> >>
> >> I think I'm missing the gist of the library approach; still, would it be
> >> possible for affected platforms (i.e. those that depend on standalone
> >> MM) to procude the necessary DXE protocols (for unblocking the variable
> >> runtime driver) in a platform DXE driver?
> >>
> >
> > Yes, that is the other option: we could create a library that
> > unconditionally produces those protocols and hook it into the MM
> > communication driver via NULL library class resolution.
> >
>
> I am not familiar with standalone MM, either ARM. So may have no much
> valuable opinion.
>
> For this case, standalone MM could not install DXE protocols into DXE
> protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need
> another way to install the DXE protocols, right?

Yes

> Could standalone MM assume the MM handler for variable is ready when MM
> communication driver runs?

Yes

> If yes, a NULL library instance should work (as a stub to install the
> DXE protocols in its constructor). :)
>

Yes, that was my suggestion.

So Jagadeesh, could you please take this approach instead?

- Create a library in StandaloneMmPkg with LIBRARY_CLASS = NULL and a
constructor that installs the two protocols.
- Update your platform so that the MM communication driver is included as

ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
  
NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
}

I don't think this will violate any ordering constraints, given that
the drivers that have a dependency on these protocols also have a
dependency on the MM communicate driver itself.

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


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Zeng, Star

On 2019/2/21 17:11, Ard Biesheuvel wrote:

On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:


On 02/20/19 13:23, Ard Biesheuvel wrote:

On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:


hi Ard,
On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
 wrote:


Hello Jagadeesh,

On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  wrote:


In preparation for providing a standalone MM based non-secure variable
runtime driver, factor out some portions that are specific to the
traditional driver, mainly related to locating variable arch protocol
and variable write arch protocol, which are not required to be located
when using standalone MM based secure variable implementation.



While i think this change is correct from a technical perspective, I
don't think this is the right approach.


these changes are mandatory, this is one of the possible solution.


It was a deliberate decision to expose the MM services in a way that
only the producer of the communication protocol is aware of the
implementation details, i.e., whether it is backed by tradtional MM or
standalone MM.


can you please provide more details on how "exposing the MM services"
will help to resolve the issue here. if this helps, definitely i will use that.



Let me rephrase this for the benefit of the MdeModulePkg maintainers,
and ask them their opinion.

Currently, the DXE runtime driver that produces the architectural
varstore protocols that are based on communication with MM components
living elsewhere, rely on the EFI protocol database for sequencing.
I.e., after dispatch, they wait for certain protocols to be installed
into the DXE protocol database by the SMM drivers before proceeding to
install the variable arch protocols.

This does not work for standalone MM, since it has no access to the
DXE protocol database, nor is it needed, since it may be assumed that
the MM execution context is fully configured by the time the DXE phase
starts.

Jagadeesh's proposal is to factor this out, and create two different
.INFs to build the same DXE runtime driver in two different ways. This
defeats the purpose of having an abstract MM communication protocol,
so it is something I would like to avoid. On the other hand, is it not
obvious how to parameterize this requirement in another way.

For the moment, I could live with putting this into a library, and
leave it up to the platform to ensure the combination of the library
resolution with the driver that produces the MM communicate protocol
is a sane one.

Any thoughts?


I think I'm missing the gist of the library approach; still, would it be
possible for affected platforms (i.e. those that depend on standalone
MM) to procude the necessary DXE protocols (for unblocking the variable
runtime driver) in a platform DXE driver?



Yes, that is the other option: we could create a library that
unconditionally produces those protocols and hook it into the MM
communication driver via NULL library class resolution.



I am not familiar with standalone MM, either ARM. So may have no much 
valuable opinion.


For this case, standalone MM could not install DXE protocols into DXE 
protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need 
another way to install the DXE protocols, right?
Could standalone MM assume the MM handler for variable is ready when MM 
communication driver runs?
If yes, a NULL library instance should work (as a stub to install the 
DXE protocols in its constructor). :)



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


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Ard Biesheuvel
On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek  wrote:
>
> On 02/20/19 13:23, Ard Biesheuvel wrote:
> > On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:
> >>
> >> hi Ard,
> >> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
> >>  wrote:
> >>>
> >>> Hello Jagadeesh,
> >>>
> >>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  
> >>> wrote:
> 
>  In preparation for providing a standalone MM based non-secure variable
>  runtime driver, factor out some portions that are specific to the
>  traditional driver, mainly related to locating variable arch protocol
>  and variable write arch protocol, which are not required to be located
>  when using standalone MM based secure variable implementation.
> 
> >>>
> >>> While i think this change is correct from a technical perspective, I
> >>> don't think this is the right approach.
> >>>
> >> these changes are mandatory, this is one of the possible solution.
> >>
> >>> It was a deliberate decision to expose the MM services in a way that
> >>> only the producer of the communication protocol is aware of the
> >>> implementation details, i.e., whether it is backed by tradtional MM or
> >>> standalone MM.
> >>>
> >> can you please provide more details on how "exposing the MM services"
> >> will help to resolve the issue here. if this helps, definitely i will use 
> >> that.
> >>
> >
> > Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> > and ask them their opinion.
> >
> > Currently, the DXE runtime driver that produces the architectural
> > varstore protocols that are based on communication with MM components
> > living elsewhere, rely on the EFI protocol database for sequencing.
> > I.e., after dispatch, they wait for certain protocols to be installed
> > into the DXE protocol database by the SMM drivers before proceeding to
> > install the variable arch protocols.
> >
> > This does not work for standalone MM, since it has no access to the
> > DXE protocol database, nor is it needed, since it may be assumed that
> > the MM execution context is fully configured by the time the DXE phase
> > starts.
> >
> > Jagadeesh's proposal is to factor this out, and create two different
> > .INFs to build the same DXE runtime driver in two different ways. This
> > defeats the purpose of having an abstract MM communication protocol,
> > so it is something I would like to avoid. On the other hand, is it not
> > obvious how to parameterize this requirement in another way.
> >
> > For the moment, I could live with putting this into a library, and
> > leave it up to the platform to ensure the combination of the library
> > resolution with the driver that produces the MM communicate protocol
> > is a sane one.
> >
> > Any thoughts?
>
> I think I'm missing the gist of the library approach; still, would it be
> possible for affected platforms (i.e. those that depend on standalone
> MM) to procude the necessary DXE protocols (for unblocking the variable
> runtime driver) in a platform DXE driver?
>

Yes, that is the other option: we could create a library that
unconditionally produces those protocols and hook it into the MM
communication driver via NULL library class resolution.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol

2019-02-21 Thread Laszlo Ersek
On 02/20/19 13:23, Ard Biesheuvel wrote:
> On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja  wrote:
>>
>> hi Ard,
>> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel
>>  wrote:
>>>
>>> Hello Jagadeesh,
>>>
>>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja  wrote:

 In preparation for providing a standalone MM based non-secure variable
 runtime driver, factor out some portions that are specific to the
 traditional driver, mainly related to locating variable arch protocol
 and variable write arch protocol, which are not required to be located
 when using standalone MM based secure variable implementation.

>>>
>>> While i think this change is correct from a technical perspective, I
>>> don't think this is the right approach.
>>>
>> these changes are mandatory, this is one of the possible solution.
>>
>>> It was a deliberate decision to expose the MM services in a way that
>>> only the producer of the communication protocol is aware of the
>>> implementation details, i.e., whether it is backed by tradtional MM or
>>> standalone MM.
>>>
>> can you please provide more details on how "exposing the MM services"
>> will help to resolve the issue here. if this helps, definitely i will use 
>> that.
>>
> 
> Let me rephrase this for the benefit of the MdeModulePkg maintainers,
> and ask them their opinion.
> 
> Currently, the DXE runtime driver that produces the architectural
> varstore protocols that are based on communication with MM components
> living elsewhere, rely on the EFI protocol database for sequencing.
> I.e., after dispatch, they wait for certain protocols to be installed
> into the DXE protocol database by the SMM drivers before proceeding to
> install the variable arch protocols.
> 
> This does not work for standalone MM, since it has no access to the
> DXE protocol database, nor is it needed, since it may be assumed that
> the MM execution context is fully configured by the time the DXE phase
> starts.
> 
> Jagadeesh's proposal is to factor this out, and create two different
> .INFs to build the same DXE runtime driver in two different ways. This
> defeats the purpose of having an abstract MM communication protocol,
> so it is something I would like to avoid. On the other hand, is it not
> obvious how to parameterize this requirement in another way.
> 
> For the moment, I could live with putting this into a library, and
> leave it up to the platform to ensure the combination of the library
> resolution with the driver that produces the MM communicate protocol
> is a sane one.
> 
> Any thoughts?

I think I'm missing the gist of the library approach; still, would it be
possible for affected platforms (i.e. those that depend on standalone
MM) to procude the necessary DXE protocols (for unblocking the variable
runtime driver) in a platform DXE driver?

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


Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option

2019-02-21 Thread Laszlo Ersek
On 02/20/19 18:19, Doran, Mark wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, February 20, 2019 1:25 AM
>> To: Ni, Ray ; Bi, Dandan 
>> Cc: edk2-devel@lists.01.org; Wu, Hao A ; Doran, Mark
>> 
>> Subject: Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when
>> fail to load/start boot option
>>
>> +Mark, for my comments on the process
> 
> Thank you :)
>  
>> On 02/20/19 03:21, Ni, Ray wrote:
>>> Laszlo,
>>> Thanks for catching this.
>>>
>>> GenPerformMemoryTest() in
>>> MdeModulePkg\Universal\MemoryTest\GenericMemoryTestDxe\LightMemoryTest
>>> .c uses the same technics as you suggested.
>>>
>>> I give up to propose another option: having pack(1) for the new status
>> structure.
>>
>> I think that byte-packing EFI_RETURN_STATUS_EXTENDED_DATA in the PI-1.7
>> spec would have been viable, but we should have thought about that in
>> advance. The PI and UEFI specs require natural alignment for structure
>> members, unless stated otherwise. There *are* a number of examples of
>> "stated otherwise" (the term that the specs use is frequently "byte-packed
>> structure"). Again, we should have thought of that in advance, before PI-
>> 1.7 was released, so now we can only fix the way the object is populated.
> 
> Agreed.
>  
>> More generally, I think this demonstrates a flaw in the standardization
>> process. PIWG and USWG should only standardize existing practice; that is,
>> features that have at least one functional implementation. (Not necessarily
>> open source, but the interfaces should be battle-hardened
>> *first*.) The restriction where we can't even propose patches for edk2
>> before the standards are updated is very counter-productive. There's
>> practically zero chance for getting an actual implementation peer-reviewed
>> and peer-tested before proposing the API for the standard.
>>
>> Personally I have suggested in the past to implement some new features as
>> edk2 extensions first, and once they work, to upstream them to the
>> standards. This idea is usually rejected by maintainers, because
>> maintainers worry about becoming stuck with more and more edk2 extensions
>> to core code (i.e., they worry about the feature proponents not making good
>> on their promise to standardize). Unfortunately, the alternative (= the
>> current practice) is that we standardize speculative interfaces, which then
>> prove suboptimal once we implement them.
> 
> So personally I'm a big believer in having working code for things we write 
> down in the standards.  When EFI was first drafted that's how we did it: what 
> was then known as "the sample implementation" and the actual spec content 
> were more or less developed in parallel and the spec wasn't done until the 
> code was working satisfactorily.  We got away from that largely because when 
> the UEFI Forum was formed, there was nominal interest in promoting more than 
> one implementation and keeping spec and code requirements separate was a part 
> of that.
> 
> Recent changes, particularly inside Intel, present an opportunity for us to 
> revisit this issue.  I'm advocating for the approach of spec-follows-code for 
> new Contributions that Intel will make to the open source project going 
> forward.  I'll have more to say about this at upcoming industry events.
> 

Sounds fantastic! Thank you!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

2019-02-21 Thread Laszlo Ersek
On 02/20/19 14:17, Ni, Ray wrote:
> On 2/20/2019 4:16 PM, Laszlo Ersek wrote:
>> In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there
>> may be
>> padding between the DataHeader and ReturnStatus members. The
>> REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
>> after DataHeader, therefore the source data must provide for the padding.
>>
>> Extract the BmReportImageFailure() function from EfiBootManagerBoot(),
>> prepare a zero padding (if any) in a temporary
>> EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
>> REPORT_STATUS_CODE_EX() macro invocation.
>>
>> Cc: Dandan Bi 
>> Cc: Hao Wu 
>> Cc: Jian J Wang 
>> Cc: Ray Ni 
>> Cc: Sean Brogan 
>> Cc: Star Zeng 
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
>> Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>>  v2:
>>  - new in v2
>>
>>   MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
>>   MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 69
>> +++-
>>   2 files changed, 52 insertions(+), 18 deletions(-)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
>> b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
>> index 978fbff966f6..0fef63fceedf 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
>> @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
>> EITHER EXPRESS OR IMPLIED.
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>     #include 
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>> index 9be1633b7480..ffb98c6c9b83 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
>> @@ -1667,6 +1667,55 @@ BmIsBootManagerMenuFilePath (
>>     return FALSE;
>>   }
>>   +/**
>> +  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about
>> LoadImage() or
>> +  StartImage() failure.
>> +
>> +  @param[in] ErrorCode  An Error Code in the Software Class, DXE
>> Boot
>> +    Service Driver Subclass. ErrorCode will
>> be used to
>> +    compose the Value parameter for status code
>> +    reporting. Must be one of
>> +    EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
>> +    EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
>> +
>> +  @param[in] FailureStatus  The failure status returned by the boot
>> service
>> +    that should be reported.
>> +**/
>> +VOID
>> +BmReportImageFailure (
> Laszlo,
> Thanks for quick fixing this issue.
> To match the status code it reports, how about rename the function as
> "BmReportLoadFailure"?

Sure, I can do that.

> Another minor comments in below.
>> +  IN UINT32 ErrorCode,
>> +  IN EFI_STATUS FailureStatus
>> +  )
>> +{
>> +  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
>> +  VOID    *PaddingStart;
>> +  UINTN   PaddingSize;
>> +
>> +  if (!ReportErrorCodeEnabled ()) {
>> +    return;
>> +  }
>> +
>> +  ASSERT (
>> +    (ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
>> +    (ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
>> +    );
>> +
>> +  PaddingStart =  + 1;
>> +  PaddingSize = (UINTN)  - (UINTN)
>> PaddingStart;
>> +  ZeroMem (PaddingStart, PaddingSize);
> 
> I prefer "ZeroMem (, sizeof (ExtendedData))" instead of
> introducing local variables such as PaddingStart/PaddingSize.
> This makes code more good-looking:).

I agree that that looks more natural. I didn't know how much you'd like
me to "optimize" this logic. Because,

(1) an optimizing compiler can eliminate PaddingSize from the ZeroMem()
call (replacing it with a constant); in other words, the PaddingSize
calculation would have no runtime cost,

(2) the ZeroMem() call would have to clear fewer bytes.

I hesitated between the smallest possible ZeroMem() and the
easiest-to-read ZeroMem(). I will rework it in v3.


> 
>> +  ExtendedData.ReturnStatus = FailureStatus;
>> +
>> +  REPORT_STATUS_CODE_EX (
>> +    (EFI_ERROR_CODE | EFI_ERROR_MINOR),
>> +    (EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
>> +    0,
>> +    NULL,
>> +    NULL,
>> +    PaddingStart,
>  + 1
> 
>> +    PaddingSize + sizeof (ExtendedData.ReturnStatus)
> sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)

Yes.

Thanks,
Laszlo

>> +    );
>> +}
>> +
>>   /**
>>     Attempt to boot the EFI boot option. This routine sets
>> L"BootCurent" and
>>     also signals the EFI ready to boot event. If the device path for
>> the option
>> @@ -1822,15 +1871,7 @@ EfiBootManagerBoot (
>>     //
>>     // Report Status Code with the failure status to indicate that
>> the failure to load boot option
>>     //
>>