[edk2] [PATCH] MdeModulePkg/PlatformLogo.h: Correct function header comments

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Include/Protocol/PlatformLogo.h | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h 
b/MdeModulePkg/Include/Protocol/PlatformLogo.h
index 4773173889..c25e7b04cb 100644
--- a/MdeModulePkg/Include/Protocol/PlatformLogo.h
+++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
@@ -2,7 +2,7 @@
   The Platform Logo Protocol defines the interface to get the Platform logo
   image with the display attribute.
 
-Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, 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 that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -39,22 +39,17 @@ typedef enum {
 } EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;
 
 /**
-
   Load a platform logo image and return its data and attributes.
 
   @param This  The pointer to this protocol instance.
   @param Instance  The visible image instance is found.
-  @param FormatThe format of the image. Examples: BMP, JPEG.
-  @param ImageData The image data for the badge file. Currently only 
-   supports the .bmp file format. 
-  @param ImageSize The size of the image returned.
+  @param Image Points to the image.
   @param Attribute The display attributes of the image returned.
   @param OffsetX   The X offset of the image regarding the Attribute.
   @param OffsetY   The Y offset of the image regarding the Attribute.
 
   @retval EFI_SUCCESS  The image was fetched successfully.
   @retval EFI_NOT_FOUNDThe specified image could not be found.
-
 **/
 typedef
 EFI_STATUS
-- 
2.16.1.windows.1

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

[edk2] [PATCH V2] BaseTools/Expression: Use 2nd passes on PCD values

[Yonghong Zhu]

From: "Kinney, Michael D" 

V2: Add bugzilla issue info and signed-off info

Use 2 passes when evaluating PCD values to discover
all the LABEL() operators and compute the byte offset
of each LABEL().  The 2nd pass then has the information
to replace the OFFSET_OF() operator with the computed
byte offset.  The 2 passes allows OFFSET_OF() to be used
before a LABEL() is declared.

fixes:https://bugzilla.tianocore.org/show_bug.cgi?id=880
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Common/Expression.py | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 74d1b08f76..28320d78a9 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -827,6 +827,30 @@ class ValueExpressionEx(ValueExpression):
 LabelDict = {}
 ReLabel = re.compile('LABEL\((\w+)\)')
 ReOffset = re.compile('OFFSET_OF\((\w+)\)')
+LabelOffset = 0
+for Index, Item in enumerate(ListItem):
+# compute byte offset of every LABEL
+Item = Item.strip()
+try:
+LabelList = ReLabel.findall(Item)
+for Label in LabelList:
+if Label not in LabelDict.keys():
+LabelDict[Label] = str(LabelOffset)
+Item = ReLabel.sub('', Item)
+except:
+pass
+if Item.startswith('UINT8'):
+LabelOffset = LabelOffset + 1
+elif Item.startswith('UINT16'):
+LabelOffset = LabelOffset + 2
+elif Item.startswith('UINT32'):
+LabelOffset = LabelOffset + 4
+elif Item.startswith('UINT64'):
+LabelOffset = LabelOffset + 8
+else:
+ItemValue, ItemSize = ParseFieldValue(Item)
+LabelOffset = LabelOffset + ItemSize
+
 for Index, Item in enumerate(ListItem):
 # for LABEL parse
 Item = Item.strip()
@@ -847,7 +871,7 @@ class ValueExpressionEx(ValueExpression):
 Re = re.compile('OFFSET_OF\(%s\)'% 
Offset)
 Item = Re.sub(LabelDict[Offset], Item)
 else:
-raise BadExpression('%s not defined 
before use' % Offset)
+raise BadExpression('%s not defined' % 
Offset)
 ValueType = ""
 if Item.startswith('UINT8'):
 ItemSize = 1
-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH] BaseTools/Expression: Use 2nd passes on PCD values

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong 
Zhu
Sent: Saturday, February 24, 2018 10:14 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D 
Subject: [edk2] [PATCH] BaseTools/Expression: Use 2nd passes on PCD values

From: "Kinney, Michael D" 

Use 2 passes when evaluating PCD values to discover all the LABEL() operators 
and compute the byte offset of each LABEL().  The 2nd pass then has the 
information to replace the OFFSET_OF() operator with the computed byte offset.  
The 2 passes allows OFFSET_OF() to be used before a LABEL() is declared.
---
 BaseTools/Source/Python/Common/Expression.py | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 74d1b08f76..28320d78a9 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -827,6 +827,30 @@ class ValueExpressionEx(ValueExpression):
 LabelDict = {}
 ReLabel = re.compile('LABEL\((\w+)\)')
 ReOffset = re.compile('OFFSET_OF\((\w+)\)')
+LabelOffset = 0
+for Index, Item in enumerate(ListItem):
+# compute byte offset of every LABEL
+Item = Item.strip()
+try:
+LabelList = ReLabel.findall(Item)
+for Label in LabelList:
+if Label not in LabelDict.keys():
+LabelDict[Label] = str(LabelOffset)
+Item = ReLabel.sub('', Item)
+except:
+pass
+if Item.startswith('UINT8'):
+LabelOffset = LabelOffset + 1
+elif Item.startswith('UINT16'):
+LabelOffset = LabelOffset + 2
+elif Item.startswith('UINT32'):
+LabelOffset = LabelOffset + 4
+elif Item.startswith('UINT64'):
+LabelOffset = LabelOffset + 8
+else:
+ItemValue, ItemSize = ParseFieldValue(Item)
+LabelOffset = LabelOffset + 
+ ItemSize
+
 for Index, Item in enumerate(ListItem):
 # for LABEL parse
 Item = Item.strip() @@ -847,7 +871,7 @@ class 
ValueExpressionEx(ValueExpression):
 Re = re.compile('OFFSET_OF\(%s\)'% 
Offset)
 Item = Re.sub(LabelDict[Offset], Item)
 else:
-raise BadExpression('%s not defined 
before use' % Offset)
+raise BadExpression('%s not 
+ defined' % Offset)
 ValueType = ""
 if Item.startswith('UINT8'):
 ItemSize = 1
--
2.14.2.windows.3

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

Re: [edk2] [PATCH] BaseTools: Update ValueExpressionEx for flexible PCD

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong

-Original Message-
From: Feng, YunhuaX 
Sent: Friday, February 23, 2018 7:48 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming 
Subject: [PATCH] BaseTools: Update ValueExpressionEx for flexible PCD

1. Byte  array number should less than 0xFF.
2. Add SplitPcdValueString for PCD split

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Expression.py | 205 +--
 1 file changed, 130 insertions(+), 75 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 28320d78a9..edb0a60de6 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -66,10 +66,48 @@ def SplitString(String):
 raise BadExpression(ERR_STRING_TOKEN % Item)
 if Item:
 RetList.append(Item)
 return RetList
 
+def SplitPcdValueString(String):
+# There might be escaped comma in GUID() or DEVICE_PATH() or " "
+# or ' ' or L' ' or L" "
+Str = String
+RetList = []
+InParenthesis = 0
+InSingleQuote = False
+InDoubleQuote = False
+Item = ''
+for i, ch in enumerate(Str):
+if ch == '(':
+InParenthesis += 1
+if ch == ')':
+if InParenthesis:
+InParenthesis -= 1
+else:
+raise BadExpression(ERR_STRING_TOKEN % Item)
+if ch == '"' and not InSingleQuote:
+if String[i-1] != '\\':
+InDoubleQuote = not InDoubleQuote
+if ch == "'" and not InDoubleQuote:
+if String[i-1] != '\\':
+InSingleQuote = not InSingleQuote
+if ch == ',':
+if InParenthesis or InSingleQuote or InDoubleQuote:
+Item += String[i]
+continue
+elif Item:
+RetList.append(Item)
+Item = ''
+continue
+Item += String[i]
+if InSingleQuote or InDoubleQuote or InParenthesis:
+raise BadExpression(ERR_STRING_TOKEN % Item)
+if Item:
+RetList.append(Item)
+return RetList
+
 ## ReplaceExprMacro
 #
 def ReplaceExprMacro(String, Macros, ExceptionList = None):
 StrList = SplitString(String)
 for i, String in enumerate(StrList):
@@ -731,28 +769,46 @@ class ValueExpressionEx(ValueExpression):
 PcdValue = Value.result
 except BadExpression, Value:
 if self.PcdType in ['UINT8', 'UINT16', 'UINT32', 'UINT64', 
'BOOLEAN']:
 PcdValue = PcdValue.strip()
 if type(PcdValue) == type('') and PcdValue.startswith('{') and 
PcdValue.endswith('}'):
-PcdValue = PcdValue[1:-1].split(',')
+PcdValue = SplitPcdValueString(PcdValue[1:-1])
 if type(PcdValue) == type([]):
 TmpValue = 0
 Size = 0
+ValueType = ''
 for Item in PcdValue:
+Item = Item.strip()
 if Item.startswith('UINT8'):
 ItemSize = 1
-if Item.startswith('UINT16'):
+ValueType = 'UINT8'
+elif Item.startswith('UINT16'):
 ItemSize = 2
+ValueType = 'UINT16'
 elif Item.startswith('UINT32'):
 ItemSize = 4
+ValueType = 'UINT32'
 elif Item.startswith('UINT64'):
 ItemSize = 8
+ValueType = 'UINT64'
+elif Item.startswith('"') or Item.startswith("'") or 
Item.startswith('L'):
+ItemSize = 0
+ValueType = 'VOID*'
 else:
 ItemSize = 0
-Item = ValueExpressionEx(Item, self.PcdType, 
self._Symb)(True)
+ValueType = 'UINT8'
+Item = ValueExpressionEx(Item, ValueType, 
self._Symb)(True)
 
 if ItemSize == 0:
+try:
+tmpValue = int(Item, 16) if 
Item.upper().startswith('0X') else int(Item, 0)
+if tmpValue > 255:
+raise BadExpression("Byte  array number %s 
should less than 0xFF." % Item)
+except BadExpression, Value:
+raise BadExpression(Value)
+except ValueError:
+   

[edk2] [PATCH] MdeModulePkg/Terminal: ReadKeyStrokeEx always return key state

[Ruiyu Ni]

Because terminal doesn't support shift and toggle key state,
ReadKeyStrokeEx just sets the two states to 0.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c 
b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
index 3c1102dac4..99316376cb 100644
--- a/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
+++ b/MdeModulePkg/Universal/Console/TerminalDxe/TerminalConIn.c
@@ -2,7 +2,7 @@
   Implementation for EFI_SIMPLE_TEXT_INPUT_PROTOCOL protocol.
 
 (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 Copyright (C) 2016 Silicon Graphics, Inc. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -41,13 +41,12 @@ ReadKeyStrokeWorker (
 return EFI_INVALID_PARAMETER;
   }
 
-  if (!EfiKeyFiFoRemoveOneKey (TerminalDevice, >Key)) {
-return EFI_NOT_READY;
-  }
-
   KeyData->KeyState.KeyShiftState  = 0;
   KeyData->KeyState.KeyToggleState = 0;
 
+  if (!EfiKeyFiFoRemoveOneKey (TerminalDevice, >Key)) {
+return EFI_NOT_READY;
+  }
 
   return EFI_SUCCESS;
 
-- 
2.16.1.windows.1

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

Re: [edk2] TPM 2.0 Manufacutre ID wrong byte order

[Zhang, Chao B]

Derek:
   Thank you for the info. TPM Library spec 1.38. Page 342 defines each 
property to be a 32-bit value. Endian conversion only applies to those 32-bit 
value that are interpreted as 16-bit, 32-bit data outside. 
It doesn't apply to the PT_MANFACTURER case. We can add comments to make this 
interface clearer. But I think current implementation is good from spec point 
of view.   


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Lin, 
Derek (HPS UEFI Dev)
Sent: Friday, February 23, 2018 4:08 PM
To: Zhang, Chao B ; edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star 
Subject: Re: [edk2] TPM 2.0 Manufacutre ID wrong byte order

Hi Chao B,

I think you are right, the Manufacture ID is a byte array. The order in ACPI 
HID is correct.

But Tpm2GetCapabilityManufactureID return a UINT32 value.
EFI_STATUS
EFIAPI
Tpm2GetCapabilityManufactureID (
  OUT UINT32*ManufactureId
  )


This is confused . When the caller use ManufactureId as UINT32, the byte order 
is confused.
For example in Tcg2Dxe.c, it print:
Tpm2GetCapabilityManufactureID - 204D5453

Which should be "53544D20" in the case.

  Status = Tpm2GetCapabilityManufactureID ();
  if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "Tpm2GetCapabilityManufactureID fail!\n"));
  } else {
DEBUG ((EFI_D_INFO, "Tpm2GetCapabilityManufactureID - %08x\n", 
mTcgDxeData.BsCap.ManufacturerID));
  }

How about changing the returning value to a 4 bytes array?

Thanks,
Derek

From: Zhang, Chao B [mailto:chao.b.zh...@intel.com]
Sent: Friday, February 23, 2018 11:03 AM
To: Lin, Derek (HPS UEFI Dev) ; edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star 
Subject: RE: TPM 2.0 Manufacutre ID wrong byte order

Hi Derek:
Can you specify the "reversed" ManufactureId issue?  What did you get from 
this interface?
The implementation follows Vendor ID registry spec. The vendor ID is octet 
array. There is no endian issue here.
We haven't seen any disorder before.


From: Lin, Derek (HPS UEFI Dev) [mailto:derek.l...@hpe.com]
Sent: Thursday, February 22, 2018 7:25 PM
To: edk2-devel@lists.01.org; Zhang, Chao B 
>
Cc: Yao, Jiewen >; Zeng, Star 
>
Subject: TPM 2.0 Manufacutre ID wrong byte order

Hi TPM expert,

The line in 
https://github.com/tianocore/edk2/commit/73126ac2bd9804632255b2fddd4d7633537c9620#diff-76abe1c1ebf05982ed72eaf56f489029R192
 change the byte order of Manufacture ID in Tpm2GetCapabilityManufactureID ().

I see it return "reversed" ManufactureId for two TPM vendor's module.
Also, all other Capability data in Tpm2Capability.c use SwapBytes32 since TPM 
is big-endian, which seems correct.

Can you check this and confirm?

Thanks,
Derek

___
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] MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers

[Guo Heyi]

Hi folks,

In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself
if some driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, if there is something wrong in some 3rd party driver (e.g. PCI oprom),
the driver health protocol of that driver may always return such status even
after one and another reconnect. The endless iteration will cause stack overflow
and then system exception, and it may be not easy to find that the exception is
actually caused by stack overflow.

So does it make sense to set a maximum count of this recursive call to avoid
whole system hang even there is a buggy 3rd party driver?

Thanks,

Gary (Heyi Guo)

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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] AX88179 UNDI driver.

[zwei4]

Add UNDI driver for AX88179 USB-to-LAN adapter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: zwei4 
---
 Platform/BroxtonPlatformPkg/PlatformPkg.fdf | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Platform/BroxtonPlatformPkg/PlatformPkg.fdf 
b/Platform/BroxtonPlatformPkg/PlatformPkg.fdf
index 6c377553f..9af77d590 100644
--- a/Platform/BroxtonPlatformPkg/PlatformPkg.fdf
+++ b/Platform/BroxtonPlatformPkg/PlatformPkg.fdf
@@ -702,10 +702,17 @@ APRIORI DXE {
   # LAN/Network
   #
 !if $(NETWORK_ENABLE) == TRUE
+  
+  FILE DRIVER = 51B24E4E-FDD2-4047-BE4D-131873A457B2 {
+SECTION PE32 = 
BroxtonPlatformPkg/Common/Binaries/UNDI/AX88179/AX88179_178A_UEFI_V2.7.0_X64.efi
+SECTION UI = "UNDI"
+  }
+
   FILE DRIVER = 2E561D56-4863-44F7-960D-EF2D7F2D35BB {
 SECTION PE32 = 
BroxtonPlatformPkg/Common/Binaries/UNDI/I210PcieUndiDxe/E7320X3.EFI
 SECTION UI = "UNDI"
   }
+
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
   INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
-- 
2.14.1.windows.1

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

[edk2] [Patch] BaseTool: GUID assignment fail.

[BobCF]

Structure PCD GUID assignment fail.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/Workspace/DecBuildData.py |  3 ++-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 11 ++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DecBuildData.py 
b/BaseTools/Source/Python/Workspace/DecBuildData.py
index 18101a0add..ee00ec0719 100644
--- a/BaseTools/Source/Python/Workspace/DecBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DecBuildData.py
@@ -13,10 +13,11 @@
 #
 from Common.String import *
 from Common.DataType import *
 from Common.Misc import *
 from types import *
+from collections import OrderedDict
 
 from Workspace.BuildClassObject import PackageBuildClassObject, StructurePcd, 
PcdClassObject
 
 ## Platform build information from DEC file
 #
@@ -365,11 +366,11 @@ class DecBuildData(PackageBuildClassObject):
 self._Pcds.update(self._GetPcd(MODEL_PCD_DYNAMIC_EX))
 return self._Pcds
 
 
 def ProcessStructurePcd(self, StructurePcdRawDataSet):
-s_pcd_set = dict()
+s_pcd_set = OrderedDict()
 for s_pcd,LineNo in StructurePcdRawDataSet:
 if s_pcd.TokenSpaceGuidCName not in s_pcd_set:
 s_pcd_set[s_pcd.TokenSpaceGuidCName] = []
 s_pcd_set[s_pcd.TokenSpaceGuidCName].append((s_pcd,LineNo))
 
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 3246a2afd8..ae937dee46 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -37,10 +37,11 @@ from Common.Parsing import IsValidWord
 from Common.VariableAttributes import VariableAttributes
 import Common.GlobalData as GlobalData
 import subprocess
 from Common.Misc import SaveFileOnChange
 from Workspace.BuildClassObject import PlatformBuildClassObject, StructurePcd, 
PcdClassObject, ModuleBuildClassObject
+from collections import OrderedDict
 
 #
 # Treat CHAR16 as a synonym for UINT16.  CHAR16 support is required for VFR C 
structs
 #
 PcdValueInitName = 'PcdValueInit'
@@ -1272,11 +1273,11 @@ class DscBuildData(PlatformBuildClassObject):
 if SkuName in SkuIds and "." in TokenSpaceGuid:
 S_PcdSet.append([ 
TokenSpaceGuid.split(".")[0],TokenSpaceGuid.split(".")[1], PcdCName,SkuName, 
default_store,Dummy5, AnalyzePcdExpression(Setting)[0]])
 
 # handle pcd value override
 StrPcdSet = self.GetStructurePcdInfo(S_PcdSet)
-S_pcd_set = {}
+S_pcd_set = OrderedDict()
 for str_pcd in StrPcdSet:
 str_pcd_obj = Pcds.get((str_pcd[1], str_pcd[0]), None)
 str_pcd_dec = self._DecPcds.get((str_pcd[1], str_pcd[0]), None)
 if not isinstance (str_pcd_dec, StructurePcd):
 EdkLogger.error('build', PARSER_ERROR,
@@ -1597,11 +1598,11 @@ class DscBuildData(PlatformBuildClassObject):
 if not FieldList:
 continue
 for FieldName in FieldList:
 FieldName = "." + FieldName
 IsArray = 
self.IsFieldValueAnArray(FieldList[FieldName.strip(".")][0])
-if IsArray:
+if IsArray and not 
(FieldList[FieldName.strip(".")][0].startswith('{GUID') and 
FieldList[FieldName.strip(".")][0].endswith('}')):
 try:
 Value = 
ValueExpressionEx(FieldList[FieldName.strip(".")][0], "VOID*", 
self._GuidDict)(True)
 except BadExpression:
 EdkLogger.error('Build', FORMAT_INVALID, "Invalid 
value format for %s. From %s Line %d " %
 
(".".join((Pcd.TokenSpaceGuidCName, Pcd.TokenCName, FieldName.strip('.'))), 
FieldList[FieldName.strip(".")][1], FieldList[FieldName.strip(".")][2]))
@@ -1627,11 +1628,11 @@ class DscBuildData(PlatformBuildClassObject):
 if not FieldList:
 continue
 for FieldName in FieldList:
 FieldName = "." + FieldName
 IsArray = 
self.IsFieldValueAnArray(FieldList[FieldName.strip(".")][0])
-if IsArray:
+if IsArray and not 
(FieldList[FieldName.strip(".")][0].startswith('{GUID') and 
FieldList[FieldName.strip(".")][0].endswith('}')):
 try:
 Value = 
ValueExpressionEx(FieldList[FieldName.strip(".")][0], "VOID*", 
self._GuidDict)(True)
 except BadExpression:
 EdkLogger.error('Build', FORMAT_INVALID, 
"Invalid value format for %s. From %s Line %d " %
 

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Guo Heyi]

On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 9:51 AM, Guo Heyi wrote:
> >On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> >>Thanks for writing up the details!
> >>
> >>Comments:
> >>
> >>On 02/23/18 09:53, Heyi Guo wrote:
> >>>PCI address translation is necessary for some non-x86 platforms. On
> >>>such platforms, address value (denoted as "device address" or "address
> >>>in PCI view") set to PCI BAR registers in configuration space might be
> >>>different from the address which is used by CPU to access the
> >>>registers in memory BAR or IO BAR spaces (denoted as "host address" or
> >>>"address in CPU view"). The difference between the two addresses is
> >>>called "Address Translation Offset" or simply "translation", and can
> >>>be represented by "Address Translation Offset" in ACPI QWORD Address
> >>>Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> >>>definitions of QWORD Address Space Descriptor, and we will follow UEFI
> >>>definition on UEFI protocols, such as PCI root bridge IO protocol and
> >>>PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> >>>to apply to the Starting address to convert it to a PCI address". This
> >>>means:
> >>>
> >>>1. Translation = device address - host address.
> >>
> >>OK, this looks like a sensible choice to me. It means that the "apply"
> >>term used in the UEFI spec means "add", which (I think) is the "natural"
> >>interpretation.
> >>
> >>>2. PciRootBridgeIo->Configuration should return CPU view address, as
> >>>well as PciIo->GetBarAttributes.
> >>
> >>OK.
> >>
> >>>
> >>>Summary of addresses used:
> >>>
> >>>1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> >>>it is easy to check whether the address is below 4G or above 4G.
> >>
> >>I agree that PciHostBridgeLib instances that do not set a nonzero
> >>Translation need not care about the difference.
> >>
> >>(1) Still, can you confirm this is a "natural" choice? Were the
> >>DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> >>the device (PCI) view in mind?
> >>
> >>... I also meant to raise a concern about the InitializePciHostBridge()
> >>function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> >>which end up manipulating GCD -- with data from
> >>PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> >>patch, so that's good. (I do have more comments on the actual
> >>implementation.)
> DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
> the root bridge HW, whether it's capable to do DMA on device address
> above 4GB.
> 
> >>
> >>>
> >>>2. Address returned by
> >>>EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> >>>is device address, or else PCI bus driver cannot set correct address
> >>>into PCI BAR registers.
> >>>
> >>>3. Address returned by PciRootBridgeIo->Configuration is host address
> >>>per UEFI 2.7 definition.
> >>>
> >>>4. Addresses used in GCD manipulation are host address.
> >>>
> >>>5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> >>>address, for they are allocated from GCD.
> >>>
> >>>6. Address passed to PciHostBridgeResourceConflict is host address,
> >>>for it comes from ResAllocNode.
> >>>
> >>>Contributed-under: TianoCore Contribution Agreement 1.1
> >>>Signed-off-by: Heyi Guo 
> >>>Cc: Ruiyu Ni 
> >>>Cc: Ard Biesheuvel 
> >>>Cc: Star Zeng 
> >>>Cc: Eric Dong 
> >>>Cc: Laszlo Ersek 
> >>>Cc: Michael D Kinney 
> >>>---
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> >>> ++---
> >>>  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >>>  4 files changed, 167 insertions(+), 29 deletions(-)
> >>>
> >>>diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> >>>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>index 1494848..e8979eb 100644
> >>>--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >>>  EFI_EVENT   mIoMmuEvent;
> >>>  VOID*mIoMmuRegistration;
> >>>
> >>>+STATIC
> >>>+UINT64
> >>>+GetTranslationByResourceType (
> >>>+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> >>>+  IN  PCI_RESOURCE_TYPEResourceType
> >>>+  )
> >>>+{
> >>>+  switch (ResourceType) {
> >>>+case TypeIo:
> >>>+  return RootBridge->Io.Translation;
> >>>+case TypeMem32:
> >>>+  return RootBridge->Mem.Translation;
> >>>+case TypePMem32:
> >>>+  return RootBridge->PMem.Translation;
> >>>+case TypeMem64:
> >>>+  

Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Perform MediaId check first in BlkIo services

[Ni, Ruiyu]

On 2/24/2018 8:48 AM, Hao Wu wrote:

The commit places the check for MediaId at the beginning of Block IO
services:
RamDiskBlkIoReadBlocks and
RamDiskBlkIoWriteBlocks

This aligns with the Block IO protocol implementations for other
devices.

Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
  .../Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
index f36e1c8ff2..4f74b5ef15 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
@@ -1,7 +1,7 @@
  /** @file
Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
  
-  Copyright (c) 2016, Intel Corporation. All rights reserved.

+  Copyright (c) 2016 - 2018, 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
@@ -137,6 +137,12 @@ RamDiskBlkIoReadBlocks (
RAM_DISK_PRIVATE_DATA   *PrivateData;
UINTN   NumberOfBlocks;
  
+  PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);

+
+  if (MediaId != PrivateData->Media.MediaId) {
+return EFI_MEDIA_CHANGED;
+  }
+
if (Buffer == NULL) {
  return EFI_INVALID_PARAMETER;
}
@@ -145,12 +151,6 @@ RamDiskBlkIoReadBlocks (
  return EFI_SUCCESS;
}
  
-  PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);

-
-  if (MediaId != PrivateData->Media.MediaId) {
-return EFI_MEDIA_CHANGED;
-  }
-
if ((BufferSize % PrivateData->Media.BlockSize) != 0) {
  return EFI_BAD_BUFFER_SIZE;
}
@@ -212,14 +212,6 @@ RamDiskBlkIoWriteBlocks (
RAM_DISK_PRIVATE_DATA   *PrivateData;
UINTN   NumberOfBlocks;
  
-  if (Buffer == NULL) {

-return EFI_INVALID_PARAMETER;
-  }
-
-  if (BufferSize == 0) {
-return EFI_SUCCESS;
-  }
-
PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);
  
if (MediaId != PrivateData->Media.MediaId) {

@@ -230,6 +222,14 @@ RamDiskBlkIoWriteBlocks (
  return EFI_WRITE_PROTECTED;
}
  
+  if (Buffer == NULL) {

+return EFI_INVALID_PARAMETER;
+  }
+
+  if (BufferSize == 0) {
+return EFI_SUCCESS;
+  }
+
if ((BufferSize % PrivateData->Media.BlockSize) != 0) {
  return EFI_BAD_BUFFER_SIZE;
}


Reviewed-by: Ruiyu Ni 

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

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Ni, Ruiyu]

On 2/24/2018 9:51 AM, Guo Heyi wrote:

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:

Thanks for writing up the details!

Comments:

On 02/23/18 09:53, Heyi Guo wrote:

PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:

1. Translation = device address - host address.


OK, this looks like a sensible choice to me. It means that the "apply"
term used in the UEFI spec means "add", which (I think) is the "natural"
interpretation.


2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.


OK.



Summary of addresses used:

1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
it is easy to check whether the address is below 4G or above 4G.


I agree that PciHostBridgeLib instances that do not set a nonzero
Translation need not care about the difference.

(1) Still, can you confirm this is a "natural" choice? Were the
DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
the device (PCI) view in mind?

... I also meant to raise a concern about the InitializePciHostBridge()
function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
which end up manipulating GCD -- with data from
PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
patch, so that's good. (I do have more comments on the actual
implementation.)

DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
the root bridge HW, whether it's capable to do DMA on device address
above 4GB.





2. Address returned by
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
is device address, or else PCI bus driver cannot set correct address
into PCI BAR registers.

3. Address returned by PciRootBridgeIo->Configuration is host address
per UEFI 2.7 definition.

4. Addresses used in GCD manipulation are host address.

5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
address, for they are allocated from GCD.

6. Address passed to PciHostBridgeResourceConflict is host address,
for it comes from ResAllocNode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
  4 files changed, 167 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..e8979eb 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
  EFI_EVENT   mIoMmuEvent;
  VOID*mIoMmuRegistration;

+STATIC
+UINT64
+GetTranslationByResourceType (
+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
+  IN  PCI_RESOURCE_TYPEResourceType
+  )
+{
+  switch (ResourceType) {
+case TypeIo:
+  return RootBridge->Io.Translation;
+case TypeMem32:
+  return RootBridge->Mem.Translation;
+case TypePMem32:
+  return RootBridge->PMem.Translation;
+case TypeMem64:
+  return RootBridge->MemAbove4G.Translation;
+case TypePMem64:
+  return RootBridge->PMemAbove4G.Translation;
+default:


(2) How about we return zero for TypeBus, explicitly, and then
ASSERT(FALSE) and return zero for "default"?


+  return 0;
+  }
+}
+
  /**
Ensure the compatibility of an IO space descriptor with the IO aperture.

@@ -411,8 +434,12 @@ InitializePciHostBridge (
  }

  if (RootBridges[Index].Io.Base <= RootBridges[Index].Io.Limit) {
+  // Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+  // According to 

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Change BIOS Version.

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Guo Mang 
---
 Platform/BroxtonPlatformPkg/BiosId.env | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/BiosId.env 
b/Platform/BroxtonPlatformPkg/BiosId.env
index d23c4b6..1d89e05 100644
--- a/Platform/BroxtonPlatformPkg/BiosId.env
+++ b/Platform/BroxtonPlatformPkg/BiosId.env
@@ -30,6 +30,6 @@
 BOARD_ID  = APLKRVP
 BOARD_REV = 3
 BUILD_TYPE= D
-VERSION_MAJOR = 0068
-VERSION_MINOR = 06
+VERSION_MAJOR = 0069
+VERSION_MINOR = 01
 BOARD_EXT = X64
-- 
2.10.1.windows.1

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

[edk2] [PATCH] BaseTools/Expression: Use 2nd passes on PCD values

[Yonghong Zhu]

From: "Kinney, Michael D" 

Use 2 passes when evaluating PCD values to discover
all the LABEL() operators and compute the byte offset
of each LABEL().  The 2nd pass then has the information
to replace the OFFSET_OF() operator with the computed
byte offset.  The 2 passes allows OFFSET_OF() to be used
before a LABEL() is declared.
---
 BaseTools/Source/Python/Common/Expression.py | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 74d1b08f76..28320d78a9 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -827,6 +827,30 @@ class ValueExpressionEx(ValueExpression):
 LabelDict = {}
 ReLabel = re.compile('LABEL\((\w+)\)')
 ReOffset = re.compile('OFFSET_OF\((\w+)\)')
+LabelOffset = 0
+for Index, Item in enumerate(ListItem):
+# compute byte offset of every LABEL
+Item = Item.strip()
+try:
+LabelList = ReLabel.findall(Item)
+for Label in LabelList:
+if Label not in LabelDict.keys():
+LabelDict[Label] = str(LabelOffset)
+Item = ReLabel.sub('', Item)
+except:
+pass
+if Item.startswith('UINT8'):
+LabelOffset = LabelOffset + 1
+elif Item.startswith('UINT16'):
+LabelOffset = LabelOffset + 2
+elif Item.startswith('UINT32'):
+LabelOffset = LabelOffset + 4
+elif Item.startswith('UINT64'):
+LabelOffset = LabelOffset + 8
+else:
+ItemValue, ItemSize = ParseFieldValue(Item)
+LabelOffset = LabelOffset + ItemSize
+
 for Index, Item in enumerate(ListItem):
 # for LABEL parse
 Item = Item.strip()
@@ -847,7 +871,7 @@ class ValueExpressionEx(ValueExpression):
 Re = re.compile('OFFSET_OF\(%s\)'% 
Offset)
 Item = Re.sub(LabelDict[Offset], Item)
 else:
-raise BadExpression('%s not defined 
before use' % Offset)
+raise BadExpression('%s not defined' % 
Offset)
 ValueType = ""
 if Item.startswith('UINT8'):
 ItemSize = 1
-- 
2.14.2.windows.3

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

Re: [edk2] [PATCH edk2-non-osi v3 7/7] Hisilicon/D05: Update binary of trusted-firmware

[Guo Heyi]

On Fri, Feb 23, 2018 at 09:02:46AM +, Ard Biesheuvel wrote:
> On 23 February 2018 at 03:17, Guo Heyi  wrote:
> > Hi Jeremy,
> >
> > This TF binaries have not been patched the latest SMCCC workaround; it is 
> > based
> > on v1.4 release and was only
> > patched with "disable/enable MMU in PSCI SMC call", as the commit in 
> > upstream TF
> > code:
> > f62ad322695d16178db464dc062fe0af592c6780
> >
> > When we generated these binaries, SMCCC patches had not come out so they 
> > are not
> > contained in these binaries.
> >
> > Do you recommend using the latest smccc patches?
> >
> 
> Yes.
> 
> The Spectre v2 mitigations that landed in v4.16 and were backported to
> v4.15 and v4.14 LTS do not use the PSCI_VERSION call anymore to
> perform branch predictor invalidation. Instead, it checks for
> SMCCCv1.1, and uses the ARCH_WORKAROUND_1 SMC call if supported. If
> not, no BP maintenance is performed.

Thanks, we'll try to apply the smccc patch to TF.

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

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Guo Heyi]

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "address
> > in PCI view") set to PCI BAR registers in configuration space might be
> > different from the address which is used by CPU to access the
> > registers in memory BAR or IO BAR spaces (denoted as "host address" or
> > "address in CPU view"). The difference between the two addresses is
> > called "Address Translation Offset" or simply "translation", and can
> > be represented by "Address Translation Offset" in ACPI QWORD Address
> > Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> > definitions of QWORD Address Space Descriptor, and we will follow UEFI
> > definition on UEFI protocols, such as PCI root bridge IO protocol and
> > PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> > to apply to the Starting address to convert it to a PCI address". This
> > means:
> >
> > 1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> > 2. PciRootBridgeIo->Configuration should return CPU view address, as
> > well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> > Summary of addresses used:
> >
> > 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> > it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> 
> >
> > 2. Address returned by
> > EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> > is device address, or else PCI bus driver cannot set correct address
> > into PCI BAR registers.
> >
> > 3. Address returned by PciRootBridgeIo->Configuration is host address
> > per UEFI 2.7 definition.
> >
> > 4. Addresses used in GCD manipulation are host address.
> >
> > 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> > address, for they are allocated from GCD.
> >
> > 6. Address passed to PciHostBridgeResourceConflict is host address,
> > for it comes from ResAllocNode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo 
> > Cc: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > ---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > index 1494848..e8979eb 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> > +STATIC
> > +UINT64
> > +GetTranslationByResourceType (
> > +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> > +  IN  PCI_RESOURCE_TYPEResourceType
> > +  )
> > +{
> > +  switch (ResourceType) {
> > +case TypeIo:
> > +  return RootBridge->Io.Translation;
> > +case TypeMem32:
> > +  return RootBridge->Mem.Translation;
> > +case TypePMem32:
> > +  return RootBridge->PMem.Translation;
> > +case TypeMem64:
> > +  return RootBridge->MemAbove4G.Translation;
> > +case TypePMem64:
> > +  return RootBridge->PMemAbove4G.Translation;
> > +default:
> 
> (2) How about we return zero for TypeBus, explicitly, and then
> ASSERT(FALSE) and return zero for "default"?
> 
> > +  return 0;
> > +  }
> > +}
> > +
> >  /**
> >Ensure the compatibility of an IO space descriptor with the IO aperture.
> >
> > @@ -411,8 

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Guo Heyi]

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "address
> > in PCI view") set to PCI BAR registers in configuration space might be
> > different from the address which is used by CPU to access the
> > registers in memory BAR or IO BAR spaces (denoted as "host address" or
> > "address in CPU view"). The difference between the two addresses is
> > called "Address Translation Offset" or simply "translation", and can
> > be represented by "Address Translation Offset" in ACPI QWORD Address
> > Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> > definitions of QWORD Address Space Descriptor, and we will follow UEFI
> > definition on UEFI protocols, such as PCI root bridge IO protocol and
> > PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> > to apply to the Starting address to convert it to a PCI address". This
> > means:
> >
> > 1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> > 2. PciRootBridgeIo->Configuration should return CPU view address, as
> > well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> > Summary of addresses used:
> >
> > 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> > it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> 
> >
> > 2. Address returned by
> > EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> > is device address, or else PCI bus driver cannot set correct address
> > into PCI BAR registers.
> >
> > 3. Address returned by PciRootBridgeIo->Configuration is host address
> > per UEFI 2.7 definition.
> >
> > 4. Addresses used in GCD manipulation are host address.
> >
> > 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> > address, for they are allocated from GCD.
> >
> > 6. Address passed to PciHostBridgeResourceConflict is host address,
> > for it comes from ResAllocNode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo 
> > Cc: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > ---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > index 1494848..e8979eb 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> > +STATIC
> > +UINT64
> > +GetTranslationByResourceType (
> > +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> > +  IN  PCI_RESOURCE_TYPEResourceType
> > +  )
> > +{
> > +  switch (ResourceType) {
> > +case TypeIo:
> > +  return RootBridge->Io.Translation;
> > +case TypeMem32:
> > +  return RootBridge->Mem.Translation;
> > +case TypePMem32:
> > +  return RootBridge->PMem.Translation;
> > +case TypeMem64:
> > +  return RootBridge->MemAbove4G.Translation;
> > +case TypePMem64:
> > +  return RootBridge->PMemAbove4G.Translation;
> > +default:
> 
> (2) How about we return zero for TypeBus, explicitly, and then
> ASSERT(FALSE) and return zero for "default"?
> 
> > +  return 0;
> > +  }
> > +}
> > +
> >  /**
> >Ensure the compatibility of an IO space descriptor with the IO aperture.
> >
> > @@ -411,8 

[edk2] [PATCH] MdeModulePkg/RamDiskDxe: Perform MediaId check first in BlkIo services

[Hao Wu]

The commit places the check for MediaId at the beginning of Block IO
services:
RamDiskBlkIoReadBlocks and
RamDiskBlkIoWriteBlocks

This aligns with the Block IO protocol implementations for other
devices.

Cc: Ruiyu Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 .../Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
index f36e1c8ff2..4f74b5ef15 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
@@ -1,7 +1,7 @@
 /** @file
   Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2018, 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
@@ -137,6 +137,12 @@ RamDiskBlkIoReadBlocks (
   RAM_DISK_PRIVATE_DATA   *PrivateData;
   UINTN   NumberOfBlocks;
 
+  PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);
+
+  if (MediaId != PrivateData->Media.MediaId) {
+return EFI_MEDIA_CHANGED;
+  }
+
   if (Buffer == NULL) {
 return EFI_INVALID_PARAMETER;
   }
@@ -145,12 +151,6 @@ RamDiskBlkIoReadBlocks (
 return EFI_SUCCESS;
   }
 
-  PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);
-
-  if (MediaId != PrivateData->Media.MediaId) {
-return EFI_MEDIA_CHANGED;
-  }
-
   if ((BufferSize % PrivateData->Media.BlockSize) != 0) {
 return EFI_BAD_BUFFER_SIZE;
   }
@@ -212,14 +212,6 @@ RamDiskBlkIoWriteBlocks (
   RAM_DISK_PRIVATE_DATA   *PrivateData;
   UINTN   NumberOfBlocks;
 
-  if (Buffer == NULL) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  if (BufferSize == 0) {
-return EFI_SUCCESS;
-  }
-
   PrivateData = RAM_DISK_PRIVATE_FROM_BLKIO (This);
 
   if (MediaId != PrivateData->Media.MediaId) {
@@ -230,6 +222,14 @@ RamDiskBlkIoWriteBlocks (
 return EFI_WRITE_PROTECTED;
   }
 
+  if (Buffer == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (BufferSize == 0) {
+return EFI_SUCCESS;
+  }
+
   if ((BufferSize % PrivateData->Media.BlockSize) != 0) {
 return EFI_BAD_BUFFER_SIZE;
   }
-- 
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 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> marcandre.lur...@redhat.com
> Sent: Friday, February 23, 2018 9:23 PM
> To: edk2-devel@lists.01.org
> Cc: qemu-de...@nongnu.org; javi...@redhat.com; pjo...@redhat.com; Yao,
> Jiewen ; ler...@redhat.com
> Subject: [edk2] [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib
> dependency
> 
> From: Marc-André Lureau 
> 
> Apparently, unnecessary. Avoids extra build dependency and churn.
> 
> CC: Laszlo Ersek 
> CC: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marc-André Lureau 
> ---
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c   | 2 --
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 -
>  2 files changed, 3 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> index a7ae3354b5..3758fc6a41 100644
> --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> @@ -18,7 +18,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -44,7 +43,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  #define PERF_ID_TCG2_PEI  0x3080
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> index f7b85444d9..bc910c3baf 100644
> --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> @@ -58,7 +58,6 @@
>PerformanceLib
>MemoryAllocationLib
>ReportStatusCodeLib
> -  Tcg2PhysicalPresenceLib
>ResetSystemLib
> 
>  [Guids]
> --
> 2.16.1.73.g5832b7e9f2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 0/2] Create UART DebugLib implementation for runtime drivers

[Kinney, Michael D]

Ard,

Just a few comments:
* Please pre-initialize global mEfiAtRuntime = FALSE;
* The UNI file in the patch is identical to BaseDebugLibSerialPort.  
  Please update UNI file header and strings to describe this as the
  runtime version of the DebugLib as described in the .inf and .C files.
* gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue should be
  SOMETIMES_CONSUMES in the INF file.

With those changes:

Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, February 23, 2018 6:10 AM
> To: edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Laszlo
> Ersek ; Gao, Liming
> ; Kinney, Michael D
> ; af...@apple.com; Zeng,
> Star ; Ni, Ruiyu
> ; Ard Biesheuvel
> 
> Subject: Re: [PATCH v4 0/2] Create UART DebugLib
> implementation for runtime drivers
> 
> On 22 February 2018 at 19:56, Ard Biesheuvel
>  wrote:
> > Commit 4bf95a9f361e
> ("MdeModulePkg/ResetSystemRuntimeDxe: Add more debug
> > message") broke the DEBUG build for systems using a
> MMIO mapped UART for
> > DEBUG output. In other words, it broke the build for
> all ARM and AARCH64
> > systems, given that port I/O does not exist on those
> architectures.
> >
> > Instead of patching it up locally, let's fix this
> issue once and for all,
> > by creating a UART DebugLib implementation for
> DXE_RUNTIME_DRIVER modules
> > that does the right thing by default.
> >
> > v4:
> > - add Laszlo's R-b
> > - keep ASSERT() message in local buffer even it is
> not printed to the serial
> >   port, to allow it to be accessed via the debugger
> >
> 
> Mike,
> 
> Given that all ARM and AARCH64 DEBUG builds are still
> broken, may we
> please have your R-b on this patch so we can proceed to
> start fixing
> things?
> 
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/7] HACK: HobLib: workaround infinite loop

[Andrew Fish]

> On Feb 23, 2018, at 5:23 AM, marcandre.lur...@redhat.com wrote:
> 
> From: Marc-André Lureau 
> 
> Without this hack, GetNextHob() loops infinitely with the next patch.
> I don't understand the reason.
> 
> The loop is triggered by the GetFirstGuidHob () call.
> 
> CC: Laszlo Ersek 
> CC: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marc-André Lureau 
> ---
> MdePkg/Library/PeiHobLib/HobLib.c | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/MdePkg/Library/PeiHobLib/HobLib.c 
> b/MdePkg/Library/PeiHobLib/HobLib.c
> index 5c0eeb992f..ed3c5fbd6d 100644
> --- a/MdePkg/Library/PeiHobLib/HobLib.c
> +++ b/MdePkg/Library/PeiHobLib/HobLib.c
> @@ -89,6 +89,10 @@ GetNextHob (
> if (Hob.Header->HobType == Type) {
>   return Hob.Raw;
> }
> +if (GET_HOB_LENGTH (HobStart) == 0) {

As Laszlo points out this error condition is likely memory corruption. Thus it 
would be better to check for all know illegal values? 

if (GET_HOB_LENGTH(HobStart) < sizeof (EFI_HOB_GENERIC_HEADER)

Thanks,

Andrew Fish

> +DEBUG ((DEBUG_INFO, "FIXME: GetNextHob length == 0"));
> +return NULL;
> +}
> Hob.Raw = GET_NEXT_HOB (Hob);
>   }
>   return NULL;
> -- 
> 2.16.1.73.g5832b7e9f2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH 3/7] HACK: HobLib: workaround infinite loop

[Laszlo Ersek]

On 02/23/18 14:23, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Without this hack, GetNextHob() loops infinitely with the next patch.
> I don't understand the reason.
> 
> The loop is triggered by the GetFirstGuidHob () call.
> 
> CC: Laszlo Ersek 
> CC: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marc-André Lureau 
> ---
>  MdePkg/Library/PeiHobLib/HobLib.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MdePkg/Library/PeiHobLib/HobLib.c 
> b/MdePkg/Library/PeiHobLib/HobLib.c
> index 5c0eeb992f..ed3c5fbd6d 100644
> --- a/MdePkg/Library/PeiHobLib/HobLib.c
> +++ b/MdePkg/Library/PeiHobLib/HobLib.c
> @@ -89,6 +89,10 @@ GetNextHob (
>  if (Hob.Header->HobType == Type) {
>return Hob.Raw;
>  }
> +if (GET_HOB_LENGTH (HobStart) == 0) {
> +DEBUG ((DEBUG_INFO, "FIXME: GetNextHob length == 0"));
> +return NULL;
> +}
>  Hob.Raw = GET_NEXT_HOB (Hob);
>}
>return NULL;
> 

Strange. The HobLength field is supposed to include the size of the HOB header, 
so it should never be zero.

Furthermore, the PEI core initializes the HOB list; it should be terminated 
with an End-of-HOB-List HOB:

PeiCore() [MdeModulePkg/Core/Pei/PeiMain/PeiMain.c]
  InitializeMemoryServices()  
[MdeModulePkg/Core/Pei/Memory/MemoryServices.c]
PeiCoreBuildHobHandoffInfoTable() [MdeModulePkg/Core/Pei/Hob/Hob.c]

I tried to reproduce this issue by:
- applying patches 1, 2, and 4
- in function PeimEntryMA(), file "SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c", moving 
the GetFirstGuidHob () call to the top of the function.

It didn't hang for me.

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

Re: [edk2] [PATCH 2/7] ovmf: link with Tcg2ConfigPei module

[Laszlo Ersek]

On 02/23/18 14:23, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> This module initializes TPM device type based on variable and
> detection.

(1) I suggest we say the following here:

"The Tcg2ConfigPei module informs the firmware globally about the TPM
device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
GUID value. The original module under SecurityPkg can perform device
detection, or read a cached value from a non-volatile UEFI variable.
OvmfPkg's clone of the module always performs the hardware detection."

Becase...

> The module requires VariablePei, which is built with
> MEM_VARSTORE_EMU_ENABLE=FALSE.

(2) ... as I hinted in my response to your blurb, and also as suggested
by "Tcg2ConfigPei.inf", we should clone Tcg2ConfigPei for OVMF, and
*trim it* quite a bit.

- The new location should be "OvmfPkg/Tcg/Tcg2Config/".

- We need not copy the ".uni" file (also drop MODULE_UNI_FILE from the
INF file)

- Re-generate FILE_GUID in the INF file with "uuidgen"

- Remove all PEI-phase variable access; always perform the hw detection.

- I would even suggest removing support for TPM1.2. Just check whether
TPM2 is available or not.


(3) Ultimately, this is what the module should do:

- Check the QEMU hardware for TPM2 availability only

- If found, set the dynamic PCD "PcdTpmInstanceGuid" to
   This is what informs the rest of
  the firmware about the TPM type.

- Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
  PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
  In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
  and the consumption of the "TPM type" PCD.

- If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
  (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
  no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)


(4) Regarding the TPM detection itself. It looks like DetectTpmDevice()
[SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPeim.c] calls a number of TPM1.2
functions. If the earliest one fails, it assumes "no TPM" at all, but if
only a later call fails, it deduces, from the 1.2 failure, that TPM2 exists.

I think we can do better than this, in our Tcg2ConfigPei clone:

- We should call Tpm2RequestUseTpm() directly, from
"SecurityPkg/Include/Library/Tpm2DeviceLib.h".

- And, Tpm2Startup(), from
"SecurityPkg/Include/Library/Tpm2CommandLib.h", will be called by Tcg2Pei.


(5) Finally, there's no need to set "PcdTpmInitializationPolicy" to
anything. I don't see it consumed by any module that we should include
in OVMF. (More on this below.)


(6) Now, I realize Tcg2Pei *apparently* depends on
gEfiPeiReadOnlyVariable2PpiGuid (i.e., read-only variable access in the
PEI phase) as well. That's a bug in the INF file (the [depex] section).
If you grep the Tcg2Pei module source for the GUID, the [depex] section
is the only hit. Can you please submit a separate patch that removes it
from the depex?


> CC: Laszlo Ersek 
> CC: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marc-André Lureau 
> ---
>  OvmfPkg/OvmfPkgX64.dsc | 20 
>  OvmfPkg/OvmfPkgX64.fdf |  3 +++
>  2 files changed, 23 insertions(+)

Is there any particular reason to exclude the Ia32 and Ia32X64 builds?

If not, then please modify all three sets of dsc/fdf files identically.

> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 32c57b04e1..b5cbe8430f 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -40,6 +40,7 @@

(7) Please implement the following git settings in your edk2 clone:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05

(in particular "xfuncname")

and

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

This will help reviewers see what section of the DSC / FDF / INI / DEC
files are modified by a patch hunk.

>DEFINE SMM_REQUIRE = FALSE
>DEFINE TLS_ENABLE  = FALSE
>DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
> +  DEFINE TPM2_ENABLE = FALSE
>  
>#
># Flash size selection. Setting FD_SIZE_IN_KB on the command line directly 
> to
> @@ -209,6 +210,11 @@
>
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>  
> +!if $(TPM2_ENABLE) == TRUE
> +  Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf
> +  Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
> +!endif
> +

(8) For the patch, as posted, resolving Tpm2CommandLib looks unneeded,
because "SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" doesn't seem to
depend on 

Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet

[Carsey, Jaben]

Thanks Laszlo!

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, February 23, 2018 4:02 AM
> To: Meenakshi Aggarwal 
> Cc: Ni, Ruiyu ; Carsey, Jaben
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> Importance: High
> 
> On 02/23/18 11:26, Meenakshi Aggarwal wrote:
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Friday, February 23, 2018 3:48 PM
> >> To: Meenakshi Aggarwal ; Ni, Ruiyu
> >> ; Carsey, Jaben ; edk2-
> >> de...@lists.01.org
> >> Subject: Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> >>
> >> On 02/23/18 10:57, Meenakshi Aggarwal wrote:
> >>> Hi All,
> >>>
> >>> Any comments on this patch or is it good to go?
> >>>
> >>> Reviewed-by: Jaben Carsey 
> >>> Reviewed-by: Ruiyu Ni 
> >>
> >> Are you asking for someone to commit & push the patch?
> >>
> > I request for both, comments (if any), else please push this patch.
> 
> The patch has been on the list for ~7 days, and it has R-b's from both
> ShellPkg maintainers.
> 
> I've pushed it for you now. Commit d624deb7abf9.
> 
> Thank you for the bugfix!
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v3 0/6] Add Secure96 mezzanine support

[Ard Biesheuvel]

On 23 February 2018 at 15:56, Leif Lindholm  wrote:
> On Fri, Feb 23, 2018 at 03:40:46PM +, Ard Biesheuvel wrote:
>> This v3 (as did v2) implements a complete split between the generic
>> 96boards LS connector support and its associated plumbing (defining which
>> I2C, SPI and GPIO controllers are connected) on the one hand, and support
>> for the Secure96 mezzanine board in particular on the other. More
>> specifically, all Secure96 PCDs were dropped, and the only platform
>> specific configuration that remains is including the Secure96 driver
>> and the driver for its peripherals to the build.
>>
>> v3:
>> - The ATSHA204A driver has been merged, so it has been dropped from this
>>   series.
>> - Rename Platform/NinetySixBoards back to Platform/96Boards. Note that in
>>   some places, using leading digits is problematic so the string does still
>>   occur in a couple of places.
>> - Rebase onto EDK2 that has the MultiPhase.h VFR changes.
>
> All of my feedback has been addressed, so for the series:
> Reviewed-by: Leif Lindholm 
>
> If we get enum support in VfrCompile in the future, a minor cleanup to
> the code introduced by 5/6 will be possible, but this is an excellent
> start to a generic mezzanine infrastructure - thanks!


Thank you

Pushed as 487015fb23c1..d8e4d4565841
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency

[Laszlo Ersek]

On 02/23/18 14:23, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Apparently, unnecessary. Avoids extra build dependency and churn.
> 
> CC: Laszlo Ersek 
> CC: Stefan Berger 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marc-André Lureau 
> ---
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c   | 2 --
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 -
>  2 files changed, 3 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c 
> b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> index a7ae3354b5..3758fc6a41 100644
> --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> @@ -18,7 +18,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -44,7 +43,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #define PERF_ID_TCG2_PEI  0x3080
>  
> diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf 
> b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> index f7b85444d9..bc910c3baf 100644
> --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
> @@ -58,7 +58,6 @@
>PerformanceLib
>MemoryAllocationLib
>ReportStatusCodeLib
> -  Tcg2PhysicalPresenceLib
>ResetSystemLib
>  
>  [Guids]
> 

Good catch.

Reviewed-by: Laszlo Ersek 

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

Re: [edk2] [PATCH edk2-platforms v3 0/6] Add Secure96 mezzanine support

[Leif Lindholm]

On Fri, Feb 23, 2018 at 03:40:46PM +, Ard Biesheuvel wrote:
> This v3 (as did v2) implements a complete split between the generic
> 96boards LS connector support and its associated plumbing (defining which
> I2C, SPI and GPIO controllers are connected) on the one hand, and support
> for the Secure96 mezzanine board in particular on the other. More
> specifically, all Secure96 PCDs were dropped, and the only platform
> specific configuration that remains is including the Secure96 driver
> and the driver for its peripherals to the build.
> 
> v3:
> - The ATSHA204A driver has been merged, so it has been dropped from this
>   series.
> - Rename Platform/NinetySixBoards back to Platform/96Boards. Note that in
>   some places, using leading digits is problematic so the string does still
>   occur in a couple of places.
> - Rebase onto EDK2 that has the MultiPhase.h VFR changes.

All of my feedback has been addressed, so for the series:
Reviewed-by: Leif Lindholm 

If we get enum support in VfrCompile in the future, a minor cleanup to
the code introduced by 5/6 will be possible, but this is an excellent
start to a generic mezzanine infrastructure - thanks!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/7] RFC: ovmf: preliminary TPM2 support

[Laszlo Ersek]

On 02/23/18 14:23, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> Hi,
> 
> The following series adds basic TPM2 support for OVMF-on-QEMU (I
> haven't tested TPM1, for lack of interest). It links with the modules
> to initializes the device in PEI phase, and do measurements (both PEI
> and DXE). The Tcg2Dxe module provides the Tcg2 protocol which allows
> the guest to access the measurement log and other facilities.
> 
> DxeTpm2MeasureBootLib seems to do its job at measuring images that are
> not measured in PEI phase (such as PCI PXE rom)
> 
> Tcg2ConfigDxe is mostly interesting for debugging for now.
> 
> A major lack is the support for Physical Present Interface (PPI, more
> below).
> 
> Linux guests seem to work fine. But windows guest generally complains
> about the lack of PPI interface (most HLK tests require it, tpm.msc
> admin interactions too). I haven't done "real" use-cases tests, as I
> lack experience with TPM usage. Any help appreciated to test the TPM.
> 
> Tcg2ConfigPei requires variable access, therefore
>  must be solved
> first. I used "[edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM,
> defragment the UEFI memmap" as a base for this series.
> 
> I build edk2 with:
> 
> $ build -DTPM2_ENABLE -DSECURE_BOOT_ENABLE  -DMEM_VARSTORE_EMU_ENABLE=FALSE
> 
> I test with qemu & swtpm/libtpms (tpm2 branches, swtpm_setup.sh --tpm2 
> --tpm-state tpmstatedir)
> 
> $ swtpm socket --tpmstate tpmstatedir --ctrl type=unixio,path=tpmsock  --tpm2 
> &
> $ qemu .. -chardev socket,id=chrtpm,path=tpmsock -tpmdev 
> emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0

Thanks for this work -- extra thanks for the instructions regarding the
software TPM backend.

> PPI is problematic, because we generally don't want or need SMM, and
> qemu is preferred to provide the ACPI tables. We therefore exclude
> using Tcg2Smm for now (which also brings other problems). Stefan
> Berger has been prototyping qemu code that provides PPI ACPI
> interface, but there is some complication regarding memory location,
> using a fixed address. My understanding is that the firmware
> (seabios/edk2) should allocate the required memory itself (using qemu
> linker script for ex) and patch the ACPI table. Then it's hopefully
> only a matter of hooking Tcg2PhysicalPresenceLibProcessRequest() as
> was done by Stefan in
> https://github.com/stefanberger/edk2/commits/tpm2. The main problem I
> see with this approach is that the location should remain stable
> across reboots (not necessarily poweroff, edk2 uses nvram variables
> for PPI flags). More investigation and help needed to support PPI!

Indeed the main requirement for the OS to queue PPI operations for the
next boot of the firmware seems a "semi-persistent" storage. "Semi-"
because we target (warm) reboot, not complete poweroff plus re-launch.

The ACPI linker/loader is not suitable for this. It is great for making
the firmware allocate memory, but such allocations are never expected to
be stable. At the first boot, the firmware can allocate some blob just
fine, patch ACPI tables with the allocation address, and even write back
the allocation address to QEMU (for some device model to use).
Furthermore, the kernel can populate this blob. However, at reboot, the
firmware won't know where to look.

The firmware could use / set aside a RAM area at a dedicated
(pre-defined) memory address for this. However, that is incompatible
with our goal that as much as possible ACPI stuff should be generated
by, and come from, QEMU. We should also minimize the differences between
SeaBIOS and OVMF.

So, we need some kind of emulated NVRAM for the PPI opcode storage, such
that both its contents and its address survive a warm reboot.

- For SeaBIOS this means dedicated hw support from QEMU (hence Stefan's
"virtual memory device" as part of the TPM MMIO register block).

- For OVMF, in theory the pflash chip could be used, via UEFI variables.
However, this requires QEMU-generated AML to call into the firmware
(namely the UEFI variable driver). This is only possible with SMM (there
is no calling convention, from AML to the firmware, other than
formatting a request buffer and raising an SMI). That would mean many
complications, and also limit the feature to Q35.

So, as long as we'd like to target both firmwares eventually, the PPI
opcode storage should be carved out of the TPM MMIO register block, and
OVMF should be taught to consume the opcodes from there.


I'll try to go through these patches soon.

FWIW, the dependency on Tcg2ConfigPei is not great. I've tried to
upstream my series for TianoCore BZ#386 several times, and I've always
failed.

In
,
Jiewen wrote,

"Tcg2ConfigPei/Dxe are platform sample driver. A platform may have its
own version based upon platform requirement [...]"

So, because 

[edk2] [PATCH edk2-platforms v3 4/6] Platform/96Boards: add a driver for the Secure96 mezzanine board

[Ard Biesheuvel]

Add a driver that describes the Secure96 mezzanine board, and exposes
both the information required to describe it to the OS using a DT overlay,
and to describe it to UEFI itself.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/96Boards/Secure96Dxe/Secure96.dts|  85 
 Platform/96Boards/Secure96Dxe/Secure96.h  |  26 +++
 Platform/96Boards/Secure96Dxe/Secure96Dxe.c   | 211 
 Platform/96Boards/Secure96Dxe/Secure96Dxe.inf |  67 +++
 4 files changed, 389 insertions(+)

diff --git a/Platform/96Boards/Secure96Dxe/Secure96.dts 
b/Platform/96Boards/Secure96Dxe/Secure96.dts
new file mode 100644
index ..b56ce59985cc
--- /dev/null
+++ b/Platform/96Boards/Secure96Dxe/Secure96.dts
@@ -0,0 +1,85 @@
+/** @file
+ * Copyright (c) 2018, Linaro Limited. All rights reserved.
+ *
+ * This program and the accompanying materials are licensed and made
+ * available under the terms and conditions of the BSD License which
+ * accompanies this distribution.  The full text of the license may be
+ * found at http://opensource.org/licenses/bsd-license.php
+ *
+ * THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+ * IMPLIED.
+ */
+
+#include "Secure96.h"
+
+//
+// Define a placeholder value for the GPIO phandle property cells appearing
+// in this file. It is up to the driver code to discover the actual phandle
+// value from the platform device tree and patch the overlay DTB before it
+// can be applied.
+//
+#define GPIO_PARENT_PLACEHOLDER_PHANDLE 0x0
+
+/dts-v1/;
+/plugin/;
+
+/ {
+fragment@0 {
+target-path = "I2C_PARENT_PLACEHOLDER_STRING";
+__overlay__ {
+clock-frequency = <10>;
+
+ATSHA204A_DT_NODENAME {
+compatible = "atmel,atsha204a";
+reg = ;
+};
+
+ATECC508A_DT_NODENAME {
+compatible = "atmel,atecc508a";
+reg = ;
+};
+};
+};
+
+fragment@1 {
+target-path = "SPI_PARENT_PLACEHOLDER_STRING";
+__overlay__ {
+INFINEON_SLB9670_DT_NODENAME {
+compatible = "infineon,slb9670";
+reg = ;
+spi-max-frequency = <2250>;
+};
+};
+};
+
+fragment@2 {
+target-path = "/";
+__overlay__ {
+gpio-leds {
+compatible = "gpio-leds";
+
+secure96-u1 {
+gpios = ;
+};
+secure96-u2 {
+gpios = ;
+};
+secure96-u3 {
+gpios = ;
+};
+secure96-u4 {
+gpios = ;
+};
+};
+};
+};
+};
diff --git a/Platform/96Boards/Secure96Dxe/Secure96.h 
b/Platform/96Boards/Secure96Dxe/Secure96.h
new file mode 100644
index ..84b8aed13d1e
--- /dev/null
+++ b/Platform/96Boards/Secure96Dxe/Secure96.h
@@ -0,0 +1,26 @@
+/** @file
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _SECURE96_H_
+#define _SECURE96_H_
+
+#define ATSHA204A_SLAVE_ADDRESS 0x60
+#define ATSHA204A_DT_NODENAME   atsha204a@60
+
+#define ATECC508A_SLAVE_ADDRESS 0x51
+#define ATECC508A_DT_NODENAME   atecc508a@51
+
+#define INFINEON_SLB9670_SPI_CS 0x0
+#define INFINEON_SLB9670_DT_NODENAMEtpm@0
+
+#endif // _SECURE96_H_
diff --git a/Platform/96Boards/Secure96Dxe/Secure96Dxe.c 
b/Platform/96Boards/Secure96Dxe/Secure96Dxe.c
new file mode 100644
index ..6c48d7c0b024
--- /dev/null
+++ b/Platform/96Boards/Secure96Dxe/Secure96Dxe.c
@@ -0,0 +1,211 @@
+/** @file
+  96boards Secure96 mezzanine board DXE driver.
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "Secure96.h"
+
+STATIC CONST UINT32 

[edk2] [PATCH edk2-platforms v3 2/6] Platform/96Boards: introduce I2C driver

[Ard Biesheuvel]

Implement a I2C DXE driver that wires up the I2C devices exposed by
a 96boards mezzanine into the EDK2 I2C stack. Note that this requires
the platform to identify its I2C master implementations using special
GUIDs-as-protocols. It also assumes [for now] that I2C buses are not
shared between the 96boards connector and other platform peripherals.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c   | 206 
 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.inf |  51 +
 2 files changed, 257 insertions(+)

diff --git a/Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c 
b/Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c
new file mode 100644
index ..79bb9ed5ffee
--- /dev/null
+++ b/Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c
@@ -0,0 +1,206 @@
+/** @file
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution. The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+STATIC MEZZANINE_PROTOCOL *mMezzanine;
+
+typedef struct {
+  EFI_I2C_ENUMERATE_PROTOCOLI2cEnumerate;
+  EFI_I2C_BUS_CONFIGURATION_MANAGEMENT_PROTOCOL I2cConfigManagement;
+  EFI_HANDLEI2cMasterHandle;
+  UINT32BusFrequency;
+  UINTN NumDevices;
+  CONST EFI_I2C_DEVICE  *Devices;
+} I2C_BUS;
+
+STATIC
+EFI_STATUS
+EFIAPI
+I2cEnumerate (
+  IN CONST EFI_I2C_ENUMERATE_PROTOCOL *This,
+  IN OUT CONST EFI_I2C_DEVICE **Device
+  )
+{
+  I2C_BUS *Bus;
+
+  if (Device == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  Bus = BASE_CR (This, I2C_BUS, I2cEnumerate);
+
+  if (Bus->NumDevices == 0 ||
+  (Bus->NumDevices > 0 && *Device == >Devices[Bus->NumDevices - 1])) {
+*Device = NULL;
+  } else if (*Device == NULL) {
+*Device = >Devices[0];
+  } else if (Bus->NumDevices > 1 &&
+ *Device >= >Devices[0] &&
+ *Device < >Devices[Bus->NumDevices - 1]) {
+++*Device;
+  } else {
+return EFI_NO_MAPPING;
+  }
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+I2cGetBusFrequency (
+  IN CONST EFI_I2C_ENUMERATE_PROTOCOL *This,
+  IN UINTNI2cBusConfiguration,
+  OUT UINTN   *BusClockHertz
+  )
+{
+  I2C_BUS *Bus;
+
+  if (BusClockHertz == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (I2cBusConfiguration > 0) {
+return EFI_NO_MAPPING;
+  }
+
+  Bus = BASE_CR (This, I2C_BUS, I2cEnumerate);
+
+  *BusClockHertz = Bus->BusFrequency;
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+EnableI2cBusConfiguration (
+  IN CONST EFI_I2C_BUS_CONFIGURATION_MANAGEMENT_PROTOCOL  *This,
+  IN UINTNI2cBusConfiguration,
+  IN EFI_EVENTEvent   OPTIONAL,
+  IN EFI_STATUS   *I2cStatus  OPTIONAL
+  )
+{
+  EFI_I2C_MASTER_PROTOCOL *I2cMaster;
+  EFI_STATUS  Status;
+  UINTN   BusClockHertz;
+  I2C_BUS *Bus;
+
+  if (I2cBusConfiguration > 0) {
+return EFI_NO_MAPPING;
+  }
+
+  Bus = BASE_CR (This, I2C_BUS, I2cConfigManagement);
+
+  Status = gBS->HandleProtocol (Bus->I2cMasterHandle,
+  , (VOID **));
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: gBS->HandleProtocol() failed - %r\n",
+  __FUNCTION__, Status));
+return Status;
+  }
+
+  BusClockHertz = Bus->BusFrequency;
+  Status = I2cMaster->SetBusFrequency (I2cMaster, );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: I2cMaster->SetBusFrequency() failed - %r\n",
+  __FUNCTION__, Status));
+return Status;
+  }
+
+  if (Event != NULL) {
+*I2cStatus = EFI_SUCCESS;
+gBS->SignalEvent (Event);
+  }
+  return EFI_SUCCESS;
+}
+
+STATIC I2C_BUS mI2cBus0 = {
+  { I2cEnumerate, I2cGetBusFrequency },
+  { EnableI2cBusConfiguration },
+  NULL,
+  FixedPcdGet32 (PcdI2c0BusFrequencyHz),
+  0,
+  NULL,
+};
+
+STATIC I2C_BUS mI2cBus1 = {
+  { I2cEnumerate, I2cGetBusFrequency },
+  { EnableI2cBusConfiguration },
+  NULL,
+  FixedPcdGet32 (PcdI2c1BusFrequencyHz),
+  0,
+  NULL,
+};
+
+STATIC
+VOID
+RegisterI2cBus (
+  IN  EFI_GUID*Guid,
+  IN  I2C_BUS *I2cBus,
+  IN  UINTN   NumDevices,
+  IN  CONST EFI_I2C_DEVICE*Devices
+  )
+{
+  

[edk2] [PATCH edk2-platforms v3 6/6] Platform/Socionext/DeveloperBox: add 96Boards mezzanine support

[Ard Biesheuvel]

Wire up the various drivers for the 96Boards LS connector and the
optional Secure96 mezzanine board. Note that this includes a [Rule]
update that allows .dtb binaries to be bundled with DXE drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc| 34 

 Platform/Socionext/DeveloperBox/DeveloperBox.fdf| 10 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c   |  9 ++
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf |  2 ++
 4 files changed, 55 insertions(+)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 3c109b495fbc..afd0a4f59f00 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -31,6 +31,9 @@ [Defines]
 [BuildOptions]
   RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
 
+  # add ample padding to the DTC so we can apply 96boards mezzanine overlays
+  *_*_*_DTC_FLAGS = -p 1024
+
 
[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
   GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
 
@@ -396,6 +399,28 @@ [PcdsFixedAtBuild.common]
 !endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareRevision|$(BUILD_NUMBER)
 
+  #
+  # 96boards mezzanine support
+  #
+  g96BoardsTokenSpaceGuid.PcdI2c0Parent|"/i2c@5121"
+  g96BoardsTokenSpaceGuid.PcdI2c0BusFrequencyHz|10
+  g96BoardsTokenSpaceGuid.PcdSpiParent|"/spi@5481"
+  g96BoardsTokenSpaceGuid.PcdGpioParent|"/gpio@5100"
+  g96BoardsTokenSpaceGuid.PcdGpioPolarity|0
+
+  g96BoardsTokenSpaceGuid.PcdGpioPinA|10
+  g96BoardsTokenSpaceGuid.PcdGpioPinB|11
+  g96BoardsTokenSpaceGuid.PcdGpioPinC|12
+  g96BoardsTokenSpaceGuid.PcdGpioPinD|13
+  g96BoardsTokenSpaceGuid.PcdGpioPinE|18
+  g96BoardsTokenSpaceGuid.PcdGpioPinF|19
+  g96BoardsTokenSpaceGuid.PcdGpioPinG|20
+  g96BoardsTokenSpaceGuid.PcdGpioPinH|21
+  g96BoardsTokenSpaceGuid.PcdGpioPinI|22
+  g96BoardsTokenSpaceGuid.PcdGpioPinJ|23
+  g96BoardsTokenSpaceGuid.PcdGpioPinK|24
+  g96BoardsTokenSpaceGuid.PcdGpioPinL|25
+
 [PcdsPatchableInModule]
   gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|0
@@ -642,6 +667,15 @@ [Components.common]
   SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf
 
   #
+  # 96board mezzanine support
+  #
+  Platform/96Boards/Secure96Dxe/Secure96Dxe.inf
+  Silicon/Atmel/AtSha204a/AtSha204aDxe.inf
+  Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.inf
+  Platform/96Boards/LsConnectorDxe/LsConnectorDxe.inf
+
+  #
   # I2C
   #
   Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
+  MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
index b668f42c7962..130572009fd0 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
@@ -237,9 +237,18 @@ [FV.FvMain]
   }
 
   #
+  # 96board mezzanine support
+  #
+  INF Platform/96Boards/Secure96Dxe/Secure96Dxe.inf
+  INF Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.inf
+  INF Silicon/Atmel/AtSha204a/AtSha204aDxe.inf
+  INF Platform/96Boards/LsConnectorDxe/LsConnectorDxe.inf
+
+  #
   # I2C
   #
   INF Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf
+  INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
 
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
@@ -421,6 +430,7 @@ [Rule.Common.DXE_DRIVER]
 DXE_DEPEXDXE_DEPEX  Optional 
$(INF_OUTPUT)/$(MODULE_NAME).depex
 PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
 UI   STRING="$(MODULE_NAME)" Optional
+RAW  BINOptional|.dtb
   }
 
 [Rule.Common.DXE_RUNTIME_DRIVER]
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
index aab830dc3a5a..8787aa6288a7 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c
@@ -313,6 +313,15 @@ PlatformDxeEntryPoint (
  );
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Install the g96BoardsI2c0MasterGuid GUID onto the same handle,
+  // identifying I2C #1 on our SoC as I2C #0 on the 96boards low speed 
connector
+  //
+  Status = gBS->InstallProtocolInterface (,
+  ,
+  EFI_NATIVE_INTERFACE, NULL);
+  ASSERT_EFI_ERROR (Status);
+
   SmmuEnableCoherentDma ();
   SetMmioTimerFrequency ();
 
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf 

[edk2] [PATCH edk2-platforms v3 3/6] Platform/96Boards: introduce LsConnector protocol

[Ard Biesheuvel]

Introduce a protocol describing the presence of a 96boards low speed (LS)
connector, and identifying the type of mezzanine that has been installed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/96Boards/96Boards.dec   |  3 ++
 Platform/96Boards/Include/Protocol/LsConnector.h | 35 
 2 files changed, 38 insertions(+)

diff --git a/Platform/96Boards/96Boards.dec b/Platform/96Boards/96Boards.dec
index 2a063ced9e4a..fa8e639b1a11 100644
--- a/Platform/96Boards/96Boards.dec
+++ b/Platform/96Boards/96Boards.dec
@@ -25,6 +25,9 @@ [Protocols]
   ## Include/Protocol/Mezzanine.h
   g96BoardsMezzanineProtocolGuid = { 0xf0467a37, 0x3436, 0x40ef, { 0x94, 0x09, 
0x4d, 0x1d, 0x7f, 0x51, 0x06, 0xd3 } }
 
+  ## Include/Protocol/LsConnector.h
+  g96BoardsLsConnectorProtocolGuid = { 0xae548d4c, 0x9062, 0x4eed, { 0x83, 
0x5f, 0xf5, 0x10, 0xf8, 0xfc, 0x48, 0xaf } }
+
 [Guids]
   # PCD scope GUID
   g96BoardsTokenSpaceGuid = { 0xe0d2f33a, 0xb7dd, 0x4a69, { 0xb6, 0x76, 0xda, 
0xe8, 0xa4, 0x17, 0xa7, 0xb5 } }
diff --git a/Platform/96Boards/Include/Protocol/LsConnector.h 
b/Platform/96Boards/Include/Protocol/LsConnector.h
new file mode 100644
index ..f337cfe0f709
--- /dev/null
+++ b/Platform/96Boards/Include/Protocol/LsConnector.h
@@ -0,0 +1,35 @@
+/** @file
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _LS_CONNECTOR_H_
+#define _LS_CONNECTOR_H_
+
+#define LS_CONNECTOR_PROTOCOL_GUID \
+  { 0xae548d4c, 0x9062, 0x4eed, { 0x83, 0x5f, 0xf5, 0x10, 0xf8, 0xfc, 0x48, 
0xaf } }
+
+typedef struct _LS_CONNECTOR_PROTOCOL LS_CONNECTOR_PROTOCOL;
+
+typedef enum {
+  MezzanineUnknown,
+  MezzanineSecure96,
+  MezzanineMax
+} MEZZANINE_TYPE;
+
+struct _LS_CONNECTOR_PROTOCOL {
+  MEZZANINE_TYPE  MezzanineType;
+};
+
+extern EFI_GUID g96BoardsLsConnectorProtocolGuid;
+
+#endif // _LS_CONNECTOR_H_
-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v3 0/6] Add Secure96 mezzanine support

[Ard Biesheuvel]

This v3 (as did v2) implements a complete split between the generic
96boards LS connector support and its associated plumbing (defining which
I2C, SPI and GPIO controllers are connected) on the one hand, and support
for the Secure96 mezzanine board in particular on the other. More
specifically, all Secure96 PCDs were dropped, and the only platform
specific configuration that remains is including the Secure96 driver
and the driver for its peripherals to the build.

v3:
- The ATSHA204A driver has been merged, so it has been dropped from this
  series.
- Rename Platform/NinetySixBoards back to Platform/96Boards. Note that in
  some places, using leading digits is problematic so the string does still
  occur in a couple of places.
- Rebase onto EDK2 that has the MultiPhase.h VFR changes.

Patch #1 introduces the mezzanine protocol, which abstracts away from
any particular mezzanine implementation.

Patch #2 introduces the generic I2C plumbing for any mezzanine that exposes
I2C peripherals.

Patch #3 implements the protocol that asserts the presence of a 96boards LS
connector and the type of mezzanine connected to it.

Patch #4 adds the Secure96 driver, which incorporates the DT overlay, and
a description of the I2C peripheral.

Patch #5 adds a LS connector driver for configuring the type of mezzanine,
and to interface with it at end of DXE time to install the appropriate DT
overlay.

Patch #6 wires everything up for the DeveloperBox platform.

Ard Biesheuvel (6):
  Platform/96Boards: introduce package and mezzanine protocol
  Platform/96Boards: introduce I2C driver
  Platform/96Boards: introduce LsConnector protocol
  Platform/96Boards: add a driver for the Secure96 mezzanine board
  Platform/96Boards: add driver for low speed (LS) connector
  Platform/Socionext/DeveloperBox: add 96Boards mezzanine support

 Platform/96Boards/96Boards.dec  |  73 +++
 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c   | 206 
++
 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.inf |  51 +
 Platform/96Boards/Include/Guid/FormSet.h|  23 ++
 Platform/96Boards/Include/Protocol/LsConnector.h|  35 
 Platform/96Boards/Include/Protocol/Mezzanine.h  |  71 +++
 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c   | 221 

 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.h   |  32 +++
 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.inf |  57 +
 Platform/96Boards/LsConnectorDxe/LsConnectorHii.uni |  27 +++
 Platform/96Boards/LsConnectorDxe/LsConnectorHii.vfr |  45 
 Platform/96Boards/Secure96Dxe/Secure96.dts  |  85 
 Platform/96Boards/Secure96Dxe/Secure96.h|  26 +++
 Platform/96Boards/Secure96Dxe/Secure96Dxe.c | 211 
+++
 Platform/96Boards/Secure96Dxe/Secure96Dxe.inf   |  67 ++
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc|  34 +++
 Platform/Socionext/DeveloperBox/DeveloperBox.fdf|  10 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c   |   9 +
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf |   2 +
 19 files changed, 1285 insertions(+)
 create mode 100644 Platform/96Boards/96Boards.dec
 create mode 100644 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.c
 create mode 100644 Platform/96Boards/96BoardsI2cDxe/96BoardsI2cDxe.inf
 create mode 100644 Platform/96Boards/Include/Guid/FormSet.h
 create mode 100644 Platform/96Boards/Include/Protocol/LsConnector.h
 create mode 100644 Platform/96Boards/Include/Protocol/Mezzanine.h
 create mode 100644 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c
 create mode 100644 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.h
 create mode 100644 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.inf
 create mode 100644 Platform/96Boards/LsConnectorDxe/LsConnectorHii.uni
 create mode 100644 Platform/96Boards/LsConnectorDxe/LsConnectorHii.vfr
 create mode 100644 Platform/96Boards/Secure96Dxe/Secure96.dts
 create mode 100644 Platform/96Boards/Secure96Dxe/Secure96.h
 create mode 100644 Platform/96Boards/Secure96Dxe/Secure96Dxe.c
 create mode 100644 Platform/96Boards/Secure96Dxe/Secure96Dxe.inf

-- 
2.11.0

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

[edk2] [PATCH edk2-platforms v3 5/6] Platform/96Boards: add driver for low speed (LS) connector

[Ard Biesheuvel]

This adds a driver that manages the 96Boards LS connector, i.e, it
installs a HII page to configure the type of mezzanine that is installed
in the slot, and it exposes this information via the LS connector protocol.
It is also in charge of applying the overlay to the platform device tree
at end of DXE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/96Boards/96Boards.dec  |   3 +
 Platform/96Boards/Include/Guid/FormSet.h|  23 ++
 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c   | 221 
 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.h   |  32 +++
 Platform/96Boards/LsConnectorDxe/LsConnectorDxe.inf |  57 +
 Platform/96Boards/LsConnectorDxe/LsConnectorHii.uni |  27 +++
 Platform/96Boards/LsConnectorDxe/LsConnectorHii.vfr |  45 
 7 files changed, 408 insertions(+)

diff --git a/Platform/96Boards/96Boards.dec b/Platform/96Boards/96Boards.dec
index fa8e639b1a11..49641828aa60 100644
--- a/Platform/96Boards/96Boards.dec
+++ b/Platform/96Boards/96Boards.dec
@@ -37,6 +37,9 @@ [Guids]
   g96BoardsI2c1MasterGuid = { 0xcf64ac46, 0xd0be, 0x4a69, { 0x90, 0xa2, 0xf2, 
0x82, 0x5b, 0x92, 0x25, 0x61 } }
   g96BoardsSpiMasterGuid = { 0x9703fd99, 0xe638, 0x42b8, { 0xab, 0x81, 0x52, 
0x61, 0x1b, 0xf7, 0xf7, 0x5d } }
 
+  # GUID for the HII configuration form
+  g96BoardsFormsetGuid = { 0x7500c9d2, 0x9203, 0x4a37, { 0x84, 0xbb, 0x92, 
0xa9, 0xce, 0x34, 0x38, 0xbd } }
+
 [PcdsFixedAtBuild]
   # ASCII DT paths to the I2C parent nodes of the 96boards LS connector
   g96BoardsTokenSpaceGuid.PcdI2c0Parent|""|VOID*|0x0001
diff --git a/Platform/96Boards/Include/Guid/FormSet.h 
b/Platform/96Boards/Include/Guid/FormSet.h
new file mode 100644
index ..a0475e641d69
--- /dev/null
+++ b/Platform/96Boards/Include/Guid/FormSet.h
@@ -0,0 +1,23 @@
+/** @file
+
+  Copyright (c) 2018, Linaro Limited. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __96BOARDS_FORMSET_H__
+#define __96BOARDS_FORMSET_H__
+
+#define NINETY_SIX_BOARDS_FORMSET_GUID  \
+  { 0x7500c9d2, 0x9203, 0x4a37, { 0x84, 0xbb, 0x92, 0xa9, 0xce, 0x34, 0x38, 
0xbd } }
+
+extern EFI_GUID g96BoardsFormsetGuid;
+
+#endif // __96BOARDS_FORMSET_H__
diff --git a/Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c 
b/Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c
new file mode 100644
index ..f19d95635056
--- /dev/null
+++ b/Platform/96Boards/LsConnectorDxe/LsConnectorDxe.c
@@ -0,0 +1,221 @@
+/** @file
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "LsConnectorDxe.h"
+
+extern  UINT8 LsConnectorHiiBin[];
+extern  UINT8 LsConnectorDxeStrings[];
+
+typedef struct {
+  VENDOR_DEVICE_PATH  VendorDevicePath;
+  EFI_DEVICE_PATH_PROTOCOLEnd;
+} HII_VENDOR_DEVICE_PATH;
+
+STATIC HII_VENDOR_DEVICE_PATH m96BoardsDxeVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+NINETY_SIX_BOARDS_FORMSET_GUID
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{
+  (UINT8) (END_DEVICE_PATH_LENGTH),
+  (UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
+}
+  }
+};
+
+STATIC LS_CONNECTOR_PROTOCOL  mLsConnector;
+STATIC EFI_EVENT  EndOfDxeEvent;
+
+STATIC
+EFI_STATUS
+InstallHiiPages (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  EFI_HII_HANDLE  HiiHandle;
+  EFI_HANDLE  DriverHandle;
+
+  DriverHandle = NULL;
+  Status = gBS->InstallMultipleProtocolInterfaces (,
+  ,
+  ,
+  NULL);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  HiiHandle = HiiAddPackages (,
+  DriverHandle,
+  LsConnectorDxeStrings,
+  

[edk2] [PATCH edk2-platforms v3 1/6] Platform/96Boards: introduce package and mezzanine protocol

[Ard Biesheuvel]

Introduce the mezzanine protocol and the 96Boards package defining
the PCDs and GUIDs that may be used by implementations of the
protocol.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/96Boards/96Boards.dec | 67 ++
 Platform/96Boards/Include/Protocol/Mezzanine.h | 71 
 2 files changed, 138 insertions(+)

diff --git a/Platform/96Boards/96Boards.dec b/Platform/96Boards/96Boards.dec
new file mode 100644
index ..2a063ced9e4a
--- /dev/null
+++ b/Platform/96Boards/96Boards.dec
@@ -0,0 +1,67 @@
+## @file
+#
+#  Copyright (c) 2018, Linaro Ltd. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = 96Boards
+  PACKAGE_GUID   = ce4a4683-6e2d-4ec3-bc11-974289a09ab0
+  PACKAGE_VERSION= 0.1
+
+[Includes]
+  Include
+
+[Protocols]
+  ## Include/Protocol/Mezzanine.h
+  g96BoardsMezzanineProtocolGuid = { 0xf0467a37, 0x3436, 0x40ef, { 0x94, 0x09, 
0x4d, 0x1d, 0x7f, 0x51, 0x06, 0xd3 } }
+
+[Guids]
+  # PCD scope GUID
+  g96BoardsTokenSpaceGuid = { 0xe0d2f33a, 0xb7dd, 0x4a69, { 0xb6, 0x76, 0xda, 
0xe8, 0xa4, 0x17, 0xa7, 0xb5 } }
+
+  # GUIDs to be installed as protocols to identify which controller connects 
to which bus
+  g96BoardsI2c0MasterGuid = { 0xba10e402, 0xcfdd, 0x4b87, { 0xbd, 0x02, 0x6e, 
0x26, 0x9f, 0x01, 0x94, 0x11 } }
+  g96BoardsI2c1MasterGuid = { 0xcf64ac46, 0xd0be, 0x4a69, { 0x90, 0xa2, 0xf2, 
0x82, 0x5b, 0x92, 0x25, 0x61 } }
+  g96BoardsSpiMasterGuid = { 0x9703fd99, 0xe638, 0x42b8, { 0xab, 0x81, 0x52, 
0x61, 0x1b, 0xf7, 0xf7, 0x5d } }
+
+[PcdsFixedAtBuild]
+  # ASCII DT paths to the I2C parent nodes of the 96boards LS connector
+  g96BoardsTokenSpaceGuid.PcdI2c0Parent|""|VOID*|0x0001
+  g96BoardsTokenSpaceGuid.PcdI2c1Parent|""|VOID*|0x0002
+
+  # I2C bus frequency in Hertz
+  g96BoardsTokenSpaceGuid.PcdI2c0BusFrequencyHz|0|UINT32|0x0003
+  g96BoardsTokenSpaceGuid.PcdI2c1BusFrequencyHz|0|UINT32|0x0004
+
+  # ASCII DT path to the SPI parent node of the 96boards LS connector
+  g96BoardsTokenSpaceGuid.PcdSpiParent|""|VOID*|0x0005
+
+  # ASCII DT path to the GPIO parent node of the 96boards LS connector
+  g96BoardsTokenSpaceGuid.PcdGpioParent|""|VOID*|0x0006
+
+  # Polarity of the 96boards LS connector GPIOs (0 == GPIO_ACTIVE_HIGH, 1 == 
GPIO_ACTIVE_LOW)
+  g96BoardsTokenSpaceGuid.PcdGpioPolarity|0|UINT32|0x0007
+
+  # Pin numbers of the 96boards LS connector GPIOs
+  g96BoardsTokenSpaceGuid.PcdGpioPinA|0|UINT32|0x0010
+  g96BoardsTokenSpaceGuid.PcdGpioPinB|0|UINT32|0x0011
+  g96BoardsTokenSpaceGuid.PcdGpioPinC|0|UINT32|0x0012
+  g96BoardsTokenSpaceGuid.PcdGpioPinD|0|UINT32|0x0013
+  g96BoardsTokenSpaceGuid.PcdGpioPinE|0|UINT32|0x0014
+  g96BoardsTokenSpaceGuid.PcdGpioPinF|0|UINT32|0x0015
+  g96BoardsTokenSpaceGuid.PcdGpioPinG|0|UINT32|0x0016
+  g96BoardsTokenSpaceGuid.PcdGpioPinH|0|UINT32|0x0017
+  g96BoardsTokenSpaceGuid.PcdGpioPinI|0|UINT32|0x0018
+  g96BoardsTokenSpaceGuid.PcdGpioPinJ|0|UINT32|0x0019
+  g96BoardsTokenSpaceGuid.PcdGpioPinK|0|UINT32|0x001A
+  g96BoardsTokenSpaceGuid.PcdGpioPinL|0|UINT32|0x001B
diff --git a/Platform/96Boards/Include/Protocol/Mezzanine.h 
b/Platform/96Boards/Include/Protocol/Mezzanine.h
new file mode 100644
index ..9847649d2ac3
--- /dev/null
+++ b/Platform/96Boards/Include/Protocol/Mezzanine.h
@@ -0,0 +1,71 @@
+/** @file
+
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _96BOARDS_MEZZANINE_H_
+#define _96BOARDS_MEZZANINE_H_
+
+#include 
+#include 
+
+#define MEZZANINE_PROTOCOL_GUID \
+  { 0xf0467a37, 0x3436, 0x40ef, { 0x94, 0x09, 0x4d, 0x1d, 0x7f, 0x51, 0x06, 
0xd3 } }
+
+typedef struct _MEZZANINE_PROTOCOL MEZZANINE_PROTOCOL;
+
+/**
+  Apply the mezzanine's DT overlay
+
+  @param[in]  This  Pointer to the MEZZANINE_PROTOCOL instance.
+  @param[in,out]  Dtb   Pointer to the device tree blob
+
+  @return   EFI_SUCCESS Operation succeeded.
+  @return   other 

Re: [edk2] [PATCH edk2-platforms v2 1/7] Silicon/Atmel: add support for AtSha204a RNG

[Ard Biesheuvel]

On 22 February 2018 at 13:08, Leif Lindholm  wrote:
> On Tue, Feb 20, 2018 at 05:49:38PM +, Ard Biesheuvel wrote:
>> This adds support for using the random number generator in the Atmel
>> AtSha204a over I2C. Other functionality of the chip is currently
>> unsupported.
>>
>> Note that the the I2C support in this device essentially violates the
>> protocol layering, by requiring that the device is woken up by driving
>> SDA low for a certain amount of time, which is something that cannot be
>> expressed in terms of an I2C packet sent to the device's slave address.
>> Instead, the slave address 0x0 is added to the device's address array,
>> and the wake is sent by sending a dummy write to address 0x0, and
>> ignoring the subsequent error. This requires the I2C bus to be clocked
>> at 100 kHz.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>
> All of my feedback from v1 has been addressed, so:
> Reviewed-by: Leif Lindholm 

Thanks.

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

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Laszlo Ersek]

On 02/23/18 16:17, Ard Biesheuvel wrote:
> On 23 February 2018 at 15:05, Laszlo Ersek  wrote:

>> (3) In general, the comment style requires comments like this:
>>
>>   //
>>   // Add empty comment lines both before and after.
>>   //
>>
> 
> Quite the opposite, in fact. Search for 'horror vacui' in the coding
> style document.

Right, I remember that. But, I don't recall a single comment block
(using "//"), recent or old, that does not violate that rule. Arguably,
the rule is wrong (it certainly doesn't match on-going practice).

Technically I was wrong however; thanks for the correction.

> That does not mean I agree with that document, and I am perfectly fine
> with both styles.

OK.

So, please ignore my comments on the comments.

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

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Ard Biesheuvel]

On 23 February 2018 at 15:05, Laszlo Ersek  wrote:
> Thanks for writing up the details!
>
> Comments:
>
> On 02/23/18 09:53, Heyi Guo wrote:
>> PCI address translation is necessary for some non-x86 platforms. On
>> such platforms, address value (denoted as "device address" or "address
>> in PCI view") set to PCI BAR registers in configuration space might be
>> different from the address which is used by CPU to access the
>> registers in memory BAR or IO BAR spaces (denoted as "host address" or
>> "address in CPU view"). The difference between the two addresses is
>> called "Address Translation Offset" or simply "translation", and can
>> be represented by "Address Translation Offset" in ACPI QWORD Address
>> Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
>> definitions of QWORD Address Space Descriptor, and we will follow UEFI
>> definition on UEFI protocols, such as PCI root bridge IO protocol and
>> PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
>> to apply to the Starting address to convert it to a PCI address". This
>> means:
>>
>> 1. Translation = device address - host address.
>
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
>
>> 2. PciRootBridgeIo->Configuration should return CPU view address, as
>> well as PciIo->GetBarAttributes.
>
> OK.
>
>>
>> Summary of addresses used:
>>
>> 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
>> it is easy to check whether the address is below 4G or above 4G.
>
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
>
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
>

Yes. Although DMA and MMIO space are different in this regard (and
this series does not cover the former), the purpose of having 32-bit
addressable BAR space and/or 32-bit addressable memory for DMA is to
ensure that the addresses can be generated/decoded by the PCI device.

So it is appropriate for the distinction between 'below' and 'above' 4
GB to be made based on the PCI address.

> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
>
>>
>> 2. Address returned by
>> EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
>> is device address, or else PCI bus driver cannot set correct address
>> into PCI BAR registers.
>>
>> 3. Address returned by PciRootBridgeIo->Configuration is host address
>> per UEFI 2.7 definition.
>>
>> 4. Addresses used in GCD manipulation are host address.
>>
>> 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
>> address, for they are allocated from GCD.
>>
>> 6. Address passed to PciHostBridgeResourceConflict is host address,
>> for it comes from ResAllocNode.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Heyi Guo 
>> Cc: Ruiyu Ni 
>> Cc: Ard Biesheuvel 
>> Cc: Star Zeng 
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Cc: Michael D Kinney 
>> ---
>>  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
>>  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
>>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
>> ++---
>>  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
>>  4 files changed, 167 insertions(+), 29 deletions(-)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
>> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> index 1494848..e8979eb 100644
>> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
>>  EFI_EVENT   mIoMmuEvent;
>>  VOID*mIoMmuRegistration;
>>
>> +STATIC
>> +UINT64
>> +GetTranslationByResourceType (
>> +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
>> +  IN  PCI_RESOURCE_TYPEResourceType
>> +  )
>> +{
>> +  switch (ResourceType) {
>> +case TypeIo:
>> +  return RootBridge->Io.Translation;
>> +case TypeMem32:
>> +  return RootBridge->Mem.Translation;
>> +case TypePMem32:
>> +  return RootBridge->PMem.Translation;
>> +case TypeMem64:
>> +  return RootBridge->MemAbove4G.Translation;
>> +case TypePMem64:
>> +  return 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 12:48, Pankaj Bansal wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, February 23, 2018 4:52 PM
>> To: Pankaj Bansal ; Udit Kumar
>> ; Leif Lindholm 
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org; Meenakshi Aggarwal
>> 
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
>> for Big Endian Mmio APIs
>>
>> On 02/23/18 12:04, Pankaj Bansal wrote:
>>
>>> However Laszlo, with the method you suggest (using STATIC CONST
>>> UINT16 mOne), would it not add delay in each Mmio Operation ?
>>>
>>> I am concerned about boot delay using this approach.
>> The condition can be evaluated at compile time, so I expect optimizing
>> compilers to eliminate the dead branch.
>>
>> Assuming the condition cannot be eliminated at build time, what is your
>> concern: the single byte access, or the branch instruction?
>>
>> I don't think the single byte access matters. (If you tried to replace that 
>> with a
>> HOB or PCD lookup, it could only be worse.)
>>
>> I also doubt the branch should be a concern. You could replace the "if"
>> (or the ternary operator "?:") with function pointers that you set e.g.
>> in a constructor function. But I think an "if" with an invariable
>> (constant) controlling expression is at least as friendly towards branch
>> predictors as a function pointer variable (through which you might be
>> *forced* to make a real function call).
>>
>> Personally I wouldn't worry.
>>
> 
> I think you are right about smart compiler eliminating the branches at build 
> time.
> I just pointed this out because we call Mmio/BeMmio APIs when accessing Nor 
> flash for variable read/write.
> As these are called so many time during boot, I did not want any delay to be 
> added to these APIs than necessary.
> Now that you have pointed it out, I don't think any significant delay will be 
> added to these APIs.

In addition to that, physical flash access is likely so slow anyway that
a few additional instructions should be lost in the noise, generally
speaking.

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

Re: [edk2] [RFC v3 3/3] MdeModulePkg/PciBus: return CPU address for GetBarAttributes

[Laszlo Ersek]

On 02/23/18 09:53, Heyi Guo wrote:
> According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
> address (CPU view ddress) rather than device address (PCI view
> address), and
> device address = host address + address translation offset,
> so we subtract translation from device address before returning.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo 
> Cc: Ruiyu Ni 
> Cc: Ard Biesheuvel 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Michael D Kinney 
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> index fef3ece..62179eb 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> @@ -1972,6 +1972,10 @@ PciIoGetBarAttributes (
>  return EFI_UNSUPPORTED;
>}
>  }
> +
> +// According to UEFI spec 2.7, we need return host address for
> +// PciIo->GetBarAttributes, and host address = device address - 
> translation.
> +Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;
>}
>  
>return EFI_SUCCESS;
> 

Patches #2 and #3 look OK to me, but I feel I don't know enough to give
an R-b with a good conscience.

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

Re: [edk2] [PATCH v4 0/2] Create UART DebugLib implementation for runtime drivers

[Ard Biesheuvel]

On 22 February 2018 at 19:56, Ard Biesheuvel  wrote:
> Commit 4bf95a9f361e ("MdeModulePkg/ResetSystemRuntimeDxe: Add more debug
> message") broke the DEBUG build for systems using a MMIO mapped UART for
> DEBUG output. In other words, it broke the build for all ARM and AARCH64
> systems, given that port I/O does not exist on those architectures.
>
> Instead of patching it up locally, let's fix this issue once and for all,
> by creating a UART DebugLib implementation for DXE_RUNTIME_DRIVER modules
> that does the right thing by default.
>
> v4:
> - add Laszlo's R-b
> - keep ASSERT() message in local buffer even it is not printed to the serial
>   port, to allow it to be accessed via the debugger
>

Mike,

Given that all ARM and AARCH64 DEBUG builds are still broken, may we
please have your R-b on this patch so we can proceed to start fixing
things?

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

[edk2] [RFC PATCH edk2-non-osi] Platform/DeveloperBox: add prebuilt binary containing stage 2 page tables

[Ard Biesheuvel]

Now that the secure firmware image BL31 has been moved back into secure
memory where it belongs, we can no longer keep the stage2 translation
tables in the same image, given that EL2 is non-secure.

So instead, let's put those tables in the NOR flash, at the end of the
ARM-TF region. This is difficult to integrate into the build sequence
of either ARM-TF or UEFI, so let's just generate the binary and put it
at the correct offset using the .fdf description of the platform.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
I am not sure where to put this and how to integrate this into the build,
hence the RFC.

 Platform/Socionext/DeveloperBox/README|   2 +
 Platform/Socionext/DeveloperBox/stage2_tables.S   |  95 
 Platform/Socionext/DeveloperBox/stage2_tables.bin | Bin 0 -> 20480 bytes
 3 files changed, 97 insertions(+)

diff --git a/Platform/Socionext/DeveloperBox/README 
b/Platform/Socionext/DeveloperBox/README
index 8f079011e153..5728bf0ef88a 100644
--- a/Platform/Socionext/DeveloperBox/README
+++ b/Platform/Socionext/DeveloperBox/README
@@ -6,3 +6,5 @@ fip_all_arm_tf.bin - prebuilt ARM Trusted Firmware RELEASE 
binary
 Repo: https://git.linaro.org/leg/noupstream/arm-trusted-firmware.git
 Commit: cd3de9253d90f5ab6eed046fb7bb9f4e9f87ae5a
 
+stage2_tables.bin - prebuilt stage 2 translation tables
+Built from stage2_tables.S in the same directory
diff --git a/Platform/Socionext/DeveloperBox/stage2_tables.S 
b/Platform/Socionext/DeveloperBox/stage2_tables.S
new file mode 100644
index ..44da21e7e467
--- /dev/null
+++ b/Platform/Socionext/DeveloperBox/stage2_tables.S
@@ -0,0 +1,95 @@
+/** @file
+  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License which accompanies this
+  distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+/*
+ * This file contains the assembler code to instantiate a set of stage 2
+ * translation tables that make the ECAM space of the Synopsys DesignWare
+ * PCIe root complexes appear sane to the OS.
+ * - ECAM 'shadows' caused by non TLP filtering root ports are eliminated
+ * - MMIO region are mapped with device attributes that supersede write combine
+ attributes that the OS may attempt to use, and which is not supported by
+ the SoC.
+ *
+ * Build using:
+ *
+ * gcc -o stage2_tables.elf stage2_tables.S \
+ *-Wl,-e,0x81f8000 -Wl,--section-start=.rodata=0x81f8000 -nostdlib
+ *
+ * objcopy -O binary -j .rodata stage2_tables.elf stage2_tables.bin
+ */
+
+#defineTT_S2_CONT_SHIFT52
+#defineTT_S2_AF(0x1 << 10)
+#defineTT_S2_SH_NON_SHAREABLE  (0x0 << 8)
+#defineTT_S2_AP_RW (0x3 << 6)
+#defineTT_S2_MEMATTR_DEVICE_nGRE   (0x2 << 2)
+#defineTT_S2_MEMATTR_MEMORY_WB (0xf << 2)
+#defineTT_S2_TABLE (0x3 << 0)
+#defineTT_S2_L3_PAGE   (0x1 << 1)
+#defineTT_S2_VALID (0x1 << 0)
+
+   .altmacro
+   .macro  for, start, count, do, arg2, arg3, arg4
+   .if \count == 1
+   \do \start, \arg2, \arg3, \arg4
+   .elseif \count > 1
+   for \start, %(\count / 2), \do, \arg2, \arg3, \arg4
+   for %(\start + \count / 2), %((\count + 1) / 2), \do, 
\arg2, \arg3, \arg4
+   .endif
+   .endm
+
+   .macro  s2_dev_entry, base, shift=30, offset=0, cont=0
+   .quad   ((\base << \shift) + \offset) | TT_S2_AF | TT_S2_AP_RW 
| \
+   TT_S2_SH_NON_SHAREABLE | TT_S2_MEMATTR_DEVICE_nGRE | \
+   TT_S2_VALID | (\cont << TT_S2_CONT_SHIFT)
+   .endm
+
+   .macro  s2_mem_entry, base, shift=30, offset=0, cont=0
+   .quad   ((\base << \shift) + \offset) | TT_S2_AF | TT_S2_AP_RW 
| \
+   TT_S2_SH_NON_SHAREABLE | TT_S2_MEMATTR_MEMORY_WB | \
+   TT_S2_VALID | (\cont << TT_S2_CONT_SHIFT)
+   .endm
+
+   .macro  s2_l3_entry, base, offset=0, cont=0
+   .quad   ((\base << 12) + \offset) | TT_S2_AF | TT_S2_AP_RW | \
+   TT_S2_SH_NON_SHAREABLE | TT_S2_MEMATTR_MEMORY_WB | \
+   TT_S2_L3_PAGE | TT_S2_VALID | (\cont << 
TT_S2_CONT_SHIFT)
+   .endm
+
+   .section".rodata", "a", %progbits
+   /* level 1 */
+   s2_mem_entry0   /* 0x_ - 0x3fff_ */
+   .quad   1f + TT_S2_TABLE/* 0x4000_ - 

[edk2] [PATCH 6/7] ovmf: link with Tcg2ConfigDxe module

[marcandre . lureau]

From: Marc-André Lureau 

The module allows to tweak and interact with the TPM. Note that many
actions are broken due to implementation of qemu TPM (providing it's
own ACPI table), and the lack of PPI implementation.

CC: Laszlo Ersek 
CC: Stefan Berger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau 
---
 OvmfPkg/OvmfPkgX64.dsc | 2 ++
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 2 files changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 9bd0709f98..2281bd5ff8 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -669,6 +669,8 @@
   NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
   }
+
+  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
 !endif
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index b8dd7ecae4..985404850f 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -399,6 +399,7 @@ INF  
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 
 !if $(TPM2_ENABLE) == TRUE
 INF  SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
+INF  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
 !endif
 
 

-- 
2.16.1.73.g5832b7e9f2

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

[edk2] [PATCH 5/7] ovmf: link with Tcg2Dxe module

[marcandre . lureau]

From: Marc-André Lureau 

This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS:

[0.00] efi: EFI v2.70 by EDK II
[0.00] efi:  SMBIOS=0x3fa1f000  ACPI=0x3fbb6000  ACPI 2.0=0x3fbb6014  
MEMATTR=0x3e7d4318  TPMEventLog=0x3db21018

$ python chipsec_util.py tpm parse_log binary_bios_measurements

[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', 
'/tmp/binary_bios_measurements']

PCR: 0  type: EV_S_CRTM_VERSION size: 0x2   digest: 
1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0  type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10  digest: 
fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x82length: 0xe
PCR: 0  type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10  digest: 
39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x90length: 0xa0
PCR: 7  type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35  digest: 
57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7  type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24  digest: 
9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7  type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26  digest: 
9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7  type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24  digest: 
5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7  type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26  digest: 
734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x3e  digest: 
252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x6e  digest: 
22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x80  digest: 
b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x84  digest: 
425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x9a  digest: 
0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0xbd  digest: 
20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1  type: EV_EFI_VARIABLE_BOOT  size: 0x88  digest: 
df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4  type: EV_EFI_ACTION size: 0x28  digest: 
cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5  type: EV_SEPARATOR  size: 0x4   digest: 
9069ca78e7450a285173431b3e52c5c25299e473

$ tpm2_pcrlist
sha1 :
  0  : 35bd1786b6909daad610d7598b1d620352d33b8a
  1  : ec0511e860206e0af13c31da2f9e943fb6ca353d
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : 45a323382bd933f08e7f0e256bc8249e4095b1ec
  5  : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
  6  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  7  : 518bd167271fbb64589c61e43d8c0165861431d8
  8  : 
  9  : 
  10 : 
  11 : 
  12 : 
  13 : 
  14 : 
  15 : 
  16 : 
  17 : 
  18 : 
  19 : 
  20 : 
  21 : 
  22 : 
  23 : 
sha256 :
  0  : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
  1  : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
  2  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  3  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  4  : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
  5  : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
  6  : 

[edk2] [PATCH 2/7] ovmf: link with Tcg2ConfigPei module

[marcandre . lureau]

From: Marc-André Lureau 

This module initializes TPM device type based on variable and
detection.

The module requires VariablePei, which is built with
MEM_VARSTORE_EMU_ENABLE=FALSE.

CC: Laszlo Ersek 
CC: Stefan Berger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau 
---
 OvmfPkg/OvmfPkgX64.dsc | 20 
 OvmfPkg/OvmfPkgX64.fdf |  3 +++
 2 files changed, 23 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 32c57b04e1..b5cbe8430f 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -40,6 +40,7 @@
   DEFINE SMM_REQUIRE = FALSE
   DEFINE TLS_ENABLE  = FALSE
   DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
+  DEFINE TPM2_ENABLE = FALSE
 
   #
   # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
@@ -209,6 +210,11 @@
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
 
+!if $(TPM2_ENABLE) == TRUE
+  Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf
+  Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
+!endif
+
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
 
@@ -272,6 +278,10 @@
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
+!if $(TPM2_ENABLE)
+  Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf
+  Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
+!endif
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -558,6 +568,12 @@
 
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
 
+!if $(TPM2_ENABLE) == TRUE
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0xb6, 0xe5, 0x01, 0x8b, 
0x19, 0x4f, 0xe8, 0x46, 0xab, 0x93, 0x1c, 0x53, 0x67, 0x1b, 0x90, 0xcc}
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2InitializationPolicy|1
+  gEfiSecurityPkgTokenSpaceGuid.PcdTpmInitializationPolicy|1
+!endif
+
 

 #
 # Components Section - list of all EDK II Modules needed by this Platform.
@@ -629,6 +645,10 @@
 
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 
+!if $(TPM2_ENABLE) == TRUE
+  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
+!endif
+
 !if $(SECURE_BOOT_ENABLE) == TRUE
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index bb46a409d9..dc35d0a1f7 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -168,6 +168,9 @@ INF  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 INF  MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
 INF  MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
 !endif
+!if $(TPM2_ENABLE) == TRUE
+INF  SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
+!endif
 
 

 
-- 
2.16.1.73.g5832b7e9f2

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

[edk2] [PATCH 0/7] RFC: ovmf: preliminary TPM2 support

[marcandre . lureau]

From: Marc-André Lureau 

Hi,

The following series adds basic TPM2 support for OVMF-on-QEMU (I
haven't tested TPM1, for lack of interest). It links with the modules
to initializes the device in PEI phase, and do measurements (both PEI
and DXE). The Tcg2Dxe module provides the Tcg2 protocol which allows
the guest to access the measurement log and other facilities.

DxeTpm2MeasureBootLib seems to do its job at measuring images that are
not measured in PEI phase (such as PCI PXE rom)

Tcg2ConfigDxe is mostly interesting for debugging for now.

A major lack is the support for Physical Present Interface (PPI, more
below).

Linux guests seem to work fine. But windows guest generally complains
about the lack of PPI interface (most HLK tests require it, tpm.msc
admin interactions too). I haven't done "real" use-cases tests, as I
lack experience with TPM usage. Any help appreciated to test the TPM.

Tcg2ConfigPei requires variable access, therefore
 must be solved
first. I used "[edk2] [PATCH v2 0/8] OvmfPkg: add the Variable PEIM,
defragment the UEFI memmap" as a base for this series.

I build edk2 with:

$ build -DTPM2_ENABLE -DSECURE_BOOT_ENABLE  -DMEM_VARSTORE_EMU_ENABLE=FALSE

I test with qemu & swtpm/libtpms (tpm2 branches, swtpm_setup.sh --tpm2 
--tpm-state tpmstatedir)

$ swtpm socket --tpmstate tpmstatedir --ctrl type=unixio,path=tpmsock  --tpm2 &
$ qemu .. -chardev socket,id=chrtpm,path=tpmsock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-crb,tpmdev=tpm0

PPI is problematic, because we generally don't want or need SMM, and
qemu is preferred to provide the ACPI tables. We therefore exclude
using Tcg2Smm for now (which also brings other problems). Stefan
Berger has been prototyping qemu code that provides PPI ACPI
interface, but there is some complication regarding memory location,
using a fixed address. My understanding is that the firmware
(seabios/edk2) should allocate the required memory itself (using qemu
linker script for ex) and patch the ACPI table. Then it's hopefully
only a matter of hooking Tcg2PhysicalPresenceLibProcessRequest() as
was done by Stefan in
https://github.com/stefanberger/edk2/commits/tpm2. The main problem I
see with this approach is that the location should remain stable
across reboots (not necessarily poweroff, edk2 uses nvram variables
for PPI flags). More investigation and help needed to support PPI!

Thanks

Related bug:
https://bugzilla.tianocore.org/show_bug.cgi?id=594

Marc-André Lureau (7):
  SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency
  ovmf: link with Tcg2ConfigPei module
  HACK: HobLib: workaround infinite loop
  ovmf: link with Tcg2Pei module
  ovmf: link with Tcg2Dxe module
  ovmf: link with Tcg2ConfigDxe module
  ovmf: add DxeTpm2MeasureBootLib

 MdePkg/Library/PeiHobLib/HobLib.c   |  4 +++
 OvmfPkg/OvmfPkgX64.dsc  | 49 -
 OvmfPkg/OvmfPkgX64.fdf  |  9 +++
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c   |  2 --
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf |  1 -
 5 files changed, 61 insertions(+), 4 deletions(-)

-- 
2.16.1.73.g5832b7e9f2

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

[edk2] [PATCH 3/7] HACK: HobLib: workaround infinite loop

[marcandre . lureau]

From: Marc-André Lureau 

Without this hack, GetNextHob() loops infinitely with the next patch.
I don't understand the reason.

The loop is triggered by the GetFirstGuidHob () call.

CC: Laszlo Ersek 
CC: Stefan Berger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau 
---
 MdePkg/Library/PeiHobLib/HobLib.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdePkg/Library/PeiHobLib/HobLib.c 
b/MdePkg/Library/PeiHobLib/HobLib.c
index 5c0eeb992f..ed3c5fbd6d 100644
--- a/MdePkg/Library/PeiHobLib/HobLib.c
+++ b/MdePkg/Library/PeiHobLib/HobLib.c
@@ -89,6 +89,10 @@ GetNextHob (
 if (Hob.Header->HobType == Type) {
   return Hob.Raw;
 }
+if (GET_HOB_LENGTH (HobStart) == 0) {
+DEBUG ((DEBUG_INFO, "FIXME: GetNextHob length == 0"));
+return NULL;
+}
 Hob.Raw = GET_NEXT_HOB (Hob);
   }
   return NULL;
-- 
2.16.1.73.g5832b7e9f2

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

[edk2] [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency

[marcandre . lureau]

From: Marc-André Lureau 

Apparently, unnecessary. Avoids extra build dependency and churn.

CC: Laszlo Ersek 
CC: Stefan Berger 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau 
---
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c   | 2 --
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 -
 2 files changed, 3 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c 
b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
index a7ae3354b5..3758fc6a41 100644
--- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
+++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
@@ -18,7 +18,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -44,7 +43,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 
 #define PERF_ID_TCG2_PEI  0x3080
 
diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf 
b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
index f7b85444d9..bc910c3baf 100644
--- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
+++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
@@ -58,7 +58,6 @@
   PerformanceLib
   MemoryAllocationLib
   ReportStatusCodeLib
-  Tcg2PhysicalPresenceLib
   ResetSystemLib
 
 [Guids]
-- 
2.16.1.73.g5832b7e9f2

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

Re: [edk2] [PATCH 0/4] Add ARM64 support for VS2017

[Pete Batard]

On 2018.02.23 11:55, Ard Biesheuvel wrote:

* PATCH 4 enables the selection of ARM64 in the conf templates.
   One item of note is that the build options for ARM64 are the same as
   for ARM, except for /BASE:0 which was removed to avoid error:
   'invalid base address 0x0; ARM64 image cannot have base address below 4GB'



This series looks fine to me, with the exception of the error
mentioned here, which seems strange to me. It does appear to be a
toolchain issue rather than anything else, so if you can build working
binaries with these patches, it's all fine by me.


Thanks Ard.

The thing about /BASE:0 producing a LNK1355 error above is that it only 
seems to occur with applications (you will see it if you try to build 
the Shell or MdeModulePkg\Application\HelloWorld for instance) and not 
drivers.


I too suspect that this may have to do with the public-facing 
VS2017/ARM64 toolchain being brand new, since it was only introduced 
with the last major VS update, and maybe still needing some ironing out 
when it comes to the generation of non Windows applications.


So far I have not seen any ill effects from the removal of /BASE:0.

Once this series has been integrated (so that it's easier for the VS dev 
team to test), I'll try to report this issue to 
https://developercommunity.visualstudio.com, to find out what they have 
to say about it.


Regards,

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

Re: [edk2] [PATCH 0/4] Add ARM64 support for VS2017

[Ard Biesheuvel]

On 23 February 2018 at 09:49, Pete Batard  wrote:
> This is v2, which just removes a redundant #if defined(_MSC_EXTENSIONS) in 
> 1/4.
>
> This series completes VS2017 support by enabling AARCH64 compilation.
> * PATCH 1 targets the disabling of VS Level 4 warnings. The disabled
>   warnings for ARM64 are the same as the ones for IA32, X64 and ARM.
> * PATCH 2 adds assembly source in MdePkg/Library/BaseLib for various low
>   level required functions. These new assembly files were converted from
>   their GCC version, with minor changes applied to make them palatable
>   to the MSFT assembler.
> * PATCH 3 adds variable argument handlers for print output. This is
>   achieved without relying on any external toolchain headers. However
>   a call to the __va_start() compiler intrinsic function is now being
>   used for the VA_START macros, which we apply for ARM as well.
> * PATCH 4 enables the selection of ARM64 in the conf templates.
>   One item of note is that the build options for ARM64 are the same as
>   for ARM, except for /BASE:0 which was removed to avoid error:
>   'invalid base address 0x0; ARM64 image cannot have base address below 4GB'
>

This series looks fine to me, with the exception of the error
mentioned here, which seems strange to me. It does appear to be a
toolchain issue rather than anything else, so if you can build working
binaries with these patches, it's all fine by me.

Acked-by: Ard Biesheuvel 


> With these patches, VS2017 toolchain users should be able to compile
> regular UEFI ARM64 applications using EDK2.
>
> Note however that ARM64 support requires the use of Visual Studio 2017
> Update 4 or later (a.k.a. v15.4), as native ARM64 compilation was not
> included in any version of Visual Studio prior to that.
>
> Additional notes:
>
> We tested compiling and running the full UEFI Shell with this series, as
> well as a small set of applications and drivers, and saw no issues.
> Since we also modified the VA_START() macro for ARM, we also re-ran
> similar tests for ARM, to confirm that there was no regression there.
>
> Finally, we did not test the generation of a complete QEMU ARM64 firmware
> as it requires porting a handful of assembly sources, that don't exist
> yet, and our focus is with the generation of working AARCH64 drivers or
> applications. Hopefully, this can be tackled as VS2017/ARM64 sees more
> usage...
>
> Regards,
>
> /Pete
>
> Pete Batard (4):
>   MdePkg: Disable some Level 4 warnings for VS2017/ARM64
>   MdePkg/Library/BaseLib: Enable VS2017/ARM64 builds
>   MdePkg/Include: Add VA list support for VS2017/ARM64
>   BaseTools/Conf: Add VS2017/ARM64 support
>
>  BaseTools/Conf/build_rule.template|   2 +-
>  BaseTools/Conf/tools_def.template |  32 ++-
>  MdePkg/Include/AArch64/ProcessorBind.h|  53 +-
>  MdePkg/Include/Base.h |   7 +-
>  MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm  |  39 
>  MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm  |  37 +++
>  MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm   |  37 +++
>  MdePkg/Library/BaseLib/AArch64/GetInterruptsState.asm |  49 ++
>  MdePkg/Library/BaseLib/AArch64/MemoryFence.asm|  38 
>  MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm| 101 
> 
>  MdePkg/Library/BaseLib/AArch64/SwitchStack.asm|  69 +
>  MdePkg/Library/BaseLib/BaseLib.inf|   8 ++
>  12 files changed, 463 insertions(+), 9 deletions(-)
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/GetInterruptsState.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/MemoryFence.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/SwitchStack.asm
>
> --
> 2.9.3.windows.2
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Pankaj Bansal]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:52 PM
> To: Pankaj Bansal ; Udit Kumar
> ; Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Meenakshi Aggarwal
> 
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 12:04, Pankaj Bansal wrote:
> 
> > However Laszlo, with the method you suggest (using STATIC CONST
> > UINT16 mOne), would it not add delay in each Mmio Operation ?
> >
> > I am concerned about boot delay using this approach.
> The condition can be evaluated at compile time, so I expect optimizing
> compilers to eliminate the dead branch.
> 
> Assuming the condition cannot be eliminated at build time, what is your
> concern: the single byte access, or the branch instruction?
> 
> I don't think the single byte access matters. (If you tried to replace that 
> with a
> HOB or PCD lookup, it could only be worse.)
> 
> I also doubt the branch should be a concern. You could replace the "if"
> (or the ternary operator "?:") with function pointers that you set e.g.
> in a constructor function. But I think an "if" with an invariable
> (constant) controlling expression is at least as friendly towards branch
> predictors as a function pointer variable (through which you might be
> *forced* to make a real function call).
> 
> Personally I wouldn't worry.
> 

I think you are right about smart compiler eliminating the branches at build 
time.
I just pointed this out because we call Mmio/BeMmio APIs when accessing Nor 
flash for variable read/write.
As these are called so many time during boot, I did not want any delay to be 
added to these APIs than necessary.
Now that you have pointed it out, I don't think any significant delay will be 
added to these APIs.

> 
> Anyway: please do not mistake my willingness / preference to go into such
> detail for having high stakes at this. If you go an entirely different route, 
> I'm
> OK with that too. I felt I was asked for my opinion and I tried to express it 
> in
> detail, that's all.

Any comments/suggestions/opinions are always appreciated from you or from any 
edk2 mailing list member.

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

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

Hi Laszlo/Leif,

For short term, is this ok to keep this lib under Silicon/NXP, here we are 
assuming  
CPU will always on be LE mode whereas IP can vary between LE/BE mode ?

For long term, we can discuss on APIs/name of Lib/Function name etc
We will update our code, as per agreement.

For me, Suggested approach is ok as well to keep CPU endianness in ARM package.
but need views from Ard/Leif here.

Thanks
Udit

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:17 PM
> To: Udit Kumar ; Leif Lindholm
> 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 11:25, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Thursday, February 22, 2018 7:26 PM
> >> To: Leif Lindholm 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support for Big Endian Mmio APIs
> >>
> >> On 02/22/18 12:52, Leif Lindholm wrote:
> >>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>
> > But that brings back the complication as to how we have a driver
> > that needs an LE IO library to write output, and a BE IO library
> > to manipulate the hardware.
> 
>  Can you please explain the "write output" use case more precisely?
> 
>  My thinking would be this:
> 
>  - Use the IoLib class directly for "writing output" in little
>  endian byte order (which is still unclear to me sorry).
> >>>
> >>> If the IoLib class is mapped to a an instance that byte-swaps
> >>> (hereto referred to as BeIoLib if IoLibSwap is unsuitable), would we
> >>> not then end up mapping the non-swapping, currently implemented in
> >>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>> needing to duplicated all IoLib implementation .infs to provide an
> >>> IoLib and a BeIoLib for each?
> >>>
> >>> It's at that point I burst an aneurysm.
> >>> Am I overthinking/underthinking this?
> >>
> >> We need two library classes, one for talking to LE devices and
> >> another to BE devices. These should be usable in a given module at
> >> the same time, as Ard says.
> >>
> >> Both library classes need to work on both LE and BE CPUs (working
> >> from your suggestion that UEFI might grow BE CPU support at some
> >> point). Whether that is implemented by dumb, separate library
> >> instances (yielding in total 2*2=4 library instances), or by smart,
> >> CPU-endianness-agnostic library instances (in total, 2), is a
> >> different question.
> >>
> >> Note that such "smarts" could be less than trivial to implement:
> >> - check CPU endianness in each library API?
> >> - or check in the lib constructor only, and flip some function
> >>   pointers?
> >> - use a dynamic PCD for caching CPU endianness?
> >> - use a HOB for the same?
> >> - use a lib global variable (for caching only on the module level)?
> >>
> >> I think the solution that saves the most on the *source* code size
> >> is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >>   BeIoLib instance that we introduce
> >> - modify the MMIO functions in *both* lib instances (original LE, and
> >>   new BE), like this:
> >>
> >>   - If the CPU architecture is known to be bound to a single
> >> endianness, then hardcode the appropriate operation. This can be
> >> done with preprocessor macros, or with the architecture support
> >> of INF files / separate source files. For example, on IA32 and
> >> X64, the IoLib instance should work transparently,
> >> unconditionally, and the BeIoLib instance should byte-swap,
> >> unconditionally.
> >>
> >>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> >> *both* lib instances should do something like this:
> >>
> >> //
> >> // at file scope
> >> //
> >> STATIC CONST UINT16 mOne = 1;
> >>
> >> //
> >> // at function scope
> >> //
> >> if (*(CONST UINT8 *) == 1) {
> >>   //
> >>   // CPU in LE mode:
> >>   // - work transparently in the IoLib instance
> >>   // - byte-swap in the BeIoLib instance
> >>   //
> >> } else {
> >>   //
> >>   // CPU in BE mode:
> >>   // - byte-swap in the IoLib instance
> >>   // - work transparently in the BeIoLib instance
> >>   //
> >> }
> >
> > You meant, sort of cpu_to_le and cpu_to_be sort of APIs
> 
> I'm lost. I don't know how to put it any clearer. Let me try with actual
> code.
> 
> (a) Suggested for "MdePkg/Library/BaseIoLibIntrinsic/IoLib.c", which is
> used on IA32 and X64, therefore 

[edk2] [PATCH] BaseTools: Update ValueExpressionEx for flexible PCD

[Feng, YunhuaX]

1. Byte  array number should less than 0xFF.
2. Add SplitPcdValueString for PCD split

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Expression.py | 205 +--
 1 file changed, 130 insertions(+), 75 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Expression.py 
b/BaseTools/Source/Python/Common/Expression.py
index 28320d78a9..edb0a60de6 100644
--- a/BaseTools/Source/Python/Common/Expression.py
+++ b/BaseTools/Source/Python/Common/Expression.py
@@ -66,10 +66,48 @@ def SplitString(String):
 raise BadExpression(ERR_STRING_TOKEN % Item)
 if Item:
 RetList.append(Item)
 return RetList
 
+def SplitPcdValueString(String):
+# There might be escaped comma in GUID() or DEVICE_PATH() or " "
+# or ' ' or L' ' or L" "
+Str = String
+RetList = []
+InParenthesis = 0
+InSingleQuote = False
+InDoubleQuote = False
+Item = ''
+for i, ch in enumerate(Str):
+if ch == '(':
+InParenthesis += 1
+if ch == ')':
+if InParenthesis:
+InParenthesis -= 1
+else:
+raise BadExpression(ERR_STRING_TOKEN % Item)
+if ch == '"' and not InSingleQuote:
+if String[i-1] != '\\':
+InDoubleQuote = not InDoubleQuote
+if ch == "'" and not InDoubleQuote:
+if String[i-1] != '\\':
+InSingleQuote = not InSingleQuote
+if ch == ',':
+if InParenthesis or InSingleQuote or InDoubleQuote:
+Item += String[i]
+continue
+elif Item:
+RetList.append(Item)
+Item = ''
+continue
+Item += String[i]
+if InSingleQuote or InDoubleQuote or InParenthesis:
+raise BadExpression(ERR_STRING_TOKEN % Item)
+if Item:
+RetList.append(Item)
+return RetList
+
 ## ReplaceExprMacro
 #
 def ReplaceExprMacro(String, Macros, ExceptionList = None):
 StrList = SplitString(String)
 for i, String in enumerate(StrList):
@@ -731,28 +769,46 @@ class ValueExpressionEx(ValueExpression):
 PcdValue = Value.result
 except BadExpression, Value:
 if self.PcdType in ['UINT8', 'UINT16', 'UINT32', 'UINT64', 
'BOOLEAN']:
 PcdValue = PcdValue.strip()
 if type(PcdValue) == type('') and PcdValue.startswith('{') and 
PcdValue.endswith('}'):
-PcdValue = PcdValue[1:-1].split(',')
+PcdValue = SplitPcdValueString(PcdValue[1:-1])
 if type(PcdValue) == type([]):
 TmpValue = 0
 Size = 0
+ValueType = ''
 for Item in PcdValue:
+Item = Item.strip()
 if Item.startswith('UINT8'):
 ItemSize = 1
-if Item.startswith('UINT16'):
+ValueType = 'UINT8'
+elif Item.startswith('UINT16'):
 ItemSize = 2
+ValueType = 'UINT16'
 elif Item.startswith('UINT32'):
 ItemSize = 4
+ValueType = 'UINT32'
 elif Item.startswith('UINT64'):
 ItemSize = 8
+ValueType = 'UINT64'
+elif Item.startswith('"') or Item.startswith("'") or 
Item.startswith('L'):
+ItemSize = 0
+ValueType = 'VOID*'
 else:
 ItemSize = 0
-Item = ValueExpressionEx(Item, self.PcdType, 
self._Symb)(True)
+ValueType = 'UINT8'
+Item = ValueExpressionEx(Item, ValueType, 
self._Symb)(True)
 
 if ItemSize == 0:
+try:
+tmpValue = int(Item, 16) if 
Item.upper().startswith('0X') else int(Item, 0)
+if tmpValue > 255:
+raise BadExpression("Byte  array number %s 
should less than 0xFF." % Item)
+except BadExpression, Value:
+raise BadExpression(Value)
+except ValueError:
+pass
 ItemValue, ItemSize = ParseFieldValue(Item)
 else:
 ItemValue = ParseFieldValue(Item)[0]
 
 if type(ItemValue) == type(''):
@@ -792,88 +848,85 @@ class ValueExpressionEx(ValueExpression):
 for I in 

Re: [edk2] [PATCH v2 1/3] MdePkg: restrict UefiMultiPhase.h contents if VFRCOMPILE defined

[Leif Lindholm]

On Fri, Feb 23, 2018 at 10:33:46AM +0800, Zeng, Star wrote:
> Leif,
> 
> On 2018/2/23 4:09, Leif Lindholm wrote:
> > Hi Star,
> > 
> > I lost track of this one during my sabbatical until Ard's patch
> > earlier today jogged my memory.
> > 
> > On Sun, Dec 17, 2017 at 11:23:10AM +, Zeng, Star wrote:
> > > You may submit a bugzilla for the long term approach as Liming
> > > suggested in V1 patch series, and then add the bug link in this
> > > commit log?
> > 
> > I have raised https://bugzilla.tianocore.org/show_bug.cgi?id=878
> > for the enhancement.
> > 
> > Are you OK with the patch as below (it rebases cleanly to current
> > master) if I add the paragraph:
> > ---
> > https://bugzilla.tianocore.org/show_bug.cgi?id=878 has been raised to
> > request VfrCompile is extended to support the original format.
> > ---
> > to the end of the commit message?
> 
> I am ok. With this update, Reviewed-by: Star Zeng .

Thanks!

> I have given RB to MdeModulePkg change before. :)

Yup.

> You may also get opinion from Mike and Liming.

Of course.

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

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 12:04, Pankaj Bansal wrote:

> However Laszlo, with the method you suggest (using STATIC CONST
> UINT16 mOne), would it not add delay in each Mmio Operation ?
> 
> I am concerned about boot delay using this approach.
The condition can be evaluated at compile time, so I expect optimizing
compilers to eliminate the dead branch.

Assuming the condition cannot be eliminated at build time, what is your
concern: the single byte access, or the branch instruction?

I don't think the single byte access matters. (If you tried to replace
that with a HOB or PCD lookup, it could only be worse.)

I also doubt the branch should be a concern. You could replace the "if"
(or the ternary operator "?:") with function pointers that you set e.g.
in a constructor function. But I think an "if" with an invariable
(constant) controlling expression is at least as friendly towards branch
predictors as a function pointer variable (through which you might be
*forced* to make a real function call).

Personally I wouldn't worry.


Anyway: please do not mistake my willingness / preference to go into
such detail for having high stakes at this. If you go an entirely
different route, I'm OK with that too. I felt I was asked for my opinion
and I tried to express it in detail, that's all.

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

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

Hi Laszlo


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:29 PM
> To: Udit Kumar ; Pankaj Bansal
> ; Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Meenakshi Aggarwal
> 
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 11:39, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Friday, February 23, 2018 2:51 PM
> >> To: Pankaj Bansal ; Leif Lindholm
> >> 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> support
> >> for Big Endian Mmio APIs
> >>
> >> On 02/23/18 09:40, Pankaj Bansal wrote:
> >>> Hi All
> >>>
>  -Original Message-
>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
>  Laszlo Ersek
>  Sent: Thursday, February 22, 2018 7:26 PM
>  To: Leif Lindholm 
>  Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>  ard.biesheu...@linaro.org
>  Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support
>  for Big Endian Mmio APIs
> 
>  On 02/22/18 12:52, Leif Lindholm wrote:
> > On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> 
> >>> But that brings back the complication as to how we have a driver
> >>> that needs an LE IO library to write output, and a BE IO library to
> >>> manipulate the hardware.
> >>
> >> Can you please explain the "write output" use case more precisely?
> >>
> >> My thinking would be this:
> >>
> >> - Use the IoLib class directly for "writing output" in little endian
> >> byte order (which is still unclear to me sorry).
> >
> > If the IoLib class is mapped to a an instance that byte-swaps (hereto
> > referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> > end up mapping the non-swapping, currently implemented in
> > BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> > needing to duplicated all IoLib implementation .infs to provide an
> > IoLib and a BeIoLib for each?
> >
> > It's at that point I burst an aneurysm.
> > Am I overthinking/underthinking this?
> 
>  We need two library classes, one for talking to LE devices and another
> to
> >> BE
>  devices. These should be usable in a given module at the same time, as
> >> Ard
>  says.
> 
>  Both library classes need to work on both LE and BE CPUs (working
> from
> >> your
>  suggestion that UEFI might grow BE CPU support at some point).
>  Whether that is implemented by dumb, separate library instances
> >> (yielding in
>  total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> >> library
>  instances (in total, 2), is a different question.
> 
>  Note that such "smarts" could be less than trivial to implement:
>  - check CPU endianness in each library API?
>  - or check in the lib constructor only, and flip some function pointers?
>  - use a dynamic PCD for caching CPU endianness?
>  - use a HOB for the same?
>  - use a lib global variable (for caching only on the module level)?
> 
>  I think the solution that saves the most on the *source* code size is:
>  - introduce the BeIoLib class
>  - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>    BeIoLib instance that we introduce
>  - modify the MMIO functions in *both* lib instances (original LE, and
>    new BE), like this:
> 
>    - If the CPU architecture is known to be bound to a single endianness,
>  then hardcode the appropriate operation. This can be done with
>  preprocessor macros, or with the architecture support of INF files /
>  separate source files. For example, on IA32 and X64, the IoLib
>  instance should work transparently, unconditionally, and the BeIoLib
>  instance should byte-swap, unconditionally.
> 
>    - On other CPU arches, all the wider-than-byte MMIO functions, in
>  *both* lib instances should do something like this:
> 
>  //
>  // at file scope
>  //
>  STATIC CONST UINT16 mOne = 1;
> 
>  //
>  // at function scope
>  //
>  if (*(CONST UINT8 *) == 1) {
>    //
>    // CPU in LE mode:
>    // - work transparently in the IoLib instance
>    // - byte-swap in the BeIoLib instance
>    //
>  } else {
>    //
>    // CPU 

Re: [edk2] [RFC] MdePkg/BaseLib: Change BitField functions.

[Pankaj Bansal]

Hi Liming Gao,

Thanks for your comments.
I am not able to understand the full purpose of the BitField functions.
Can you please help me to understand.

As per my understanding :
BitFieldAnd32 (Operand, StartBit, EndBit, AndData) :

We want to calculate the bitwise and (&) between Operand's bits (StartBit to 
EndBit, both inclusive) and AndData's bits (Startbit to Endbit, both inclusive).
If this is the case, then why is there a restriction on AndData ? (If AndData 
is larger than the bitmask value range specified by StartBit and EndBit, then 
ASSERT().)

How these functions are intended to be used ?

Thanks & Regards,
Pankaj Bansal

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Friday, February 23, 2018 4:33 PM
> To: Pankaj Bansal ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D 
> Subject: RE: [RFC] MdePkg/BaseLib: Change BitField functions.
> 
> Pankaj:
>   OrData, AndData and Value are the bit field value specified by StartBit and
> EndBit. They are not the full value. They must be adjusted to the full value,
> then calculated with Operand.
> 
>   And, we use LShit() or RShit() function for 64bit operand, because we find
> VS compiler may generate the intrinsic function when >> or << is used 64bit
> operand on 32bit arch.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
> >Sent: Tuesday, February 20, 2018 12:50 PM
> >To: edk2-devel@lists.01.org
> >Cc: Gao, Liming ; Kinney, Michael D
> >
> >Subject: RE: [RFC] MdePkg/BaseLib: Change BitField functions.
> >
> >Hi everybody,
> >
> >Any comments on this change ?
> >
> >> -Original Message-
> >> From: Pankaj Bansal
> >> Sent: Friday, February 09, 2018 4:30 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Pankaj Bansal ; Michael D Kinney
> >> ; Liming Gao 
> >> Subject: [RFC] MdePkg/BaseLib: Change BitField functions.
> >>
> >> The bit field functions in MdePkg are not working as expected.
> >> The restrictions on Value parameter such that Value should not be
> >> greater than the bitmask value range specified by StartBit and EndBit
> >> doesn't seem
> >to
> >> make sense.
> >>
> >> Also the restriction on End bit to not be equal to start bit
> >> prohibits single bit change.
> >>
> >> This is an attempt to correct these limitations.
> >>
> >> Cc: Michael D Kinney 
> >> Cc: Liming Gao 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Pankaj Bansal 
> >> ---
> >>
> >> Notes:
> >> This is a RFC patch.
> >>
> >>  MdePkg/Library/BaseLib/BitField.c | 179 ++--
> >>  1 file changed, 89 insertions(+), 90 deletions(-)
> >>
> >> diff --git a/MdePkg/Library/BaseLib/BitField.c
> >> b/MdePkg/Library/BaseLib/BitField.c
> >> index eb9e276..2b5be52 100644
> >> --- a/MdePkg/Library/BaseLib/BitField.c
> >> +++ b/MdePkg/Library/BaseLib/BitField.c
> >> @@ -2,6 +2,8 @@
> >>Bit field functions of BaseLib.
> >>
> >>Copyright (c) 2006 - 2013, Intel Corporation. All rights
> >> reserved.
> >> +  Copyright 2018 NXP
> >> +
> >>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 @@ -14,6 +16,12 @@
> >>
> >>  #include "BaseLibInternals.h"
> >>
> >> +#define BITMASK_UNITN(StartBit, EndBit) \
> >> +(((MAX_UINTN) << (StartBit)) & (MAX_UINTN >> ((sizeof (UINTN) *
> >> +8)
> >> +- 1 - (EndBit
> >> +
> >> +#define BITMASK_UNIT64(StartBit, EndBit) \
> >> +(((MAX_UINT64) << (StartBit)) & (MAX_UINT64 >> ((sizeof (UINT64)
> >> +*
> >> +8) - 1 - (EndBit
> >> +
> >>  /**
> >>Worker function that returns a bit field from Operand.
> >>
> >> @@ -34,11 +42,9 @@ InternalBaseLibBitFieldReadUint (
> >>IN  UINTN EndBit
> >>)
> >>  {
> >> -  //
> >> -  // ~((UINTN)-2 << EndBit) is a mask in which bit[0] thru
> >> bit[EndBit]
> >> -  // are 1's while bit[EndBit + 1] thru the most significant bit are 0's.
> >> -  //
> >> -  return (Operand & ~((UINTN)-2 << EndBit)) >> StartBit;
> >> +  UINTN  Mask = BITMASK_UNITN (StartBit, EndBit);
> >> +
> >> +  return ( (Operand & Mask) >> StartBit);
> >>  }
> >>
> >>  /**
> >> @@ -68,19 +74,9 @@ InternalBaseLibBitFieldOrUint (
> >>IN  UINTN OrData
> >>)
> >>  {
> >> -  //
> >> -  // Higher bits in OrData those are not used must be zero.
> >> -  //
> >> -  // EndBit - StartBit + 1 might be 32 while the result right
> >> shifting 32 on a 32bit integer is undefined,
> >> -  // So the logic is updated to right shift (EndBit - StartBit) bits
> >> and compare the last bit directly.
> >> -  //
> >> -  

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Pankaj Bansal]

Hi All

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, February 23, 2018 4:29 PM
> To: Udit Kumar ; Pankaj Bansal
> ; Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Meenakshi Aggarwal
> 
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 11:39, Udit Kumar wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Laszlo Ersek
> >> Sent: Friday, February 23, 2018 2:51 PM
> >> To: Pankaj Bansal ; Leif Lindholm
> >> 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support for Big Endian Mmio APIs
> >>
> >> On 02/23/18 09:40, Pankaj Bansal wrote:
> >>> Hi All
> >>>
>  -Original Message-
>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>  Of Laszlo Ersek
>  Sent: Thursday, February 22, 2018 7:26 PM
>  To: Leif Lindholm 
>  Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>  ard.biesheu...@linaro.org
>  Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> >> support
>  for Big Endian Mmio APIs
> 
>  On 02/22/18 12:52, Leif Lindholm wrote:
> > On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> 
> >>> But that brings back the complication as to how we have a driver
> >>> that needs an LE IO library to write output, and a BE IO library
> >>> to manipulate the hardware.
> >>
> >> Can you please explain the "write output" use case more precisely?
> >>
> >> My thinking would be this:
> >>
> >> - Use the IoLib class directly for "writing output" in little
> >> endian byte order (which is still unclear to me sorry).
> >
> > If the IoLib class is mapped to a an instance that byte-swaps
> > (hereto referred to as BeIoLib if IoLibSwap is unsuitable), would
> > we not then end up mapping the non-swapping, currently
> implemented
> > in BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> > needing to duplicated all IoLib implementation .infs to provide an
> > IoLib and a BeIoLib for each?
> >
> > It's at that point I burst an aneurysm.
> > Am I overthinking/underthinking this?
> 
>  We need two library classes, one for talking to LE devices and
>  another to
> >> BE
>  devices. These should be usable in a given module at the same time,
>  as
> >> Ard
>  says.
> 
>  Both library classes need to work on both LE and BE CPUs (working
>  from
> >> your
>  suggestion that UEFI might grow BE CPU support at some point).
>  Whether that is implemented by dumb, separate library instances
> >> (yielding in
>  total 2*2=4 library instances), or by smart,
>  CPU-endianness-agnostic
> >> library
>  instances (in total, 2), is a different question.
> 
>  Note that such "smarts" could be less than trivial to implement:
>  - check CPU endianness in each library API?
>  - or check in the lib constructor only, and flip some function pointers?
>  - use a dynamic PCD for caching CPU endianness?
>  - use a HOB for the same?
>  - use a lib global variable (for caching only on the module level)?
> 
>  I think the solution that saves the most on the *source* code size is:
>  - introduce the BeIoLib class
>  - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>    BeIoLib instance that we introduce
>  - modify the MMIO functions in *both* lib instances (original LE, and
>    new BE), like this:
> 
>    - If the CPU architecture is known to be bound to a single endianness,
>  then hardcode the appropriate operation. This can be done with
>  preprocessor macros, or with the architecture support of INF files /
>  separate source files. For example, on IA32 and X64, the IoLib
>  instance should work transparently, unconditionally, and the BeIoLib
>  instance should byte-swap, unconditionally.
> 
>    - On other CPU arches, all the wider-than-byte MMIO functions, in
>  *both* lib instances should do something like this:
> 
>  //
>  // at file scope
>  //
>  STATIC CONST UINT16 mOne = 1;
> 
>  //
>  // at function scope
>  //
>  if (*(CONST UINT8 *) == 1) {
>    //
>    // CPU in LE mode:
>    // - work transparently in the IoLib instance
>    // - byte-swap in the BeIoLib instance
>    //
>  } else {
>    //
> 

Re: [edk2] [RFC] MdePkg/BaseLib: Change BitField functions.

[Gao, Liming]

Pankaj:
  OrData, AndData and Value are the bit field value specified by StartBit and 
EndBit. They are not the full value. They must be adjusted to the full value, 
then calculated with Operand.

  And, we use LShit() or RShit() function for 64bit operand, because we find VS 
compiler may generate the intrinsic function when >> or << is used 64bit 
operand on 32bit arch. 

Thanks
Liming
>-Original Message-
>From: Pankaj Bansal [mailto:pankaj.ban...@nxp.com]
>Sent: Tuesday, February 20, 2018 12:50 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Kinney, Michael D
>
>Subject: RE: [RFC] MdePkg/BaseLib: Change BitField functions.
>
>Hi everybody,
>
>Any comments on this change ?
>
>> -Original Message-
>> From: Pankaj Bansal
>> Sent: Friday, February 09, 2018 4:30 PM
>> To: edk2-devel@lists.01.org
>> Cc: Pankaj Bansal ; Michael D Kinney
>> ; Liming Gao 
>> Subject: [RFC] MdePkg/BaseLib: Change BitField functions.
>>
>> The bit field functions in MdePkg are not working as expected.
>> The restrictions on Value parameter such that Value should not be greater
>> than the bitmask value range specified by StartBit and EndBit doesn't seem
>to
>> make sense.
>>
>> Also the restriction on End bit to not be equal to start bit prohibits 
>> single bit
>> change.
>>
>> This is an attempt to correct these limitations.
>>
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Pankaj Bansal 
>> ---
>>
>> Notes:
>> This is a RFC patch.
>>
>>  MdePkg/Library/BaseLib/BitField.c | 179 ++--
>>  1 file changed, 89 insertions(+), 90 deletions(-)
>>
>> diff --git a/MdePkg/Library/BaseLib/BitField.c
>> b/MdePkg/Library/BaseLib/BitField.c
>> index eb9e276..2b5be52 100644
>> --- a/MdePkg/Library/BaseLib/BitField.c
>> +++ b/MdePkg/Library/BaseLib/BitField.c
>> @@ -2,6 +2,8 @@
>>Bit field functions of BaseLib.
>>
>>Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
>> +  Copyright 2018 NXP
>> +
>>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 @@ -14,6 +16,12 @@
>>
>>  #include "BaseLibInternals.h"
>>
>> +#define BITMASK_UNITN(StartBit, EndBit) \
>> +(((MAX_UINTN) << (StartBit)) & (MAX_UINTN >> ((sizeof (UINTN) * 8)
>> +- 1 - (EndBit
>> +
>> +#define BITMASK_UNIT64(StartBit, EndBit) \
>> +(((MAX_UINT64) << (StartBit)) & (MAX_UINT64 >> ((sizeof (UINT64) *
>> +8) - 1 - (EndBit
>> +
>>  /**
>>Worker function that returns a bit field from Operand.
>>
>> @@ -34,11 +42,9 @@ InternalBaseLibBitFieldReadUint (
>>IN  UINTN EndBit
>>)
>>  {
>> -  //
>> -  // ~((UINTN)-2 << EndBit) is a mask in which bit[0] thru bit[EndBit]
>> -  // are 1's while bit[EndBit + 1] thru the most significant bit are 0's.
>> -  //
>> -  return (Operand & ~((UINTN)-2 << EndBit)) >> StartBit;
>> +  UINTN  Mask = BITMASK_UNITN (StartBit, EndBit);
>> +
>> +  return ( (Operand & Mask) >> StartBit);
>>  }
>>
>>  /**
>> @@ -68,19 +74,9 @@ InternalBaseLibBitFieldOrUint (
>>IN  UINTN OrData
>>)
>>  {
>> -  //
>> -  // Higher bits in OrData those are not used must be zero.
>> -  //
>> -  // EndBit - StartBit + 1 might be 32 while the result right shifting 32 
>> on a
>> 32bit integer is undefined,
>> -  // So the logic is updated to right shift (EndBit - StartBit) bits and 
>> compare
>> the last bit directly.
>> -  //
>> -  ASSERT ((OrData >> (EndBit - StartBit)) == ((OrData >> (EndBit - 
>> StartBit)) &
>> 1));
>> -
>> -  //
>> -  // ~((UINTN)-2 << EndBit) is a mask in which bit[0] thru bit[EndBit]
>> -  // are 1's while bit[EndBit + 1] thru the most significant bit are 0's.
>> -  //
>> -  return Operand | ((OrData << StartBit) & ~((UINTN) -2 << EndBit));
>> +  UINTN  Mask = BITMASK_UNITN (StartBit, EndBit);
>> +
>> +  return ( ( (Operand | OrData) & Mask) | (Operand & ~Mask));
>>  }
>>
>>  /**
>> @@ -110,19 +106,38 @@ InternalBaseLibBitFieldAndUint (
>>IN  UINTN AndData
>>)
>>  {
>> -  //
>> -  // Higher bits in AndData those are not used must be zero.
>> -  //
>> -  // EndBit - StartBit + 1 might be 32 while the result right shifting 32 
>> on a
>> 32bit integer is undefined,
>> -  // So the logic is updated to right shift (EndBit - StartBit) bits and 
>> compare
>> the last bit directly.
>> -  //
>> -  ASSERT ((AndData >> (EndBit - StartBit)) == ((AndData >> (EndBit -
>StartBit))
>> & 1));
>> -
>> -  //
>> -  // ~((UINTN)-2 << EndBit) is a mask in which bit[0] thru bit[EndBit]
>> -  // are 1's while bit[EndBit + 1] thru the most significant bit are 0's.

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 11:39, Udit Kumar wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, February 23, 2018 2:51 PM
>> To: Pankaj Bansal ; Leif Lindholm
>> 
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
>> for Big Endian Mmio APIs
>>
>> On 02/23/18 09:40, Pankaj Bansal wrote:
>>> Hi All
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Laszlo Ersek
 Sent: Thursday, February 22, 2018 7:26 PM
 To: Leif Lindholm 
 Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
 ard.biesheu...@linaro.org
 Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
>> support
 for Big Endian Mmio APIs

 On 02/22/18 12:52, Leif Lindholm wrote:
> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:

>>> But that brings back the complication as to how we have a driver
>>> that needs an LE IO library to write output, and a BE IO library to
>>> manipulate the hardware.
>>
>> Can you please explain the "write output" use case more precisely?
>>
>> My thinking would be this:
>>
>> - Use the IoLib class directly for "writing output" in little endian
>> byte order (which is still unclear to me sorry).
>
> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> end up mapping the non-swapping, currently implemented in
> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> needing to duplicated all IoLib implementation .infs to provide an
> IoLib and a BeIoLib for each?
>
> It's at that point I burst an aneurysm.
> Am I overthinking/underthinking this?

 We need two library classes, one for talking to LE devices and another to
>> BE
 devices. These should be usable in a given module at the same time, as
>> Ard
 says.

 Both library classes need to work on both LE and BE CPUs (working from
>> your
 suggestion that UEFI might grow BE CPU support at some point).
 Whether that is implemented by dumb, separate library instances
>> (yielding in
 total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
>> library
 instances (in total, 2), is a different question.

 Note that such "smarts" could be less than trivial to implement:
 - check CPU endianness in each library API?
 - or check in the lib constructor only, and flip some function pointers?
 - use a dynamic PCD for caching CPU endianness?
 - use a HOB for the same?
 - use a lib global variable (for caching only on the module level)?

 I think the solution that saves the most on the *source* code size is:
 - introduce the BeIoLib class
 - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
   BeIoLib instance that we introduce
 - modify the MMIO functions in *both* lib instances (original LE, and
   new BE), like this:

   - If the CPU architecture is known to be bound to a single endianness,
 then hardcode the appropriate operation. This can be done with
 preprocessor macros, or with the architecture support of INF files /
 separate source files. For example, on IA32 and X64, the IoLib
 instance should work transparently, unconditionally, and the BeIoLib
 instance should byte-swap, unconditionally.

   - On other CPU arches, all the wider-than-byte MMIO functions, in
 *both* lib instances should do something like this:

 //
 // at file scope
 //
 STATIC CONST UINT16 mOne = 1;

 //
 // at function scope
 //
 if (*(CONST UINT8 *) == 1) {
   //
   // CPU in LE mode:
   // - work transparently in the IoLib instance
   // - byte-swap in the BeIoLib instance
   //
 } else {
   //
   // CPU in BE mode:
   // - byte-swap in the IoLib instance
   // - work transparently in the BeIoLib instance
   //
 }
>>>
>>> I suggest this approach :
>>>
>>> 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap
>> the input before write and swap output after read and so on.
>>> Mmio* functions will not perform any byte swapping
>>> 2. create second instance (a copy) of this IoLib for CPUs that are Big 
>>> Endian.
>> We can call it BigEndianIoLib.
>>>  In this library Mmio* functions will swap the input before write and
>> swap output after read and so on.
>>>  BeMmio* functions will not perform any byte swapping.
>>> 3. Include the instance of IoLib 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 11:25, Udit Kumar wrote:
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Laszlo Ersek
>> Sent: Thursday, February 22, 2018 7:26 PM
>> To: Leif Lindholm 
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
>> support for Big Endian Mmio APIs
>>
>> On 02/22/18 12:52, Leif Lindholm wrote:
>>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
>>
> But that brings back the complication as to how we have a driver
> that needs an LE IO library to write output, and a BE IO library
> to manipulate the hardware.

 Can you please explain the "write output" use case more precisely?

 My thinking would be this:

 - Use the IoLib class directly for "writing output" in little
 endian byte order (which is still unclear to me sorry).
>>>
>>> If the IoLib class is mapped to a an instance that byte-swaps
>>> (hereto referred to as BeIoLib if IoLibSwap is unsuitable), would we
>>> not then end up mapping the non-swapping, currently implemented in
>>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
>>> needing to duplicated all IoLib implementation .infs to provide an
>>> IoLib and a BeIoLib for each?
>>>
>>> It's at that point I burst an aneurysm.
>>> Am I overthinking/underthinking this?
>>
>> We need two library classes, one for talking to LE devices and
>> another to BE devices. These should be usable in a given module at
>> the same time, as Ard says.
>>
>> Both library classes need to work on both LE and BE CPUs (working
>> from your suggestion that UEFI might grow BE CPU support at some
>> point). Whether that is implemented by dumb, separate library
>> instances (yielding in total 2*2=4 library instances), or by smart,
>> CPU-endianness-agnostic library instances (in total, 2), is a
>> different question.
>>
>> Note that such "smarts" could be less than trivial to implement:
>> - check CPU endianness in each library API?
>> - or check in the lib constructor only, and flip some function
>>   pointers?
>> - use a dynamic PCD for caching CPU endianness?
>> - use a HOB for the same?
>> - use a lib global variable (for caching only on the module level)?
>>
>> I think the solution that saves the most on the *source* code size
>> is:
>> - introduce the BeIoLib class
>> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>>   BeIoLib instance that we introduce
>> - modify the MMIO functions in *both* lib instances (original LE, and
>>   new BE), like this:
>>
>>   - If the CPU architecture is known to be bound to a single
>> endianness, then hardcode the appropriate operation. This can be
>> done with preprocessor macros, or with the architecture support
>> of INF files / separate source files. For example, on IA32 and
>> X64, the IoLib instance should work transparently,
>> unconditionally, and the BeIoLib instance should byte-swap,
>> unconditionally.
>>
>>   - On other CPU arches, all the wider-than-byte MMIO functions, in
>> *both* lib instances should do something like this:
>>
>> //
>> // at file scope
>> //
>> STATIC CONST UINT16 mOne = 1;
>>
>> //
>> // at function scope
>> //
>> if (*(CONST UINT8 *) == 1) {
>>   //
>>   // CPU in LE mode:
>>   // - work transparently in the IoLib instance
>>   // - byte-swap in the BeIoLib instance
>>   //
>> } else {
>>   //
>>   // CPU in BE mode:
>>   // - byte-swap in the IoLib instance
>>   // - work transparently in the BeIoLib instance
>>   //
>> }
>
> You meant, sort of cpu_to_le and cpu_to_be sort of APIs

I'm lost. I don't know how to put it any clearer. Let me try with actual
code.

(a) Suggested for "MdePkg/Library/BaseIoLibIntrinsic/IoLib.c", which is
used on IA32 and X64, therefore CPU byte order is little endian only:

> UINT32
> EFIAPI
> MmioWrite32 (
>   IN  UINTN Address,
>   IN  UINT32Value
>   )
> {
>   ASSERT ((Address & 3) == 0);
>
>   MemoryFence ();
>   *(volatile UINT32*)Address = Value;
>   MemoryFence ();
>
>   return Value;
> }

In other words, no change to the current implementation.


(b) Suggested for "MdePkg/Library/BaseBeIoLibIntrinsic/IoLib.c", also to
be used on IA32 and X64. Because the CPU byte order is LE only, this
variant will byte-swap unconditionally.

> UINT32
> EFIAPI
> BeMmioWrite32 (
>   IN  UINTN Address,
>   IN  UINT32Value
>   )
> {
>   ASSERT ((Address & 3) == 0);
>
>   MemoryFence ();
>   *(volatile UINT32*)Address = SwapBytes32 (Value);
>   MemoryFence ();
>
>   return Value;
> }


(c) Suggested for "MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c", which
is used on ARM and AARCH64. And here I'll assume that the CPU byte order
on those can be either LE 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, February 23, 2018 2:51 PM
> To: Pankaj Bansal ; Leif Lindholm
> 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 09:40, Pankaj Bansal wrote:
> > Hi All
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Thursday, February 22, 2018 7:26 PM
> >> To: Leif Lindholm 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> support
> >> for Big Endian Mmio APIs
> >>
> >> On 02/22/18 12:52, Leif Lindholm wrote:
> >>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>
> > But that brings back the complication as to how we have a driver
> > that needs an LE IO library to write output, and a BE IO library to
> > manipulate the hardware.
> 
>  Can you please explain the "write output" use case more precisely?
> 
>  My thinking would be this:
> 
>  - Use the IoLib class directly for "writing output" in little endian
>  byte order (which is still unclear to me sorry).
> >>>
> >>> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> >>> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> >>> end up mapping the non-swapping, currently implemented in
> >>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>> needing to duplicated all IoLib implementation .infs to provide an
> >>> IoLib and a BeIoLib for each?
> >>>
> >>> It's at that point I burst an aneurysm.
> >>> Am I overthinking/underthinking this?
> >>
> >> We need two library classes, one for talking to LE devices and another to
> BE
> >> devices. These should be usable in a given module at the same time, as
> Ard
> >> says.
> >>
> >> Both library classes need to work on both LE and BE CPUs (working from
> your
> >> suggestion that UEFI might grow BE CPU support at some point).
> >> Whether that is implemented by dumb, separate library instances
> (yielding in
> >> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> library
> >> instances (in total, 2), is a different question.
> >>
> >> Note that such "smarts" could be less than trivial to implement:
> >> - check CPU endianness in each library API?
> >> - or check in the lib constructor only, and flip some function pointers?
> >> - use a dynamic PCD for caching CPU endianness?
> >> - use a HOB for the same?
> >> - use a lib global variable (for caching only on the module level)?
> >>
> >> I think the solution that saves the most on the *source* code size is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >>   BeIoLib instance that we introduce
> >> - modify the MMIO functions in *both* lib instances (original LE, and
> >>   new BE), like this:
> >>
> >>   - If the CPU architecture is known to be bound to a single endianness,
> >> then hardcode the appropriate operation. This can be done with
> >> preprocessor macros, or with the architecture support of INF files /
> >> separate source files. For example, on IA32 and X64, the IoLib
> >> instance should work transparently, unconditionally, and the BeIoLib
> >> instance should byte-swap, unconditionally.
> >>
> >>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> >> *both* lib instances should do something like this:
> >>
> >> //
> >> // at file scope
> >> //
> >> STATIC CONST UINT16 mOne = 1;
> >>
> >> //
> >> // at function scope
> >> //
> >> if (*(CONST UINT8 *) == 1) {
> >>   //
> >>   // CPU in LE mode:
> >>   // - work transparently in the IoLib instance
> >>   // - byte-swap in the BeIoLib instance
> >>   //
> >> } else {
> >>   //
> >>   // CPU in BE mode:
> >>   // - byte-swap in the IoLib instance
> >>   // - work transparently in the BeIoLib instance
> >>   //
> >> }
> >
> > I suggest this approach :
> >
> > 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap
> the input before write and swap output after read and so on.
> > Mmio* functions will not perform any byte swapping
> > 2. create second instance (a copy) of this IoLib for CPUs that are Big 
> > Endian.
> We can call it BigEndianIoLib.
> >  In this library Mmio* functions will swap the input before write and
> swap output after read and so on.
> >  BeMmio* functions will not perform any byte swapping.
> > 3. Include the instance of IoLib in dsc file based on cpu endianness that 
> > the
> platform 

Re: [edk2] [PATCH v2 1/3] MdePkg: restrict UefiMultiPhase.h contents if VFRCOMPILE defined

[Gao, Liming]

I agree the change in MdePkg. Reviewed-by: Liming Gao 

Thanks
Liming
>-Original Message-
>From: Zeng, Star
>Sent: Friday, February 23, 2018 10:34 AM
>To: Leif Lindholm 
>Cc: Kinney, Michael D ; edk2-
>de...@lists.01.org; Gao, Liming ; Zeng, Star
>
>Subject: Re: [edk2] [PATCH v2 1/3] MdePkg: restrict UefiMultiPhase.h
>contents if VFRCOMPILE defined
>
>Leif,
>
>On 2018/2/23 4:09, Leif Lindholm wrote:
>> Hi Star,
>>
>> I lost track of this one during my sabbatical until Ard's patch
>> earlier today jogged my memory.
>>
>> On Sun, Dec 17, 2017 at 11:23:10AM +, Zeng, Star wrote:
>>> You may submit a bugzilla for the long term approach as Liming
>>> suggested in V1 patch series, and then add the bug link in this
>>> commit log?
>>
>> I have raised https://bugzilla.tianocore.org/show_bug.cgi?id=878
>> for the enhancement.
>>
>> Are you OK with the patch as below (it rebases cleanly to current
>> master) if I add the paragraph:
>> ---
>> https://bugzilla.tianocore.org/show_bug.cgi?id=878 has been raised to
>> request VfrCompile is extended to support the original format.
>> ---
>> to the end of the commit message?
>
>I am ok. With this update, Reviewed-by: Star Zeng .
>I have given RB to MdeModulePkg change before. :)
>
>You may also get opinion from Mike and Liming.
>
>Thanks,
>Star
>
>>
>> Regards,
>>
>> Leif
>>>
>>>
>>>
>>> Thanks,
>>> Star
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Leif Lindholm
>>> Sent: Saturday, December 16, 2017 12:59 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Kinney, Michael D ; Gao, Liming
>
>>> Subject: [edk2] [PATCH v2 1/3] MdePkg: restrict UefiMultiPhase.h
>contents if VFRCOMPILE defined
>>>
>>> Turns out all .vfr files in the tree interacting with DynamicPcds manually
>copy the same set of EFI_VARIABLE_* definitions, since the rest of
>UefiMultiPhase.h is incompatible with VfrCompile.
>>>
>>> Instead, reshuffle these definitions to the start of the file, and put the 
>>> rest
>of the file behind #ifndef VFRCOMPILE to permit direct inclusion in .vfr source
>files.
>>>
>>> Cc: Michael D Kinney 
>>> Cc: Liming Gao 
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Leif Lindholm 
>>> ---
>>>   MdePkg/Include/Uefi/UefiMultiPhase.h | 44 ++--
>>>   1 file changed, 23 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/MdePkg/Include/Uefi/UefiMultiPhase.h
>b/MdePkg/Include/Uefi/UefiMultiPhase.h
>>> index 0dcbb1b9ee..67ecc4c27c 100644
>>> --- a/MdePkg/Include/Uefi/UefiMultiPhase.h
>>> +++ b/MdePkg/Include/Uefi/UefiMultiPhase.h
>>> @@ -15,6 +15,28 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
>ANY KIND, EITHER EXPRESS OR IMPLIED.
>>>   #ifndef __UEFI_MULTIPHASE_H__
>>>   #define __UEFI_MULTIPHASE_H__
>>>
>>> +///
>>> +/// Attributes of variable.
>>> +///
>>> +#define EFI_VARIABLE_NON_VOLATILE0x0001
>>> +#define EFI_VARIABLE_BOOTSERVICE_ACCESS  0x0002
>>> +#define EFI_VARIABLE_RUNTIME_ACCESS  0x0004
>>> +///
>>> +/// This attribute is identified by the mnemonic 'HR'
>>> +/// elsewhere in this specification.
>>> +///
>>> +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD
>0x0008
>>> +///
>>> +/// Attributes of Authenticated Variable ///
>>> +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
>0x0020
>>> +#define EFI_VARIABLE_APPEND_WRITE0x0040
>>> +///
>>> +/// NOTE: EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated
>and should be considered reserved.
>>> +///
>>> +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
>0x0010
>>> +
>>> +#ifndef VFRCOMPILE
>>>   #include 
>>>   ///
>>>   /// Enumeration of memory types introduced in UEFI.
>>> @@ -156,27 +178,6 @@ typedef struct {
>>>   } EFI_TABLE_HEADER;
>>>
>>>   ///
>>> -/// Attributes of variable.
>>> -///
>>> -#define EFI_VARIABLE_NON_VOLATILE0x0001
>>> -#define EFI_VARIABLE_BOOTSERVICE_ACCESS  0x0002
>>> -#define EFI_VARIABLE_RUNTIME_ACCESS  0x0004
>>> -///
>>> -/// This attribute is identified by the mnemonic 'HR'
>>> -/// elsewhere in this specification.
>>> -///
>>> -#define EFI_VARIABLE_HARDWARE_ERROR_RECORD   0x0008
>>> -///
>>> -/// Attributes of Authenticated Variable -///
>>> -#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
>0x0020
>>> -#define EFI_VARIABLE_APPEND_WRITE0x0040
>>> -///
>>> -/// NOTE: EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated
>and should be considered reserved.
>>> -///
>>> -#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
>0x0010
>>> -
>>> -///
>>>   

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Udit Kumar]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, February 22, 2018 7:26 PM
> To: Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/22/18 12:52, Leif Lindholm wrote:
> > On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> 
> >>> But that brings back the complication as to how we have a driver
> >>> that needs an LE IO library to write output, and a BE IO library to
> >>> manipulate the hardware.
> >>
> >> Can you please explain the "write output" use case more precisely?
> >>
> >> My thinking would be this:
> >>
> >> - Use the IoLib class directly for "writing output" in little endian
> >> byte order (which is still unclear to me sorry).
> >
> > If the IoLib class is mapped to a an instance that byte-swaps (hereto
> > referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> > end up mapping the non-swapping, currently implemented in
> > BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> > needing to duplicated all IoLib implementation .infs to provide an
> > IoLib and a BeIoLib for each?
> >
> > It's at that point I burst an aneurysm.
> > Am I overthinking/underthinking this?
> 
> We need two library classes, one for talking to LE devices and another to BE
> devices. These should be usable in a given module at the same time, as Ard
> says.
> 
> Both library classes need to work on both LE and BE CPUs (working from
> your suggestion that UEFI might grow BE CPU support at some point).
> Whether that is implemented by dumb, separate library instances (yielding
> in total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> library instances (in total, 2), is a different question.
> 
> Note that such "smarts" could be less than trivial to implement:
> - check CPU endianness in each library API?
> - or check in the lib constructor only, and flip some function pointers?
> - use a dynamic PCD for caching CPU endianness?
> - use a HOB for the same?
> - use a lib global variable (for caching only on the module level)?
> 
> I think the solution that saves the most on the *source* code size is:
> - introduce the BeIoLib class
> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>   BeIoLib instance that we introduce
> - modify the MMIO functions in *both* lib instances (original LE, and
>   new BE), like this:
> 
>   - If the CPU architecture is known to be bound to a single endianness,
> then hardcode the appropriate operation. This can be done with
> preprocessor macros, or with the architecture support of INF files /
> separate source files. For example, on IA32 and X64, the IoLib
> instance should work transparently, unconditionally, and the BeIoLib
> instance should byte-swap, unconditionally.
> 
>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> *both* lib instances should do something like this:
> 
> //
> // at file scope
> //
> STATIC CONST UINT16 mOne = 1;
> 
> //
> // at function scope
> //
> if (*(CONST UINT8 *) == 1) {
>   //
>   // CPU in LE mode:
>   // - work transparently in the IoLib instance
>   // - byte-swap in the BeIoLib instance
>   //
> } else {
>   //
>   // CPU in BE mode:
>   // - byte-swap in the IoLib instance
>   // - work transparently in the BeIoLib instance
>   //
> }

You meant, sort of cpu_to_le and cpu_to_be sort of APIs 
Thanks
Udit
 
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> 01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cudit.kumar%40nxp.com%7C930d96bb226d4491df2
> d08d579fc1717%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63654
> 9046016636482=0uPLjiDP60oNVSdbh44gostMx2id%2BzdLYjk8t%2BLwJ
> tU%3D=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet

[Laszlo Ersek]

On 02/23/18 10:57, Meenakshi Aggarwal wrote:
> Hi All,
> 
> Any comments on this patch or is it good to go?
> 
> Reviewed-by: Jaben Carsey 
> Reviewed-by: Ruiyu Ni 

Are you asking for someone to commit & push the patch?

Laszlo

>> -Original Message-
>> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>> Sent: Thursday, February 22, 2018 2:03 PM
>> To: Meenakshi Aggarwal ; Carsey, Jaben
>> ; edk2-devel@lists.01.org; ler...@redhat.com
>> Subject: Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
>>
>> On 2/20/2018 2:18 PM, Meenakshi Aggarwal wrote:
>>> Hi Ray,
>>>
>>> Please share your comments.
>>>
>>>
>>> Thanks,
>>> Meenakshi
>>>
 -Original Message-
 From: Carsey, Jaben [mailto:jaben.car...@intel.com]
 Sent: Friday, February 16, 2018 8:51 PM
 To: Meenakshi Aggarwal ; Ni, Ruiyu
 ; edk2-devel@lists.01.org; ler...@redhat.com
 Subject: RE: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet

 Seems good to me.  I will let Ray review also.

 Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of
> Meenakshi
> Sent: Friday, February 16, 2018 12:45 AM
> To: Ni, Ruiyu ; Carsey, Jaben
> ; edk2-devel@lists.01.org;
>> ler...@redhat.com
> Subject: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> Importance: High
>
> From: Meenakshi Aggarwal 
>
> Issue:
> Reply for first ping packet was getting dropped.
>
> Cause:
> Sometimes reply message comes even before trasmit
> function returns, hence missing 1st reply
>
> Fix:
> Prepare the TxList before calling Transmit function.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Meenakshi Aggarwal 
> ---
>   ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> index bec9535..46ba701 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> @@ -784,14 +784,17 @@ PingSendEchoRequest (
> }
>
> ASSERT(Private->ProtocolPointers.Transmit != NULL);
> +
> +  InsertTailList (>TxList, >Link);
> +
> Status = Private->ProtocolPointers.Transmit (Private->IpProtocol,
>> TxInfo-
>> Token);
>
> if (EFI_ERROR (Status)) {
> +RemoveEntryList (>Link);
>   PingDestroyTxInfo (TxInfo, Private->IpChoice);
>   return Status;
> }
>
> -  InsertTailList (>TxList, >Link);
> Private->TxCount++;
>
> return EFI_SUCCESS;
> --
> 1.9.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
>

>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
 s.01.org%2Fmailman%2Flistinfo%2Fedk2-

>> devel=02%7C01%7Cmeenakshi.aggarwal%40nxp.com%7C1d7bd63786b

>> 044ba3c9508d57550d50a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0

>> %7C636543912439710731=Bn%2Febt4emmCvayFNmcKCi3xJuFfV52Vq
 4aQLVSNNti8%3D=0
>> Reviewed-by: Ruiyu Ni 
>>
>>
>> --
>> Thanks,
>> Ray

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

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 10:47, Meenakshi Aggarwal wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, February 23, 2018 2:51 PM
>> To: Pankaj Bansal ; Leif Lindholm
>> 
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
>> for Big Endian Mmio APIs
>>
>> On 02/23/18 09:40, Pankaj Bansal wrote:
>>> Hi All
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
 Laszlo Ersek
 Sent: Thursday, February 22, 2018 7:26 PM
 To: Leif Lindholm 
 Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
 ard.biesheu...@linaro.org
 Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
>> support
 for Big Endian Mmio APIs

 On 02/22/18 12:52, Leif Lindholm wrote:
> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:

>>> But that brings back the complication as to how we have a driver
>>> that needs an LE IO library to write output, and a BE IO library to
>>> manipulate the hardware.
>>
>> Can you please explain the "write output" use case more precisely?
>>
>> My thinking would be this:
>>
>> - Use the IoLib class directly for "writing output" in little endian
>> byte order (which is still unclear to me sorry).
>
> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> end up mapping the non-swapping, currently implemented in
> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> needing to duplicated all IoLib implementation .infs to provide an
> IoLib and a BeIoLib for each?
>
> It's at that point I burst an aneurysm.
> Am I overthinking/underthinking this?

 We need two library classes, one for talking to LE devices and another to
>> BE
 devices. These should be usable in a given module at the same time, as
>> Ard
 says.

 Both library classes need to work on both LE and BE CPUs (working from
>> your
 suggestion that UEFI might grow BE CPU support at some point).
 Whether that is implemented by dumb, separate library instances
>> (yielding in
 total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
>> library
 instances (in total, 2), is a different question.

 Note that such "smarts" could be less than trivial to implement:
 - check CPU endianness in each library API?
 - or check in the lib constructor only, and flip some function pointers?
 - use a dynamic PCD for caching CPU endianness?
 - use a HOB for the same?
 - use a lib global variable (for caching only on the module level)?

 I think the solution that saves the most on the *source* code size is:
 - introduce the BeIoLib class
 - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
   BeIoLib instance that we introduce
 - modify the MMIO functions in *both* lib instances (original LE, and
   new BE), like this:

   - If the CPU architecture is known to be bound to a single endianness,
 then hardcode the appropriate operation. This can be done with
 preprocessor macros, or with the architecture support of INF files /
 separate source files. For example, on IA32 and X64, the IoLib
 instance should work transparently, unconditionally, and the BeIoLib
 instance should byte-swap, unconditionally.

   - On other CPU arches, all the wider-than-byte MMIO functions, in
 *both* lib instances should do something like this:

 //
 // at file scope
 //
 STATIC CONST UINT16 mOne = 1;

 //
 // at function scope
 //
 if (*(CONST UINT8 *) == 1) {
   //
   // CPU in LE mode:
   // - work transparently in the IoLib instance
   // - byte-swap in the BeIoLib instance
   //
 } else {
   //
   // CPU in BE mode:
   // - byte-swap in the IoLib instance
   // - work transparently in the BeIoLib instance
   //
 }
>>>
>>> I suggest this approach :
>>>
>>> 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap
>> the input before write and swap output after read and so on.
>>> Mmio* functions will not perform any byte swapping
>>> 2. create second instance (a copy) of this IoLib for CPUs that are Big 
>>> Endian.
>> We can call it BigEndianIoLib.
>>>  In this library Mmio* functions will swap the input before write and 
>>> swap
>> output after read and so on.
>>>  BeMmio* functions will not perform any byte swapping.
>>> 3. Include the 

Re: [edk2] [Patch] BaseTools: Add check for INF statement must be a .inf file

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhu,
>Yonghong
>Sent: Wednesday, February 07, 2018 2:44 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Add check for INF statement must be a .inf
>file
>
>Per FDF spec, INF statement must use a .inf file, we add this error
>check.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/GenFds/FdfParser.py | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
>b/BaseTools/Source/Python/GenFds/FdfParser.py
>index 0190be8..44a3564 100644
>--- a/BaseTools/Source/Python/GenFds/FdfParser.py
>+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
>@@ -1,9 +1,9 @@
> ## @file
> # parse FDF file
> #
>-#  Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
>+#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> #  Copyright (c) 2015, Hewlett Packard Enterprise Development, L.P.
> #
> #  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
>@@ -2484,10 +2484,12 @@ class FdfParser:
> self.__GetInfOptions(ffsInf)
>
> if not self.__GetNextToken():
> raise Warning("expected INF file path", self.FileName,
>self.CurrentLineNumber)
> ffsInf.InfFileName = self.__Token
>+if not ffsInf.InfFileName.endswith('.inf'):
>+raise Warning("expected .inf file path", self.FileName,
>self.CurrentLineNumber)
>
> ffsInf.CurrentLineNum = self.CurrentLineNumber
> ffsInf.CurrentLineContent = self.__CurrentLine()
>
> #Replace $(SAPCE) with real space
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet

[Meenakshi Aggarwal]

Hi All,

Any comments on this patch or is it good to go?

Reviewed-by: Jaben Carsey 
Reviewed-by: Ruiyu Ni 

Thanks,
Meenakshi

> -Original Message-
> From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
> Sent: Thursday, February 22, 2018 2:03 PM
> To: Meenakshi Aggarwal ; Carsey, Jaben
> ; edk2-devel@lists.01.org; ler...@redhat.com
> Subject: Re: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> 
> On 2/20/2018 2:18 PM, Meenakshi Aggarwal wrote:
> > Hi Ray,
> >
> > Please share your comments.
> >
> >
> > Thanks,
> > Meenakshi
> >
> >> -Original Message-
> >> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> >> Sent: Friday, February 16, 2018 8:51 PM
> >> To: Meenakshi Aggarwal ; Ni, Ruiyu
> >> ; edk2-devel@lists.01.org; ler...@redhat.com
> >> Subject: RE: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> >>
> >> Seems good to me.  I will let Ray review also.
> >>
> >> Reviewed-by: Jaben Carsey 
> >>
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
> >>> Meenakshi
> >>> Sent: Friday, February 16, 2018 12:45 AM
> >>> To: Ni, Ruiyu ; Carsey, Jaben
> >>> ; edk2-devel@lists.01.org;
> ler...@redhat.com
> >>> Subject: [edk2] [RFC] ShellPkg/Ping: fix loss of first packet
> >>> Importance: High
> >>>
> >>> From: Meenakshi Aggarwal 
> >>>
> >>> Issue:
> >>> Reply for first ping packet was getting dropped.
> >>>
> >>> Cause:
> >>> Sometimes reply message comes even before trasmit
> >>> function returns, hence missing 1st reply
> >>>
> >>> Fix:
> >>> Prepare the TxList before calling Transmit function.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Meenakshi Aggarwal 
> >>> ---
> >>>   ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 5 -
> >>>   1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> >>> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> >>> index bec9535..46ba701 100644
> >>> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> >>> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> >>> @@ -784,14 +784,17 @@ PingSendEchoRequest (
> >>> }
> >>>
> >>> ASSERT(Private->ProtocolPointers.Transmit != NULL);
> >>> +
> >>> +  InsertTailList (>TxList, >Link);
> >>> +
> >>> Status = Private->ProtocolPointers.Transmit (Private->IpProtocol,
> TxInfo-
>  Token);
> >>>
> >>> if (EFI_ERROR (Status)) {
> >>> +RemoveEntryList (>Link);
> >>>   PingDestroyTxInfo (TxInfo, Private->IpChoice);
> >>>   return Status;
> >>> }
> >>>
> >>> -  InsertTailList (>TxList, >Link);
> >>> Private->TxCount++;
> >>>
> >>> return EFI_SUCCESS;
> >>> --
> >>> 1.9.1
> >>>
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >> s.01.org%2Fmailman%2Flistinfo%2Fedk2-
> >>
> devel=02%7C01%7Cmeenakshi.aggarwal%40nxp.com%7C1d7bd63786b
> >>
> 044ba3c9508d57550d50a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> >>
> %7C636543912439710731=Bn%2Febt4emmCvayFNmcKCi3xJuFfV52Vq
> >> 4aQLVSNNti8%3D=0
> Reviewed-by: Ruiyu Ni 
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 2/2] BaseTools: Fixed the pcd value override issue.

[BobCF]

1. the issue in the overriding value from command line.
2. dec fully value < dec field assign value <
dsc fully value < dsc field assign value

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/AutoGen/GenMake.py | 27 +++---
 .../Source/Python/Workspace/BuildClassObject.py|  4 
 BaseTools/Source/Python/Workspace/DecBuildData.py  |  1 +
 BaseTools/Source/Python/Workspace/DscBuildData.py  | 24 +++
 4 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index afe6f2f99c..110174fb17 100644
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -1549,24 +1549,23 @@ class TopLevelMakefile(BuildFile):
 if GlobalData.gEnableGenfdsMultiThread:
 ExtraOption += " --genfds-multi-thread"
 if GlobalData.gIgnoreSource:
 ExtraOption += " --ignore-sources"
 
-if GlobalData.BuildOptionPcd:
-for index, option in enumerate(GlobalData.gCommand):
-if "--pcd" == option and GlobalData.gCommand[index+1]:
-pcdName, pcdValue = GlobalData.gCommand[index+1].split('=')
-if pcdValue.startswith('H'):
-pcdValue = 'H' + '"' + pcdValue[1:] + '"'
-ExtraOption += " --pcd " + pcdName + '=' + pcdValue
-elif pcdValue.startswith("L'"):
-ExtraOption += "--pcd " + pcdName + '=' + pcdValue
-elif pcdValue.startswith('L'):
-pcdValue = 'L' + '"' + pcdValue[1:] + '"'
-ExtraOption += " --pcd " + pcdName + '=' + pcdValue
-else:
-ExtraOption += " --pcd " + GlobalData.gCommand[index+1]
+for index, option in enumerate(GlobalData.gCommand):
+if "--pcd" == option and GlobalData.gCommand[index+1]:
+pcdName, pcdValue = GlobalData.gCommand[index+1].split('=')
+if pcdValue.startswith('H'):
+pcdValue = 'H' + '"' + pcdValue[1:] + '"'
+ExtraOption += " --pcd " + pcdName + '=' + pcdValue
+elif pcdValue.startswith("L'"):
+ExtraOption += "--pcd " + pcdName + '=' + pcdValue
+elif pcdValue.startswith('L'):
+pcdValue = 'L' + '"' + pcdValue[1:] + '"'
+ExtraOption += " --pcd " + pcdName + '=' + pcdValue
+else:
+ExtraOption += " --pcd " + GlobalData.gCommand[index+1]
 
 MakefileName = self._FILE_NAME_[self._FileType]
 SubBuildCommandList = []
 for A in PlatformInfo.ArchList:
 Command = self._MAKE_TEMPLATE_[self._FileType] % 
{"file":os.path.join("$(BUILD_DIR)", A, MakefileName)}
diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py 
b/BaseTools/Source/Python/Workspace/BuildClassObject.py
index f499cbd58b..05a83e84ac 100644
--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
@@ -124,19 +124,22 @@ class StructurePcd(PcdClassObject):
 self.SkuOverrideValues = collections.OrderedDict({})
 self.FlexibleFieldName = None
 self.StructName = None
 self.PcdDefineLineNo = 0
 self.PkgPath = ""
+self.DefaultValueFromDec = ""
 def __repr__(self):
 return self.TypeName
 
 def AddDefaultValue (self, FieldName, Value, FileName="", LineNo=0):
 if FieldName in self.DefaultValues:
 del self.DefaultValues[FieldName]
 self.DefaultValues[FieldName] = [Value.strip(), FileName, LineNo]
 return self.DefaultValues[FieldName]
 
+def SetDecDefaultValue(self,DefaultValue):
+self.DefaultValueFromDec = DefaultValue
 def AddOverrideValue (self, FieldName, Value, SkuName, DefaultStoreName, 
FileName="", LineNo=0):
 if SkuName not in self.SkuOverrideValues:
 self.SkuOverrideValues[SkuName] = collections.OrderedDict({})
 if DefaultStoreName not in self.SkuOverrideValues[SkuName]:
 self.SkuOverrideValues[SkuName][DefaultStoreName] = 
collections.OrderedDict({})
@@ -173,10 +176,11 @@ class StructurePcd(PcdClassObject):
 self.StructuredPcdIncludeFile = PcdObject.StructuredPcdIncludeFile 
if PcdObject.StructuredPcdIncludeFile else self.StructuredPcdIncludeFile
 self.PackageDecs = PcdObject.PackageDecs if PcdObject.PackageDecs 
else self.PackageDecs
 self.DefaultValues = PcdObject.DefaultValues if 
PcdObject.DefaultValues else self.DefaultValues
 self.PcdMode = PcdObject.PcdMode if PcdObject.PcdMode else 
self.PcdMode
 self.DefaultFromDSC=None
+

[edk2] [Patch 1/2] BaseTools: Improve build performance

[BobCF]

Add cache for building PcdValueInit.c.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/GenFds/GenFds.py  |   1 +
 BaseTools/Source/Python/Workspace/DecBuildData.py |  12 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 168 +++---
 3 files changed, 99 insertions(+), 82 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/GenFds.py 
b/BaseTools/Source/Python/GenFds/GenFds.py
index dcba9f24cb..cd705630a3 100644
--- a/BaseTools/Source/Python/GenFds/GenFds.py
+++ b/BaseTools/Source/Python/GenFds/GenFds.py
@@ -324,10 +324,11 @@ def main():
 EdkLogger.error("GenFds", 
FORMAT_INVALID, "The FV %s's region is specified in multiple FD with different 
value." %FvObj.UiFvName)
 else:
 FvObj.FvRegionInFD = RegionObj.Size
 
RegionObj.BlockInfoOfRegion(FdObj.BlockSizeList, FvObj)
 
+GlobalData.BuildOptionPcd = Options.OptionPcd if Options.OptionPcd 
else {}
 """Call GenFds"""
 GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
 
 """Generate GUID cross reference file"""
 GenFds.GenerateGuidXRefFile(BuildWorkSpace, ArchList, FdfParserObj)
diff --git a/BaseTools/Source/Python/Workspace/DecBuildData.py 
b/BaseTools/Source/Python/Workspace/DecBuildData.py
index 99c3bf14f1..f029169489 100644
--- a/BaseTools/Source/Python/Workspace/DecBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DecBuildData.py
@@ -93,10 +93,11 @@ class DecBuildData(PackageBuildClassObject):
 self._PkgUniFile= None
 self._Protocols = None
 self._Ppis  = None
 self._Guids = None
 self._Includes  = None
+self._CommonIncludes= None
 self._LibraryClasses= None
 self._Pcds  = None
 self.__Macros   = None
 self._PrivateProtocols  = None
 self._PrivatePpis   = None
@@ -294,11 +295,12 @@ class DecBuildData(PackageBuildClassObject):
 self._PrivateGuids[Name] = PrivateGuidDict[self._Arch, Name]
 return self._Guids
 
 ## Retrieve public include paths declared in this package
 def _GetInclude(self):
-if self._Includes == None:
+if self._Includes == None or self._CommonIncludes is None:
+self._CommonIncludes = []
 self._Includes = []
 self._PrivateIncludes = []
 PublicInclues = []
 RecordList = self._RawData[MODEL_EFI_INCLUDE, self._Arch]
 Macros = self._Macros
@@ -322,11 +324,12 @@ class DecBuildData(PackageBuildClassObject):
 else:
 if File not in PublicInclues:
 PublicInclues.append(File)
 if File in self._PrivateIncludes:
 EdkLogger.error('build', OPTION_CONFLICT, "Can't 
determine %s's attribute, it is both defined as Private and non-Private 
attribute in DEC file." % File, File=self.MetaFile, Line=LineNo)
-
+if Record[3] == "COMMON":
+self._CommonIncludes.append(File)
 return self._Includes
 
 ## Retrieve library class declarations (not used in build at present)
 def _GetLibraryClass(self):
 if self._LibraryClasses == None:
@@ -449,10 +452,15 @@ class DecBuildData(PackageBuildClassObject):
 StructurePcds = self.ProcessStructurePcd(StrPcdSet)
 for pcd in StructurePcds:
 Pcds[pcd.TokenCName, pcd.TokenSpaceGuidCName, 
self._PCD_TYPE_STRING_[Type]] = pcd
 
 return Pcds
+@property
+def CommonIncludes(self):
+if self._CommonIncludes is None:
+self.Includes
+return self._CommonIncludes
 
 
 _Macros = property(_GetMacros)
 Arch = property(_GetArch, _SetArch)
 PackageName = property(_GetPackageName)
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 75b877a5aa..5d2922ba44 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -35,10 +35,11 @@ from Common.Misc import ProcessDuplicatedInf
 import re
 from Common.Parsing import IsValidWord
 from Common.VariableAttributes import VariableAttributes
 import Common.GlobalData as GlobalData
 import subprocess
+from Common.Misc import SaveFileOnChange
 from Workspace.BuildClassObject import PlatformBuildClassObject, StructurePcd, 
PcdClassObject, ModuleBuildClassObject
 
 #
 # Treat CHAR16 as a synonym for UINT16.  CHAR16 support is required for VFR C 
structs
 #
@@ -87,11 +88,10 @@ LIBS = $(LIB_PATH)\Common.lib
 
 !INCLUDE $(BASE_TOOLS_PATH)\Source\C\Makefiles\ms.app
 '''
 
 PcdGccMakefile = '''
-ARCH ?= IA32
 MAKEROOT 

[edk2] [PATCH 3/4] MdePkg/Include: Add VA list support for VS2017/ARM64

[Pete Batard]

We need to explicitly call the built-in __va_start() for ARM64, otherwise
the variable parameters are not properly enqueued for the next function
calls.
Also do the same for ARM, as as it doesn't harm us.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 MdePkg/Include/Base.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
index a94182f08886..4f7bd4449c36 100644
--- a/MdePkg/Include/Base.h
+++ b/MdePkg/Include/Base.h
@@ -668,16 +668,15 @@ struct _LIST_ENTRY {
 
 #define VA_COPY(Dest, Start)  __va_copy (Dest, Start)
 
-#elif defined(_M_ARM)
+#elif defined(_M_ARM) || defined(_M_ARM64)
 //
 // MSFT ARM variable argument list support.
-// Same as the generic macros below, except for VA_ARG that needs extra 
adjustment.
 //
 
 typedef char* VA_LIST;
 
-#define VA_START(Marker, Parameter) (Marker = (VA_LIST) ((UINTN) & 
(Parameter) + _INT_SIZE_OF(Parameter)))
-#define VA_ARG(Marker, TYPE)(*(TYPE *) ((Marker += 
_INT_SIZE_OF(TYPE) + ((-(INTN)Marker) & (sizeof(TYPE) - 1))) - _INT_SIZE_OF 
(TYPE)))
+#define VA_START(Marker, Parameter) __va_start (, , 
_INT_SIZE_OF (Parameter), __alignof(Parameter), )
+#define VA_ARG(Marker, TYPE)(*(TYPE *) ((Marker += _INT_SIZE_OF 
(TYPE) + ((-(INTN)Marker) & (sizeof(TYPE) - 1))) - _INT_SIZE_OF (TYPE)))
 #define VA_END(Marker)  (Marker = (VA_LIST) 0)
 #define VA_COPY(Dest, Start)((void)((Dest) = (Start)))
 
-- 
2.9.3.windows.2

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

[edk2] [PATCH 1/4] MdePkg: Disable some Level 4 warnings for VS2017/ARM64

[Pete Batard]

We disable the exact same warnings as IA32 and X64.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 MdePkg/Include/AArch64/ProcessorBind.h | 53 +++-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/AArch64/ProcessorBind.h 
b/MdePkg/Include/AArch64/ProcessorBind.h
index bc473562f9e5..968c18f915ae 100644
--- a/MdePkg/Include/AArch64/ProcessorBind.h
+++ b/MdePkg/Include/AArch64/ProcessorBind.h
@@ -1,7 +1,7 @@
 /** @file
   Processor or Compiler specific defines and types for AArch64.
 
-  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
   Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
 
@@ -30,7 +30,53 @@
 #pragma pack()
 #endif
 
-#if _MSC_EXTENSIONS
+#if defined(_MSC_EXTENSIONS)
+
+//
+// Disable some level 4 compilation warnings (same as IA32 and X64)
+//
+
+//
+// Disabling bitfield type checking warnings.
+//
+#pragma warning ( disable : 4214 )
+
+//
+// Disabling the unreferenced formal parameter warnings.
+//
+#pragma warning ( disable : 4100 )
+
+//
+// Disable slightly different base types warning as CHAR8 * can not be set
+// to a constant string.
+//
+#pragma warning ( disable : 4057 )
+
+//
+// ASSERT(FALSE) or while (TRUE) are legal constructs so suppress this warning
+//
+#pragma warning ( disable : 4127 )
+
+//
+// This warning is caused by functions defined but not used. For precompiled 
header only.
+//
+#pragma warning ( disable : 4505 )
+
+//
+// This warning is caused by empty (after preprocessing) source file. For 
precompiled header only.
+//
+#pragma warning ( disable : 4206 )
+
+//
+// Disable 'potentially uninitialized local variable X used' warnings
+//
+#pragma warning ( disable : 4701 )
+
+//
+// Disable 'potentially uninitialized local pointer variable X used' warnings
+//
+#pragma warning ( disable : 4703 )
+
   //
   // use Microsoft* C compiler dependent integer width types
   //
@@ -45,7 +91,9 @@
   typedef unsigned char   UINT8;
   typedef charCHAR8;
   typedef signed char INT8;
+
 #else
+
   //
   // Assume standard AARCH64 alignment.
   //
@@ -60,6 +108,7 @@
   typedef unsigned char   UINT8;
   typedef charCHAR8;
   typedef signed char INT8;
+
 #endif
 
 ///
-- 
2.9.3.windows.2

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

[edk2] [PATCH 2/4] MdePkg/Library/BaseLib: Enable VS2017/ARM64 builds

[Pete Batard]

Required GCC assembly files are converted for the MSFT assembler

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm  |  39 
 MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm  |  37 +++
 MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm   |  37 +++
 MdePkg/Library/BaseLib/AArch64/GetInterruptsState.asm |  49 ++
 MdePkg/Library/BaseLib/AArch64/MemoryFence.asm|  38 
 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm| 101 

 MdePkg/Library/BaseLib/AArch64/SwitchStack.asm|  69 +
 MdePkg/Library/BaseLib/BaseLib.inf|   8 ++
 8 files changed, 378 insertions(+)

diff --git a/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm 
b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm
new file mode 100644
index ..17e993f5b77e
--- /dev/null
+++ b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm
@@ -0,0 +1,39 @@
+;--
+;
+; CpuBreakpoint() for AArch64
+;
+; Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+; Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+; Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
+; This program and the accompanying materials
+; are licensed and made available under the terms and conditions of the BSD 
License
+; which accompanies this distribution.  The full text of the license may be 
found at
+; http://opensource.org/licenses/bsd-license.php.
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+;--
+
+
+  EXPORT CpuBreakpoint
+  AREA BaseLib_LowLevel, CODE, READONLY
+
+;/**
+;  Generates a breakpoint on the CPU.
+;
+;  Generates a breakpoint on the CPU. The breakpoint must be implemented such
+;  that code can resume normal execution after the breakpoint.
+;
+;**/
+;VOID
+;EFIAPI
+;CpuBreakpoint (
+;  VOID
+;  );
+;
+CpuBreakpoint
+svc   0xdbdb// Superviser exception. Takes 16bit arg -> Armv7 had 
'swi' here.
+ret
+
+  END
diff --git a/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm 
b/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm
new file mode 100644
index ..498493454c7d
--- /dev/null
+++ b/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm
@@ -0,0 +1,37 @@
+;--
+;
+; DisableInterrupts() for AArch64
+;
+; Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+; Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+; Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
+; This program and the accompanying materials
+; are licensed and made available under the terms and conditions of the BSD 
License
+; which accompanies this distribution.  The full text of the license may be 
found at
+; http://opensource.org/licenses/bsd-license.php.
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+;--
+
+  EXPORT DisableInterrupts
+  AREA BaseLib_LowLevel, CODE, READONLY
+
+DAIF_WR_IRQ_BIT EQU (1 << 1)
+
+;/**
+;  Disables CPU interrupts.
+;
+;**/
+;VOID
+;EFIAPI
+;DisableInterrupts (
+;  VOID
+;  );
+;
+DisableInterrupts
+msr  daifset, #DAIF_WR_IRQ_BIT
+ret
+
+  END
diff --git a/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm 
b/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm
new file mode 100644
index ..ec3d6e45ff8a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm
@@ -0,0 +1,37 @@
+;--
+;
+; EnableInterrupts() for AArch64
+;
+; Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+; Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
+; Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
+; This program and the accompanying materials
+; are licensed and made available under the terms and conditions of the BSD 
License
+; which accompanies this distribution.  The full text of the license may be 
found at
+; http://opensource.org/licenses/bsd-license.php.
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+;--
+
+  EXPORT EnableInterrupts
+  AREA BaseLib_LowLevel, CODE, READONLY
+
+DAIF_WR_IRQ_BIT EQU (1 << 1)
+
+;/**
+;  Enables CPU interrupts.
+;
+;**/
+;VOID
+;EFIAPI

[edk2] [PATCH 4/4] BaseTools/Conf: Add VS2017/ARM64 support

[Pete Batard]

Build options for ARM64 are the same as for ARM, except for /BASE:0
which is removed from DLINK flags to avoid LNK1355 error:
invalid base address 0x0; ARM64 image cannot have base address below 4GB

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 BaseTools/Conf/build_rule.template |  2 +-
 BaseTools/Conf/tools_def.template  | 32 ++--
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 77ed282e0311..308505b3dca5 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -206,7 +206,7 @@
 # For RVCTCYGWIN ASM_FLAGS must be first to work around pathing issues
 "$(ASM)" $(ASM_FLAGS) -o ${dst} $(INC) ${d_path}(+)${s_base}.iii
 
-[Assembly-Code-File.COMMON.ARM]
+[Assembly-Code-File.COMMON.ARM,Assembly-Code-File.COMMON.AARCH64]
 # Remove --convert-hex for ARM as it breaks MSFT assemblers
 
 ?.asm, ?.Asm, ?.ASM
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 427ad60b0e26..703019129f79 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -80,6 +80,7 @@ DEFINE VS2017_BIN_HOST= 
DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\DEF(VS2017_HOST
 DEFINE VS2017_BIN_IA32= DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x86
 DEFINE VS2017_BIN_X64 = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\x64
 DEFINE VS2017_BIN_ARM = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\arm
+DEFINE VS2017_BIN_AARCH64 = DEF(VS2017_BIN)\HostDEF(VS2017_HOST)\arm64
 
 DEFINE WINSDK_BIN   = ENV(WINSDK_PREFIX)
 DEFINE WINSDKx86_BIN= ENV(WINSDKx86_PREFIX)
@@ -329,7 +330,7 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
 #   VS2017  -win32-  Requires:
-# Microsoft Visual Studio 2017 version 15.2 or 
later
+# Microsoft Visual Studio 2017 version 15.2 (15.4 
for ARM64) or later
 #Optional:
 # Required to build EBC drivers:
 #   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
@@ -337,7 +338,7 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
 #Note:
-# Building of XIP firmware images for ARM is not 
currently supported (only applications).
+# Building of XIP firmware images for ARM/ARM64 is 
not currently supported (only applications).
 # /FILEALIGN:4096 and other changes are needed for 
ARM firmware builds.
 #   DDK3790 -win32-  Requires:
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
@@ -4200,6 +4201,33 @@ NOOPT_VS2017_ARM_ASM_FLAGS= /nologo
 RELEASE_VS2017_ARM_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB /IGNORE:4001 
/IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /SECTION:.xdata,D /SECTION:.pdata,D 
/MACHINE:ARM /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER 
/MERGE:.rdata=.data
 NOOPT_VS2017_ARM_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
/OPT:REF /OPT:ICF=10 /MAP /SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:ARM 
/LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /DEBUG
 
+#
+# AARCH64 definitions
+#
+*_VS2017_AARCH64_CC_PATH   = DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_VFRPP_PATH= DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_SLINK_PATH= DEF(VS2017_BIN_AARCH64)\lib.exe
+*_VS2017_AARCH64_DLINK_PATH= DEF(VS2017_BIN_AARCH64)\link.exe
+*_VS2017_AARCH64_APP_PATH  = DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_PP_PATH   = DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_ASM_PATH  = DEF(VS2017_BIN_AARCH64)\armasm64.exe
+*_VS2017_AARCH64_ASLCC_PATH= DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_ASLPP_PATH= DEF(VS2017_BIN_AARCH64)\cl.exe
+*_VS2017_AARCH64_ASLDLINK_PATH = DEF(VS2017_BIN_AARCH64)\link.exe
+
+  *_VS2017_AARCH64_MAKE_FLAGS  = /nologo
+  DEBUG_VS2017_AARCH64_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw /Oi-
+RELEASE_VS2017_AARCH64_CC_FLAGS= /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw /Oi-
+NOOPT_VS2017_AARCH64_CC_FLAGS  = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od /Oi-
+
+  

[edk2] [PATCH 0/4] Add ARM64 support for VS2017

[Pete Batard]

This is v2, which just removes a redundant #if defined(_MSC_EXTENSIONS) in 1/4.

This series completes VS2017 support by enabling AARCH64 compilation.
* PATCH 1 targets the disabling of VS Level 4 warnings. The disabled
  warnings for ARM64 are the same as the ones for IA32, X64 and ARM.
* PATCH 2 adds assembly source in MdePkg/Library/BaseLib for various low
  level required functions. These new assembly files were converted from
  their GCC version, with minor changes applied to make them palatable
  to the MSFT assembler.
* PATCH 3 adds variable argument handlers for print output. This is
  achieved without relying on any external toolchain headers. However
  a call to the __va_start() compiler intrinsic function is now being
  used for the VA_START macros, which we apply for ARM as well.
* PATCH 4 enables the selection of ARM64 in the conf templates.
  One item of note is that the build options for ARM64 are the same as
  for ARM, except for /BASE:0 which was removed to avoid error:
  'invalid base address 0x0; ARM64 image cannot have base address below 4GB'

With these patches, VS2017 toolchain users should be able to compile
regular UEFI ARM64 applications using EDK2.

Note however that ARM64 support requires the use of Visual Studio 2017
Update 4 or later (a.k.a. v15.4), as native ARM64 compilation was not
included in any version of Visual Studio prior to that.

Additional notes:

We tested compiling and running the full UEFI Shell with this series, as
well as a small set of applications and drivers, and saw no issues.
Since we also modified the VA_START() macro for ARM, we also re-ran
similar tests for ARM, to confirm that there was no regression there.

Finally, we did not test the generation of a complete QEMU ARM64 firmware
as it requires porting a handful of assembly sources, that don't exist
yet, and our focus is with the generation of working AARCH64 drivers or
applications. Hopefully, this can be tackled as VS2017/ARM64 sees more
usage...

Regards,

/Pete

Pete Batard (4):
  MdePkg: Disable some Level 4 warnings for VS2017/ARM64
  MdePkg/Library/BaseLib: Enable VS2017/ARM64 builds
  MdePkg/Include: Add VA list support for VS2017/ARM64
  BaseTools/Conf: Add VS2017/ARM64 support

 BaseTools/Conf/build_rule.template|   2 +-
 BaseTools/Conf/tools_def.template |  32 ++-
 MdePkg/Include/AArch64/ProcessorBind.h|  53 +-
 MdePkg/Include/Base.h |   7 +-
 MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm  |  39 
 MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm  |  37 +++
 MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm   |  37 +++
 MdePkg/Library/BaseLib/AArch64/GetInterruptsState.asm |  49 ++
 MdePkg/Library/BaseLib/AArch64/MemoryFence.asm|  38 
 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm| 101 

 MdePkg/Library/BaseLib/AArch64/SwitchStack.asm|  69 +
 MdePkg/Library/BaseLib/BaseLib.inf|   8 ++
 12 files changed, 463 insertions(+), 9 deletions(-)
 create mode 100644 MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/DisableInterrupts.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/EnableInterrupts.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/GetInterruptsState.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/MemoryFence.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
 create mode 100644 MdePkg/Library/BaseLib/AArch64/SwitchStack.asm

-- 
2.9.3.windows.2

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

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Meenakshi Aggarwal]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, February 23, 2018 2:51 PM
> To: Pankaj Bansal ; Leif Lindholm
> 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/23/18 09:40, Pankaj Bansal wrote:
> > Hi All
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Thursday, February 22, 2018 7:26 PM
> >> To: Leif Lindholm 
> >> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> >> ard.biesheu...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add
> support
> >> for Big Endian Mmio APIs
> >>
> >> On 02/22/18 12:52, Leif Lindholm wrote:
> >>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> >>
> > But that brings back the complication as to how we have a driver
> > that needs an LE IO library to write output, and a BE IO library to
> > manipulate the hardware.
> 
>  Can you please explain the "write output" use case more precisely?
> 
>  My thinking would be this:
> 
>  - Use the IoLib class directly for "writing output" in little endian
>  byte order (which is still unclear to me sorry).
> >>>
> >>> If the IoLib class is mapped to a an instance that byte-swaps (hereto
> >>> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> >>> end up mapping the non-swapping, currently implemented in
> >>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> >>> needing to duplicated all IoLib implementation .infs to provide an
> >>> IoLib and a BeIoLib for each?
> >>>
> >>> It's at that point I burst an aneurysm.
> >>> Am I overthinking/underthinking this?
> >>
> >> We need two library classes, one for talking to LE devices and another to
> BE
> >> devices. These should be usable in a given module at the same time, as
> Ard
> >> says.
> >>
> >> Both library classes need to work on both LE and BE CPUs (working from
> your
> >> suggestion that UEFI might grow BE CPU support at some point).
> >> Whether that is implemented by dumb, separate library instances
> (yielding in
> >> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic
> library
> >> instances (in total, 2), is a different question.
> >>
> >> Note that such "smarts" could be less than trivial to implement:
> >> - check CPU endianness in each library API?
> >> - or check in the lib constructor only, and flip some function pointers?
> >> - use a dynamic PCD for caching CPU endianness?
> >> - use a HOB for the same?
> >> - use a lib global variable (for caching only on the module level)?
> >>
> >> I think the solution that saves the most on the *source* code size is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >>   BeIoLib instance that we introduce
> >> - modify the MMIO functions in *both* lib instances (original LE, and
> >>   new BE), like this:
> >>
> >>   - If the CPU architecture is known to be bound to a single endianness,
> >> then hardcode the appropriate operation. This can be done with
> >> preprocessor macros, or with the architecture support of INF files /
> >> separate source files. For example, on IA32 and X64, the IoLib
> >> instance should work transparently, unconditionally, and the BeIoLib
> >> instance should byte-swap, unconditionally.
> >>
> >>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> >> *both* lib instances should do something like this:
> >>
> >> //
> >> // at file scope
> >> //
> >> STATIC CONST UINT16 mOne = 1;
> >>
> >> //
> >> // at function scope
> >> //
> >> if (*(CONST UINT8 *) == 1) {
> >>   //
> >>   // CPU in LE mode:
> >>   // - work transparently in the IoLib instance
> >>   // - byte-swap in the BeIoLib instance
> >>   //
> >> } else {
> >>   //
> >>   // CPU in BE mode:
> >>   // - byte-swap in the IoLib instance
> >>   // - work transparently in the BeIoLib instance
> >>   //
> >> }
> >
> > I suggest this approach :
> >
> > 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap
> the input before write and swap output after read and so on.
> > Mmio* functions will not perform any byte swapping
> > 2. create second instance (a copy) of this IoLib for CPUs that are Big 
> > Endian.
> We can call it BigEndianIoLib.
> >  In this library Mmio* functions will swap the input before write and 
> > swap
> output after read and so on.
> >  BeMmio* functions will not perform any byte swapping.
> > 3. Include the instance of IoLib in dsc file based on cpu endianness that 
> > the
> 

Re: [edk2] [Patch] BaseTools: Add *B Flag for the field that from command line

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Friday, February 23, 2018 1:07 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Add *B Flag for the field that from
>command line
>
>For structure PCD, the field value may override in the command line,
>so in the report when we print the field info we add *B Flag for those
>field.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/build/BuildReport.py | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
>diff --git a/BaseTools/Source/Python/build/BuildReport.py
>b/BaseTools/Source/Python/build/BuildReport.py
>index 53d0039..2114499 100644
>--- a/BaseTools/Source/Python/build/BuildReport.py
>+++ b/BaseTools/Source/Python/build/BuildReport.py
>@@ -1234,18 +1234,14 @@ class PcdReport(object):
> self.PrintPcdDefault(File, Pcd, IsStructure, DscMatch,
>DscDefaultValue, InfMatch, InfDefaultValue, DecMatch, DecDefaultValue)
>
> def PrintStructureInfo(self, File, Struct):
> NewInfo = collections.OrderedDict()
> for Key, Value in Struct.items():
>-if Key not in NewInfo:
>-NewInfo[Key] = Value[0]
>+if Value[1] and 'build command options' in Value[1]:
>+FileWrite(File, '*B  %-*s = %s' % (self.MaxLen + 4, '.' + 
>Key,
>Value[0]))
> else:
>-del NewInfo[Key]
>-NewInfo[Key] = Value[0]
>-if NewInfo:
>-for item in NewInfo:
>-FileWrite(File, '%-*s = %s' % (self.MaxLen + 4, '.' + 
>item,
>NewInfo[item]))
>+FileWrite(File, '%-*s = %s' % (self.MaxLen + 4, '.' + 
>Key, Value[0]))
>
> def StrtoHex(self, value):
> try:
> value = hex(int(value))
> return value
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Fix the bug to display the single SKUID info

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Wednesday, February 21, 2018 10:10 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Fix the bug to display the single SKUID info
>
>when defined SKUID_IDENTIFIER = DEFAULT|TEST in DSC [Defines] section,
>per spec it means current SKUID is single, the bug is build report print
>both DEFAULT and TEST info, it should only print TEST.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/Common/Misc.py | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/BaseTools/Source/Python/Common/Misc.py
>b/BaseTools/Source/Python/Common/Misc.py
>index b13e35c..1461d00 100644
>--- a/BaseTools/Source/Python/Common/Misc.py
>+++ b/BaseTools/Source/Python/Common/Misc.py
>@@ -2237,10 +2237,14 @@ class SkuClass():
> self.AvailableSkuIds.update({'DEFAULT':0, 'COMMON':0})
> if self.SkuIdSet:
> GlobalData.gSkuids = (self.SkuIdSet)
> if 'COMMON' in GlobalData.gSkuids:
> GlobalData.gSkuids.remove('COMMON')
>+if self.SkuUsageType == self.SINGLE:
>+if len(GlobalData.gSkuids) != 1:
>+if 'DEFAULT' in GlobalData.gSkuids:
>+GlobalData.gSkuids.remove('DEFAULT')
> if GlobalData.gSkuids:
> GlobalData.gSkuids.sort()
>
> def GetNextSkuId(self, skuname):
> if not self.__SkuInherit:
>--
>2.6.1.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Create NvStorage.fv for GCC build

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Guo Mang 
---
 Platform/BroxtonPlatformPkg/BuildBxtBios.sh | 39 +++--
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/BuildBxtBios.sh 
b/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
index 4ea22bb..fc5a6e2 100755
--- a/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
+++ b/Platform/BroxtonPlatformPkg/BuildBxtBios.sh
@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+# Copyright (c) 2006 - 2018, 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
@@ -288,6 +288,7 @@ echo "check if Build was successful"
 ##**
 ## Post Build processing and cleanup
 ##**
+grep "_PCD_VALUE_" 
$BUILD_PATH/IA32/BroxtonPlatformPkg/Common/PlatformSettings/PlatformPreMemPei/PlatformPreMemPei/DEBUG/AutoGen.h
 > FlashMap.h
 
 #
 # FSP Rebase and Split
@@ -322,6 +323,35 @@ Split -f $BUILD_PATH/FV/Bxt"$Arch".fd -s 0x35000 -o 
$BUILD_PATH/FV/FVIBBM.Fv
 VERSION_MAJOR=$(grep '^VERSION_MAJOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-4)
 VERSION_MINOR=$(grep '^VERSION_MINOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-2)
 
BIOS_Name="$BOARD_ID""$BOARD_REV""$SV_String""$Arch"_"$BUILD_TYPE"_"$VERSION_MAJOR"_"$VERSION_MINOR"
+cp $BUILD_PATH/FV/SOC.fd 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/$BIOS_Name.ROM
+
+echo Get NvStorage Base and Size...
+if [ -e $(pwd)/FlashMap.h ]; then
+  NvStorageBase=$(printf "0x%x" $(grep _PCD_VALUE_PcdFlashNvStorageBase 
FlashMap.h | awk '{print $3}' | awk -FU '{print $1}'))
+  BaseAddress=$(printf "0x%x" $(grep _PCD_VALUE_PcdFlashBaseAddress FlashMap.h 
| awk '{print $3}' | awk -FU '{print $1}'))
+  NvStorageSize=$(printf "0x%x" $(grep _PCD_VALUE_PcdFlashNvStorageSize 
FlashMap.h | awk '{print $3}' | awk -FU '{print $1}'))
+  VpdOffset=$(($NvStorageBase - $BaseAddress))
+  VpdSize=$(printf "%d" $NvStorageSize)
+
+  #Dump what we found
+  echo - NvStorageBase = $NvStorageBase
+  echo - BaseAddress = $BaseAddress
+  echo - NvStorageSize = $NvStorageSize
+  echo - VpdOffset = $VpdOffset
+  echo - VpdSize= $VpdSize
+
+  #Create NvStorage.fv
+  echo Create NvStorage.fv...
+  pushd $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+  Split -f $BIOS_Name.ROM -s $VpdOffset -o temp1.bin -t temp2.bin
+  Split -f temp2.bin -s $VpdSize -o NvStorage.Fv -t temp3.bin
+  rm temp1.bin temp2.bin temp3.bin
+  popd
+else
+  echo "ERROR: Couldn't find FlashMap.h"
+  ErrorExit
+fi
+
 
 cp -f $BUILD_PATH/FV/FVOBB.Fv  
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f $BUILD_PATH/FV/FVOBBX.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
@@ -334,12 +364,10 @@ if [ $BoardId == "BG" ]; then
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_B/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_B/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_B/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_B/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
   else 
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_A/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_A/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_A/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/BensonGlacier/IFWI/FAB_A/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
   fi
 fi
 
@@ -348,12 +376,10 @@ if [ $BoardId == "MN" ]; then
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/IFWI/FAB_B/SpiChunk1.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/IFWI/FAB_B/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Board/MinnowBoard3/IFWI/FAB_B/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-cp -f 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Laszlo Ersek]

On 02/23/18 09:40, Pankaj Bansal wrote:
> Hi All
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Thursday, February 22, 2018 7:26 PM
>> To: Leif Lindholm 
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
>> for Big Endian Mmio APIs
>>
>> On 02/22/18 12:52, Leif Lindholm wrote:
>>> On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
>>
> But that brings back the complication as to how we have a driver
> that needs an LE IO library to write output, and a BE IO library to
> manipulate the hardware.

 Can you please explain the "write output" use case more precisely?

 My thinking would be this:

 - Use the IoLib class directly for "writing output" in little endian
 byte order (which is still unclear to me sorry).
>>>
>>> If the IoLib class is mapped to a an instance that byte-swaps (hereto
>>> referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
>>> end up mapping the non-swapping, currently implemented in
>>> BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
>>> needing to duplicated all IoLib implementation .infs to provide an
>>> IoLib and a BeIoLib for each?
>>>
>>> It's at that point I burst an aneurysm.
>>> Am I overthinking/underthinking this?
>>
>> We need two library classes, one for talking to LE devices and another to BE
>> devices. These should be usable in a given module at the same time, as Ard
>> says.
>>
>> Both library classes need to work on both LE and BE CPUs (working from your
>> suggestion that UEFI might grow BE CPU support at some point).
>> Whether that is implemented by dumb, separate library instances (yielding in
>> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic library
>> instances (in total, 2), is a different question.
>>
>> Note that such "smarts" could be less than trivial to implement:
>> - check CPU endianness in each library API?
>> - or check in the lib constructor only, and flip some function pointers?
>> - use a dynamic PCD for caching CPU endianness?
>> - use a HOB for the same?
>> - use a lib global variable (for caching only on the module level)?
>>
>> I think the solution that saves the most on the *source* code size is:
>> - introduce the BeIoLib class
>> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>>   BeIoLib instance that we introduce
>> - modify the MMIO functions in *both* lib instances (original LE, and
>>   new BE), like this:
>>
>>   - If the CPU architecture is known to be bound to a single endianness,
>> then hardcode the appropriate operation. This can be done with
>> preprocessor macros, or with the architecture support of INF files /
>> separate source files. For example, on IA32 and X64, the IoLib
>> instance should work transparently, unconditionally, and the BeIoLib
>> instance should byte-swap, unconditionally.
>>
>>   - On other CPU arches, all the wider-than-byte MMIO functions, in
>> *both* lib instances should do something like this:
>>
>> //
>> // at file scope
>> //
>> STATIC CONST UINT16 mOne = 1;
>>
>> //
>> // at function scope
>> //
>> if (*(CONST UINT8 *) == 1) {
>>   //
>>   // CPU in LE mode:
>>   // - work transparently in the IoLib instance
>>   // - byte-swap in the BeIoLib instance
>>   //
>> } else {
>>   //
>>   // CPU in BE mode:
>>   // - byte-swap in the IoLib instance
>>   // - work transparently in the BeIoLib instance
>>   //
>> }
> 
> I suggest this approach :
> 
> 1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap the 
> input before write and swap output after read and so on.
> Mmio* functions will not perform any byte swapping
> 2. create second instance (a copy) of this IoLib for CPUs that are Big 
> Endian. We can call it BigEndianIoLib.
>  In this library Mmio* functions will swap the input before write and 
> swap output after read and so on.
>  BeMmio* functions will not perform any byte swapping.
> 3. Include the instance of IoLib in dsc file based on cpu endianness that the 
> platform wants to use. i.e.
> If BIG_ENDIAN == FALSE
>IoLib | ..\..\..\IoLib
>Else
>   IoLib | ..\..\..\BigEndianIoLib
> 4. The devices that are Big endian in platform will always call BeMmio* 
> functions. They need not check CPU endianness.
> 5. The devices that are Little endian in platform will always call Mmio* 
> functions. They need not check CPU endianness.

This can work too, but there is a downside: a large number of IoLib
instances exist in the tree already. If you add the BeMmio* functions to
the existent IoLib class, you'll have to duplicate the implementation to
all instances (identically, I think).

We've had this debate in 

Re: [edk2] [PATCH edk2-non-osi v3 7/7] Hisilicon/D05: Update binary of trusted-firmware

[Ard Biesheuvel]

On 23 February 2018 at 03:17, Guo Heyi  wrote:
> Hi Jeremy,
>
> This TF binaries have not been patched the latest SMCCC workaround; it is 
> based
> on v1.4 release and was only
> patched with "disable/enable MMU in PSCI SMC call", as the commit in upstream 
> TF
> code:
> f62ad322695d16178db464dc062fe0af592c6780
>
> When we generated these binaries, SMCCC patches had not come out so they are 
> not
> contained in these binaries.
>
> Do you recommend using the latest smccc patches?
>

Yes.

The Spectre v2 mitigations that landed in v4.16 and were backported to
v4.15 and v4.14 LTS do not use the PSCI_VERSION call anymore to
perform branch predictor invalidation. Instead, it checks for
SMCCCv1.1, and uses the ARCH_WORKAROUND_1 SMC call if supported. If
not, no BP maintenance is performed.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 1/2] MdePkg: introduce DxeRuntimeDebugLibSerialPort

[Laszlo Ersek]

On 02/22/18 20:57, Ard Biesheuvel wrote:
> On 22 February 2018 at 19:40, Kinney, Michael D
>  wrote:
>>
>> Ard,
>>
>> In DebugAssert(), if you have deadloop or BP enabled for
>> the ASSERT(), then it would be good to have the message
>> available in the local variable Buffer.
>>
>> Perhaps only the call to SerialPortWrite() should be
>> filtered.
>>
> 
> Good point!

I agree!

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

[edk2] [RFC v3 3/3] MdeModulePkg/PciBus: return CPU address for GetBarAttributes

[Heyi Guo]

According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index fef3ece..62179eb 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1972,6 +1972,10 @@ PciIoGetBarAttributes (
 return EFI_UNSUPPORTED;
   }
 }
+
+// According to UEFI spec 2.7, we need return host address for
+// PciIo->GetBarAttributes, and host address = device address - 
translation.
+Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;
   }
 
   return EFI_SUCCESS;
-- 
2.7.4

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

[edk2] [RFC v3 0/3] Add translation support to generic PciHostBridge

[Heyi Guo]

Please note: this is still *RFC* version, so we have not gone thru all the code
in EDK2 for applying the change of PciSegmentLib definition.

v3:
1. Keep definition of Translation consistent in EDKII code: Translation = device
address - host address.
2. Patch 2/2 is split into 2 patches (2/3 and 3/3).
3. Refine comments and commit messages to make the code easier to understand.


v2:
Changs are made according to the discussion on the mailing list, including:

1. PciRootBridgeIo->Configuration should return CPU view address, as well as
PciIo->GetBarAttributes, and Translation Offset should be equal to PCI view
address - CPU view address.

2. Add translation offset to PCI_ROOT_BRIDGE_APERTURE structure definition.

3. PciHostBridge driver internally used Base Address is still based on PCI view
address, and translation offset = CPU view - PCI view, which follows the
definition in ACPI, and not the same as that in UEFI spec.

This is still RFC version, so we have not gone thru all the code in EDK2 for
applying the change of PciSegmentLib definition.

Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 


Heyi Guo (3):
  MdeModulePkg/PciHostBridgeDxe: Add support for address translation
  MdeModulePkg/PciBus: convert host address to device address
  MdeModulePkg/PciBus: return CPU address for GetBarAttributes

 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c |  12 ++-
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
 .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
 MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
 5 files changed, 177 insertions(+), 31 deletions(-)

-- 
2.7.4

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

[edk2] [RFC v3 2/3] MdeModulePkg/PciBus: convert host address to device address

[Heyi Guo]

According to UEFI spec 2.7, PciRootBridgeIo->Configuration() should
return host address (CPU view ddress) rather than device address
(PCI view address), so in function GetMmioAddressTranslationOffset we
need to convert the range to device address before comparing.

And device address = host address + translation offset.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index 190f4b0..fef3ece 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1812,10 +1812,14 @@ GetMmioAddressTranslationOffset (
 return (UINT64) -1;
   }
 
+  // According to UEFI 2.7, EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL::Configuration()
+  // returns host address instead of device address, while 
AddrTranslationOffset
+  // is not zero, and device address = host address + AddrTranslationOffset, so
+  // we convert host address to device address for range compare.
   while (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
 if ((Configuration->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) &&
-(Configuration->AddrRangeMin <= AddrRangeMin) &&
-(Configuration->AddrRangeMin + Configuration->AddrLen >= AddrRangeMin 
+ AddrLen)
+(Configuration->AddrRangeMin + Configuration->AddrTranslationOffset <= 
AddrRangeMin) &&
+(Configuration->AddrRangeMin + Configuration->AddrLen + 
Configuration->AddrTranslationOffset >= AddrRangeMin + AddrLen)
 ) {
   return Configuration->AddrTranslationOffset;
 }
-- 
2.7.4

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

[edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Heyi Guo]

PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:

1. Translation = device address - host address.

2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.

Summary of addresses used:

1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
it is easy to check whether the address is below 4G or above 4G.

2. Address returned by
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
is device address, or else PCI bus driver cannot set correct address
into PCI BAR registers.

3. Address returned by PciRootBridgeIo->Configuration is host address
per UEFI 2.7 definition.

4. Addresses used in GCD manipulation are host address.

5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
address, for they are allocated from GCD.

6. Address passed to PciHostBridgeResourceConflict is host address,
for it comes from ResAllocNode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
 .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
 MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
 4 files changed, 167 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..e8979eb 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
 EFI_EVENT   mIoMmuEvent;
 VOID*mIoMmuRegistration;
 
+STATIC
+UINT64
+GetTranslationByResourceType (
+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
+  IN  PCI_RESOURCE_TYPEResourceType
+  )
+{
+  switch (ResourceType) {
+case TypeIo:
+  return RootBridge->Io.Translation;
+case TypeMem32:
+  return RootBridge->Mem.Translation;
+case TypePMem32:
+  return RootBridge->PMem.Translation;
+case TypeMem64:
+  return RootBridge->MemAbove4G.Translation;
+case TypePMem64:
+  return RootBridge->PMemAbove4G.Translation;
+default:
+  return 0;
+  }
+}
+
 /**
   Ensure the compatibility of an IO space descriptor with the IO aperture.
 
@@ -411,8 +434,12 @@ InitializePciHostBridge (
 }
 
 if (RootBridges[Index].Io.Base <= RootBridges[Index].Io.Limit) {
+  // Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+  // According to UEFI 2.7, device address = host address + Translation.
+  // For GCD resource manipulation, we should use host address, so
+  // Translation is subtracted from device address here.
   Status = AddIoSpace (
- RootBridges[Index].Io.Base,
+ RootBridges[Index].Io.Base - 
RootBridges[Index].Io.Translation,
  RootBridges[Index].Io.Limit - RootBridges[Index].Io.Base + 1
  );
   ASSERT_EFI_ERROR (Status);
@@ -422,7 +449,7 @@ InitializePciHostBridge (
 EfiGcdIoTypeIo,
 0,
 RootBridges[Index].Io.Limit - 
RootBridges[Index].Io.Base + 1,
-[Index].Io.Base,
+[Index].Io.Base - 
RootBridges[Index].Io.Translation,
 gImageHandle,
 NULL
 );
@@ -443,14 +470,18 @@ InitializePciHostBridge (
 
 for (MemApertureIndex = 0; MemApertureIndex < ARRAY_SIZE (MemApertures); 
MemApertureIndex++) {
   if (MemApertures[MemApertureIndex]->Base <= 
MemApertures[MemApertureIndex]->Limit) {
+// Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+// According to UEFI 2.7, 

Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs

[Pankaj Bansal]

Hi All

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, February 22, 2018 7:26 PM
> To: Leif Lindholm 
> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
> for Big Endian Mmio APIs
> 
> On 02/22/18 12:52, Leif Lindholm wrote:
> > On Thu, Feb 22, 2018 at 09:34:05AM +0100, Laszlo Ersek wrote:
> 
> >>> But that brings back the complication as to how we have a driver
> >>> that needs an LE IO library to write output, and a BE IO library to
> >>> manipulate the hardware.
> >>
> >> Can you please explain the "write output" use case more precisely?
> >>
> >> My thinking would be this:
> >>
> >> - Use the IoLib class directly for "writing output" in little endian
> >> byte order (which is still unclear to me sorry).
> >
> > If the IoLib class is mapped to a an instance that byte-swaps (hereto
> > referred to as BeIoLib if IoLibSwap is unsuitable), would we not then
> > end up mapping the non-swapping, currently implemented in
> > BaseLibIoIntrinsic, variant as BeIoLib? Or if not, do we end up
> > needing to duplicated all IoLib implementation .infs to provide an
> > IoLib and a BeIoLib for each?
> >
> > It's at that point I burst an aneurysm.
> > Am I overthinking/underthinking this?
> 
> We need two library classes, one for talking to LE devices and another to BE
> devices. These should be usable in a given module at the same time, as Ard
> says.
> 
> Both library classes need to work on both LE and BE CPUs (working from your
> suggestion that UEFI might grow BE CPU support at some point).
> Whether that is implemented by dumb, separate library instances (yielding in
> total 2*2=4 library instances), or by smart, CPU-endianness-agnostic library
> instances (in total, 2), is a different question.
> 
> Note that such "smarts" could be less than trivial to implement:
> - check CPU endianness in each library API?
> - or check in the lib constructor only, and flip some function pointers?
> - use a dynamic PCD for caching CPU endianness?
> - use a HOB for the same?
> - use a lib global variable (for caching only on the module level)?
> 
> I think the solution that saves the most on the *source* code size is:
> - introduce the BeIoLib class
> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
>   BeIoLib instance that we introduce
> - modify the MMIO functions in *both* lib instances (original LE, and
>   new BE), like this:
> 
>   - If the CPU architecture is known to be bound to a single endianness,
> then hardcode the appropriate operation. This can be done with
> preprocessor macros, or with the architecture support of INF files /
> separate source files. For example, on IA32 and X64, the IoLib
> instance should work transparently, unconditionally, and the BeIoLib
> instance should byte-swap, unconditionally.
> 
>   - On other CPU arches, all the wider-than-byte MMIO functions, in
> *both* lib instances should do something like this:
> 
> //
> // at file scope
> //
> STATIC CONST UINT16 mOne = 1;
> 
> //
> // at function scope
> //
> if (*(CONST UINT8 *) == 1) {
>   //
>   // CPU in LE mode:
>   // - work transparently in the IoLib instance
>   // - byte-swap in the BeIoLib instance
>   //
> } else {
>   //
>   // CPU in BE mode:
>   // - byte-swap in the IoLib instance
>   // - work transparently in the BeIoLib instance
>   //
> }

I suggest this approach :

1. Add BeMmio* functions in existing IoLib. BeMmio* functions will swap the 
input before write and swap output after read and so on.
Mmio* functions will not perform any byte swapping
2. create second instance (a copy) of this IoLib for CPUs that are Big Endian. 
We can call it BigEndianIoLib.
 In this library Mmio* functions will swap the input before write and swap 
output after read and so on.
 BeMmio* functions will not perform any byte swapping.
3. Include the instance of IoLib in dsc file based on cpu endianness that the 
platform wants to use. i.e.
If BIG_ENDIAN == FALSE
   IoLib | ..\..\..\IoLib
   Else
  IoLib | ..\..\..\BigEndianIoLib
4. The devices that are Big endian in platform will always call BeMmio* 
functions. They need not check CPU endianness.
5. The devices that are Little endian in platform will always call Mmio* 
functions. They need not check CPU endianness.

> 
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists
> .01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel=02%7C01%7Cpankaj.bansal%40nxp.com%7C930d96bb226d4491
> df2d08d579fc1717%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 36549046015230218=OtqNxwO10GcZw1GgvSdocBCwNFuuO2Am23eN
> 

Re: [edk2] OEM EFI_STATUS Code Ranges?

[Gao, Liming]

Andrew:
  PI, DXE and BASE status code macro are added to define their status code. 

  Now, there is no OEM status code definition. So, OEM status code macro is not 
added. Have you the usage on OEM status macro?

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Andrew Fish
>Sent: Tuesday, February 20, 2018 8:20 AM
>To: edk2-devel 
>Subject: [edk2] OEM EFI_STATUS Code Ranges?
>
>I noticed the edk2 is missing UEFI defined ranges for OEM EFI_STATUS Code
>Ranges.
>
>~/work/src/edk2/MdePkg(master)>git grep MAX_BIT -- *.h
>Include/AArch64/ProcessorBind.h:84:#define MAX_BIT
>0x8000ULL
>Include/Arm/ProcessorBind.h:139:#define MAX_BIT  0x8000
>Include/Base.h:977:#define ENCODE_ERROR(StatusCode)
>((RETURN_STATUS)(MAX_BIT | (StatusCode)))
>Include/Ebc/ProcessorBind.h:94:#define MAX_BIT ((UINTN)((1ULL <<
>(sizeof (INTN) * 8 - 1
>Include/Ia32/ProcessorBind.h:238:#define MAX_BIT 0x8000
>Include/Ipf/ProcessorBind.h:228:#define MAX_BIT 0x8000ULL
>Include/Pi/PiMultiPhase.h:42:#define DXE_ERROR(StatusCode)  (MAX_BIT |
>(MAX_BIT >> 2) | StatusCode)
>Include/Pi/PiMultiPhase.h:60:#define PI_ENCODE_WARNING(a)
>((MAX_BIT >> 2) | (a))
>Include/Pi/PiMultiPhase.h:67:#define PI_ENCODE_ERROR(a)
>(MAX_BIT | (MAX_BIT >> 2) | (a))
>Include/X64/ProcessorBind.h:252:#define MAX_BIT
>0x8000ULL
>
>
>Is there a reason the OEM ranges never got added?
>
>#define OEM_ENCODE_ERROR(a)  (MAX_BIT | (MAX_BIT >> 1) | (a))
>#define OEM_ENCODE_WARNING(a)  ((MAX_BIT >> 1) | (a))
>
>
>
>
>Thanks,
>
>Andrew Fish
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TPM 2.0 Manufacutre ID wrong byte order

[Lin, Derek (HPS UEFI Dev)]

Hi Chao B,

I think you are right, the Manufacture ID is a byte array. The order in ACPI 
HID is correct.

But Tpm2GetCapabilityManufactureID return a UINT32 value.
EFI_STATUS
EFIAPI
Tpm2GetCapabilityManufactureID (
  OUT UINT32*ManufactureId
  )


This is confused . When the caller use ManufactureId as UINT32, the byte order 
is confused.
For example in Tcg2Dxe.c, it print:
Tpm2GetCapabilityManufactureID - 204D5453

Which should be "53544D20" in the case.

  Status = Tpm2GetCapabilityManufactureID ();
  if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "Tpm2GetCapabilityManufactureID fail!\n"));
  } else {
DEBUG ((EFI_D_INFO, "Tpm2GetCapabilityManufactureID - %08x\n", 
mTcgDxeData.BsCap.ManufacturerID));
  }

How about changing the returning value to a 4 bytes array?

Thanks,
Derek

From: Zhang, Chao B [mailto:chao.b.zh...@intel.com]
Sent: Friday, February 23, 2018 11:03 AM
To: Lin, Derek (HPS UEFI Dev) ; edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Zeng, Star 
Subject: RE: TPM 2.0 Manufacutre ID wrong byte order

Hi Derek:
Can you specify the "reversed" ManufactureId issue?  What did you get from 
this interface?
The implementation follows Vendor ID registry spec. The vendor ID is octet 
array. There is no endian issue here.
We haven't seen any disorder before.


From: Lin, Derek (HPS UEFI Dev) [mailto:derek.l...@hpe.com]
Sent: Thursday, February 22, 2018 7:25 PM
To: edk2-devel@lists.01.org; Zhang, Chao B 
>
Cc: Yao, Jiewen >; Zeng, Star 
>
Subject: TPM 2.0 Manufacutre ID wrong byte order

Hi TPM expert,

The line in 
https://github.com/tianocore/edk2/commit/73126ac2bd9804632255b2fddd4d7633537c9620#diff-76abe1c1ebf05982ed72eaf56f489029R192
 change the byte order of Manufacture ID in Tpm2GetCapabilityManufactureID ().

I see it return "reversed" ManufactureId for two TPM vendor's module.
Also, all other Capability data in Tpm2Capability.c use SwapBytes32 since TPM 
is big-endian, which seems correct.

Can you check this and confirm?

Thanks,
Derek

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