[edk2] [Patch 5/6] MdePkg: Add two PcdApi for Patch VOID* PCD set operation.

2015-08-18 Thread Liming Gao
Two new APIs LibPatchPcdSetPtrAndSize() and LibPatchPcdSetPtrAndSizeS()
are added to catch the size of the updated VOID* PCD value buffer, then
PcdGetSize() API can return the actual size.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
---
 MdePkg/Include/Library/PcdLib.h  |  75 ++-
 MdePkg/Library/DxePcdLib/DxePcdLib.c | 111 +++
 MdePkg/Library/PeiPcdLib/PeiPcdLib.c | 111 +++
 3 files changed, 295 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Library/PcdLib.h b/MdePkg/Include/Library/PcdLib.h
index 962d442..0bbccb3 100644
--- a/MdePkg/Include/Library/PcdLib.h
+++ b/MdePkg/Include/Library/PcdLib.h
@@ -340,12 +340,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
   @return Return the pointer to the Buffer that was set.
 
 **/
 #define PatchPcdSetPtr(TokenName, Size, Buffer) \
-LibPatchPcdSetPtr (
\
-  _gPcd_BinaryPatch_##TokenName,   
\
+LibPatchPcdSetPtrAndSize ( 
\
+  (VOID 
*)_gPcd_BinaryPatch_##TokenName,   \
+  
_gPcd_BinaryPatch_Size_##TokenName, \
   
(UINTN)_PCD_PATCHABLE_##TokenName##_SIZE, \
   (Size),  
\
   (Buffer) 
\
   )
 /**
@@ -2104,10 +2105,80 @@ LibPatchPcdSetPtrS (
   IN   UINTNMaximumDatumSize,
   IN OUT   UINTN*SizeOfBuffer,
   IN CONST VOID *Buffer
   );
 
+/**
+  Sets a value and size of a patchable PCD entry that is type pointer.
+  
+  Sets the PCD entry specified by PatchVariable to the value specified by 
Buffer 
+  and SizeOfBuffer. Buffer is returned.  If SizeOfBuffer is greater than 
+  MaximumDatumSize, then set SizeOfBuffer to MaximumDatumSize and return 
+  NULL to indicate that the set operation was not actually performed.  
+  If SizeOfBuffer is set to MAX_ADDRESS, then SizeOfBuffer must be set to 
+  MaximumDatumSize and NULL must be returned.
+  
+  If PatchVariable is NULL, then ASSERT().
+  If SizeOfPatchVariable is NULL, then ASSERT().
+  If SizeOfBuffer is NULL, then ASSERT().
+  If SizeOfBuffer  0 and Buffer is NULL, then ASSERT().
+
+  @param[out] PatchVariable A pointer to the global variable in a module 
that is 
+the target of the set operation.
+  @param[out] SizeOfPatchVariable A pointer to the size, in bytes, of 
PatchVariable.
+  @param[in] MaximumDatumSize   The maximum size allowed for the PCD entry 
specified by PatchVariable.
+  @param[in, out] SizeOfBuffer  A pointer to the size, in bytes, of Buffer.
+  @param[in] Buffer A pointer to the buffer to used to set the 
target variable.
+  
+  @return Return the pointer to the Buffer that was set.
+
+**/
+VOID *
+EFIAPI
+LibPatchPcdSetPtrAndSize (
+  OUT   VOID*PatchVariable,
+  OUT   UINTN   *SizeOfPatchVariable,
+  INUINTN   MaximumDatumSize,
+  IN OUTUINTN   *SizeOfBuffer,
+  IN CONST  VOID*Buffer
+  );
+
+/**
+  Sets a value and size of a patchable PCD entry that is type pointer.
+
+  Sets the PCD entry specified by PatchVariable to the value specified
+  by Buffer and SizeOfBuffer. If SizeOfBuffer is greater than MaximumDatumSize,
+  then set SizeOfBuffer to MaximumDatumSize and return RETURN_INVALID_PARAMETER
+  to indicate that the set operation was not actually performed.
+  If SizeOfBuffer is set to MAX_ADDRESS, then SizeOfBuffer must be set to
+  MaximumDatumSize and RETURN_INVALID_PARAMETER must be returned.
+
+  If PatchVariable is NULL, then ASSERT().
+  If SizeOfPatchVariable is NULL, then ASSERT().
+  If SizeOfBuffer is NULL, then ASSERT().
+  If SizeOfBuffer  0 and Buffer is NULL, then ASSERT().
+
+  @param[in] PatchVariable  A pointer to the global variable in a module 
that is
+the target of the set operation.
+  @param[out] SizeOfPatchVariable A pointer to the size, in bytes, of 
PatchVariable.
+  @param[in] MaximumDatumSize   The maximum size allowed for the PCD entry 
specified by PatchVariable.
+  @param[in, out] SizeOfBuffer  A pointer to the size, in bytes, of Buffer.
+  @param[in] Buffer A pointer to the buffer to used to set the 
target variable.
+  
+  @return The status of the set operation.
+
+**/
+RETURN_STATUS
+EFIAPI
+LibPatchPcdSetPtrAndSizeS (
+  OUT  VOID *PatchVariable,
+  OUT  UINTN*SizeOfPatchVariable,
+  IN   UINTNMaximumDatumSize,
+  IN OUT   UINTN*SizeOfBuffer,
+  IN CONST VOID 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 21:16, David Woodhouse dw...@infradead.org wrote:
 See http://www.infradead.org/rpr.html
 X-SRS-Rewrite: SMTP reverse-path rewritten from dw...@infradead.org by 
 twosheds.infradead.org
 See http://www.infradead.org/rpr.html


 On 2015-08-17 11:25:41, David Woodhouse wrote:
 On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?

 Not for testing LLP64, no.

 How/who is this helping?

 It was massively useful for testing the OpenSSL stuff I've been working on
 recently. It showed up a number of issues which would otherwise only occur
 a Windows build.


Indeed. I don't use Windows or have access to any MS toolchains, so
this is basically the only way to make sure my code is LLP64 clean.

  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.

 Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
 is lost.

 Maybe MINGW49. But, please not before we figure out how to actually
 deprecate toolchains. :)


Why *must* we have the version encoded into the name? For GCC4x, the
differences are so minor that it is just maintenance overhead imo. I
used CLANG35 instead of CLANG per your request, but I am definitely
not going to add CLANG36 CLANG37 etc unless there is a real need.

 By 'figure out', I mean get to the point where we are okay with
 actually deprecating toolchains.

 Deprecating toolchains is pointless until we can ditch the badly
 maintained 20th century crap that holds us back from using C99 code. Once
 we have the political will to say here's a nickel, kid. Buy yourself a
 real compiler and provide Windows-hosted GCC or LLVM based toolchains,
 there really is no point.


Well, I would think that deprecating toolchains that don't support C99
is the first step towards allowing C99.

We are kidding ourselves if we think that 'present in
tools_def.template' and 'supported' are the same thing. In other
words, many of these toolchains are already deprecated since nobody
uses them, and they may not work anymore at all.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [Patch 3/6] BaseTools: Update SetPcdPtr in AutoGen Code

2015-08-18 Thread Liming Gao
For patchable PCD, map SetPcdPtr() to LibPatchPcdSetPtrAndSize(),
then the size of the updated VOID* value can be cached.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
---
 BaseTools/Source/Python/AutoGen/GenC.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index c4d3307..b76d315 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -1010,12 +1010,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
 AutoGenH.Append('extern %s  %s  %s%s;\n' % (Const, Pcd.DatumType, 
PcdVariableName, Array))
 AutoGenH.Append('#define %s  %s%s\n' % (GetModeName, Type, 
PcdVariableName))
 
 if Pcd.Type == TAB_PCDS_PATCHABLE_IN_MODULE:
 if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, 
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrAndSize((VOID *)_gPcd_BinaryPatch_%s, 
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer), 
(Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrAndSizeS((VOID *)_gPcd_BinaryPatch_%s, 
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer), 
(Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, Pcd.TokenCName, 
Pcd.TokenCName))
 else:
 AutoGenH.Append('#define %s(Value)  (%s = (Value))\n' % 
(SetModeName, PcdVariableName))
 AutoGenH.Append('#define %s(Value)  ((%s = (Value)), 
RETURN_SUCCESS) \n' % (SetModeStatusName, PcdVariableName))
 else:
 AutoGenH.Append('//#define %s  ASSERT(FALSE)  // It is not allowed 
to set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
@@ -1133,12 +1133,12 @@ def CreateLibraryPcdCode(Info, AutoGenC, AutoGenH, Pcd):
 if PcdItemType == TAB_PCDS_PATCHABLE_IN_MODULE:
 PcdVariableName = '_gPcd_' + 
gItemTypeStringDatabase[TAB_PCDS_PATCHABLE_IN_MODULE] + '_' + TokenCName
 AutoGenH.Append('extern volatile %s _gPcd_BinaryPatch_%s%s;\n' 
%(DatumType, TokenCName, Array) )
 AutoGenH.Append('#define %s  %s_gPcd_BinaryPatch_%s\n' %(GetModeName, 
Type, TokenCName))
 if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, 
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrAndSize((VOID *)_gPcd_BinaryPatch_%s, 
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer), 
(Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrAndSizeS((VOID *)_gPcd_BinaryPatch_%s, 
_gPcd_BinaryPatch_Size_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, (SizeOfBuffer), 
(Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, Pcd.TokenCName, 
Pcd.TokenCName))
 else:
 AutoGenH.Append('#define %s(Value)  (%s = (Value))\n' % 
(SetModeName, PcdVariableName))
 AutoGenH.Append('#define %s(Value)  ((%s = (Value)), 
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
 
 PcdDataSize = GetPcdSize(Pcd)
-- 
1.9.5.msysgit.0

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


[edk2] [Patch 6/6] SecurityPkg: Use PcdGetSize to get the size of VOID* PCD value.

2015-08-18 Thread Liming Gao
PcdLib introduces generic API to get the size of VOID* PCD value.
Update Pei and Dxe RsaGuidedLib to use generic PCD API instead of GetEx API.
This change can remove PCD type limitation in these two libraries.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
---
 .../DxeRsa2048Sha256GuidedSectionExtractLib.c | 4 ++--
 .../DxeRsa2048Sha256GuidedSectionExtractLib.inf   | 4 ++--
 .../PeiRsa2048Sha256GuidedSectionExtractLib.c | 4 ++--
 .../PeiRsa2048Sha256GuidedSectionExtractLib.inf   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
 
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
index 2b61014..1f7a299 100644
--- 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
+++ 
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.c
@@ -2,11 +2,11 @@
 
   This library registers RSA 2048 SHA 256 guided section handler 
   to parse RSA 2048 SHA 256 encapsulation section and extract raw data.
   It uses the BaseCrypyLib based on OpenSSL to authenticate the signature.
 
-Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.BR
 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 
   

   
@@ -270,11 +270,11 @@ Rsa2048Sha256GuidedSectionHandler (
   //
   PublicKey = (UINT8 *)PcdGetPtr (PcdRsa2048Sha256PublicKeyBuffer);
   DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer = %p\n, 
PublicKey));
   ASSERT (PublicKey != NULL);
   DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer Token = 
%08x\n, PcdToken (PcdRsa2048Sha256PublicKeyBuffer)));
-  PublicKeyBufferSize = LibPcdGetExSize (gEfiSecurityPkgTokenSpaceGuid, 
PcdToken (PcdRsa2048Sha256PublicKeyBuffer));
+  PublicKeyBufferSize = PcdGetSize (PcdRsa2048Sha256PublicKeyBuffer);
   DEBUG ((DEBUG_VERBOSE, DxePcdRsa2048Sha256: PublicKeyBuffer Size = %08x\n, 
PublicKeyBufferSize));
   ASSERT ((PublicKeyBufferSize % SHA256_DIGEST_SIZE) == 0);
   CryptoStatus = FALSE;
   while (PublicKeyBufferSize != 0) {
 if (CompareMem (Digest, PublicKey, SHA256_DIGEST_SIZE) == 0) {
diff --git 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
 
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
index f1777f4..4681f08 100644
--- 
a/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
+++ 
b/SecurityPkg/Library/DxeRsa2048Sha256GuidedSectionExtractLib/DxeRsa2048Sha256GuidedSectionExtractLib.inf
@@ -48,13 +48,13 @@
   MemoryAllocationLib
   BaseCryptLib
   PcdLib
   PerformanceLib
 
-[PcdEx]  
+[Pcd]  
   gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer## 
SOMETIMES_CONSUMES
-  
+
 [Protocols]
   gEfiSecurityPolicyProtocolGuid   ## SOMETIMES_CONSUMES (Set 
platform override AUTH status if exist)
   
 [Guids]
   gEfiCertTypeRsa2048Sha256Guid  ## PRODUCES   ## UNDEFINED  # Specifies 
RSA 2048 SHA 256 authentication algorithm.
diff --git 
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
 
b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
index 8c0047e..e2a0fb6 100644
--- 
a/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
+++ 
b/SecurityPkg/Library/PeiRsa2048Sha256GuidedSectionExtractLib/PeiRsa2048Sha256GuidedSectionExtractLib.c
@@ -2,11 +2,11 @@
 
   This library registers RSA 2048 SHA 256 guided section handler 
   to parse RSA 2048 SHA 256 encapsulation section and extract raw data.
   It uses the BaseCrypyLib based on OpenSSL to authenticate the signature.
 
-Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2013 - 2015, Intel Corporation. All rights reserved.BR
 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 
   

[edk2] [Patch 0/6] Add generic PcdGetSize() API

2015-08-18 Thread Liming Gao
PcdLib LibPcdGetSize() and LibPcdGetExSize() are type specific API. New 
generic PcdGetSize() API will be added to reterieve the size of PCD value. 
Like PcdGetValue(), it supports all PCD types and all PCD data types. 

BaseTools generates PCD size macros in AutoGen code. 
MdePkg PcdLib adds PcdGetSize() APIs to match those generated macros. 
Modules use PcdGetSize() API to replace LibPcdGetSize() and LibPcdGetExSize() 
APIs.

Liming Gao (6):
  BaseTools: Generate macro for the size of PCD value
  BaseTools: Fix AutoGen issue for Patchable VOID* PCD.
  BaseTools: Update SetPcdPtr in AutoGen Code
  MdePkg: Add four PcdGetSize() API in PcdLib
  MdePkg: Add two PcdApi for Patch VOID* PCD set operation.
  SecurityPkg: Use PcdGetSize to get the size of VOID* PCD value.

 BaseTools/Source/Python/AutoGen/GenC.py|  82 +++--
 MdePkg/Include/Library/PcdLib.h| 133 -
 MdePkg/Library/DxePcdLib/DxePcdLib.c   | 111 +
 MdePkg/Library/PeiPcdLib/PeiPcdLib.c   | 111 +
 .../DxeRsa2048Sha256GuidedSectionExtractLib.c  |   4 +-
 .../DxeRsa2048Sha256GuidedSectionExtractLib.inf|   4 +-
 .../PeiRsa2048Sha256GuidedSectionExtractLib.c  |   4 +-
 .../PeiRsa2048Sha256GuidedSectionExtractLib.inf|   2 +-
 8 files changed, 432 insertions(+), 19 deletions(-)

-- 
1.9.5.msysgit.0

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


[edk2] [Patch 1/6] BaseTools: Generate macro for the size of PCD value

2015-08-18 Thread Liming Gao
PcdLib introduces new APIs to get the size of PCD value.
BaseTools generates those macros in AutoGen code.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bob Feng bob.c.f...@intel.com
---
 BaseTools/Source/Python/AutoGen/GenC.py | 70 ++---
 1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index 84bd607..d706574 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -730,10 +730,25 @@ def DynExPcdTokenNumberMapping(Info, AutoGenH):
 #  COMPAREGUID() will only be used if the Guid passed in 
is local to the module.
 AutoGenH.Append('#define _PCD_TOKEN_EX_%s(GuidPtr)   
__PCD_%s_ADDR_CMP(GuidPtr) ? __PCD_%s_ADDR_CMP(GuidPtr) : 
__PCD_%s_VAL_CMP(GuidPtr)  \n'
 % (Pcd.TokenCName, Pcd.TokenCName, 
Pcd.TokenCName, Pcd.TokenCName))
 TokenCNameList.append(TokenCName)
 
+def GetPcdSize(Pcd):
+if Pcd.DatumType == 'VOID*':
+return Pcd.MaxDatumSize
+if Pcd.DatumType == 'UINT64':
+return 8
+if Pcd.DatumType == 'UINT32':
+return 4
+if Pcd.DatumType == 'UINT16':
+return 2
+if Pcd.DatumType == 'UINT8':
+return 1
+if Pcd.DatumType == 'BOOLEAN':
+return 1
+
+
 ## Create code for module PCDs
 #
 #   @param  InfoThe ModuleAutoGen object
 #   @param  AutoGenCThe TemplateString object for C code
 #   @param  AutoGenHThe TemplateString object for header file
@@ -744,10 +759,14 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
 PcdTokenNumber = Info.PlatformInfo.PcdTokenNumber
 #
 # Write PCDs
 #
 PcdTokenName = '_PCD_TOKEN_' + Pcd.TokenCName
+PatchPcdSizeTokenName = '_PCD_PATCHABLE_' + Pcd.TokenCName +'_SIZE'
+PatchPcdSizeVariableName = '_gPcd_BinaryPatch_Size_' + Pcd.TokenCName
+FixPcdSizeTokenName = '_PCD_SIZE_' + Pcd.TokenCName
+
 if Pcd.Type in gDynamicExPcd:
 TokenNumber = int(Pcd.TokenValue, 0)
 # Add TokenSpaceGuidValue value to PcdTokenName to discriminate the 
DynamicEx PCDs with 
 # different Guids but same TokenCName
 PcdExTokenName = '_PCD_TOKEN_' + Pcd.TokenSpaceGuidCName + '_' + 
Pcd.TokenCName
@@ -785,11 +804,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
 DatumSize = gDatumSizeStringDatabase[Pcd.DatumType]
 DatumSizeLib = gDatumSizeStringDatabaseLib[Pcd.DatumType]
 GetModeName = '_PCD_GET_MODE_' + gDatumSizeStringDatabaseH[Pcd.DatumType] 
+ '_' + Pcd.TokenCName
 SetModeName = '_PCD_SET_MODE_' + gDatumSizeStringDatabaseH[Pcd.DatumType] 
+ '_' + Pcd.TokenCName
 SetModeStatusName = '_PCD_SET_MODE_' + 
gDatumSizeStringDatabaseH[Pcd.DatumType] + '_S_' + Pcd.TokenCName
-
+GetModeSizeName = '_PCD_GET_MODE_SIZE' + '_' + Pcd.TokenCName
+
 PcdExCNameList  = []
 if Pcd.Type in gDynamicExPcd:
 if Info.IsLibrary:
 PcdList = Info.LibraryPcdList
 else:
@@ -802,27 +822,30 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
 # If PcdToken and PcdGet/Set used in the Pcds with different Guids but 
same CName, it should failed to build.
 if PcdExCNameList.count(Pcd.TokenCName)  1:
 AutoGenH.Append('// Disabled the macros, as PcdToken and 
PcdGet/Set are not allowed in the case that more than one DynamicEx Pcds are 
different Guids but same CName.\n')
 AutoGenH.Append('// #define %s  %s\n' % (PcdTokenName, 
PcdExTokenName))
 AutoGenH.Append('// #define %s  LibPcdGetEx%s(%s, %s)\n' % 
(GetModeName, DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
+AutoGenH.Append('#define %s LibPcdGetExSize(%s, %s)\n' % 
(GetModeSizeName,Pcd.TokenSpaceGuidCName, PcdTokenName))
 if Pcd.DatumType == 'VOID*':
 AutoGenH.Append('// #define %s(SizeOfBuffer, Buffer)  
LibPcdSetEx%s(%s, %s, (SizeOfBuffer), (Buffer))\n' % (SetModeName, 
DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
 AutoGenH.Append('// #define %s(SizeOfBuffer, Buffer)  
LibPcdSetEx%sS(%s, %s, (SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, 
DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
 else:
 AutoGenH.Append('// #define %s(Value)  LibPcdSetEx%s(%s, %s, 
(Value))\n' % (SetModeName, DatumSizeLib, Pcd.TokenSpaceGuidCName, 
PcdTokenName))
 AutoGenH.Append('// #define %s(Value)  LibPcdSetEx%sS(%s, %s, 
(Value))\n' % (SetModeStatusName, DatumSizeLib, Pcd.TokenSpaceGuidCName, 
PcdTokenName))
 else:
 AutoGenH.Append('#define %s  %s\n' % (PcdTokenName, 
PcdExTokenName))
 AutoGenH.Append('#define %s  LibPcdGetEx%s(%s, %s)\n' % 
(GetModeName, DatumSizeLib, Pcd.TokenSpaceGuidCName, PcdTokenName))
+AutoGenH.Append('#define %s LibPcdGetExSize(%s, 

[edk2] [Patch 2/6] BaseTools: Fix AutoGen issue for Patchable VOID* PCD.

2015-08-18 Thread Liming Gao
Patchable VOID* PCD set operation should map LibPatchPcdSetPtr()
and LibPatchPcdSetPtrS() API. This has been done when PCD is used
in driver, but not done when PCD is used in library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao liming@intel.com
---
 BaseTools/Source/Python/AutoGen/GenC.py | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
index d706574..c4d3307 100644
--- a/BaseTools/Source/Python/AutoGen/GenC.py
+++ b/BaseTools/Source/Python/AutoGen/GenC.py
@@ -1010,12 +1010,12 @@ def CreateModulePcdCode(Info, AutoGenC, AutoGenH, Pcd):
 AutoGenH.Append('extern %s  %s  %s%s;\n' % (Const, Pcd.DatumType, 
PcdVariableName, Array))
 AutoGenH.Append('#define %s  %s%s\n' % (GetModeName, Type, 
PcdVariableName))
 
 if Pcd.Type == TAB_PCDS_PATCHABLE_IN_MODULE:
 if Pcd.DatumType == 'VOID*':
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtr(_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
-AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrS(_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, 
Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, 
Pcd.TokenCName))
 else:
 AutoGenH.Append('#define %s(Value)  (%s = (Value))\n' % 
(SetModeName, PcdVariableName))
 AutoGenH.Append('#define %s(Value)  ((%s = (Value)), 
RETURN_SUCCESS) \n' % (SetModeStatusName, PcdVariableName))
 else:
 AutoGenH.Append('//#define %s  ASSERT(FALSE)  // It is not allowed 
to set value for a FIXED_AT_BUILD PCD\n' % SetModeName)
@@ -1132,12 +1132,16 @@ def CreateLibraryPcdCode(Info, AutoGenC, AutoGenH, Pcd):
 AutoGenH.Append('#define %s(Value)  LibPcdSet%sS(%s, (Value))\n' % 
(SetModeStatusName, DatumSizeLib, PcdTokenName))
 if PcdItemType == TAB_PCDS_PATCHABLE_IN_MODULE:
 PcdVariableName = '_gPcd_' + 
gItemTypeStringDatabase[TAB_PCDS_PATCHABLE_IN_MODULE] + '_' + TokenCName
 AutoGenH.Append('extern volatile %s _gPcd_BinaryPatch_%s%s;\n' 
%(DatumType, TokenCName, Array) )
 AutoGenH.Append('#define %s  %s_gPcd_BinaryPatch_%s\n' %(GetModeName, 
Type, TokenCName))
-AutoGenH.Append('#define %s(Value)  (%s = (Value))\n' % (SetModeName, 
PcdVariableName))
-AutoGenH.Append('#define %s(Value)  ((%s = (Value)), 
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
+if Pcd.DatumType == 'VOID*':
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtr((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeName, Pcd.TokenCName, Pcd.TokenCName))
+AutoGenH.Append('#define %s(SizeOfBuffer, Buffer)  
LibPatchPcdSetPtrS((VOID *)_gPcd_BinaryPatch_%s, (UINTN)_PCD_PATCHABLE_%s_SIZE, 
(SizeOfBuffer), (Buffer))\n' % (SetModeStatusName, Pcd.TokenCName, 
Pcd.TokenCName))
+else:
+AutoGenH.Append('#define %s(Value)  (%s = (Value))\n' % 
(SetModeName, PcdVariableName))
+AutoGenH.Append('#define %s(Value)  ((%s = (Value)), 
RETURN_SUCCESS)\n' % (SetModeStatusName, PcdVariableName))
 
 PcdDataSize = GetPcdSize(Pcd)
 AutoGenH.Append('#define %s %s\n' % (PatchPcdSizeTokenName, 
PcdDataSize))
 AutoGenH.Append('#define %s %s\n' % 
(GetModeSizeName,PatchPcdSizeVariableName))
 AutoGenH.Append('extern UINTN %s; \n' % PatchPcdSizeVariableName)
-- 
1.9.5.msysgit.0

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


Re: [edk2] [PATCH 1/3] ArmPlatformPkg: PL061: fix accessing GPIO DATA

2015-08-18 Thread Haojian Zhuang
On Tue, 2015-08-18 at 10:45 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 10:39, Haojian Zhuang haojian.zhu...@linaro.org wrote:
  // All bits low except one bit high, restricted to 8 bits
  // (i.e. ensures zeros above 8bits)
 
  But '' is wrong at here. It'll only return 1 or 0 as the result
  of GPIO_PIN_MASK_HIGH_8BIT(Pin).
 
  Since PL061 spec said in below.
 
  In order to write to GPIODATA, the corresponding bits in the mask,
  resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise
  the bit values remain unchanged by the write.
  Similarly, the values read from this register are determined for
  each bit, by the mask bit derived from the address used to access
  the data register, PADDR[9:2]. Bits that are 1 in the address mask
  cause the corresponding bits in GPIODATA to be read, and bits that
  are 0 in the address mask cause the corresponding bits in GPIODATA
  to be read as 0, regardless of their value.
 
  Now simplify the way to read/write bit of GPIO_DATA register.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
  ---
   ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 16 
   ArmPlatformPkg/Include/Drivers/PL061Gpio.h  |  4 
   2 files changed, 8 insertions(+), 12 deletions(-)
 
  diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
  b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  index ff05662..e8a2094 100644
  --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  @@ -125,7 +125,7 @@ Get (
   }
 }
 
  -  if (MmioRead8 (PL061_GPIO_DATA_REG)  GPIO_PIN_MASK_HIGH_8BIT(Gpio)) {
  +  if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Gpio)  2))) {
   *Value = 1;
 } else {
   *Value = 0;
  @@ -181,21 +181,21 @@ Set (
 {
   case GPIO_MODE_INPUT:
 // Set the corresponding direction bit to LOW for input
  -  MmioAnd8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio));
  +  MmioAnd8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK(Gpio));
 
 This should be ~GPIO_PIN_MASK(Gpio)

OK. I'll fix it.
 
 break;
 
   case GPIO_MODE_OUTPUT_0:
 // Set the corresponding data bit to LOW for 0
  -  MmioAnd8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio));
  +  MmioWrite8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Gpio)  2), 
  GPIO_PIN_MASK(Gpio));
 
 You should write the value 0x0 here: this will only affect the GPIO
 that you selected, so it will clear only a single bit
 

All these are already fixed in v3 patches. But I miss to merge them into
the 3rd patch. I'll reformat the patches.

And these other 2 patches of v3 are sent separately since I met the
issue of sending email. I have to resend them again.

Regards
Haojian

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


[edk2] EFI_FILE_PROTOCOL Read my files on local disk

2015-08-18 Thread zaman khan
Hello,
I am trying to read a file on the local disk from an UEFI app (that I'm
executing using NT32). I am new to the programming of it. Could some one
please point me in the right direction.

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:22, Jordan Justen jordan.l.jus...@intel.com wrote:
  Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
  based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
  of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
  you count the comment in tools_def :) This is why I'd rather deprecate
  it as a toolchain, and use the GCC4X toolchains instead.
 

 No, you can't really.

 MinGW generates PE/COFF not ELF, so much of the linker command line is
 different, and it really deserves a toolchain of its own

 Why does it deserve a toolchain of its own if the other toolchain
 produces better code? Why should EDK II care about using the different
 linker path if it isn't the best recommended way to build images?


By the same logic, why on earth do we insist on retaining support for
GCC44 and GCC45?

Note that it is not about the linker path, but about the options that
we pass, for instance to get 4 KB section alignment. MinGW does not
need a linker script for this, you can simply set --section-alignment
and --file-alignment on the command line.

As for the PE/COFF support: if you are incorporating PE/COFF binary
static libraries into your build, you need a native PE/COFF toolchain.
But in general, I think the ELF to PE/COFF conversion is not the most
elegant step in the build, and I would prefer to avoid it if possible
(only, there is no PE/COFF support in the GNU tools for ARM or
AARCH64)

 Making version 4.3.0 part of the definition of UNIXGCC sounds awkward
 to me. In fact, the idea of supporting all toolchains into eternity
 sounds awkward, and it is obviously not working, since many are
 deprecated and don't work at all or only partially. It would be much
 better imo to allow a definition like UNIXGCC to evolve with the state
 of the art

 I mostly agree, but I would rather see us add new toolchains and
 deprecate the old ones rather than evolving the requirements for a
 particular toolchain.

 I think the name UNIXGCC is too generic and too short sighted. It made
 sense at the time, but I don't think we should keep moving it forward
 and turn it into a moving target.

 The MYTOOLS toolchain was what you are describing, but for MSVC. It
 looks like it is stuck at VS2008 though. Anyway, I guess we should
 also deprecate MYTOOLS. :)


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


[edk2] [PATCH v3 0/3] support multiple PL061 gpio controllers

2015-08-18 Thread Haojian Zhuang
*** BLURB HERE ***
Changelog:
  v3:
* Remove GPIO_PIN_MASK_HIGH_8BIT() and GPIO_PIN_MASK_LOW_8BIT().
* Avoid to use MmioAnd8() on updating GPIO DATA register, since PL061
  could access each bit by specified register offset.
* Add PLATFORM_GPIO_CONTROLLER structure in embedded gpio.
* Support multiple PL061 gpio controllers in one platform.
  v2:
* Append the patch to fix gpio pin mask macro.

Haojian Zhuang (3):
  ArmPlatformPkg: PL061: fix accessing GPIO DATA
  EmbeddedPkg: enhance for multiple gpio controllers
  ArmPlatformPkg: PL061: support multiple controller

 ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 ++---
 .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
 ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  44 -
 EmbeddedPkg/EmbeddedPkg.dec|   1 +
 EmbeddedPkg/Include/Protocol/EmbeddedGpio.h|  18 
 5 files changed, 115 insertions(+), 58 deletions(-)

-- 
2.1.4

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


[edk2] [Basetool][ECC][patch]Remove the checkpoint for STATIC modifer

2015-08-18 Thread Chen, Hesheng
Hello Yang and all,
Could you help review this patch? Thank you

[Description]

1.   Remove the checkpoint for STATIC modifier

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen hesheng.c...@intel.commailto:hesheng.c...@intel.com 



Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.commailto:hesheng.c...@intel.com

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


Re: [edk2] [PATCH 13/15] ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org

 ---
  ArmVirtPkg/ArmVirtQemu.dsc | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
 index 216f130..f1af968 100644
 --- a/ArmVirtPkg/ArmVirtQemu.dsc
 +++ b/ArmVirtPkg/ArmVirtQemu.dsc
 @@ -256,7 +256,10 @@ [Components.common]
#
ArmPkg/Drivers/CpuDxe/CpuDxe.inf
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
  !if $(SECURE_BOOT_ENABLE) == TRUE
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
  LibraryClasses
 --
 1.9.5.msysgit.0

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


Re: [edk2] [PATCH 14/15] ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Cc: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org

 ---
  ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 5 -
  4 files changed, 16 insertions(+), 4 deletions(-)

 diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc 
 b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 index 09ec5b3..f5af426 100644
 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
 @@ -220,7 +220,10 @@ [Components.common]
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
EmbeddedPkg/SerialDxe/SerialDxe.inf

 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

#
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 index c1e3513..c76d729 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
 @@ -233,7 +233,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 index 119ba3a..71c794b 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
 @@ -262,7 +262,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 index 37f3648..72103e2 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
 @@ -245,7 +245,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 -  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
 +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 +LibraryClasses
 +  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
 +  }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf

 MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
 --
 1.9.5.msysgit.0

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


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Leif Lindholm
On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
 On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
  Instead of omitting some drivers that are known to break the Foundation
  model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
  simply fail to load without interfering with the boot.
 
  This way, we can use the same boot image for both models.
 
 
 Ping?

Basicallt looks good to me, but I thought I'd wait for Ryan to comment
(and he's on holiday through this week).

Just to confirm - the Mmio probes just return zeroes in the Foundation
model, rather than aborting?

/
Leif

  Ard Biesheuvel (3):
ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
  initializing
ArmPlatformPkg/FVP: unify support for Foundation and Base models
 
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
  -
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 
  +
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
  +++
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
  +
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
  +
   ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
  +
   8 files changed, 64 insertions(+), 18 deletions(-)
 
  --
  1.9.1
 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 14:30, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 On Tue, 2015-08-18 at 11:43 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 11:31, Haojian Zhuang haojian.zhu...@linaro.org wrote:
  On Tue, 2015-08-18 at 11:22 +0200, Ard Biesheuvel wrote:
  On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org 
  wrote:
   Support multiple PL061 controllers.
  
   Contributed-under: TianoCore Contribution Agreement 1.0
   Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
   ---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
   ++---
.../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
3 files changed, 96 insertions(+), 54 deletions(-)
  
   diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
   b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   index e8a2094..3027656 100644
   --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
   @@ -28,6 +28,7 @@
#include Drivers/PL061Gpio.h
  
BOOLEAN mPL061Initialized = FALSE;
   +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;
  
/**
  Function implementations
   @@ -38,20 +39,31 @@ PL061Identify (
  VOID
  )
{
   -  // Check if this is a PrimeCell Peripheral
   -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
   -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
   -return EFI_NOT_FOUND;
   +  UINTNIndex;
   +  UINT32   RegisterBase;
 
  Why is this a 32-bit value?
 
  All registers in PL061 are 32-bit. So we don't need to define UINTN at
  here.
 

 So what happens if the GPIO controller is mapped above 4 GB in physical 
 memory?


 OK. I'll use 64-bit register base at here. But the original PL061 driver
 is also using 32-bit register base. We could get the definition from
 PL061Gpio.h
 #define PL061_GPIO_DATA_REG ((UINT32)PcdGet32
 (PcdPL061GpioBase) + 0x000)


OK. We should also fix that at some point, but for new code, please
don't make any 32-bit assumptions

   @@ -329,6 +367,9 @@ PL061InstallProtocol (
  //
  ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);
  
   +  Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, 
   (VOID **)mPL061PlatformGpio);
   +  ASSERT_EFI_ERROR (Status);
   +
 
  We should fall back to using the PCD if the protocol cannot be found.
  This way, we won't break existing users.
 
 
  I was intended to use fallback. But I think it's not good enough.
 
  1. If anyone defines the PCD register base in dec file. The fallback
  mechanism will be broken.
 

 Well, you would only look at the PCD if the protocol is not installed,
 so I don't see how that would change anything compared to the current
 situation.

  2. Since every driver is built as module, we must create the driver
  dependency.
 

 Please try and use a BEFORE ... depex instead, you can put it in your
 platform GPIO DXE with the file GUID of the PL061 DXE driver.


 I tried to use BEFORE in inf. Here's the content in platform gpio inf.
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = HiKeyGpio
   FILE_GUID  = b51a851c-7bf7-463f-b261-cfb158b7f699
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
   ENTRY_POINT= HiKeyGpioEntryPoint

 [Protocols]
   gPlatformGpioProtocolGuid

 [Depex]
   BEFORE gEmbeddedGpioProtocolGuid


You need to use the file GUID of PL061 DXE here. Perhaps you should
add it as a new GUID definition in the HiSiPkg .dec, with the value
5c1997d7-8d45-4f21-af3c-2206b8ed8bec


 And here's updated PL061 driver.

 PL061InstallProtocol (
   IN EFI_HANDLE ImageHandle,
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
   EFI_STATUSStatus;
   EFI_HANDLEHandle;
   GPIO_CONTROLLER   *GpioController;

   //
   // Make sure the Gpio protocol has not been installed in the system
 yet.
   //
   ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);

   Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, (VOID
 **)mPL061PlatformGpio);
   DEBUG ((EFI_D_ERROR, #%a, %d, Status:%r\n, __func__, __LINE__,
 Status));
   if (EFI_ERROR (Status)  (Status == EFI_NOT_FOUND)) {
 // Create the mPL061PlatformGpio
 mPL061PlatformGpio = (PLATFORM_GPIO_CONTROLLER *)AllocateZeroPool
 (sizeof (PLATFORM_GPIO_CONTROLLER) + sizeof (GPIO_CONTROLLER));
 if (mPL061PlatformGpio == NULL) {
   DEBUG ((EFI_D_ERROR, %a: failed to allocate
 PLATFORM_GPIO_CONTROLLER\n, __func__));
   return EFI_BAD_BUFFER_SIZE;
 }

 mPL061PlatformGpio-GpioCount = PL061_GPIO_PINS;
 mPL061PlatformGpio-GpioControllerCount = 1;
 mPL061PlatformGpio-GpioControllerSize = sizeof (GPIO_CONTROLLER);

Re: [edk2] [PATCH 07/15] ArmPlatformPkg: Add VarCheckLib library mapping

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Since Variable driver has been updated to consume the separated VarCheckLib.

 Cc: Leif Lindholm leif.lindh...@linaro.org
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org

 ---
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc 
 b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 index d2f8f5a..dc69bbb 100644
 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
 @@ -130,6 +130,7 @@ [LibraryClasses.common]


 TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

 AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf

  [LibraryClasses.common.SEC]

 ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf
 --
 1.9.5.msysgit.0

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


Re: [edk2] [PATCH 06/15] ArmVirtPkg: Add VarCheckLib library mapping

2015-08-18 Thread Ard Biesheuvel
On 17 August 2015 at 10:24, Star Zeng star.z...@intel.com wrote:
 Since Variable driver has been updated to consume the separated VarCheckLib.

 Cc: Laszlo Ersek ler...@redhat.com
 Cc: Ard Biesheuvel ard.biesheu...@linaro.org
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Star Zeng star.z...@intel.com

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org

 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index 7bba6eb..8372c58 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -134,6 +134,7 @@ [LibraryClasses.common]

 TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

 AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
  !endif
 +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf

  [LibraryClasses.common.SEC]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
 --
 1.9.5.msysgit.0

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


Re: [edk2] [PATCH 0/5] secure boot support for ARM FVP

2015-08-18 Thread Ard Biesheuvel
On 8 August 2015 at 14:00, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 This series adds support for using the Intel BDS with ArmVExpress-FVP,
 and for building it with UEFI Secure Boot enabled.

 Note that the former is a prerequisite of the latter, since the ARM BDS
 has no GUI for enrolling certificates and enabling secure boot.

 Patch #1 removes the PlatformIntelBdsLIb dependency on BdsLib, which is
 ARM BDS specific. (This patch has been sent out before as an RFC, and
 reviewed by Laszlo, but I had to add a 'Status = EFI_SUCCESS;' to
 GetConsoleDevicePathFromVariable () to fix a RELEASE build error, so
 I dropped the R-b)

 Patch #2 fixes a bug in some debug code that clobbers a EFI_STATUS var
 in the error path that is supposed to report it to the user.

 Patch #3 adds quiet boot/splash screen support to our PlatformIntelBdsLib

 Patch #4 enables the Intel BDS build of ArmVExpress-FVP, by introducing
 a define 'USE_ARM_BDS' which defaults to TRUE but can be disabled on the
 build command line to use the Intel BDS instead.

 Patch #5 enables the Secure Boot build of ArmVExpress-FVP, by introducing
 a define 'SECURE_BOOT_ENABLE' which defaults to FALSE but can be enabled
 on the build command line.


Ping?

 Ard Biesheuvel (5):
   ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency
   ArmPlatformPkg/PlatformIntelBdsLib: fix error handling
   ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support
   ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS
   ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot

  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 18 
 +
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  | 20 
 ++
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc  | 40 
 
  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 36 
 --
  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 -
  ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  2 +-
  6 files changed, 104 insertions(+), 13 deletions(-)

 --
 1.9.1

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


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 14:12, Leif Lindholm leif.lindh...@linaro.org wrote:
 On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
 On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
  Instead of omitting some drivers that are known to break the Foundation
  model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
  simply fail to load without interfering with the boot.
 
  This way, we can use the same boot image for both models.
 

 Ping?

 Basicallt looks good to me, but I thought I'd wait for Ryan to comment
 (and he's on holiday through this week).

 Just to confirm - the Mmio probes just return zeroes in the Foundation
 model, rather than aborting?


Foundation model output:

WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0.
WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0.

Note sure what these reads return, but in each case, the first byte
already differs from the expected value so the init aborts.

I know that this would still be sufficient to blow up on a real
system, but thankfully the model does not model /that/ :-)


  Ard Biesheuvel (3):
ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
  initializing
ArmPlatformPkg/FVP: unify support for Foundation and Base models
 
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
  -
   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 
  +
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
  +++
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
  +
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
  +
   ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
  +
   8 files changed, 64 insertions(+), 18 deletions(-)
 
  --
  1.9.1
 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 Instead of omitting some drivers that are known to break the Foundation
 model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
 simply fail to load without interfering with the boot.

 This way, we can use the same boot image for both models.


Ping?

 Ard Biesheuvel (3):
   ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
   ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
 initializing
   ArmPlatformPkg/FVP: unify support for Foundation and Base models

  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
 -
  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
 +++
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
 +
  ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
 +
  ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
 +
  8 files changed, 64 insertions(+), 18 deletions(-)

 --
 1.9.1

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


Re: [edk2] [PATCH 0/2] AARCH64 tiny code model support

2015-08-18 Thread Ard Biesheuvel
On 10 August 2015 at 12:27, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 The AARCH64 GCC builds use the GCC large code model by default, simply
 because it is the code model that requires the least amount of hacking
 to produce code that supports the PE/COFF conversion applied by Tianocore.

 However, it is suboptimal in more than one way:
 - each symbol reference requires a PC-relative literal load (to obtain the
   address of the memory location that stores the address of the symbol) and 8
   bytes to store the address itself, so it uses more space than necessary;
 - loading the symbol address may stall on the D-cache
 - each symbol address is an absolute address which requires fixing up by the
   PE/COFF loader
 - the large model is not recommended by the GCC developers, and not used very
   widely so it does not receive a lot of testing coverage.

 Now that we can support relative AARCH64 relocations, we can actually switch 
 to
 the GCC tiny code model, which does away with the literals, and simply uses
 PC-relative references to refer to the symbol directly. This does impose a
 1 MB size limit on modules, but this limit is exceeded only very rarely, and
 we can work around it by switching to the small or large model in that case.

 Patch #1 overrides the BuildOptions for the DEBUG Shell build to use the small
 model, since its size exceeds the 1 MB limit.

 Patch #2 sets the AARCH64 code model to 'tiny' by default.

 For the ArmVirtQemu AARCH64 RELEASE build, the size reduction is 10% before
 compression, 3% after compression, with the number of PE/COFF fixups reduced
 by 80% (see below for details)



Ping?


 Ard Biesheuvel (2):
   ArmVirtPkg: build our DEBUG Shell using the small code model
   BaseTools AARCH64: use tiny code model by default

  ArmVirtPkg/ArmVirt.dsc.inc| 9 +
  BaseTools/Conf/tools_def.template | 2 +-
  2 files changed, 10 insertions(+), 1 deletion(-)


 Size and offset of the compressed inner FV, with the uncompressed size
 near the bottom, using the large code model:

 
 File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
 File Offset:  0x0001C8B8
 File Length:  0x0009562C
 File Attributes:  0x00
 File State:   0xF8
 EFI_FILE_DATA_VALID
 File Type:0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
 
   Type:  EFI_SECTION_GUID_DEFINED
   Size:  0x00095614
   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf

   DataOffset: 0x0018
   Attributes: 0x0001
 
   Type:  EFI_SECTION_RAW
   Size:  0x000C
 
   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
   Size:  0x003FD4C4
 


 Size and offset of the compressed inner FV, with the uncompressed size
 near the bottom, using the tiny code model:

 
 File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792
 File Offset:  0x0001BDF8
 File Length:  0x000915F0
 File Attributes:  0x00
 File State:   0xF8
 EFI_FILE_DATA_VALID
 File Type:0x0B  EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
 
   Type:  EFI_SECTION_GUID_DEFINED
   Size:  0x000915D8
   SectionDefinitionGuid:  ee4e5898-3914-4259-9d6e-dc7bd79403cf

   DataOffset: 0x0018
   Attributes: 0x0001
 
   Type:  EFI_SECTION_RAW
   Size:  0x000C
 
   Type:  EFI_SECTION_FIRMWARE_VOLUME_IMAGE
   Size:  0x0039B484
 

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Bruce Cran

On 8/18/2015 10:26 AM, Ard Biesheuvel wrote:

Ultimately, it would be useful to have a subset of
platforms/toolchains that need to pass before a patch is accepted, but
I am aware that we are still far away from anything like that.

For internal use, I have set up some infrastructure that we can use to
test patch series against the following combos

...
(https://ci.linaro.org/job/leg-tianocore-edk2-build-test/)

It would be good if we could formalize something like this in the
future, i.e., define a 'gold standard' of combos that need to build
correctly, and automate it. (I know having MSFT toolchains in here
would be better, but they are not accessible to everyone as easily.)
In the mean time, triggering these jobs by hand when proposing series
that touch common code should help gain confidence that it won't break
the build for someone else.


In case anyone's wondering - I *did* have a Jenkins server setup that 
did something similar, but it was going to cost over $500/month to run 
all the various platforms on AWS so I shut it down for now.


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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
it does make some difference, it is still not sufficient

Building OvmfX64 in RELEASE mode gives me

Before:
  the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

After:
  the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

where GCC/ELF obviously produces something  0xcc000

I will report back to Nick tomorrow.

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


[edk2] [Patch 1/2] Allocate temp buffer to avoid potential change user input string buffer.

2015-08-18 Thread Eric Dong
Current logic will directly change user input string buffer which may cause 
ASSERT if user input string buffer is a constant string buffer. Now update 
logic to allocate a temp buffer to let code to update at run-time.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong eric.d...@intel.com
Reviewed-by: Liming Gao liming@intel.com
---
 .../HiiDatabaseDxe/ConfigKeywordHandler.c  | 38 +++---
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
index 529e90f..4cf803c 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
@@ -2806,38 +2806,45 @@ EfiConfigKeywordHandlerSetData (
 {
   CHAR8   *NameSpace;
   EFI_STATUS  Status;
   CHAR16  *StringPtr;
   EFI_DEVICE_PATH_PROTOCOL*DevicePath;
-  CHAR16  *NextStringPtr;  
+  CHAR16  *NextStringPtr;
   CHAR16  *KeywordData;
   EFI_STRING_ID   KeywordStringId;
   UINT32  RetVal;
   HII_DATABASE_RECORD *DataBaseRecord;
   UINT8   *OpCode;
   CHAR16  *ConfigResp;
   CHAR16  *MultiConfigResp;
   CHAR16  *ValueElement;
   BOOLEAN ReadOnly;
   EFI_STRING  InternalProgress;
+  CHAR16  *TempString;
 
   if (This == NULL || Progress == NULL || ProgressErr == NULL || KeywordString 
== NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
   *Progress= KeywordString;
   *ProgressErr = KEYWORD_HANDLER_UNDEFINED_PROCESSING_ERROR;
   Status   = EFI_SUCCESS;
-  StringPtr= KeywordString;
   MultiConfigResp = NULL;
   NameSpace   = NULL;
   DevicePath  = NULL;
   KeywordData = NULL;
   ValueElement= NULL;
   ConfigResp  = NULL;
   KeywordStringId = 0;
 
+  //
+  // Use temp string to avoid changing input string buffer.
+  //
+  TempString = AllocateCopyPool (StrSize (KeywordString), KeywordString);
+  ASSERT (TempString != NULL);
+  StringPtr = TempString;
+
   while ((StringPtr != NULL)  (*StringPtr != L'\0')) {
 //
 // 1. Get NameSpace from NameSpaceId keyword.
 //
 Status = ExtractNameSpace (StringPtr, NameSpace, NextStringPtr);
@@ -2960,10 +2967,12 @@ EfiConfigKeywordHandlerSetData (
   }
   
   *ProgressErr = KEYWORD_HANDLER_NO_ERROR;
 
 Done:
+  ASSERT (TempString != NULL);
+  FreePool (TempString);
   if (NameSpace != NULL) {
 FreePool (NameSpace);
   }
   if (DevicePath != NULL) {
 FreePool (DevicePath);
@@ -3076,10 +3085,11 @@ EfiConfigKeywordHandlerGetData (
   CHAR16  *ValueElement;
   UINT32  RetVal;
   BOOLEAN ReadOnly;
   CHAR16  *KeywordResp;
   CHAR16  *MultiKeywordResp;
+  CHAR16  *TempString;
 
   if (This == NULL || Progress == NULL || ProgressErr == NULL || Results == 
NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -3091,22 +3101,39 @@ EfiConfigKeywordHandlerGetData (
   ConfigRequest= NULL;
   StringPtr= KeywordString;
   ReadOnly = FALSE;
   MultiKeywordResp = NULL;
   KeywordStringId  = 0;
+  TempString   = NULL;
 
   //
+  // Use temp string to avoid changing input string buffer.
+  //
+  if (NameSpaceId != NULL) {
+TempString = AllocateCopyPool (StrSize (NameSpaceId), NameSpaceId);
+ASSERT (TempString != NULL);
+  }
+  //
   // 1. Get NameSpace from NameSpaceId keyword.
   //
-  Status = ExtractNameSpace (NameSpaceId, NameSpace, NULL);
+  Status = ExtractNameSpace (TempString, NameSpace, NULL);
+  if (TempString != NULL) {
+FreePool (TempString);
+TempString = NULL;
+  }
   if (EFI_ERROR (Status)) {
 *ProgressErr = KEYWORD_HANDLER_NAMESPACE_ID_NOT_FOUND;
 return Status;
   }
 
   if (KeywordString != NULL) {
-StringPtr = KeywordString;
+//
+// Use temp string to avoid changing input string buffer.
+//
+TempString = AllocateCopyPool (StrSize (KeywordString), KeywordString);
+ASSERT (TempString != NULL);
+StringPtr = TempString;
 
 while (*StringPtr != L'\0') {
   //
   // 2. Get possible Device Path info from KeywordString.
   //
@@ -3223,10 +3250,13 @@ EfiConfigKeywordHandlerGetData (
   }
 
   *ProgressErr = KEYWORD_HANDLER_NO_ERROR;
 
 Done:
+  if (TempString != NULL) {
+FreePool (TempString);
+  }
   if (NameSpace != NULL) {
 FreePool (NameSpace);
   }
   if (DevicePath != NULL) {
 FreePool (DevicePath);
-- 
1.9.5.msysgit.1


[edk2] [Patch 0/2] Enhance the keyword handler protocol to do more validation and error handling.

2015-08-18 Thread Eric Dong
Current code not do the enough validation and error handling, so some case may 
casued this sytem hang
or assert, these patches enhanced it.

Eric Dong (2):
  Allocate temp buffer to avoid potential change user input string
buffer.
  Do valid check for the input namespace field.

 .../HiiDatabaseDxe/ConfigKeywordHandler.c  | 58 +++---
 1 file changed, 52 insertions(+), 6 deletions(-)

-- 
1.9.5.msysgit.1

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


[edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Haojian Zhuang
Support multiple PL061 controllers.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
 ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 ++---
 .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
 ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
 3 files changed, 96 insertions(+), 54 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
index e8a2094..3027656 100644
--- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
+++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
@@ -28,6 +28,7 @@
 #include Drivers/PL061Gpio.h
 
 BOOLEAN mPL061Initialized = FALSE;
+PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;
 
 /**
   Function implementations
@@ -38,20 +39,31 @@ PL061Identify (
   VOID
   )
 {
-  // Check if this is a PrimeCell Peripheral
-  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
-  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
-  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
-  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
-return EFI_NOT_FOUND;
+  UINTNIndex;
+  UINT32   RegisterBase;
+
+  if (   (mPL061PlatformGpio-GpioCount == 0)
+  || (mPL061PlatformGpio-GpioControllerCount == 0)) {
+ return EFI_NOT_FOUND;
   }
 
-  // Check if this PrimeCell Peripheral is the PL061 GPIO
-  if ((MmioRead8 (PL061_GPIO_PERIPH_ID0) != 0x61)
-  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID1) != 0x10)
-  ||  ((MmioRead8 (PL061_GPIO_PERIPH_ID2)  0xF) != 0x04)
-  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID3) != 0x00)) {
-return EFI_NOT_FOUND;
+  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
+RegisterBase = (UINT32) 
mPL061PlatformGpio-GpioController[Index].RegisterBase;
+// Check if this is a PrimeCell Peripheral
+if ((MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID0) != 0x0D)
+||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID1) != 0xF0)
+||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID2) != 0x05)
+||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID3) != 0xB1)) {
+  return EFI_NOT_FOUND;
+}
+   
+// Check if this PrimeCell Peripheral is the PL061 GPIO
+if ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID0) != 0x61)
+||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID1) != 0x10)
+||  ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID2)  0xF) != 0x04)
+||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID3) != 0x00)) {
+  return EFI_NOT_FOUND;
+}
   }
 
   return EFI_SUCCESS;
@@ -84,6 +96,30 @@ PL061Initialize (
   return Status;
 }
 
+EFI_STATUS
+EFIAPI
+PL061Locate (
+  IN  EMBEDDED_GPIO_PIN Gpio,
+  OUT UINT32*ControllerIndex,
+  OUT UINT32*ControllerOffset,
+  OUT UINT32*RegisterBase
+  )
+{
+  UINT32Index;
+
+  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
+if ((Gpio = mPL061PlatformGpio-GpioController[Index].GpioIndex)
+  (Gpio  mPL061PlatformGpio-GpioController[Index].GpioIndex
+ + mPL061PlatformGpio-GpioController[Index].InternalGpioCount)) {
+  *ControllerIndex = Index;
+  *ControllerOffset = Gpio % 
mPL061PlatformGpio-GpioController[Index].InternalGpioCount;
+  *RegisterBase = mPL061PlatformGpio-GpioController[Index].RegisterBase;
+  return EFI_SUCCESS;
+}
+  }
+  return EFI_INVALID_PARAMETER;
+}
+
 /**
 
 Routine Description:
@@ -110,11 +146,15 @@ Get (
   )
 {
   EFI_STATUSStatus = EFI_SUCCESS;
+  UINT32Index, Offset, RegisterBase;
 
-  if ((Value == NULL)
-  ||  (Gpio  LAST_GPIO_PIN))
-  {
-return EFI_INVALID_PARAMETER;
+  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
+  if (EFI_ERROR (Status))
+goto EXIT;
+
+  if (Value == NULL) {
+Status = EFI_INVALID_PARAMETER;
+goto EXIT;
   }
 
   // Initialize the hardware if not already done
@@ -125,7 +165,7 @@ Get (
 }
   }
 
-  if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Gpio)  2))) {
+  if (MmioRead8 (RegisterBase + PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Offset) 
 2))) {
 *Value = 1;
   } else {
 *Value = 0;
@@ -162,12 +202,11 @@ Set (
   )
 {
   EFI_STATUSStatus = EFI_SUCCESS;
+  UINT32Index, Offset, RegisterBase;
 
-  // Check for errors
-  if (Gpio  LAST_GPIO_PIN) {
-Status = EFI_INVALID_PARAMETER;
+  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
+  if (EFI_ERROR (Status))
 goto EXIT;
-  }
 
   // Initialize the hardware if not already done
   if (!mPL061Initialized) {
@@ -181,21 +220,21 @@ Set (
   {
 case GPIO_MODE_INPUT:
   // Set the corresponding direction bit to LOW for input
-  MmioAnd8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK(Gpio));
+  MmioAnd8 (RegisterBase + PL061_GPIO_DIR_REG, GPIO_PIN_MASK(Offset));
   break;
 
 case GPIO_MODE_OUTPUT_0:
   // Set the corresponding data bit to LOW 

[edk2] [PATCH 2/3] EmbeddedPkg: enhance for multiple gpio controllers

2015-08-18 Thread Haojian Zhuang
EmbeddedGpio only supports one gpio controller in one platform. Now create
PLATFORM_GPIO_CONTROLLER to support multiple gpio controllers in one platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
 EmbeddedPkg/EmbeddedPkg.dec |  1 +
 EmbeddedPkg/Include/Protocol/EmbeddedGpio.h | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 4bac580..bd3e301 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -65,6 +65,7 @@
   gAndroidFastbootTransportProtocolGuid = { 0x74bd9fe0, 0x8902, 0x11e3, {0xb9, 
0xd3, 0xf7, 0x22, 0x38, 0xfc, 0x9a, 0x31}}
   gAndroidFastbootPlatformProtocolGuid =  { 0x524685a0, 0x89a0, 0x11e3, {0x9d, 
0x4d, 0xbf, 0xa9, 0xf6, 0xa4, 0x03, 0x08}}
   gUsbDeviceProtocolGuid =  { 0x021bd2ca, 0x51d2, 0x11e3, {0x8e, 0x56, 0xb7, 
0x54, 0x17, 0xc7,  0x0b, 0x44 }}
+  gPlatformGpioProtocolGuid = { 0x52ce9845, 0x5af4, 0x43e2, {0xba, 0xfd, 0x23, 
0x08, 0x12, 0x54, 0x7a, 0xc2 }}
 
 [PcdsFeatureFlag.common]
   gEmbeddedTokenSpaceGuid.PcdEmbeddedMacBoot|FALSE|BOOLEAN|0x0001
diff --git a/EmbeddedPkg/Include/Protocol/EmbeddedGpio.h 
b/EmbeddedPkg/Include/Protocol/EmbeddedGpio.h
index 4e7c8db..c1a86c1 100644
--- a/EmbeddedPkg/Include/Protocol/EmbeddedGpio.h
+++ b/EmbeddedPkg/Include/Protocol/EmbeddedGpio.h
@@ -164,4 +164,22 @@ struct _EMBEDDED_GPIO {
 
 extern EFI_GUID gEmbeddedGpioProtocolGuid;
 
+typedef struct _GPIO_CONTROLLER  GPIO_CONTROLLER;
+typedef struct _PLATFORM_GPIO_CONTROLLER PLATFORM_GPIO_CONTROLLER;
+
+struct _GPIO_CONTROLLER {
+  UINTN   RegisterBase;
+  UINTN   GpioIndex;
+  UINTN   InternalGpioCount;
+};
+
+struct _PLATFORM_GPIO_CONTROLLER {
+  UINTN   GpioCount;
+  UINTN   GpioControllerCount;
+  UINTN   GpioControllerSize;
+  GPIO_CONTROLLER *GpioController;
+};
+
+extern EFI_GUID gPlatformGpioProtocolGuid;
+
 #endif
-- 
2.1.4

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


Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 Support multiple PL061 controllers.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
 ---
  ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
 ++---
  .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
  ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
  3 files changed, 96 insertions(+), 54 deletions(-)

 diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
 b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 index e8a2094..3027656 100644
 --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
 @@ -28,6 +28,7 @@
  #include Drivers/PL061Gpio.h

  BOOLEAN mPL061Initialized = FALSE;
 +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;

  /**
Function implementations
 @@ -38,20 +39,31 @@ PL061Identify (
VOID
)
  {
 -  // Check if this is a PrimeCell Peripheral
 -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
 -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
 -return EFI_NOT_FOUND;
 +  UINTNIndex;
 +  UINT32   RegisterBase;

Why is this a 32-bit value?

 +
 +  if (   (mPL061PlatformGpio-GpioCount == 0)
 +  || (mPL061PlatformGpio-GpioControllerCount == 0)) {
 + return EFI_NOT_FOUND;
}

 -  // Check if this PrimeCell Peripheral is the PL061 GPIO
 -  if ((MmioRead8 (PL061_GPIO_PERIPH_ID0) != 0x61)
 -  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID1) != 0x10)
 -  ||  ((MmioRead8 (PL061_GPIO_PERIPH_ID2)  0xF) != 0x04)
 -  ||  (MmioRead8 (PL061_GPIO_PERIPH_ID3) != 0x00)) {
 -return EFI_NOT_FOUND;
 +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
 +RegisterBase = (UINT32) 
 mPL061PlatformGpio-GpioController[Index].RegisterBase;
 +// Check if this is a PrimeCell Peripheral
 +if ((MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID0) != 0x0D)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID1) != 0xF0)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID2) != 0x05)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PCELL_ID3) != 0xB1)) {
 +  return EFI_NOT_FOUND;
 +}
 +
 +// Check if this PrimeCell Peripheral is the PL061 GPIO
 +if ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID0) != 0x61)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID1) != 0x10)
 +||  ((MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID2)  0xF) != 
 0x04)
 +||  (MmioRead8 (RegisterBase + PL061_GPIO_PERIPH_ID3) != 0x00)) {
 +  return EFI_NOT_FOUND;
 +}
}

return EFI_SUCCESS;
 @@ -84,6 +96,30 @@ PL061Initialize (
return Status;
  }

 +EFI_STATUS
 +EFIAPI
 +PL061Locate (
 +  IN  EMBEDDED_GPIO_PIN Gpio,
 +  OUT UINT32*ControllerIndex,
 +  OUT UINT32*ControllerOffset,
 +  OUT UINT32*RegisterBase
 +  )
 +{
 +  UINT32Index;
 +
 +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; Index++) {
 +if ((Gpio = mPL061PlatformGpio-GpioController[Index].GpioIndex)
 +  (Gpio  mPL061PlatformGpio-GpioController[Index].GpioIndex
 + + mPL061PlatformGpio-GpioController[Index].InternalGpioCount)) 
 {
 +  *ControllerIndex = Index;
 +  *ControllerOffset = Gpio % 
 mPL061PlatformGpio-GpioController[Index].InternalGpioCount;

Since you are relying on the internal GPIO count to be the same for
all instances, you should probably check that the value is correct in
PL061Identify()

 +  *RegisterBase = mPL061PlatformGpio-GpioController[Index].RegisterBase;
 +  return EFI_SUCCESS;
 +}
 +  }
 +  return EFI_INVALID_PARAMETER;
 +}
 +
  /**

  Routine Description:
 @@ -110,11 +146,15 @@ Get (
)
  {
EFI_STATUSStatus = EFI_SUCCESS;
 +  UINT32Index, Offset, RegisterBase;

 -  if ((Value == NULL)
 -  ||  (Gpio  LAST_GPIO_PIN))
 -  {
 -return EFI_INVALID_PARAMETER;
 +  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
 +  if (EFI_ERROR (Status))
 +goto EXIT;
 +
 +  if (Value == NULL) {
 +Status = EFI_INVALID_PARAMETER;
 +goto EXIT;
}

// Initialize the hardware if not already done
 @@ -125,7 +165,7 @@ Get (
  }
}

 -  if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Gpio)  2))) {
 +  if (MmioRead8 (RegisterBase + PL061_GPIO_DATA_REG + (GPIO_PIN_MASK(Offset) 
  2))) {
  *Value = 1;
} else {
  *Value = 0;
 @@ -162,12 +202,11 @@ Set (
)
  {
EFI_STATUSStatus = EFI_SUCCESS;
 +  UINT32Index, Offset, RegisterBase;

 -  // Check for errors
 -  if (Gpio  LAST_GPIO_PIN) {
 -Status = EFI_INVALID_PARAMETER;
 +  Status = PL061Locate (Gpio, Index, Offset, RegisterBase);
 +  if (EFI_ERROR (Status))
  goto EXIT;
 -  }

// Initialize the hardware if not already 

Re: [edk2] [PATCH 3/3] ArmPlatformPkg: PL061: support multiple controller

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 11:31, Haojian Zhuang haojian.zhu...@linaro.org wrote:
 On Tue, 2015-08-18 at 11:22 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 11:04, Haojian Zhuang haojian.zhu...@linaro.org wrote:
  Support multiple PL061 controllers.
 
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
  ---
   ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c| 107 
  ++---
   .../Drivers/PL061GpioDxe/PL061GpioDxe.inf  |   3 +-
   ArmPlatformPkg/Include/Drivers/PL061Gpio.h |  40 
   3 files changed, 96 insertions(+), 54 deletions(-)
 
  diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c 
  b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  index e8a2094..3027656 100644
  --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
  @@ -28,6 +28,7 @@
   #include Drivers/PL061Gpio.h
 
   BOOLEAN mPL061Initialized = FALSE;
  +PLATFORM_GPIO_CONTROLLER *mPL061PlatformGpio;
 
   /**
 Function implementations
  @@ -38,20 +39,31 @@ PL061Identify (
 VOID
 )
   {
  -  // Check if this is a PrimeCell Peripheral
  -  if ((MmioRead8 (PL061_GPIO_PCELL_ID0) != 0x0D)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID1) != 0xF0)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID2) != 0x05)
  -  ||  (MmioRead8 (PL061_GPIO_PCELL_ID3) != 0xB1)) {
  -return EFI_NOT_FOUND;
  +  UINTNIndex;
  +  UINT32   RegisterBase;

 Why is this a 32-bit value?

 All registers in PL061 are 32-bit. So we don't need to define UINTN at
 here.


So what happens if the GPIO controller is mapped above 4 GB in physical memory?

  +EFI_STATUS
  +EFIAPI
  +PL061Locate (
  +  IN  EMBEDDED_GPIO_PIN Gpio,
  +  OUT UINT32*ControllerIndex,
  +  OUT UINT32*ControllerOffset,
  +  OUT UINT32*RegisterBase
  +  )
  +{
  +  UINT32Index;
  +
  +  for (Index = 0; Index  mPL061PlatformGpio-GpioControllerCount; 
  Index++) {
  +if ((Gpio = mPL061PlatformGpio-GpioController[Index].GpioIndex)
  +  (Gpio  mPL061PlatformGpio-GpioController[Index].GpioIndex
  + + 
  mPL061PlatformGpio-GpioController[Index].InternalGpioCount)) {
  +  *ControllerIndex = Index;
  +  *ControllerOffset = Gpio % 
  mPL061PlatformGpio-GpioController[Index].InternalGpioCount;

 Since you are relying on the internal GPIO count to be the same for
 all instances, you should probably check that the value is correct in
 PL061Identify()

 OK. I'll check whether it's 8 at here.

  @@ -329,6 +367,9 @@ PL061InstallProtocol (
 //
 ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, gEmbeddedGpioProtocolGuid);
 
  +  Status = gBS-LocateProtocol (gPlatformGpioProtocolGuid, NULL, (VOID 
  **)mPL061PlatformGpio);
  +  ASSERT_EFI_ERROR (Status);
  +

 We should fall back to using the PCD if the protocol cannot be found.
 This way, we won't break existing users.


 I was intended to use fallback. But I think it's not good enough.

 1. If anyone defines the PCD register base in dec file. The fallback
 mechanism will be broken.


Well, you would only look at the PCD if the protocol is not installed,
so I don't see how that would change anything compared to the current
situation.

 2. Since every driver is built as module, we must create the driver
 dependency.


Please try and use a BEFORE ... depex instead, you can put it in your
platform GPIO DXE with the file GUID of the PL061 DXE driver.

 // Install the Embedded GPIO Protocol onto a new handle
 Handle = NULL;
 Status = gBS-InstallMultipleProtocolInterfaces(
  diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf 
  b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  index 9d9e4cd..971452c 100644
  --- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  +++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061GpioDxe.inf
  @@ -45,6 +45,7 @@
 
   [Protocols]
 gEmbeddedGpioProtocolGuid
  +  gPlatformGpioProtocolGuid
 
   [Depex]
  -  TRUE
  +  gPlatformGpioProtocolGuid

 Likewise, this breaks existing users

 Withouth this dependency, LocateProtocol() will be invoked before
 InstallMultipleProtocols(). So I have to add the dependency at here.


Where is the InstallMultipleProtocols() call? Are you going to post it as well?

 I can't find that any driver is using PL061 in edk2 code repository. So
 I can't update the code to reference PL061 driver.


Well, that is not entirely the point. First of all, it may be used
outside of the edk2 tree. But we should also not complicate the common
case by forcing everyone to use the multiple GPIO protocol and install
it programmatically rather than simply setting a PCD

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


Re: [edk2] [PATCH v2 02/16] BaseTools/GenFv: use PE/COFF virtual section size if raw size is larger

2015-08-18 Thread Gao, Liming
I agree this change. Reviewed-by: Liming Gao liming@intel.com

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Monday, August 17, 2015 10:25 PM
To: edk2-devel@lists.01.org; Liu, Yingke D
Cc: Gao, Liming; Justen, Jordan L; wp...@windriver.com; sc...@notabs.org; 
dw...@infradead.org; Ard Biesheuvel
Subject: [PATCH v2 02/16] BaseTools/GenFv: use PE/COFF virtual section size if 
raw size is larger

When copying the relocated sections into the FFS file, we need to take care 
that we don't overrun the end of the file. Since, unlike the virtual size, the 
PE/COFF raw section size must be a multiple of the file alignment, which means 
its size may exceed the virtual size.
So use the minimum of the two.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
 BaseTools/Source/C/GenFv/GenFvInternalLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c 
b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
index 6d2d5d1f8c67..b0135bf0155a 100644
--- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c
+++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
@@ -3329,7 +3329,7 @@ Returns:
   CopyMem (
 (UINT8 *) CurrentPe32Section.Pe32Section + CurSecHdrSize + 
SectionHeader-PointerToRawData, 
 (VOID*) (UINTN) (ImageContext.ImageAddress + 
SectionHeader-VirtualAddress), 
-SectionHeader-SizeOfRawData
+MIN(SectionHeader-SizeOfRawData, 
+ SectionHeader-Misc.VirtualSize)
 );
 }
 
--
1.9.1

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


Re: [edk2] [PATCH] MdeModulePkg: Add PlatformVarCleanupLib library

2015-08-18 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

-Original Message-
From: Zeng, Star 
Sent: Tuesday, August 18, 2015 8:29 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] MdeModulePkg: Add PlatformVarCleanupLib library

Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 .../Include/Library/PlatformVarCleanupLib.h|   61 +
 .../Library/PlatformVarCleanupLib/PlatVarCleanup.h |  111 ++
 .../PlatformVarCleanupLib/PlatVarCleanup.vfr   |   41 +
 .../PlatformVarCleanupLib/PlatVarCleanupHii.h  |   59 +
 .../PlatformVarCleanupLib/PlatVarCleanupLib.c  | 1250 
 .../PlatformVarCleanupLib.inf  |   74 ++
 .../PlatformVarCleanupLib.uni  |  Bin 0 - 1766 bytes
 .../Library/PlatformVarCleanupLib/VfrStrings.uni   |  Bin 0 - 4528 bytes
 MdeModulePkg/MdeModulePkg.dec  |4 +
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 10 files changed, 1601 insertions(+)
 create mode 100644 MdeModulePkg/Include/Library/PlatformVarCleanupLib.h
 create mode 100644 MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.h
 create mode 100644 
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.vfr
 create mode 100644 
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupHii.h
 create mode 100644 
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c
 create mode 100644 
MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
 create mode 100644 
MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.uni
 create mode 100644 MdeModulePkg/Library/PlatformVarCleanupLib/VfrStrings.uni

diff --git a/MdeModulePkg/Include/Library/PlatformVarCleanupLib.h 
b/MdeModulePkg/Include/Library/PlatformVarCleanupLib.h
new file mode 100644
index 000..a4691f0
--- /dev/null
+++ b/MdeModulePkg/Include/Library/PlatformVarCleanupLib.h
@@ -0,0 +1,61 @@
+/** @file
+  The library class provides platform variable cleanup services.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+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 _PLATFORM_VARIABLE_CLEANUP_LIB_
+#define _PLATFORM_VARIABLE_CLEANUP_LIB_
+
+#include Guid/VarErrorFlag.h
+
+typedef enum {
+  VarCleanupAll,
+  VarCleanupManually,
+  VarCleanupMax,
+} VAR_CLEANUP_TYPE;
+
+/**
+  Get last boot variable error flag.
+
+  @return   Last boot variable error flag.
+
+**/
+VAR_ERROR_FLAG
+EFIAPI
+GetLastBootVarErrorFlag (
+  );
+
+/**
+  Platform variable cleanup.
+
+  @param[in] Flag   Variable error flag.
+  @param[in] Type   Variable cleanup type.
+If it is VarCleanupManually, the interface 
must be called after console connected.
+
+  @retval EFI_SUCCESS   No error or error processed.
+  @retval EFI_UNSUPPORTED   The specified Flag or Type is not 
supported.
+For example, system error may be not 
supported to process and Platform should have mechanism to reset system to 
manufacture mode.
+Another, if system and user variables are 
wanted to be distinguished to process, the interface must be called after 
EndOfDxe.
+  @retval EFI_OUT_OF_RESOURCES  Not enough resource to process the error.
+  @retval EFI_INVALID_PARAMETER The specified Flag or Type is an invalid 
value.
+  @retval OthersOther failure occurs.
+
+**/
+EFI_STATUS
+EFIAPI
+PlatformVarCleanup (
+  IN VAR_ERROR_FLAG Flag,
+  IN VAR_CLEANUP_TYPE   Type
+  );
+
+#endif
+
diff --git a/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.h 
b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.h
new file mode 100644
index 000..30c2595
--- /dev/null
+++ b/MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanup.h
@@ -0,0 +1,111 @@
+/** @file
+  Include file for platform variable cleanup.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+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 _PLAT_VAR_CLEANUP_
+#define _PLAT_VAR_CLEANUP_
+
+#include PiDxe.h
+
+#include Library/UefiBootServicesTableLib.h
+#include 

Re: [edk2] [PATCH] MdeModulePkg: Add VarCheckPcdLib NULL class library

2015-08-18 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

-Original Message-
From: Zeng, Star 
Sent: Tuesday, August 18, 2015 8:29 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] MdeModulePkg: Add VarCheckPcdLib NULL class library

The check will be based on PcdVarCheck binary that generated by BaseTools.

Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 .../Library/VarCheckPcdLib/VarCheckPcdLib.inf  |  65 +++
 .../Library/VarCheckPcdLib/VarCheckPcdLib.uni  | Bin 0 - 1766 bytes
 .../VarCheckPcdLib/VarCheckPcdLibNullClass.c   | 474 +
 .../Library/VarCheckPcdLib/VarCheckPcdStructure.h  |  76 
 MdeModulePkg/MdeModulePkg.dsc  |   3 +
 5 files changed, 618 insertions(+)
 create mode 100644 MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c
 create mode 100644 MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdStructure.h

diff --git a/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf 
b/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
new file mode 100644
index 000..b9d235b
--- /dev/null
+++ b/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
@@ -0,0 +1,65 @@
+## @file
+#  NULL class library to register var check PCD handler.
+#
+#  In platform *.fdf, the example build rule for the driver this library 
linked to.
+#[Rule.Common.DXE_RUNTIME_DRIVER.VARCHECKPCD]
+#  FILE DRIVER = $(NAMED_GUID) {
+#RAW  BIN 
$(WORKSPACE)/$(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/FV/PcdVarCheck.bin
+#DXE_DEPEXDXE_DEPEX Optional  
$(INF_OUTPUT)/$(MODULE_NAME).depex
+#PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
+#UI   STRING=$(MODULE_NAME) Optional
+#VERSION  STRING=$(INF_VERSION) Optional 
BUILD_NUM=$(BUILD_NUMBER)
+#  }
+#
+#or
+#
+#[Rule.Common.DXE_SMM_DRIVER.VARCHECKPCD]
+#  FILE SMM = $(NAMED_GUID) {
+#RAW  BIN 
$(WORKSPACE)/$(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/FV/PcdVarCheck.bin
+#DXE_DEPEXDXE_DEPEX Optional  
$(INF_OUTPUT)/$(MODULE_NAME).depex
+#PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
+#UI   STRING=$(MODULE_NAME) Optional
+#VERSION  STRING=$(INF_VERSION) Optional 
BUILD_NUM=$(BUILD_NUMBER)
+#  }
+#
+#  In platform *.dsc, also need add one line below to enable PcdVarCheck.bin 
generation by BaseTools.
+#PCD_VAR_CHECK_GENERATION= TRUE
+#
+#  Copyright (c) 2015, Intel Corporation. All rights reserved.BR # #  
+This program and the accompanying materials #  are licensed and made 
+available under the terms and conditions #  of the BSD License which 
+accompanies this distribution.  The #  full text of the license may be 
+found at #  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS 
+BASIS, #  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = VarCheckPcdLib
+  MODULE_UNI_FILE= VarCheckPcdLib.uni
+  FILE_GUID  = D4FA5311-5F1F-4B1E-9AC3-90C4DFC029F1
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
+  CONSTRUCTOR= VarCheckPcdLibNullClassConstructor
+
+[Sources]
+  VarCheckPcdLibNullClass.c
+  VarCheckPcdStructure.h
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  BaseMemoryLib
+  DxeServicesLib
+  MemoryAllocationLib
+  VarCheckLib
diff --git a/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.uni 
b/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.uni
new file mode 100644
index 
..4a3d932be930275c9edef85e51cec9dd381d8427
GIT binary patch
literal 1766
zcmd6nTW`}q5QWb(692(UUjVfUAn}3_B54d*lqSkWg{LZ)HnGSBIib)$4}52x*l7q7
zPpGoIyE8jGbLPzK{`y%{O%eYSzDRF$tyD8z7gE=_1?MqI^BpVrQTgUJcaP#JQj
zTjaHtj2R~?5vQlkRsg#3!j~$8R-kUwocV#p0c;lIK0TEn?n}*r#OlmE1DnSgZ-
z;zwlgnEAP$X}~Xm~}!9UVJyXEIKC9H32EEyyfVoqb!B-pr!;S_P(V7{^$?QbQfR
zKEOo}3}!aMe};lh%rabS#%A|vEopQgbZ5cgwj2_7NJRa%EChGrW~tyOKWb%8pnq
z0!Urf1e(2BDk*ZlmT7feu?yr6W(zw@C6^MHDb(#UL?7W_D;C7oBEYp5GKm?WX
z66^QCg?sAHY*R4UqcP-sIhH%pSr5UvTNkrx^w;R~3K{bcZ1yqTt69Roj=^1Uv3yM
zqV*21?wmE1cp2`Kdn)JF_E})MO7D`sqJyULNfUSSNcsRlH33OGbKnuNX9Kx~HXg
zjCFlPPGB;EOV2D3H{Y)6$gI%-0mjp4mMj4CHD#a9AnW9o?EQk#~v%p_G_;d=0=b$
z9q(YeVBcO_A!4KptU3YNIr;z_R$K_J4nWEon!W}wT+|ZRTL^v}#6*fDb7zjzZR
zmz{R!cXZvfr~b8m}52%zBGRSY5}`B^?y|KOn!HA{x0#!iV3)SeGCUuL!rTRrgn

Re: [edk2] [PATCH] MdeModulePkg: Add VarCheckHiiLib NULL class library

2015-08-18 Thread Yao, Jiewen
Reviewed-by: jiewen@intel.com

-Original Message-
From: Zeng, Star 
Sent: Tuesday, August 18, 2015 8:29 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH] MdeModulePkg: Add VarCheckHiiLib NULL class library

The check will be based on VarCheckHiiBin that generated
from FV and Hii Database.

Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 .../VarCheckHiiLib/InternalVarCheckStructure.h |   82 ++
 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHii.h  |   63 +
 .../Library/VarCheckHiiLib/VarCheckHiiGen.c| 1483 
 .../Library/VarCheckHiiLib/VarCheckHiiGen.h|  136 ++
 .../Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c  |  443 ++
 .../Library/VarCheckHiiLib/VarCheckHiiGenFromHii.c |   73 +
 .../Library/VarCheckHiiLib/VarCheckHiiLib.inf  |   58 +
 .../Library/VarCheckHiiLib/VarCheckHiiLib.uni  |  Bin 0 - 1766 bytes
 .../VarCheckHiiLib/VarCheckHiiLibNullClass.c   |  539 +++
 MdeModulePkg/MdeModulePkg.dec  |6 +
 MdeModulePkg/MdeModulePkg.dsc  |3 +
 MdeModulePkg/MdeModulePkg.uni  |  Bin 182392 - 183916 
bytes
 12 files changed, 2886 insertions(+)
 create mode 100644 
MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHii.h
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.h
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromFv.c
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGenFromHii.c
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
 create mode 100644 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.uni
 create mode 100644 
MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLibNullClass.c

diff --git a/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h 
b/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
new file mode 100644
index 000..a9faed4
--- /dev/null
+++ b/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
@@ -0,0 +1,82 @@
+/** @file
+  Internal structure for Var Check Hii.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.BR
+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 _VAR_CHECK_STRUCTURE_H_
+#define _VAR_CHECK_STRUCTURE_H_
+
+//
+// Alignment for Hii Variable and Question header.
+//
+#define HEADER_ALIGNMENT  4
+#define HEADER_ALIGN(Header)  (((UINTN) (Header) + HEADER_ALIGNMENT - 1)  
(~(HEADER_ALIGNMENT - 1)))
+
+#pragma pack (1)
+
+#define VAR_CHECK_HII_REVISION  0x0001
+
+typedef struct {
+  UINT16Revision;
+  UINT16HeaderLength;
+  UINT32Length; // Length include this header
+  UINT8 OpCode;
+  UINT8 Reserved;
+  UINT16Size;
+  UINT32Attributes;
+  EFI_GUID  Guid;
+//CHAR16  Name[];
+} VAR_CHECK_HII_VARIABLE_HEADER;
+
+typedef struct {
+  UINT8 OpCode;
+  UINT8 Length; // Length include this header
+  UINT16VarOffset;
+  UINT8 StorageWidth;
+} VAR_CHECK_HII_QUESTION_HEADER;
+
+typedef struct {
+  UINT8 OpCode;
+  UINT8 Length; // Length include this header
+  UINT16VarOffset;
+  UINT8 StorageWidth;
+//UINTx   Data[]; // x = UINT8/UINT16/UINT32/UINT64;
+} VAR_CHECK_HII_QUESTION_ONEOF;
+
+typedef struct {
+  UINT8 OpCode;
+  UINT8 Length; // Length include this header
+  UINT16VarOffset;
+  UINT8 StorageWidth;
+} VAR_CHECK_HII_QUESTION_CHECKBOX;
+
+typedef struct {
+  UINT8 OpCode;
+  UINT8 Length; // Length include this header
+  UINT16VarOffset;
+  UINT8 StorageWidth;
+//UINTx   Minimum; // x = UINT8/UINT16/UINT32/UINT64;
+//UINTx   Maximum; // x = UINT8/UINT16/UINT32/UINT64;
+} VAR_CHECK_HII_QUESTION_NUMERIC;
+
+typedef struct {
+  UINT8 OpCode;
+  UINT8 Length; // Length include this header
+  UINT16VarOffset;
+  UINT8 StorageWidth;
+  UINT8 MaxContainers;
+//UINTx   Data[]; // x = UINT8/UINT16/UINT32/UINT64;
+} VAR_CHECK_HII_QUESTION_ORDEREDLIST;
+
+#pragma pack ()
+
+#endif
diff --git a/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHii.h 
b/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHii.h
new 

Re: [edk2] [PATCH 08/15] Vlv2TbltDevicePkg: Add VarCheckLib library mapping

2015-08-18 Thread He, Tim
Reviewed-by: Tim He tim...@intel.com 

-Original Message-
From: Zeng, Star 
Sent: Monday, August 17, 2015 4:24 PM
To: edk2-devel@lists.01.org
Cc: Wei, David; He, Tim
Subject: [PATCH 08/15] Vlv2TbltDevicePkg: Add VarCheckLib library mapping

Since Variable driver has been updated to consume the separated VarCheckLib.

Cc: David Wei david@intel.com
Cc: Tim He tim...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc   | 1 +
 Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 +
 3 files changed, 3 insertions(+)

diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 45008a0..39884af 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -267,6 +267,7 @@ [LibraryClasses.common]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 !if $(RC_BINARY_RELEASE) == TRUE
   I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf
 !endif
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 2fa7a36..e89b5f9 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -267,6 +267,7 @@ [LibraryClasses.common]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 !if $(RC_BINARY_RELEASE) == TRUE
   I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf
 !endif
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc 
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 4e0a9f8..fc8334f 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -267,6 +267,7 @@ [LibraryClasses.common]
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
 !endif
+  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
 !if $(RC_BINARY_RELEASE) == TRUE
   I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf
 !endif
-- 
1.9.5.msysgit.0

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


[edk2] [PATCH] BaseTools: Add support for nested !include in FDF and DSC files Also added code to detect include loops and enhanced error reporting for included files

2015-08-18 Thread Sheng, Cecil (HPS SW)

(The previous mail got rejected by the mail list so I have to resent again.)

Hi,

Sorry for the delayed update. Please review the attachment for changes to 
support nested include in DSC and FDF files. The performance impact in previous 
patch has been addressed.




Sincerely,

Cecil Sheng
ISS Firmware Development
HP Servers

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


Re: [edk2] [patch] MdeModulePkg/Xhci: make all timeout values be consistent with comments.

2015-08-18 Thread Tian, Feng
Ok, the commit log would be updated to reflect this change.

Thanks
Feng

-Original Message-
From: Zeng, Star 
Sent: Wednesday, August 19, 2015 09:19
To: Tian, Feng
Cc: edk2-devel@lists.01.org
Subject: RE: [patch] MdeModulePkg/Xhci: make all timeout values be consistent 
with comments.

In fact, the code updated the every poll delay from 1ms to 1us. Suggest to add 
this information to the commit log.

Reviewed-by: Star Zeng star.z...@intel.com 

-Original Message-
From: Tian, Feng 
Sent: Monday, August 17, 2015 2:31 PM
To: Zeng, Star
Cc: edk2-devel@lists.01.org; Tian, Feng
Subject: [patch] MdeModulePkg/Xhci: make all timeout values be consistent with 
comments.

In the original code, there exists some mismatches between the real waiting 
time and the corresponding timeout comments. For example, the 
XHC_GENERIC_TIMEOUT comment says it's 10ms timeout value, but the real code in 
fact waits 10s.

So the code is refined and XHC_POLL_DELAY macro also be removed to simplify 
code logic.

Note the changes doesn't change the original code behavior.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian feng.t...@intel.com
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.h  | 15 +--
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c   | 16 
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c |  2 +-
 MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.c   | 12 ++--
 MdeModulePkg/Bus/Pci/XhciPei/XhcPeim.h   | 17 -
 5 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.h 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.h
index 9927f79..7999151 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.h
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.h
@@ -2,7 +2,7 @@
 
   Provides some data structure definitions used by the XHCI host controller 
driver.
 
-Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.BR
 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
@@ -47,24 +47,19 @@ typedef struct _USB_DEV_CONTEXT  USB_DEV_CONTEXT;
 //
 #define XHC_1_MICROSECOND(1)
 //
-// Convert millisecond to microsecond.
+// The unit is microsecond, setting it as 1ms.
 //
 #define XHC_1_MILLISECOND(1000)
 //
 // XHC generic timeout experience values.
-// The unit is microsecond, setting it as 10ms.
+// The unit is millisecond, setting it as 10s.
 //
 #define XHC_GENERIC_TIMEOUT  (10 * 1000)
 //
 // XHC reset timeout experience values.
-// The unit is microsecond, setting it as 1s.
+// The unit is millisecond, setting it as 1s.
 //
-#define XHC_RESET_TIMEOUT(1000 * 1000)
-//
-// XHC delay experience value for polling operation.
-// The unit is microsecond, set it as 1ms.
-//
-#define XHC_POLL_DELAY   (1000)
+#define XHC_RESET_TIMEOUT(1000)
 //
 // XHC async transfer timer interval, set by experience.
 // The unit is 100us, takes 1ms as interval.
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
index a513dd9..d0f2205 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
@@ -2,7 +2,7 @@
 
   The XHCI register operation routines.
 
-Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.BR
+Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.BR
 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 @@ -499,7 +499,7 @@ 
XhcClearOpRegBit (
   @param  Offset   The offset of the operation register.
   @param  Bit  The bit of the register to wait for.
   @param  WaitToSetWait the bit to set or clear.
-  @param  Timeout  The time to wait before abort (in microsecond, us).
+  @param  Timeout  The time to wait before abort (in millisecond, ms).
 
   @retval EFI_SUCCESS  The bit successfully changed by host controller.
   @retval EFI_TIMEOUT  The time out occurred.
@@ -515,16 +515,16 @@ XhcWaitOpRegBit (
   )
 {
   UINT32  Index;
-  UINTN   Loop;
+  UINT64  Loop;
 
-  Loop   = (Timeout / XHC_POLL_DELAY) + 1;
+  Loop   = Timeout * XHC_1_MILLISECOND;
 
   for (Index = 0; Index  Loop; Index++) {
 if (XHC_REG_BIT_IS_SET (Xhc, Offset, Bit) == WaitToSet) {
   return EFI_SUCCESS;
 }
 
-gBS-Stall (XHC_POLL_DELAY);
+gBS-Stall (XHC_1_MICROSECOND);
   }
 
   return EFI_TIMEOUT;
@@ -656,7 +656,7 @@ XhcIsSysError (
   Reset the XHCI host controller.
 
   @param  Xhc  The XHCI Instance.
-  @param  Timeout  Time to wait before abort (in microsecond, us).
+  @param  Timeout  Time to wait before abort (in 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Laszlo Ersek
On 08/18/15 22:04, Paolo Bonzini wrote:
 
 
 On 18/08/2015 08:52, Ard Biesheuvel wrote:
 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)
 
 RHEL 6 is shipping GCC 4.4.  True, there are software collections to
 overcome that, but I think supporting GCC 4.4 is a good idea for at
 least a couple more years.
 
 Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

My laptop dual-boots RHEL-6 and RHEL-7, but I only use RHEL-6 when I
need to work on RHEL-6 qemu-kvm or the RHEL-6 kernel. Which is nowadays
practically never, thankfully.

In addition, I couldn't sensibly *test* OVMF on a RHEL-6 host, because
the RHEL-6 components lack support for the pflash-backed varstore.
Which, for me at least, makes *building* OVMF on RHEL-6 kinda moot too.

I have a number of Fedora virtual machines just for build-testing with
gcc-4.4..gcc-4.9, but they are the consequence of the edk2 compiler
support, not the reason for it. :)

So, I'm in favor of dropping gcc-4.4 support. (In Fedora release terms,
gcc-4.4 corresponds to fc13.)

Thanks!
Laszlo

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Paolo Bonzini


On 18/08/2015 08:52, Ard Biesheuvel wrote:
  Personally, I would not mind deprecating GCC44, but the biggest
  question I would have is what toolchains do the latest UDK releases
  claim to support.
 
  We also have the issue that every time I ask about deprecating a
  toolchain, Larry looks at me like I'm crazy. :)

 Well, perhaps he can chime in and explain his motivation behind this?
 At some point, we need to start removing things, surely. Larry just
 has a higher tolerance for pain :-)

RHEL 6 is shipping GCC 4.4.  True, there are software collections to
overcome that, but I think supporting GCC 4.4 is a good idea for at
least a couple more years.

Laszlo, do you still use RHEL 6?  Are you building with GCC 4.4?

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


[edk2] [Patch] NetworkPkg: Fix DHCP TransmitReceive EFI_NO_MAPPING return in DnsDxe

2015-08-18 Thread Jiaxin Wu
If the default station address is not available, TransmitReceive function will 
return
EFI_NO_MAPPING. DNS driver should handle this case. This issue is caused by the 
r18201
fix.

Cc: Ye Ting ting...@intel.com
Cc: Zhang Lubo lubo.zh...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
 NetworkPkg/DnsDxe/DnsDhcp.c  | 151 +++
 NetworkPkg/DnsDxe/DnsDxe.inf |   2 +
 2 files changed, 153 insertions(+)

diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c
index 1cc337f..9d1000b 100644
--- a/NetworkPkg/DnsDxe/DnsDhcp.c
+++ b/NetworkPkg/DnsDxe/DnsDhcp.c
@@ -13,10 +13,151 @@ Intel Corporation.
 **/
 
 #include DnsImpl.h
 
 /**
+  The callback function for the timer event used to get map.
+
+  @param[in] EventThe event this function is registered to.
+  @param[in] Context  The context registered to the event.
+**/
+VOID
+EFIAPI
+TimeoutToGetMap (
+  IN EFI_EVENT  Event,
+  IN VOID   *Context
+  )
+{
+  *((BOOLEAN *) Context) = TRUE;
+  return ;
+}
+
+/**
+  Create an IP child, use it to start the auto configuration, then destroy it.
+
+  @param[in] Controller   The controller which has the service installed.
+  @param[in] ImageThe image handle used to open service.
+
+  @retval EFI_SUCCESS The configuration is done.
+**/
+EFI_STATUS
+EFIAPI
+DnsStartIp4(
+  IN  EFI_HANDLEController,
+  IN  EFI_HANDLEImage
+  )
+{
+  EFI_IP4_PROTOCOL  *Ip4;
+  EFI_HANDLEIp4Handle;
+  EFI_EVENT TimerToGetMap;
+  EFI_IP4_CONFIG_DATA   Ip4ConfigData;
+  EFI_IP4_MODE_DATA Ip4Mode;
+  EFI_STATUSStatus;
+
+  BOOLEAN   mTimeout;
+
+  //
+  // Get the Ip4ServiceBinding Protocol
+  //
+  Ip4Handle = NULL;
+  Ip4   = NULL;
+  TimerToGetMap = NULL;
+  
+  mTimeout  = FALSE;
+
+  Status = NetLibCreateServiceChild (
+ Controller,
+ Image,
+ gEfiIp4ServiceBindingProtocolGuid,
+ Ip4Handle
+ );
+
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  Status = gBS-OpenProtocol (
+ Ip4Handle,
+ gEfiIp4ProtocolGuid,
+ (VOID **) Ip4,
+ Controller,
+ Image,
+ EFI_OPEN_PROTOCOL_GET_PROTOCOL
+ );
+
+  if (EFI_ERROR (Status)) {
+goto ON_EXIT;
+  }
+
+  Ip4ConfigData.DefaultProtocol  = EFI_IP_PROTO_ICMP;
+  Ip4ConfigData.AcceptAnyProtocol= FALSE;
+  Ip4ConfigData.AcceptIcmpErrors = FALSE;
+  Ip4ConfigData.AcceptBroadcast  = FALSE;
+  Ip4ConfigData.AcceptPromiscuous= FALSE;
+  Ip4ConfigData.UseDefaultAddress= TRUE;
+  ZeroMem (Ip4ConfigData.StationAddress, sizeof (EFI_IPv4_ADDRESS));
+  ZeroMem (Ip4ConfigData.SubnetMask, sizeof (EFI_IPv4_ADDRESS));
+  Ip4ConfigData.TypeOfService= 0;
+  Ip4ConfigData.TimeToLive   = 1;
+  Ip4ConfigData.DoNotFragment= FALSE;
+  Ip4ConfigData.RawData  = FALSE;
+  Ip4ConfigData.ReceiveTimeout   = 0;
+  Ip4ConfigData.TransmitTimeout  = 0;
+
+  Status = Ip4-Configure (Ip4, Ip4ConfigData);
+
+  if (Status == EFI_NO_MAPPING) {
+Status  = gBS-CreateEvent (
+EVT_NOTIFY_SIGNAL | EVT_TIMER,
+TPL_CALLBACK,
+TimeoutToGetMap,
+mTimeout,
+TimerToGetMap
+);
+
+if (EFI_ERROR (Status)) {
+  goto ON_EXIT;
+}
+
+Status = gBS-SetTimer (
+   TimerToGetMap,
+   TimerRelative,
+   MultU64x32 (1000, 5)
+   );
+
+if (EFI_ERROR (Status)) {
+  goto ON_EXIT;
+}
+
+while (!mTimeout) {
+  Ip4-Poll (Ip4);
+  
+  if (!EFI_ERROR (Ip4-GetModeData (Ip4, Ip4Mode, NULL, NULL))  
+  Ip4Mode.IsConfigured) {   
+break;
+  }
+}
+  }
+  
+ON_EXIT: 
+
+  if (TimerToGetMap != NULL) {
+gBS-SetTimer (TimerToGetMap, TimerCancel, 0);
+gBS-CloseEvent (TimerToGetMap);
+  }
+
+  NetLibDestroyServiceChild (
+Controller,
+Image,
+gEfiIp4ServiceBindingProtocolGuid,
+Ip4Handle
+);
+  
+  return Status;
+}
+
+/**
   This function initialize the DHCP4 message instance.
 
   This function will pad each item of dhcp4 message packet.
 
   @param  Seed Pointer to the message instance of the DHCP4 packet.
@@ -321,10 +462,20 @@ GetDns4ServerFromDhcp4 (
   if (!MediaPresent) {
 return EFI_NO_MEDIA;
   }
 
   //
+  // Start the auto configuration if UseDefaultSetting.
+  //
+  if (Instance-Dns4CfgData.UseDefaultSetting) {
+Status = DnsStartIp4 (Controller, Image);
+if (EFI_ERROR(Status)) {
+  return Status;
+}
+  }
+  
+  //
   // Create a Mnp child 

[edk2] [PATCH v2] NetworkPkg: Fix DHCP TransmitReceive EFI_NO_MAPPING return in DnsDxe

2015-08-18 Thread Jiaxin Wu
v2:
* Add Timeout check, if time out, return EFI_DEVICE_ERROR.

If the default station address is not available, TransmitReceive
function will return EFI_NO_MAPPING. DNS driver should handle this
case. This issue is caused by the r18201 fix.

Cc: Ye Ting ting...@intel.com
Cc: Zhang Lubo lubo.zh...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
 NetworkPkg/DnsDxe/DnsDhcp.c  | 155 +++
 NetworkPkg/DnsDxe/DnsDxe.inf |   2 +
 2 files changed, 157 insertions(+)

diff --git a/NetworkPkg/DnsDxe/DnsDhcp.c b/NetworkPkg/DnsDxe/DnsDhcp.c
index 1cc337f..d0a0888 100644
--- a/NetworkPkg/DnsDxe/DnsDhcp.c
+++ b/NetworkPkg/DnsDxe/DnsDhcp.c
@@ -13,10 +13,155 @@ Intel Corporation.
 **/
 
 #include DnsImpl.h
 
 /**
+  The callback function for the timer event used to get map.
+
+  @param[in] EventThe event this function is registered to.
+  @param[in] Context  The context registered to the event.
+**/
+VOID
+EFIAPI
+TimeoutToGetMap (
+  IN EFI_EVENT  Event,
+  IN VOID   *Context
+  )
+{
+  *((BOOLEAN *) Context) = TRUE;
+  return ;
+}
+
+/**
+  Create an IP child, use it to start the auto configuration, then destroy it.
+
+  @param[in] Controller   The controller which has the service installed.
+  @param[in] ImageThe image handle used to open service.
+
+  @retval EFI_SUCCESS The configuration is done.
+**/
+EFI_STATUS
+EFIAPI
+DnsStartIp4(
+  IN  EFI_HANDLEController,
+  IN  EFI_HANDLEImage
+  )
+{
+  EFI_IP4_PROTOCOL  *Ip4;
+  EFI_HANDLEIp4Handle;
+  EFI_EVENT TimerToGetMap;
+  EFI_IP4_CONFIG_DATA   Ip4ConfigData;
+  EFI_IP4_MODE_DATA Ip4Mode;
+  EFI_STATUSStatus;
+
+  BOOLEAN   Timeout;
+
+  //
+  // Get the Ip4ServiceBinding Protocol
+  //
+  Ip4Handle = NULL;
+  Ip4   = NULL;
+  TimerToGetMap = NULL;
+  
+  Timeout  = FALSE;
+
+  Status = NetLibCreateServiceChild (
+ Controller,
+ Image,
+ gEfiIp4ServiceBindingProtocolGuid,
+ Ip4Handle
+ );
+
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  Status = gBS-OpenProtocol (
+ Ip4Handle,
+ gEfiIp4ProtocolGuid,
+ (VOID **) Ip4,
+ Controller,
+ Image,
+ EFI_OPEN_PROTOCOL_GET_PROTOCOL
+ );
+
+  if (EFI_ERROR (Status)) {
+goto ON_EXIT;
+  }
+
+  Ip4ConfigData.DefaultProtocol  = EFI_IP_PROTO_ICMP;
+  Ip4ConfigData.AcceptAnyProtocol= FALSE;
+  Ip4ConfigData.AcceptIcmpErrors = FALSE;
+  Ip4ConfigData.AcceptBroadcast  = FALSE;
+  Ip4ConfigData.AcceptPromiscuous= FALSE;
+  Ip4ConfigData.UseDefaultAddress= TRUE;
+  ZeroMem (Ip4ConfigData.StationAddress, sizeof (EFI_IPv4_ADDRESS));
+  ZeroMem (Ip4ConfigData.SubnetMask, sizeof (EFI_IPv4_ADDRESS));
+  Ip4ConfigData.TypeOfService= 0;
+  Ip4ConfigData.TimeToLive   = 1;
+  Ip4ConfigData.DoNotFragment= FALSE;
+  Ip4ConfigData.RawData  = FALSE;
+  Ip4ConfigData.ReceiveTimeout   = 0;
+  Ip4ConfigData.TransmitTimeout  = 0;
+
+  Status = Ip4-Configure (Ip4, Ip4ConfigData);
+
+  if (Status == EFI_NO_MAPPING) {
+Status  = gBS-CreateEvent (
+EVT_NOTIFY_SIGNAL | EVT_TIMER,
+TPL_CALLBACK,
+TimeoutToGetMap,
+Timeout,
+TimerToGetMap
+);
+
+if (EFI_ERROR (Status)) {
+  goto ON_EXIT;
+}
+
+Status = gBS-SetTimer (
+   TimerToGetMap,
+   TimerRelative,
+   MultU64x32 (1000, 5)
+   );
+
+if (EFI_ERROR (Status)) {
+  goto ON_EXIT;
+}
+
+while (!Timeout) {
+  Ip4-Poll (Ip4);
+  
+  if (!EFI_ERROR (Ip4-GetModeData (Ip4, Ip4Mode, NULL, NULL))  
+  Ip4Mode.IsConfigured) {   
+break;
+  }
+}
+
+if (Timeout) {
+  Status = EFI_DEVICE_ERROR;
+}
+  }
+  
+ON_EXIT: 
+
+  if (TimerToGetMap != NULL) {
+gBS-SetTimer (TimerToGetMap, TimerCancel, 0);
+gBS-CloseEvent (TimerToGetMap);
+  }
+
+  NetLibDestroyServiceChild (
+Controller,
+Image,
+gEfiIp4ServiceBindingProtocolGuid,
+Ip4Handle
+);
+  
+  return Status;
+}
+
+/**
   This function initialize the DHCP4 message instance.
 
   This function will pad each item of dhcp4 message packet.
 
   @param  Seed Pointer to the message instance of the DHCP4 packet.
@@ -321,10 +466,20 @@ GetDns4ServerFromDhcp4 (
   if (!MediaPresent) {
 return EFI_NO_MEDIA;
   }
 
   //
+  // Start the auto configuration if UseDefaultSetting.
+  //
+  if (Instance-Dns4CfgData.UseDefaultSetting) {
+Status = DnsStartIp4 

Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Leif Lindholm
On Tue, Aug 18, 2015 at 02:14:53PM +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 14:12, Leif Lindholm leif.lindh...@linaro.org wrote:
  On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
  On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org 
  wrote:
   Instead of omitting some drivers that are known to break the Foundation
   model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
   simply fail to load without interfering with the boot.
  
   This way, we can use the same boot image for both models.
  
 
  Ping?
 
  Basicallt looks good to me, but I thought I'd wait for Ryan to comment
  (and he's on holiday through this week).
 
  Just to confirm - the Mmio probes just return zeroes in the Foundation
  model, rather than aborting?
 
 
 Foundation model output:
 
 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0.
 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0.
 
 Note sure what these reads return, but in each case, the first byte
 already differs from the expected value so the init aborts.
 
 I know that this would still be sufficient to blow up on a real
 system, but thankfully the model does not model /that/ :-)

No, my main concern would be if future versions of the model delete
this trapping and instead signal an abort (or do something else
entirely), to better mimic hardware behaviour.

Do we have output console available at this point?
If so, maybe put in a printout - at least in DEBUG build - that this
is about to happen, to reduce debug time if the model behaviour
changes?

Regardless, unless Ryan objects on Monday:
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org

/
Leif

   Ard Biesheuvel (3):
 ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
 ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
   initializing
 ArmPlatformPkg/FVP: unify support for Foundation and Base models
  
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 
   -
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
   
ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 
   +
ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 
   +-
ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 19 
   +++
ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 13 
   +
ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
   +
ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 
   +
8 files changed, 64 insertions(+), 18 deletions(-)
  
   --
   1.9.1
  
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
Instead of omitting some drivers that are known to break the Foundation
model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
simply fail to load without interfering with the boot.

Changes since v1:
- Print a diagnostic at EFI_D_WARN level that we are about to access the
  PrimeCell ID registers. This is currently not required, since the Foundation
  model deals gracefully with the reads to the unpopulated range, but this may
  change in future versions
- Added Leif's R-b
- Rebased onto latest upstream

Ard Biesheuvel (3):
  ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing
  ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before
initializing
  ArmPlatformPkg/FVP: unify support for Foundation and Base models

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc  | 13 

 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf  |  4 
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 

 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c  | 16 
++
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h  | 17 
+++
 ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 

 8 files changed, 70 insertions(+), 18 deletions(-)

-- 
1.9.1

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


Re: [edk2] [PATCH 0/3] unify FVP Base and Foundation model support

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 15:50, Leif Lindholm leif.lindh...@linaro.org wrote:
 On Tue, Aug 18, 2015 at 02:14:53PM +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 14:12, Leif Lindholm leif.lindh...@linaro.org wrote:
  On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
  On 12 August 2015 at 08:45, Ard Biesheuvel ard.biesheu...@linaro.org 
  wrote:
   Instead of omitting some drivers that are known to break the Foundation
   model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
   simply fail to load without interfering with the boot.
  
   This way, we can use the same boot image for both models.
  
 
  Ping?
 
  Basicallt looks good to me, but I thought I'd wait for Ryan to comment
  (and he's on holiday through this week).
 
  Just to confirm - the Mmio probes just return zeroes in the Foundation
  model, rather than aborting?
 

 Foundation model output:

 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0.
 WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0.

 Note sure what these reads return, but in each case, the first byte
 already differs from the expected value so the init aborts.

 I know that this would still be sufficient to blow up on a real
 system, but thankfully the model does not model /that/ :-)

 No, my main concern would be if future versions of the model delete
 this trapping and instead signal an abort (or do something else
 entirely), to better mimic hardware behaviour.

 Do we have output console available at this point?
 If so, maybe put in a printout - at least in DEBUG build - that this
 is about to happen, to reduce debug time if the model behaviour
 changes?


I suppose that makes sense. These are DXEs being launched, so it is
definitely feasible to print some diagnostic on a DEBUG build.

 Regardless, unless Ryan objects on Monday:
 Reviewed-by: Leif Lindholm leif.lindh...@linaro.org


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


[edk2] [PATCH v2 1/3] ArmPlatformPkg/PL180MciDxe: check PrimeCell ID before initializing

2015-08-18 Thread Ard Biesheuvel
To deal gracefully with the absence of the PL180 hardware on
the Foundation model, check the PrimeCell ID before proceeding
with the installation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c | 16 
 ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h | 17 +
 2 files changed, 33 insertions(+)

diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c 
b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
index 411a61ed040f..688cd8a98ced 100644
--- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
+++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.c
@@ -521,6 +521,22 @@ PL180MciDxeInitialize (
   EFI_STATUSStatus;
   EFI_HANDLEHandle;
 
+  DEBUG ((EFI_D_WARN, Probing ID registers at 0x%lx for a PL180\n,
+MCI_PERIPH_ID_REG0));
+
+  // Check if this is a PL180
+  if (MmioRead8 (MCI_PERIPH_ID_REG0) != MCI_PERIPH_ID0 ||
+  MmioRead8 (MCI_PERIPH_ID_REG1) != MCI_PERIPH_ID1 ||
+  MmioRead8 (MCI_PERIPH_ID_REG2) != MCI_PERIPH_ID2 ||
+  MmioRead8 (MCI_PERIPH_ID_REG3) != MCI_PERIPH_ID3 ||
+  MmioRead8 (MCI_PCELL_ID_REG0)  != MCI_PCELL_ID0  ||
+  MmioRead8 (MCI_PCELL_ID_REG1)  != MCI_PCELL_ID1  ||
+  MmioRead8 (MCI_PCELL_ID_REG2)  != MCI_PCELL_ID2  ||
+  MmioRead8 (MCI_PCELL_ID_REG3)  != MCI_PCELL_ID3) {
+
+return EFI_NOT_FOUND;
+  }
+
   Handle = NULL;
 
   MCI_TRACE (PL180MciDxeInitialize());
diff --git a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h 
b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
index 6dc155ee9a61..ce38a9e70619 100644
--- a/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
+++ b/ArmPlatformPkg/Drivers/PL180MciDxe/PL180Mci.h
@@ -51,6 +51,23 @@
 #define MCI_SELECT_REG  (MCI_SYSCTL + 0x044)
 #define MCI_FIFOCOUNT_REG   (MCI_SYSCTL + 0x048)
 #define MCI_FIFO_REG(MCI_SYSCTL + 0x080)
+#define MCI_PERIPH_ID_REG0  (MCI_SYSCTL + 0xFE0)
+#define MCI_PERIPH_ID_REG1  (MCI_SYSCTL + 0xFE4)
+#define MCI_PERIPH_ID_REG2  (MCI_SYSCTL + 0xFE8)
+#define MCI_PERIPH_ID_REG3  (MCI_SYSCTL + 0xFEC)
+#define MCI_PCELL_ID_REG0   (MCI_SYSCTL + 0xFF0)
+#define MCI_PCELL_ID_REG1   (MCI_SYSCTL + 0xFF4)
+#define MCI_PCELL_ID_REG2   (MCI_SYSCTL + 0xFF8)
+#define MCI_PCELL_ID_REG3   (MCI_SYSCTL + 0xFFC)
+
+#define MCI_PERIPH_ID0  0x80
+#define MCI_PERIPH_ID1  0x11
+#define MCI_PERIPH_ID2  0x04
+#define MCI_PERIPH_ID3  0x00
+#define MCI_PCELL_ID0   0x0D
+#define MCI_PCELL_ID1   0xF0
+#define MCI_PCELL_ID2   0x05
+#define MCI_PCELL_ID3   0xB1
 
 #define MCI_POWER_OFF   0
 #define MCI_POWER_UPBIT1
-- 
1.9.1

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


[edk2] [PATCH v2 3/3] ArmPlatformPkg/FVP: unify support for Foundation and Base models

2015-08-18 Thread Ard Biesheuvel
Now that the PL180 and PL111 drivers know how to behave when executed
on the Foundation model that does not emulate the hardware, we can
remove the ARM_FOUNDATION_FVP ifdefs and produce a single build that
runs on both the Foundation model and the Base model.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 13 -
 ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf |  4 
 2 files changed, 17 deletions(-)

diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 119ba3a0c61e..28fc1d85243d 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -41,9 +41,7 @@ [LibraryClasses.common]
 
   
ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
   
NorFlashPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/NorFlashArmVExpressLib/NorFlashArmVExpressLib.inf
-!ifndef ARM_FOUNDATION_FVP
   
LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
-!endif
 
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
 
@@ -85,14 +83,9 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Fixed Virtual Platform
   gEmbeddedTokenSpaceGuid.PcdEmbeddedPrompt|ARM-FVP
 
-!ifndef ARM_FOUNDATION_FVP
   # Up to 8 cores on Base models. This works fine if model happens to have 
less.
   gArmPlatformTokenSpaceGuid.PcdCoreCount|8
   gArmPlatformTokenSpaceGuid.PcdClusterCount|2
-!else
-  # Up to 4 cores on Foundation models. This works fine if model happens to 
have less.
-  gArmPlatformTokenSpaceGuid.PcdCoreCount|4
-!endif
 
   #
   # NV Storage PCDs. Use base of 0x0C00 for NOR1
@@ -149,14 +142,12 @@ [PcdsFixedAtBuild.common]
   ## PL031 RealTimeClock
   gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17
 
-!ifndef ARM_FOUNDATION_FVP
   ## PL111 Versatile Express Motherboard controller
   gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x1C1F
 
   ## PL180 MMC/SD card controller
   gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x1C010048
   gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x1C05
-!endif
 
   #
   # ARM General Interrupt Controller
@@ -280,9 +271,7 @@ [Components.common]
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-!ifndef ARM_FOUNDATION_FVP
   ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-!endif
   ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
   #
@@ -290,13 +279,11 @@ [Components.common]
   #
   ArmPkg/Filesystem/SemihostFs/SemihostFs.inf
 
-!ifndef ARM_FOUNDATION_FVP
   #
   # Multimedia Card Interface
   #
   EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
   ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf
-!endif
 
   #
   # Platform Driver
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf 
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
index 9c447084e316..1d92d6f34832 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf
@@ -160,9 +160,7 @@ [FV.FvMain]
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
-!ifndef ARM_FOUNDATION_FVP
   INF ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf
-!endif
   INF ArmPlatformPkg/Drivers/SP805WatchdogDxe/SP805WatchdogDxe.inf
 
   #
@@ -178,13 +176,11 @@ [FV.FvMain]
   INF FatBinPkg/EnhancedFatDxe/Fat.inf
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
 
-!ifndef ARM_FOUNDATION_FVP
   #
   # Multimedia Card Interface
   #
   INF EmbeddedPkg/Universal/MmcDxe/MmcDxe.inf
   INF ArmPlatformPkg/Drivers/PL180MciDxe/PL180MciDxe.inf
-!endif
 
   #
   # Platform Driver
-- 
1.9.1

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


[edk2] [PATCH v2 2/3] ArmPlatformPkg/LcdGraphicsOutputDxe: check PrimeCell ID before initializing

2015-08-18 Thread Ard Biesheuvel
To deal gracefully with the absence of the PL111 hardware on
the Foundation model, check the PrimeCell ID before proceeding
with the installation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Reviewed-by: Leif Lindholm leif.lindh...@linaro.org
---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |  5 +
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  2 +-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c | 22 

 ArmPlatformPkg/Include/Drivers/PL111Lcd.h  |  9 

 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
index cbc20343496b..b721061fc1df 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
@@ -156,6 +156,11 @@ LcdGraphicsOutputDxeInitialize (
   EFI_STATUS  Status = EFI_SUCCESS;
   LCD_INSTANCE* Instance;
 
+  Status = LcdIdentify ();
+  if (EFI_ERROR(Status)) {
+goto EXIT;
+  }
+
   Status = LcdInstanceContructor (Instance);
   if (EFI_ERROR(Status)) {
 goto EXIT;
diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
index dfbf2ed67122..8856b79901b6 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
@@ -106,7 +106,7 @@ InitializeDisplay (
 );
 
 EFI_STATUS
-LcdIndentify (
+LcdIdentify (
   VOID
 );
 
diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
index ad841cd8dcac..b5e113b844d4 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
@@ -27,6 +27,28 @@
  **/
 
 EFI_STATUS
+LcdIdentify (
+  VOID
+  )
+{
+  DEBUG ((EFI_D_WARN, Probing ID registers at 0x%lx for a PL111\n,
+PL111_REG_CLCD_PERIPH_ID_0));
+
+  // Check if this is a PL111
+  if (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_0) == PL111_CLCD_PERIPH_ID_0 
+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_1) == PL111_CLCD_PERIPH_ID_1 
+ (MmioRead8 (PL111_REG_CLCD_PERIPH_ID_2)  0xf) == PL111_CLCD_PERIPH_ID_2 

+  MmioRead8 (PL111_REG_CLCD_PERIPH_ID_3) == PL111_CLCD_PERIPH_ID_3 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_0) == PL111_CLCD_P_CELL_ID_0 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_1) == PL111_CLCD_P_CELL_ID_1 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_2) == PL111_CLCD_P_CELL_ID_2 
+  MmioRead8 (PL111_REG_CLCD_P_CELL_ID_3) == PL111_CLCD_P_CELL_ID_3) {
+return EFI_SUCCESS;
+  }
+  return EFI_NOT_FOUND;
+}
+
+EFI_STATUS
 LcdInitialize (
   IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
   )
diff --git a/ArmPlatformPkg/Include/Drivers/PL111Lcd.h 
b/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
index 8c1c29de6cdd..18e28af805f6 100644
--- a/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
+++ b/ArmPlatformPkg/Include/Drivers/PL111Lcd.h
@@ -47,6 +47,15 @@
 #define PL111_REG_CLCD_P_CELL_ID_2((UINTN)PcdGet32 (PcdPL111LcdBase) + 
0xFF8)
 #define PL111_REG_CLCD_P_CELL_ID_3((UINTN)PcdGet32 (PcdPL111LcdBase) + 
0xFFC)
 
+#define PL111_CLCD_PERIPH_ID_00x11
+#define PL111_CLCD_PERIPH_ID_10x11
+#define PL111_CLCD_PERIPH_ID_20x04
+#define PL111_CLCD_PERIPH_ID_30x00
+#define PL111_CLCD_P_CELL_ID_00x0D
+#define PL111_CLCD_P_CELL_ID_10xF0
+#define PL111_CLCD_P_CELL_ID_20x05
+#define PL111_CLCD_P_CELL_ID_30xB1
+
 /**/
 
 // Register components (register bits)
-- 
1.9.1

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 22:03, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
 On 18 August 2015 at 19:35, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2015-08-18 at 17:52 +0200, Ard Biesheuvel wrote:
 On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
  Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
  same ball park size-wise. UNIXGCC produced much larger images because
  it could not strip unused functions/data.

 Yeah, that is still true, unfortunately.

 Is it really still true?

 https://sourceware.org/bugzilla/show_bug.cgi?id=11539#c14

 If the patch that Nick committed to fix this *isn't* working, please
 add a comment telling him that :)


 I did a quick test with the gdb-7.10-branch of binutils-gdb, and while
 it does make some difference, it is still not sufficient

 Building OvmfX64 in RELEASE mode gives me

 Before:
   the required fv image size 0xd67c0 exceeds the set fv image size 0xcc000

 After:
   the required fv image size 0xd2a18 exceeds the set fv image size 0xcc000

 where GCC/ELF obviously produces something  0xcc000


I had mistakenly omitted the -ffunction-sections -fdata-sections
switches, but adding those makes it even worse

  the required fv image size 0xdbf98 exceeds the set fv image size 0xcc000

so there is definitely something dodgy going on here.

I may not have the bandwidth to investigate this in depth, though.

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


[edk2] [PATCH] CorebootModulePkg: Prevent erasure of coreboot header before use

2015-08-18 Thread Scott Duplichan
Remove EFI_RESOURCE_ATTRIBUTE_TESTED when reporting lower 640KB
memory so that the coreboot header is not erased before being
processed by CbParseMemoryInfo. This change is needed for
compatibility with SVN revision 18146.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan sc...@notabs.org
---

CorebootModulePkg/CbSupportPei/CbSupportPei.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/CorebootModulePkg/CbSupportPei/CbSupportPei.c 
b/CorebootModulePkg/CbSupportPei/CbSupportPei.c
index 46b08d2..6b20ca9 100755
--- a/CorebootModulePkg/CbSupportPei/CbSupportPei.c
+++ b/CorebootModulePkg/CbSupportPei/CbSupportPei.c
@@ -186,12 +186,16 @@ CbPeiEntryPoint (
 
   ASSERT (LowMemorySize  0);
 
+  //
+  // Report lower 640KB of RAM. Attribute EFI_RESOURCE_ATTRIBUTE_TESTED
+  // is intentionally omitted to prevent erasing of the coreboot header
+  // record before it is processed by CbParseMemoryInfo.
+  //
   BuildResourceDescriptorHob (
 EFI_RESOURCE_SYSTEM_MEMORY,
 (
 EFI_RESOURCE_ATTRIBUTE_PRESENT |
 EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
-EFI_RESOURCE_ATTRIBUTE_TESTED |
 EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
 EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
 EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |


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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Ard Biesheuvel
On 18 August 2015 at 17:19, Jordan Justen jordan.l.jus...@intel.com wrote:
 On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 

 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

 Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
 same ball park size-wise. UNIXGCC produced much larger images because
 it could not strip unused functions/data.


Yeah, that is still true, unfortunately. Having a LLP64 toolchain
under Linux is nice, though, if only for test coverage

 Personally, I would not mind deprecating GCC44, but the biggest
 question I would have is what toolchains do the latest UDK releases
 claim to support.

 We also have the issue that every time I ask about deprecating a
 toolchain, Larry looks at me like I'm crazy. :)


Well, perhaps he can chime in and explain his motivation behind this?
At some point, we need to start removing things, surely. Larry just
has a higher tolerance for pain :-)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.

 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

 Is this something we want to support?


Perhaps not

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

 It is doing a better job than any other GCC based option we have.

 Certainly LTO will be a big change for our GCC based builds. If
 somehow LTO support is finally integrated into EDK II and manages to
 directly produce a PE/COFF image easily on Linux, then I don't think
 ELF is needed.


Yes, that is another thing to consider.

All in all, I think we agree that it would be useful to get rid of as
much cruft as we can, and my cleanup is intended to reduce the
maintenance burden of the GCC4x series that we want to keep. I am
perfectly happy getting rid of ELFGCC, CYGGCC and even UNIXGCC if we
can come up with a reasonble replacement.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Jordan Justen
On 2015-08-18 03:57:51, Ard Biesheuvel wrote:
 On 17 August 2015 at 20:53, Jordan Justen jordan.l.jus...@intel.com wrote:
  On 2015-08-17 11:25:56, Ard Biesheuvel wrote:
  MinGW generates PE/COFF not ELF, so much of the linker command line is
  different, and it really deserves a toolchain of its own
 
  Why does it deserve a toolchain of its own if the other toolchain
  produces better code? Why should EDK II care about using the different
  linker path if it isn't the best recommended way to build images?
 
 
 By the same logic, why on earth do we insist on retaining support for
 GCC44 and GCC45?

Last time I checked, GCC44 ~ GCC49 all produced images roughly in the
same ball park size-wise. UNIXGCC produced much larger images because
it could not strip unused functions/data.

Personally, I would not mind deprecating GCC44, but the biggest
question I would have is what toolchains do the latest UDK releases
claim to support.

We also have the issue that every time I ask about deprecating a
toolchain, Larry looks at me like I'm crazy. :)

 Note that it is not about the linker path, but about the options that
 we pass, for instance to get 4 KB section alignment. MinGW does not
 need a linker script for this, you can simply set --section-alignment
 and --file-alignment on the command line.
 
 As for the PE/COFF support: if you are incorporating PE/COFF binary
 static libraries into your build, you need a native PE/COFF toolchain.

Is this something we want to support?

 But in general, I think the ELF to PE/COFF conversion is not the most
 elegant step in the build, and I would prefer to avoid it if possible
 (only, there is no PE/COFF support in the GNU tools for ARM or
 AARCH64)

It is doing a better job than any other GCC based option we have.

Certainly LTO will be a big change for our GCC based builds. If
somehow LTO support is finally integrated into EDK II and manages to
directly produce a PE/COFF image easily on Linux, then I don't think
ELF is needed.

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


Re: [edk2] [PATCH v2 00/16] unify GCC command line options

2015-08-18 Thread Jordan Justen
On 2015-08-18 04:01:36, Ard Biesheuvel wrote:
 On 17 August 2015 at 21:16, David Woodhouse dw...@infradead.org wrote:
  On 2015-08-17 11:25:41, David Woodhouse wrote:
  On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote:
   Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead?
 
  Not for testing LLP64, no.
 
  How/who is this helping?
 
  It was massively useful for testing the OpenSSL stuff I've been working on
  recently. It showed up a number of issues which would otherwise only occur
  a Windows build.
 
 Indeed. I don't use Windows or have access to any MS toolchains, so
 this is basically the only way to make sure my code is LLP64 clean.

Maybe instead of tools_def.deprecated, we could add a
tools_def.unsupported. Then we could put both deprecated, and
unsupported toolchains in there. This might allow us to have less
review/testing for changes to these toolchains.

   I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be
   based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part
   of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if
   you count the comment in tools_def :) This is why I'd rather deprecate
   it as a toolchain, and use the GCC4X toolchains instead.
 
  Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage
  is lost.
 
  Maybe MINGW49. But, please not before we figure out how to actually
  deprecate toolchains. :)
 
 Why *must* we have the version encoded into the name? For GCC4x, the
 differences are so minor that it is just maintenance overhead imo. I

Adding GCC49 with some new switches is a lot easier than going back
and verifying that the new switch doesn't break on GCC 4.4.

Although it might have looked pretty gross in tools_def, I don't think
there was much maintainance overhead.

 used CLANG35 instead of CLANG per your request, but I am definitely
 not going to add CLANG36 CLANG37 etc unless there is a real need.

Regarding GCC44-GCC49, I think we only added them as someone
discovered a new switch was required. (Coupled with trying to avoid
modifying the old toolchain.)

Your 'unify' series definitely throws out the strategy of trying to
not modify old toolchains. You appear to have done the extra work to
show that it should be fine...

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