date:20150611

Re: [edk2] SCT build error

2015-06-11 Thread Meenakshi Aggarwal

Hi Scott,

Following path exist on my computer:
"C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\nmake.exe" 

i.e. without (x86) string.

What is the solution?
Which file needs to be changed?


Thanks
Meenakshi



-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Thursday, June 11, 2015 6:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] SCT build error

Meenakshi Aggarwal [mailto:meenakshi.aggar...@freescale.com] wrote:

]Sent: Thursday, June 11, 2015 06:31 AM
]To: edk2-devel@lists.sourceforge.net
]Subject: [edk2] SCT build error
]
]Hi All,
]
]
]I am trying to build SCT and facing following error:
]
]“: error 7000: Failed to start command
]C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe 
/no logo tbuild 
][c:\test\Build\UefiSct\DEBUG_VS2013x86\X64\EdkCompatibilityPkg\Foundation\Efi\Protocol\EfiProtocolLib]
]”
]
]Any idea will be of great help.
]
]
]
]Thanks & regards
]Meenakshi Aggarwal

EDK2 does not use the usual environment variable method of locating the Visual 
studio installation. Instead, it uses hard-coded paths that are suitable for 
some machines and not suitable for others.
Build.exe is trying to launch:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\nmake.exe Does this 
file exist on your computer?

Thanks,
Scott



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdePkg: Refine the comments for FileHandleIsDirectory.

2015-06-11 Thread Qiu Shumin

Make the function comments of FileHandleIsDirectory in FileHandleLib consistent 
with instance implementation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 MdePkg/Include/Library/FileHandleLib.h   | 4 ++--
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 7 ---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/MdePkg/Include/Library/FileHandleLib.h 
b/MdePkg/Include/Library/FileHandleLib.h
index 123cc8c..9c2d056 100644
--- a/MdePkg/Include/Library/FileHandleLib.h
+++ b/MdePkg/Include/Library/FileHandleLib.h
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -242,7 +242,7 @@ FileHandleFlush (
 /**
   Function to determine if a given handle is a directory handle.
 
-  If DirHandle is NULL, then ASSERT().
+  If DirHandle is NULL then return EFI_INVALID_PARAMETER.
 
   Open the file information on the DirHandle, and verify that the Attribute
   includes EFI_FILE_DIRECTORY bit set.
diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index be66c57..089f610 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -1,7 +1,7 @@
 /** @file
   Provides interface to EFI_FILE_HANDLE functionality.
 
-  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved. 
+  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved. 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -385,7 +385,7 @@ FileHandleFlush (
 /**
   function to determine if a given handle is a directory handle
 
-  if DirHandle is NULL then return error
+  If DirHandle is NULL then return EFI_INVALID_PARAMETER
 
   open the file information on the DirHandle and verify that the Attribute
   includes EFI_FILE_DIRECTORY bit set.
@@ -393,7 +393,8 @@ FileHandleFlush (
   @param DirHandle  Handle to open file
 
   @retval EFI_SUCCESS   DirHandle is a directory
-  @retval EFI_INVALID_PARAMETER DirHandle did not have EFI_FILE_INFO available
+  @retval EFI_INVALID_PARAMETER DirHandle is NULL or the file information 
+returns from FileHandleGetInfo is NULL 
   @retval EFI_NOT_FOUND DirHandle is not a directory
 **/
 EFI_STATUS
-- 
1.9.5.msysgit.1



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] FV FvName in FV Ext Entry

2015-06-11 Thread Tim Lewis

Would someone care to document the changes that were made to add the FV Name to 
the FV volume header? It would be helpful for other folks to know what Intel is 
planning here, and how it fits in with the overall scheme. Also, how to turn 
off this feature so that it is not generated.

Thanks,

Tim
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Build Tool Changes

2015-06-11 Thread Tim Lewis

Would someone care to document the recent changes surrounding the VFR and UNI 
offsets encoded as a binary? I don't think I've seen this discussed anywhere. 
It seems to me that a better course of action would have been to solve the 
problem with linking the resources in the method defined in the UEFI 
specification.

Tim
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] PcAtChipsetPkg: Fix PCD expression build failure

2015-06-11 Thread Gao, Liming

Reviewed-by: Liming Gao 

-Original Message-
From: Ni, Ruiyu 
Sent: Friday, June 12, 2015 9:34 AM
To: edk2-devel@lists.sourceforge.net
Cc: Ni, Ruiyu; Gao, Liming
Subject: [Patch] PcAtChipsetPkg: Fix PCD expression build failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 PcAtChipsetPkg/PcAtChipsetPkg.dec |   7 ++-
 PcAtChipsetPkg/PcAtChipsetPkg.uni | Bin 24384 -> 24586 bytes
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec 
b/PcAtChipsetPkg/PcAtChipsetPkg.dec
index 6a1415c..cbd5707 100644
--- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
+++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
@@ -34,6 +34,11 @@
 [Guids]
   gPcAtChipsetPkgTokenSpaceGuid = { 0x326ae723, 0xae32, 0x4589, { 0x98, 0xb8, 
0xca, 0xc2, 0x3c, 0xdc, 0xc1, 0xb1 } }
 
+#
+# [Error.gPcAtChipsetPkgTokenSpaceGuid]
+#   0x8001 | Invalid value provided.
+#
+
 [PcdsFeatureFlag]
   ## Indicates the HPET Timer will be configured to use MSI interrupts if the 
HPET timer supports them, or use I/O APIC interrupts.
   #   TRUE  - Configures the HPET Timer to use MSI interrupts if the HPET 
Timer supports them.
@@ -123,7 +128,7 @@
 
   ## This PCD specifies the maximal valid year in RTC.
   # @Prompt Maximal valid year in RTC.
-  # @Expression gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear < 
gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100
+  # @Expression 0x8001 | 
+ gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear < 
+ gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100
   gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear|2097|UINT16|0x000E
   
 [PcdsFixedAtBuild, PcdsPatchableInModule] diff --git 
a/PcAtChipsetPkg/PcAtChipsetPkg.uni b/PcAtChipsetPkg/PcAtChipsetPkg.uni
index 
e6d91632933bd3c481927a63a54835838afe35a7..0ce08d4733f964ebb2e2597dee0032b1e2b4f4b0
 100644 GIT binary patch delta 84 
zcmX@GkFo0j;|7QL$qiN^;;sxqKp4+p!C-&{4JRv_s89Z2z#>}4kjRk3kjaq3puhlO
VmolVIzQ`}kqsO4cz{|h|#sG!O5!(O&

delta 9
QcmeA=z<6LE;|7O#02UJj8UO$Q

--
1.9.5.msysgit.1


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch] PcAtChipsetPkg: Fix PCD expression build failure

2015-06-11 Thread Ruiyu Ni

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Liming Gao 
---
 PcAtChipsetPkg/PcAtChipsetPkg.dec |   7 ++-
 PcAtChipsetPkg/PcAtChipsetPkg.uni | Bin 24384 -> 24586 bytes
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec 
b/PcAtChipsetPkg/PcAtChipsetPkg.dec
index 6a1415c..cbd5707 100644
--- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
+++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
@@ -34,6 +34,11 @@
 [Guids]
   gPcAtChipsetPkgTokenSpaceGuid = { 0x326ae723, 0xae32, 0x4589, { 0x98, 0xb8, 
0xca, 0xc2, 0x3c, 0xdc, 0xc1, 0xb1 } }
 
+#
+# [Error.gPcAtChipsetPkgTokenSpaceGuid]
+#   0x8001 | Invalid value provided.
+#
+
 [PcdsFeatureFlag]
   ## Indicates the HPET Timer will be configured to use MSI interrupts if the 
HPET timer supports them, or use I/O APIC interrupts.
   #   TRUE  - Configures the HPET Timer to use MSI interrupts if the HPET 
Timer supports them.
@@ -123,7 +128,7 @@
 
   ## This PCD specifies the maximal valid year in RTC.
   # @Prompt Maximal valid year in RTC.
-  # @Expression gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear < 
gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100
+  # @Expression 0x8001 | gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear 
< gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100
   gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear|2097|UINT16|0x000E
   
 [PcdsFixedAtBuild, PcdsPatchableInModule]
diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.uni 
b/PcAtChipsetPkg/PcAtChipsetPkg.uni
index 
e6d91632933bd3c481927a63a54835838afe35a7..0ce08d4733f964ebb2e2597dee0032b1e2b4f4b0
 100644
GIT binary patch
delta 84
zcmX@GkFo0j;|7QL$qiN^;;sxqKp4+p!C-&{4JRv_s89Z2z#>}4kjRk3kjaq3puhlO
VmolVIzQ`}kqsO4cz{|h|#sG!O5!(O&

delta 9
QcmeA=z<6LE;|7O#02UJj8UO$Q

-- 
1.9.5.msysgit.1


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Basetool][Upt][patch]Update help message of UPT

2015-06-11 Thread Chen, Hesheng

Hello Larry and all,
Could you help review this patch? Thank you

[Description]
Update help message of UPT to remove Intel(R) from the string.

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


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



Upt.patch
Description: Upt.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug

2015-06-11 Thread Ni, Ruiyu

Laszlo,
Yes I can reproduce this build failure.
I did build without the expression comments but didn't do that again after 
adding the expression comments in DEC. I thought it was only comments and not 
checked by tool.
We are working on patch to fix the build failure.

Thanks,
Ray

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, June 11, 2015 11:17 PM
> To: Ni, Ruiyu
> Cc: edk2-devel@lists.sourceforge.net; Gerd Hoffmann (GMail address)
> Subject: Re: [edk2] [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug
> 
> On 06/10/15 06:10, Ruiyu Ni wrote:
> > The original driver cannot handle the case when system time runs from
> 1999/12/31 23:59:59
> > to 2000/1/1 0:0:0.
> > A simple test to set system time to 1999/12/31 23:59:59 can expose this
> bug.
> > The patch limits the driver to only support year in 100 range and decide the
> century value based
> > on the supporting range: Century either equals to PcdMinimalYear / 100 or
> equals to PcdMinimalYear / 100 + 1.
> >
> > The patch passed the Y2K test.
> > However with year range [1998, 2097], when system time is 2097/12/31
> 23:59:59,
> > the next second system time will become 1998/1/1 0:0:0. I think it's a
> acceptable limitation.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > ---
> >  PcAtChipsetPkg/PcAtChipsetPkg.dec  |  5 +-
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c | 55
> +-
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.h | 11 +
> >  3 files changed, 27 insertions(+), 44 deletions(-)
> >
> > diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > index fb6fb8b..6a1415c 100644
> > --- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > @@ -123,7 +123,8 @@
> >
> >## This PCD specifies the maximal valid year in RTC.
> ># @Prompt Maximal valid year in RTC.
> > -
> gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear|2099|UINT16|0x000
> E
> > +  # @Expression gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear
> < gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100
> 
> This @Expression is malformed, it causes the following build error:
> 
> > build.py...
> >  : error C0DE: Unknown fatal error when processing
> [.../PcAtChipsetPkg/PcAtChipsetPkg.dec]
> >
> > (Please send email to edk2-devel@lists.sourceforge.net for help, attaching
> following call stack trace!)
> >
> > (Python 2.7.5 on linux2) Traceback (most recent call last):
> >   File
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 2032, in Main
> > MyBuild.Launch()
> >   File
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 1788, in Launch
> > self._MultiThreadBuildPlatform()
> >   File
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 1583, in _MultiThreadBuildPlatform
> > self.Progress
> >   File ".../BaseTools/Source/Python/AutoGen/AutoGen.py", line 175, in
> __new__
> > if not AutoGenObject._Init(Workspace, MetaFile, Target, Toolchain,
> Arch, *args, **kwargs):
> >   File ".../BaseTools/Source/Python/AutoGen/AutoGen.py", line 357, in
> _Init
> > for Pcd in Pkg.Pcds:
> >   File ".../BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
> line 1487, in _GetPcds
> > self._Pcds.update(self._GetPcd(MODEL_PCD_FIXED_AT_BUILD))
> >   File ".../BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
> line 1521, in _GetPcd
> > validateranges, validlists, expressions =
> self._RawData.GetValidExpression(TokenSpaceGuid, PcdCName)
> >   File ".../BaseTools/Source/Python/Workspace/MetaFileParser.py", line
> 380, in GetValidExpression
> > return self._Table.GetValidExpression(TokenSpaceGuid, PcdCName)
> >   File ".../BaseTools/Source/Python/Workspace/MetaFileTable.py", line
> 246, in GetValidExpression
> > expressions.append(comment.split("|")[1].strip())
> > IndexError: list index out of range
> >
> > - Failed -
> 
> @Expression's should have a number (I guess a bitmask of flags?) associated
> with them, and that number should be separated from the actual expression
> with a filter bar (|). Example:
> 
>   MdePkg/MdePkg.dec:  # @Expression  0x8002 |
> (gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 0xC0) == 0
> 
> The above @Expression in "PcAtChipsetPkg/PcAtChipsetPkg.dec" lacks the
> bitmask and the "|" separator. (Which makes me question if this patch was
> ever build tested.)
> 
> Thanks
> Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

2015-06-11 Thread Gao, Liming

Got it. Reviewed-by: Liming Gao 

-Original Message-
From: Liu, Yingke D [mailto:yingke.d@intel.com] 
Sent: Friday, June 12, 2015 8:44 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Liming,

1) TotalSize is the EXT header size
2) TotalSize is the whole EXT header size, and it is initianlized with 16 + 4 
which is the size of EFI_FIRMWARE_VOLUME_EXT_HEADER.

Dennis

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Thursday, June 11, 2015 23:18
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Dennis:
  Two comments are here. 
1) Do you update EXT header size filed to include this EXT entry?
2) EXT entry size is recorded in totalsize. How about directly use totalsize in 
the following code?

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Thursday, June 11, 2015 4:21 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

This patch also removed a warning message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py |  1 -
 BaseTools/Source/Python/GenFds/Fv.py   | 21 +
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 996b654..0e7482a 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2297,7 +2297,6 @@ class ModuleAutoGen(AutoGen):
 if Module.MetaFile == self.MetaFile:
 continue
 if Module.Name == self.Name:
-EdkLogger.warn('build', 'Modules have same BaseName:\n  %s\n  
%s' % (Module.MetaFile, self.MetaFile))
 if uuid.UUID(Module.Guid) == uuid.UUID(self.Guid):
 EdkLogger.error("build", FILE_DUPLICATED, 'Modules have 
same BaseName and FILE_GUID:\n'
 '  %s\n  %s' % (Module.MetaFile, 
self.MetaFile)) diff --git a/BaseTools/Source/Python/GenFds/Fv.py 
b/BaseTools/Source/Python/GenFds/Fv.py
index 03a7426..8f341d3 100644
--- a/BaseTools/Source/Python/GenFds/Fv.py
+++ b/BaseTools/Source/Python/GenFds/Fv.py
@@ -30,6 +30,7 @@ from Common.LongFilePathSupport import CopyLongFilePath  from 
Common.LongFilePathSupport import OpenLongFilePath as open
 
 T_CHAR_LF = '\n'
+FV_UI_EXT_ENTY_GUID = 'A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C'
 
 ## generate FV
 #
@@ -295,6 +296,26 @@ class FV (FvClassObject):
 if self.FvNameGuid <> None and self.FvNameGuid <> '':
 TotalSize = 16 + 4
 Buffer = ''
+#
+# Create EXT entry for FV UI name
+# This GUID is used: A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C
+#
+FvUiLen = len(self.UiFvName)
+TotalSize += (FvUiLen + 16 + 4)
+Guid = FV_UI_EXT_ENTY_GUID.split('-')
+#
+# Layout:
+#   EFI_FIRMWARE_VOLUME_EXT_ENTRY : size 4
+#   GUID  : size 16
+#   FV UI name
+#
+Buffer += (pack('HH', (FvUiLen + 16 + 4), 0x0002)
+   + pack('=LHH', int(Guid[0], 16), int(Guid[1], 
16), int(Guid[2], 16),
+  int(Guid[3][-4:-2], 16), int(Guid[3][-2:], 16), 
int(Guid[4][-12:-10], 16),
+  int(Guid[4][-10:-8], 16), int(Guid[4][-8:-6], 
16), int(Guid[4][-6:-4], 16),
+  int(Guid[4][-4:-2], 16), int(Guid[4][-2:], 16))
+   + self.UiFvName)
+
 for Index in range (0, len(self.FvExtEntryType)):
 if self.FvExtEntryType[Index] == 'FILE':
 # check if the path is absolute or relative
--
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

2015-06-11 Thread Liu, Yingke D

Liming,

1) TotalSize is the EXT header size
2) TotalSize is the whole EXT header size, and it is initianlized with 16 + 4 
which is the size of EFI_FIRMWARE_VOLUME_EXT_HEADER.

Dennis

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Thursday, June 11, 2015 23:18
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Dennis:
  Two comments are here. 
1) Do you update EXT header size filed to include this EXT entry?
2) EXT entry size is recorded in totalsize. How about directly use totalsize in 
the following code?

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Thursday, June 11, 2015 4:21 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

This patch also removed a warning message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py |  1 -
 BaseTools/Source/Python/GenFds/Fv.py   | 21 +
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 996b654..0e7482a 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2297,7 +2297,6 @@ class ModuleAutoGen(AutoGen):
 if Module.MetaFile == self.MetaFile:
 continue
 if Module.Name == self.Name:
-EdkLogger.warn('build', 'Modules have same BaseName:\n  %s\n  
%s' % (Module.MetaFile, self.MetaFile))
 if uuid.UUID(Module.Guid) == uuid.UUID(self.Guid):
 EdkLogger.error("build", FILE_DUPLICATED, 'Modules have 
same BaseName and FILE_GUID:\n'
 '  %s\n  %s' % (Module.MetaFile, 
self.MetaFile)) diff --git a/BaseTools/Source/Python/GenFds/Fv.py 
b/BaseTools/Source/Python/GenFds/Fv.py
index 03a7426..8f341d3 100644
--- a/BaseTools/Source/Python/GenFds/Fv.py
+++ b/BaseTools/Source/Python/GenFds/Fv.py
@@ -30,6 +30,7 @@ from Common.LongFilePathSupport import CopyLongFilePath  from 
Common.LongFilePathSupport import OpenLongFilePath as open
 
 T_CHAR_LF = '\n'
+FV_UI_EXT_ENTY_GUID = 'A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C'
 
 ## generate FV
 #
@@ -295,6 +296,26 @@ class FV (FvClassObject):
 if self.FvNameGuid <> None and self.FvNameGuid <> '':
 TotalSize = 16 + 4
 Buffer = ''
+#
+# Create EXT entry for FV UI name
+# This GUID is used: A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C
+#
+FvUiLen = len(self.UiFvName)
+TotalSize += (FvUiLen + 16 + 4)
+Guid = FV_UI_EXT_ENTY_GUID.split('-')
+#
+# Layout:
+#   EFI_FIRMWARE_VOLUME_EXT_ENTRY : size 4
+#   GUID  : size 16
+#   FV UI name
+#
+Buffer += (pack('HH', (FvUiLen + 16 + 4), 0x0002)
+   + pack('=LHH', int(Guid[0], 16), int(Guid[1], 
16), int(Guid[2], 16),
+  int(Guid[3][-4:-2], 16), int(Guid[3][-2:], 16), 
int(Guid[4][-12:-10], 16),
+  int(Guid[4][-10:-8], 16), int(Guid[4][-8:-6], 
16), int(Guid[4][-6:-4], 16),
+  int(Guid[4][-4:-2], 16), int(Guid[4][-2:], 16))
+   + self.UiFvName)
+
 for Index in range (0, len(self.FvExtEntryType)):
 if self.FvExtEntryType[Index] == 'FILE':
 # check if the path is absolute or relative
--
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Show image BMP with UEFI

2015-06-11 Thread Andrew Fish

> On Jun 11, 2015, at 6:50 AM, S.Vieira  wrote:
> 
> Hi everyone.
> 
> I am trying show a image with UEFI 
> 
> (i see a example in http://uefi.blogspot.com.br/)
> 
> But does not worked .
> 
> Can help me Somebody   ?!
> 

The edk2 supports BMP logos on boot:
The Logo is a bmp file: 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Logo/Logo.bmp

I assume you are looking for the code to convert a BMP into a GOP Blt buffer.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c
/**
  Convert a *.BMP graphics image to a GOP blt buffer. If a NULL Blt buffer
  is passed in a GopBlt buffer will be allocated by this routine. If a GopBlt
  buffer is passed in it will be used if it is big enough.

  @param  BmpImage  Pointer to BMP file
  @param  BmpImageSize  Number of bytes in BmpImage
  @param  GopBltBuffer containing GOP version of BmpImage.
  @param  GopBltSizeSize of GopBlt in bytes.
  @param  PixelHeight   Height of GopBlt/BmpImage in pixels
  @param  PixelWidthWidth of GopBlt/BmpImage in pixels

  @retval EFI_SUCCESS   GopBlt and GopBltSize are returned.
  @retval EFI_UNSUPPORTED   BmpImage is not a valid *.BMP image
  @retval EFI_BUFFER_TOO_SMALL  The passed in GopBlt buffer is not big enough.
GopBltSize will contain the required size.
  @retval EFI_OUT_OF_RESOURCES  No enough buffer to allocate.

**/
EFI_STATUS
ConvertBmpToGopBlt (
  IN VOID  *BmpImage,
  IN UINTN BmpImageSize,
  IN OUT VOID  **GopBlt,
  IN OUT UINTN *GopBltSize,
 OUT UINTN *PixelHeight,
 OUT UINTN *PixelWidth
  )

Thanks,

Andrew Fish

> 
> Source code of the example:
> 
> http://sourceforge.net/p/syslibforuefi/code/HEAD/tree/trunk/Applications/
> 
> 
> Thx S.Vieira
> 
> 
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Show image BMP with UEFI

2015-06-11 Thread Rod Smith

On 06/11/2015 09:50 AM, S.Vieira wrote:
> Hi everyone.
> 
> I am trying show a image with UEFI 
> 
> (i see a example in http://uefi.blogspot.com.br/)
> 
> But does not worked .
> 
> Can help me Somebody   ?!
> 
> 
> Source code of the example:
> 
> http://sourceforge.net/p/syslibforuefi/code/HEAD/tree/trunk/Applications/

I can't comment on the code to which you're referring, but for more
example code, see rEFIt (BSD-licensed) and rEFInd (GPLv3-licensed; I
forked it from rEFIt):

https://sourceforge.net/p/refit/code/HEAD/tree/trunk/refit/
https://sourceforge.net/p/refind/code/ci/master/tree/

In both cases, the BMP code is in the libeg subdirectory, and especially
in the load_bmp.c file. Other files, like screen.c and image.c, hold
more EFI-specific code for image manipulation; the load_bmp.c file has
little or nothing EFI-specific in it.

-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [patch 1/3] [CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the patch file for openssl-1.0.2a.

2015-06-11 Thread Laszlo Ersek

On 06/11/15 15:50, Ard Biesheuvel wrote:
> On 10 June 2015 at 19:22, Long, Qin  wrote:
>> Thanks, Ard.
>>
>> This is one historical changes, and come from some early user's requests: 
>> they would like to keep the built result / image of this module identical as 
>> possible, whatever any path was used (e.g. aaa/edk2/.../openssl v.s. 
>> bbb/edk2/...openssl, ...). To meet this, we have to patch those __FILE__ 
>> macro then.  :-(
>>
> 
> OK, fair enough.
> 
>> I keep this for all later updates.
>>
> 
> I guess not all toolchains support
> 
> #undef __FILE__
> #define __FILE__ NULL
> 
> ??
> 
> because that would be a bit simpler.

It would also be undefined behavior. The C standards say that

  None of these macro names, nor the identifier "defined", shall be the
  subject of a #define or a #undef preprocessing directive.

Thanks
Laszlo


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] "cond" vs. ?

2015-06-11 Thread Gao, Liming

Tim:
  Got your point. We will update VFR doc to explain it.

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 6:46 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

There is already an example in the VFR specification. But there is no comment 
to indicate which is "TRUE" and which is "FALSE"

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, June 10, 2015 6:04 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Tim:
  How about add one example in VFR spec to explain it?

Thanks
Liming

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 5:11 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Yes. But this is confusing because the VFR specification is not clear. As a 
result, many programmers assume that the cond() operator will work like the C ? 
operator.

How do we get the VFR specification updated?

Thanks,

Tim

From: Gao, Liming [mailto:liming@intel.com]
Sent: Wednesday, June 10, 2015 5:01 PM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: Re: [edk2] "cond" vs. ?

Lewis:
  Second way. If (expr1) then x = expr3 else expr2

Thanks
Liming
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, June 10, 2015 10:48 AM
To: edk2-devel@lists.sourceforge.net
Cc: Lawrence Chiu
Subject: [edk2] "cond" vs. ?

Folks -

It appears that the VFR spec is not clear about how the 2nd and 3rd parameters 
of the "cond" operator are handled.

cond(expr1, expr2, expr3)

Is it: if (expr1) then x = expr2 else expr3

Or

If (expr1) then x = expr3 else expr2

We have seen alternate implementations in the wild.

Thanks,

Tim

The VFR spec says:

conditionalExp ::=

"cond"

"("

vfrStatementExpression

"?"

vfrStatementExpression

":"

vfrStatementExpression

")"

BEHAVIORS AND RESTRICTIONS:

Generates EFI_IFR_CONDITIONAL op-codes.VFR Description in BNF 52

Example:

numeric varid = MyData.Data,

prompt = STRING_TOKEN(STR_PROMPT),

help = STRING_TOKEN(STR_HELP),

minimum = 0,

maximum = 255,

default value = cond(2 == 1 ? 5 : 10),
endnumeric;

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug

2015-06-11 Thread Laszlo Ersek

On 06/10/15 06:10, Ruiyu Ni wrote:
> The original driver cannot handle the case when system time runs from 
> 1999/12/31 23:59:59
> to 2000/1/1 0:0:0.
> A simple test to set system time to 1999/12/31 23:59:59 can expose this bug.
> The patch limits the driver to only support year in 100 range and decide the 
> century value based
> on the supporting range: Century either equals to PcdMinimalYear / 100 or 
> equals to PcdMinimalYear / 100 + 1.
> 
> The patch passed the Y2K test.
> However with year range [1998, 2097], when system time is 2097/12/31 23:59:59,
> the next second system time will become 1998/1/1 0:0:0. I think it's a 
> acceptable limitation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Feng Tian 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> ---
>  PcAtChipsetPkg/PcAtChipsetPkg.dec  |  5 +-
>  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c | 55 
> +-
>  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.h | 11 +
>  3 files changed, 27 insertions(+), 44 deletions(-)
> 
> diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec 
> b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> index fb6fb8b..6a1415c 100644
> --- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> @@ -123,7 +123,8 @@
>  
>## This PCD specifies the maximal valid year in RTC.
># @Prompt Maximal valid year in RTC.
> -  gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear|2099|UINT16|0x000E
> +  # @Expression gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear < 
> gPcAtChipsetPkgTokenSpaceGuid.PcdMinimalValidYear + 100

This @Expression is malformed, it causes the following build error:

> build.py...
>  : error C0DE: Unknown fatal error when processing 
> [.../PcAtChipsetPkg/PcAtChipsetPkg.dec]
> 
> (Please send email to edk2-devel@lists.sourceforge.net for help, attaching 
> following call stack trace!)
> 
> (Python 2.7.5 on linux2) Traceback (most recent call last):
>   File 
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line 2032, in Main
> MyBuild.Launch()
>   File 
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line 1788, in Launch
> self._MultiThreadBuildPlatform()
>   File 
> ".../BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
> line 1583, in _MultiThreadBuildPlatform
> self.Progress
>   File ".../BaseTools/Source/Python/AutoGen/AutoGen.py", line 175, in __new__
> if not AutoGenObject._Init(Workspace, MetaFile, Target, Toolchain, Arch, 
> *args, **kwargs):
>   File ".../BaseTools/Source/Python/AutoGen/AutoGen.py", line 357, in _Init
> for Pcd in Pkg.Pcds:
>   File ".../BaseTools/Source/Python/Workspace/WorkspaceDatabase.py", line 
> 1487, in _GetPcds
> self._Pcds.update(self._GetPcd(MODEL_PCD_FIXED_AT_BUILD))
>   File ".../BaseTools/Source/Python/Workspace/WorkspaceDatabase.py", line 
> 1521, in _GetPcd
> validateranges, validlists, expressions = 
> self._RawData.GetValidExpression(TokenSpaceGuid, PcdCName)
>   File ".../BaseTools/Source/Python/Workspace/MetaFileParser.py", line 380, 
> in GetValidExpression
> return self._Table.GetValidExpression(TokenSpaceGuid, PcdCName)
>   File ".../BaseTools/Source/Python/Workspace/MetaFileTable.py", line 246, in 
> GetValidExpression
> expressions.append(comment.split("|")[1].strip())
> IndexError: list index out of range
> 
> - Failed -

@Expression's should have a number (I guess a bitmask of flags?) associated 
with them, and that number should be separated from the actual expression with 
a filter bar (|). Example:

  MdePkg/MdePkg.dec:  # @Expression  0x8002 | 
(gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask & 0xC0) == 0

The above @Expression in "PcAtChipsetPkg/PcAtChipsetPkg.dec" lacks the bitmask 
and the "|" separator. (Which makes me question if this patch was ever build 
tested.)

Thanks
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

2015-06-11 Thread Gao, Liming

Dennis:
  Two comments are here. 
1) Do you update EXT header size filed to include this EXT entry?
2) EXT entry size is recorded in totalsize. How about directly use totalsize in 
the following code?

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Thursday, June 11, 2015 4:21 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

This patch also removed a warning message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py |  1 -
 BaseTools/Source/Python/GenFds/Fv.py   | 21 +
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 996b654..0e7482a 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2297,7 +2297,6 @@ class ModuleAutoGen(AutoGen):
 if Module.MetaFile == self.MetaFile:
 continue
 if Module.Name == self.Name:
-EdkLogger.warn('build', 'Modules have same BaseName:\n  %s\n  
%s' % (Module.MetaFile, self.MetaFile))
 if uuid.UUID(Module.Guid) == uuid.UUID(self.Guid):
 EdkLogger.error("build", FILE_DUPLICATED, 'Modules have 
same BaseName and FILE_GUID:\n'
 '  %s\n  %s' % (Module.MetaFile, 
self.MetaFile)) diff --git a/BaseTools/Source/Python/GenFds/Fv.py 
b/BaseTools/Source/Python/GenFds/Fv.py
index 03a7426..8f341d3 100644
--- a/BaseTools/Source/Python/GenFds/Fv.py
+++ b/BaseTools/Source/Python/GenFds/Fv.py
@@ -30,6 +30,7 @@ from Common.LongFilePathSupport import CopyLongFilePath  from 
Common.LongFilePathSupport import OpenLongFilePath as open
 
 T_CHAR_LF = '\n'
+FV_UI_EXT_ENTY_GUID = 'A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C'
 
 ## generate FV
 #
@@ -295,6 +296,26 @@ class FV (FvClassObject):
 if self.FvNameGuid <> None and self.FvNameGuid <> '':
 TotalSize = 16 + 4
 Buffer = ''
+#
+# Create EXT entry for FV UI name
+# This GUID is used: A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C
+#
+FvUiLen = len(self.UiFvName)
+TotalSize += (FvUiLen + 16 + 4)
+Guid = FV_UI_EXT_ENTY_GUID.split('-')
+#
+# Layout:
+#   EFI_FIRMWARE_VOLUME_EXT_ENTRY : size 4
+#   GUID  : size 16
+#   FV UI name
+#
+Buffer += (pack('HH', (FvUiLen + 16 + 4), 0x0002)
+   + pack('=LHH', int(Guid[0], 16), int(Guid[1], 
16), int(Guid[2], 16),
+  int(Guid[3][-4:-2], 16), int(Guid[3][-2:], 16), 
int(Guid[4][-12:-10], 16),
+  int(Guid[4][-10:-8], 16), int(Guid[4][-8:-6], 
16), int(Guid[4][-6:-4], 16),
+  int(Guid[4][-4:-2], 16), int(Guid[4][-2:], 16))
+   + self.UiFvName)
+
 for Index in range (0, len(self.FvExtEntryType)):
 if self.FvExtEntryType[Index] == 'FILE':
 # check if the path is absolute or relative
--
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [patch 1/3] [CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the patch file for openssl-1.0.2a.

2015-06-11 Thread Ard Biesheuvel

On 10 June 2015 at 19:22, Long, Qin  wrote:
> Thanks, Ard.
>
> This is one historical changes, and come from some early user's requests: 
> they would like to keep the built result / image of this module identical as 
> possible, whatever any path was used (e.g. aaa/edk2/.../openssl v.s. 
> bbb/edk2/...openssl, ...). To meet this, we have to patch those __FILE__ 
> macro then.  :-(
>

OK, fair enough.

> I keep this for all later updates.
>

I guess not all toolchains support

#undef __FILE__
#define __FILE__ NULL

??

because that would be a bit simpler.

-- 
Ard.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, June 10, 2015 7:55 PM
> To: Long, Qin
> Cc: Ye, Ting; edk2-devel@lists.sourceforge.net
> Subject: Re: [patch 1/3] [CryptoPkg] Remove the old patch file for 
> openssl-0.9.8zf build, and add the patch file for openssl-1.0.2a.
>
> On 10 June 2015 at 12:22, Ard Biesheuvel  wrote:
>> On 10 June 2015 at 04:21, qlong  wrote:
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Long, Qin 
>>> Signed-off-by: qlong 
>>
>> Reviewed-by: Ard Biesheuvel 
>>
>
> I do have a question, though. Why does the underlying patch replace __FILE__ 
> and __LINE__ references? These macros appear in MdeModulePkg unconditionally, 
> so I suppose all supported toolchains can deal with them
>
>
>>> ---
>>>  .../Library/OpensslLib/EDKII_openssl-0.9.8zf.patch | 279
>>>   .../Library/OpensslLib/EDKII_openssl-1.0.2a.patch
>>> | 358 +
>>>  2 files changed, 358 insertions(+), 279 deletions(-)  delete mode
>>> 100644 CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
>>>  create mode 100644
>>> CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2a.patch
>>>
>>> diff --git a/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
>>> b/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
>>> deleted file mode 100644
>>> index 4abe62c..000
>>> --- a/CryptoPkg/Library/OpensslLib/EDKII_openssl-0.9.8zf.patch
>>> +++ /dev/null
>>> @@ -1,279 +0,0 @@
>>> -Index: crypto/bio/bss_file.c
>>> -===
>>>  crypto/bio/bss_file.c  (revision 1)
>>> -+++ crypto/bio/bss_file.c  (working copy)
>>> -@@ -418,6 +418,23 @@
>>> - return (ret);
>>> - }
>>> -
>>> -+#else
>>> -+
>>> -+BIO_METHOD *BIO_s_file(void)
>>> -+{
>>> -+return NULL;
>>> -+}
>>> -+
>>> -+BIO *BIO_new_file(const char *filename, const char *mode) {
>>> -+return NULL;
>>> -+}
>>> -+
>>> -+BIO *BIO_new_fp(FILE *stream, int close_flag) {
>>> -+return NULL;
>>> -+}
>>> -+
>>> - # endif /* OPENSSL_NO_STDIO */
>>> -
>>> - #endif  /* HEADER_BSS_FILE_C */
>>> -Index: crypto/crypto.h
>>> -===
>>>  crypto/crypto.h(revision 1)
>>> -+++ crypto/crypto.h(working copy)
>>> -@@ -239,15 +239,15 @@
>>> - # ifndef OPENSSL_NO_LOCKING
>>> - #  ifndef CRYPTO_w_lock
>>> - #   define CRYPTO_w_lock(type) \
>>> --CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
>>> -+CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,NULL,0)
>>> - #   define CRYPTO_w_unlock(type)   \
>>> --CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
>>> -+CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,NULL,0)
>>> - #   define CRYPTO_r_lock(type) \
>>> --CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,__FILE__,__LINE__)
>>> -+CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,NULL,0)
>>> - #   define CRYPTO_r_unlock(type)   \
>>> --CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,__FILE__,__LINE__)
>>> -+CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,NULL,0)
>>> - #   define CRYPTO_add(addr,amount,type)\
>>> --CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__)
>>> -+CRYPTO_add_lock(addr,amount,type,NULL,0)
>>> - #  endif
>>> - # else
>>> - #  define CRYPTO_w_lock(a)
>>> -@@ -374,19 +374,19 @@
>>> - # define MemCheck_off()  CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE)
>>> - # define is_MemCheck_on() CRYPTO_is_mem_check_on()
>>> -
>>> --# define OPENSSL_malloc(num) CRYPTO_malloc((int)num,__FILE__,__LINE__)
>>> --# define OPENSSL_strdup(str) CRYPTO_strdup((str),__FILE__,__LINE__)
>>> -+# define OPENSSL_malloc(num) CRYPTO_malloc((int)num,NULL,0)
>>> -+# define OPENSSL_strdup(str) CRYPTO_strdup((str),NULL,0)
>>> - # define OPENSSL_realloc(addr,num) \
>>> --CRYPTO_realloc((char *)addr,(int)num,__FILE__,__LINE__)
>>> -+CRYPTO_realloc((char *)addr,(int)num,NULL,0)
>>> - # define OPENSSL_realloc_clean(addr,old_num,num) \
>>> --CRYPTO_realloc_clean(addr,old_num,num,__FILE__,__LINE__)
>>> -+CRYPTO_realloc_clean(addr,old_num,num,NULL,0)
>>> - # define OPENSSL_remalloc(addr,num) \
>>> --CRYPTO_remalloc((char **)addr,(int)num,__FILE__,__LINE__)
>>> -+CRYPTO_remalloc((char **)addr,(i

[edk2] Show image BMP with UEFI

2015-06-11 Thread S . Vieira

Hi everyone.

I am trying show a image with UEFI 

(i see a example in http://uefi.blogspot.com.br/)

But does not worked .

Can help me Somebody   ?!


Source code of the example:

http://sourceforge.net/p/syslibforuefi/code/HEAD/tree/trunk/Applications/


Thx S.Vieira


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [patch 3/3] [CryptoPkg] Updates some support header files and wrapper files to support openssl-1.0.2a build, and correct some openssl API usages when handling ASN.1 en/decoding.

2015-06-11 Thread Ard Biesheuvel

On 10 June 2015 at 19:47, Long, Qin  wrote:
> Lee, I totally agree with you. And ever made some tries years ago, but no 
> result. :-(
> >From OpenSSL community, there also were lots of requests about the supports 
> >to have smaller fingerprint for those embedded system (e.g. adding more 
> >MACRO to disable something). Also no positive feedback. That's why many 
> >derived projects were created, such as MatrixSSL, CyaSSL, etc. Looks OpenSSL 
> >Dev Team is still short of resource to do this.
>
> Moreover, in current EDKII-OpenSSL patch, I believe some issues we patched 
> are really openssl issue: e.g.
> Missed DECLARE_PEM_write_fp_const definition if OPENSSL_NO_FP_API was 
> used in pem.h
> Wrong memory allocation for paramid in  x509_vpm.c
> ..

Those are fixed in the OpenSSL master branch now. The change that
moves a buffer allocation from the stack to the heap is not upstream,
but may be a candidate if we propose it as a standalone patch.

> At least, there should be valuable to upstream these changes, and we will 
> have smaller patch in future. :-)
>

Agreed.

-- 
Ard.

> -Original Message-
> From: Blibbet [mailto:blib...@gmail.com]
> Sent: Saturday, June 6, 2015 3:56 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [patch 3/3] [CryptoPkg] Updates some support header files 
> and wrapper files to support openssl-1.0.2a build, and correct some openssl 
> API usages when handling ASN.1 en/decoding.
>
> Has there been any thought to upstream the libOpenSSL changes?
>
> It would be nice to be able to grab a current OpenSSL tarball and have it 
> include UEFI support, and not have to patch it each time. Having the patches 
> in truck also makes the main OpenSSL developers aware of how their changes 
> impact UEFI-centric codepaths, which they are currently blind to.
>
> The previous OpenSSL patch was apparently not acceptable to them. I hope some 
> consideration has been made for this patch.
>
> Thanks,
> Lee
>
> On 06/05/2015 09:11 AM, Long, Qin wrote:
>> Copy that. Thanks biesheuvel.
>> I will double-check the GCC building.
>>
>>
>> Best Regards & Thanks,
>> LONG, Qin
>>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Friday, June 5, 2015 5:20 PM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: Re: [edk2] [patch 3/3] [CryptoPkg] Updates some support
> header files and wrapper files to support openssl-1.0.2a build, and correct 
> some openssl API usages when handling ASN.1 en/decoding.
>>
>> Hello Long Qin,
>>
>> This patch breaks the build on GCC due to UINT8* variables being
> passed as 'const unsigned char*' parameters.
>> Please see below.
>>
>> On 5 June 2015 at 03:06, qlong  wrote:
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Long Qin 
>>> Signed-off-by: qlong 
>>> ---
>>>  CryptoPkg/Include/OpenSslSupport.h|  8 +++-
>>>  CryptoPkg/Include/memory.h| 16
> 
>>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c |  6 --
>>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c| 10 +-
>>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c  |  9 +
>>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c   | 10 +++---
>>>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c |  6 --
>>>  7 files changed, 48 insertions(+), 17 deletions(-)  create mode
>>> 100644 CryptoPkg/Include/memory.h
>>>
>> [...]
>>> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
>>> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
>>> index 4ce2b06..9ace5e6 100644
>>> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
>>> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
>>> @@ -9,7 +9,7 @@
>>>AuthenticodeVerify() will get PE/COFF Authenticode and will do
> basic check for
>>>data structure.
>>>
>>> -Copyright (c) 2011 - 2014, Intel Corporation. All rights
>>> reserved.
>>> +Copyright (c) 2011 - 2015, Intel Corporation. All rights
>>> +reserved.
>>>  This program and the accompanying materials  are licensed and made
>>> available under the terms and conditions of the BSD License  which
>>> accompanies this distribution.  The full text of the license may be
>>> found at @@ -72,6 +72,7 @@ AuthenticodeVerify (  {
>>>BOOLEAN  Status;
>>>PKCS7*Pkcs7;
>>> +  UINT8*Temp;
>>
>> CONST UINT8 *Temp;
>>
>>>CONST UINT8  *OrigAuthData;
>>>UINT8*SpcIndirectDataContent;
>>>UINT8Asn1Byte;
>>> @@ -96,7 +97,8 @@ AuthenticodeVerify (
>>>//
>>>// Retrieve & Parse PKCS#7 Data (DER encoding) from Authenticode
> Signature
>>>//
>>> -  Pkcs7 = d2i_PKCS7 (NULL, &AuthData, (int)DataSize);
>>> +  Temp  = (UINT8 *)AuthData;
>>> +  Pkcs7 = d2i_PKCS7 (NULL, &Temp, (int)DataSize);
>>>if (Pkcs7 == NULL) {
>>>  goto _Exit;
>>>}
>>
>> [...]
>>
>>> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk

[edk2] [Patch 0/2] Fix "reset -s" issue

2015-06-11 Thread Guo Dong

When using coreboot + UEFI payload, sometimes it will be waken up after issuing 
"reset -s".
This patch disable wake up when shut down.

Guo Dong (2):
  CorebootModulePkg: Get power management register addresses.
  CorebootPayloadPkg: Fix "reset -s" issue.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Guo Dong 

 CorebootModulePkg/CbSupportPei/CbSupportPei.c  |  6 -
 CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h |  4 ++-
 CorebootModulePkg/Include/Library/CbParseLib.h |  6 -
 .../Library/ResetSystemLib/ResetSystemLib.c| 31 --
 4 files changed, 42 insertions(+), 5 deletions(-)

-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 2/2] CorebootPayloadPkg: Fix "reset -s" issue.

2015-06-11 Thread Guo Dong

This patch will fix reboot issue after issuing shell command "reset -s" from 
UEFI payload.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Guo Dong 
---
 .../Library/ResetSystemLib/ResetSystemLib.c| 31 --
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c 
b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
index 77b81db..55f5609 100644
--- a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
+++ b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c
@@ -110,15 +110,42 @@ VOID
 EFIAPI
 ResetShutdown (
   VOID
   )
 {
-  AcpiPmControl (7);
+  EFI_HOB_GUID_TYPE  *GuidHob;
+  ACPI_BOARD_INFO*pAcpiBoardInfo;
+  UINTN  PmCtrlReg;
+
+  //
+  // Find the acpi board information guid hob
+  //
+  GuidHob = GetFirstGuidHob (&gUefiAcpiBoardInfoGuid);
+  ASSERT (GuidHob != NULL);
+  pAcpiBoardInfo = (ACPI_BOARD_INFO *)GET_GUID_HOB_DATA (GuidHob); 
+  
+  //
+  // GPE0_EN should be disabled to avoid any GPI waking up the system from S5
+  //
+  IoWrite16 ((UINTN)pAcpiBoardInfo->PmGpeEnBase,  0);
+
+  //
+  // Clear Power Button Status
+  //
+  IoWrite16((UINTN) pAcpiBoardInfo->PmEvtBase, BIT8);
+  
+  //
+  // Transform system into S5 sleep state
+  //
+  PmCtrlReg = (UINTN)pAcpiBoardInfo->PmCtrlRegBase; 
+  IoAndThenOr16 (PmCtrlReg, (UINT16) ~0x3c00, (UINT16) (7 << 10));
+  IoOr16 (PmCtrlReg, BIT13);
+  CpuDeadLoop ();
+
   ASSERT (FALSE);
 }
 
-
 /**
   Calling this function causes the system to enter a power state for capsule
   update.
 
   Reset update should not return, if it returns, it means the system does
-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 1/2] CorebootModulePkg: Get power management register addresses.

2015-06-11 Thread Guo Dong

This patch will get power management event register address and power 
management GPE enable register address.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Guo Dong 
---
 CorebootModulePkg/CbSupportPei/CbSupportPei.c  | 6 +-
 CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h | 4 +++-
 CorebootModulePkg/Include/Library/CbParseLib.h | 6 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/CorebootModulePkg/CbSupportPei/CbSupportPei.c 
b/CorebootModulePkg/CbSupportPei/CbSupportPei.c
index b3705fa..2fb28d4 100755
--- a/CorebootModulePkg/CbSupportPei/CbSupportPei.c
+++ b/CorebootModulePkg/CbSupportPei/CbSupportPei.c
@@ -169,10 +169,12 @@ CbPeiEntryPoint (
   SYSTEM_TABLE_INFO*   pSystemTableInfo;
   FRAME_BUFFER_INFOFbInfo;
   FRAME_BUFFER_INFO*   pFbInfo;
   ACPI_BOARD_INFO* pAcpiBoardInfo;
   UINTNPmCtrlRegBase, PmTimerRegBase, ResetRegAddress, 
ResetValue;
+  UINTNPmEvtBase;
+  UINTNPmGpeEnBase;
 
   LowMemorySize = 0;
   HighMemorySize = 0;
 
   Status = CbParseMemoryInfo (&LowMemorySize, &HighMemorySize);
@@ -353,19 +355,21 @@ CbPeiEntryPoint (
   DEBUG ((EFI_D_ERROR, "Create system table info guid hob\n"));
 
   //
   // Create guid hob for acpi board information
   //
-  Status = CbParseFadtInfo (&PmCtrlRegBase, &PmTimerRegBase, &ResetRegAddress, 
&ResetValue);
+  Status = CbParseFadtInfo (&PmCtrlRegBase, &PmTimerRegBase, &ResetRegAddress, 
&ResetValue, &PmEvtBase, &PmGpeEnBase);
   ASSERT_EFI_ERROR (Status);
   pAcpiBoardInfo = NULL;
   pAcpiBoardInfo = BuildGuidHob (&gUefiAcpiBoardInfoGuid, sizeof 
(ACPI_BOARD_INFO));
   ASSERT (pAcpiBoardInfo != NULL);
   pAcpiBoardInfo->PmCtrlRegBase = (UINT64)PmCtrlRegBase;
   pAcpiBoardInfo->PmTimerRegBase = (UINT64)PmTimerRegBase;
   pAcpiBoardInfo->ResetRegAddress = (UINT64)ResetRegAddress;
   pAcpiBoardInfo->ResetValue = (UINT8)ResetValue;
+  pAcpiBoardInfo->PmEvtBase = (UINT64)PmEvtBase;
+  pAcpiBoardInfo->PmGpeEnBase = (UINT64)PmGpeEnBase;
   DEBUG ((EFI_D_ERROR, "Create acpi board info guid hob\n"));
 
   //
   // Create guid hob for frame buffer information
   //
diff --git a/CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h 
b/CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h
index 66ebffe..609e989 100644
--- a/CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h
+++ b/CorebootModulePkg/Include/Guid/AcpiBoardInfoGuid.h
@@ -18,11 +18,13 @@
 ///
 /// Board information GUID
 ///
 extern EFI_GUID gUefiAcpiBoardInfoGuid;
 
-typedef struct {  
+typedef struct {
+  UINT64 PmEvtBase;
+  UINT64 PmGpeEnBase;
   UINT64 PmCtrlRegBase;
   UINT64 PmTimerRegBase;
   UINT64 ResetRegAddress;
   UINT8  ResetValue;  
 } ACPI_BOARD_INFO;
diff --git a/CorebootModulePkg/Include/Library/CbParseLib.h 
b/CorebootModulePkg/Include/Library/CbParseLib.h
index 36727d3..170375b 100644
--- a/CorebootModulePkg/Include/Library/CbParseLib.h
+++ b/CorebootModulePkg/Include/Library/CbParseLib.h
@@ -89,21 +89,25 @@ CbParseSmbiosTable (
 
   @param  pPmCtrlReg Pointer to the address of power management 
control register
   @param  pPmTimerRegPointer to the address of power management timer 
register
   @param  pResetReg  Pointer to the address of system reset register
   @param  pResetValuePointer to the value to be writen to the system 
reset register
+  @param  pPmEvtReg  Pointer to the address of power management event 
register
+  @param  pPmGpeEnRegPointer to the address of power management GPE 
enable register
 
   @retval RETURN_SUCCESS Successfully find out all the required fadt 
information.
   @retval RETURN_NOT_FOUND   Failed to find the fadt table.
 
 **/
 RETURN_STATUS
 CbParseFadtInfo (
   IN UINTN* pPmCtrlReg,
   IN UINTN* pPmTimerReg,
   IN UINTN* pResetReg,
-  IN UINTN* pResetValue
+  IN UINTN* pResetValue,
+  IN UINTN* pPmEvtReg,
+  IN UINTN* pPmGpeEnReg
   );
   
 /**
   Find the serial port information
 
-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL

2015-06-11 Thread Blibbet

> BSD is a GPL compatible licence.
> GPL is NOT a BSD compatible licence.

Where is the requirement that all OEMs must only include BSD code in
their firmware? Why not let Puri.sm or Novena have a downstream UEFI
firmware volume that is GPL, will the world end or something? Today,
there is some non-BSD code needed to boot Linux on UEFI. Linux OSVs
probably don't have the same fear of GPL that closed-source OS vendors
do. You're free to ignore that code and focus on the license subset you
prefer.

>> What about a Tiano way to distribute [L]GPL code, safely separate from
>> main BSD branch, like FAT driver is dealt with, so GPL-friendly
>> OSVs/ISVs/OEMs -- everyone but Microsoft? :-) -- can safely use GPL
>> code? Perhaps other non-BSD, OSI-approved FOSS licensed, and no others?
>>
>
> As you point out we solve issues with licensing by splitting git repos
> and having separate projects. That is probably a separate conversation
> from what goes in the edk2 project. 

I thought the conversation was to deal with this current code
contribution, not just focus on EDK2 subproject.

What about using TianoCore's EDK2share for non-BSD projects? That code
isn't bundled into UDK releases. If contributor can relicense to BSD
great, but if not, dropping code is rude, a non-BSD friendly area
outside main EDK2 project, somewhere on Tiano, would be better than
dropping the code, I'd think.

>> Users of this code will also have to face their main hurdle, getting
>> Microsoft to bless their EFI code, and their current restrictions
>> already hinder any GPL code, which gets worse with each Windows release.
>
> I don’t really understand that statement. Microsoft does not “bless”
firmware code.
> The platform vendor can have any firmware implementation they want.

I was referring to 'pre-OS' ISVs. For firmware that doesn't come built
by OEMs/ODMs/IBVs, Microsoft does bless that firmware code, and UEFI
Forum does nothing to help, and Microsoft applies it's own biases and
uses it's position to compete with vendors. I'd at least hope that an
additional techincal and policy restrictions that Microsoft adds to code
would be set by UEFI Forum and not by Microsoft. The Microsoft CA really
is an ugly pink elephant for UEFI Forum, and it helps let them continue
to be a bully in the Intel playground (except in the Apple corner).

And for this case of a smartcard driver, I presume the above Microsoft
comment won't apply since a SC driver has to be (?) bundled into main
FV, not a separate .efi that Microsoft would need to sign.

http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/dn609883.aspx#reviewprocess
http://techrights.org/2012/06/29/traps-behind-uefi/
http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
http://www.itworld.com/article/2737487/it-management/microsoft-washes-its-hands-of-uefi-linux-mess.html

Thanks,
Lee


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] SCT build error

2015-06-11 Thread Scott Duplichan

Meenakshi Aggarwal [mailto:meenakshi.aggar...@freescale.com] wrote:

]Sent: Thursday, June 11, 2015 06:31 AM
]To: edk2-devel@lists.sourceforge.net
]Subject: [edk2] SCT build error
]
]Hi All,
]
]
]I am trying to build SCT and facing following error:
]
]“: error 7000: Failed to start command
]C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe 
/no logo tbuild 
][c:\test\Build\UefiSct\DEBUG_VS2013x86\X64\EdkCompatibilityPkg\Foundation\Efi\Protocol\EfiProtocolLib]
]”
]
]Any idea will be of great help.
]
]
]
]Thanks & regards
]Meenakshi Aggarwal

EDK2 does not use the usual environment variable method of locating
the Visual studio installation. Instead, it uses hard-coded paths
that are suitable for some machines and not suitable for others.
Build.exe is trying to launch:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\nmake.exe
Does this file exist on your computer?

Thanks,
Scott



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] SCT build error

2015-06-11 Thread Meenakshi Aggarwal

Hi All,


I am trying to build SCT and facing following error:


": error 7000: Failed to start command

C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe 
/no logo tbuild 
[c:\test\Build\UefiSct\DEBUG_VS2013x86\X64\EdkCompatibilityPkg\Foundation\Efi\Protocol\EfiProtocolLib]
"

Any idea will be of great help.



Thanks & regards
Meenakshi Aggarwal

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 0/3] Add Sec Platform Information2 PPI

2015-06-11 Thread Jeff Fan

PI 1.4 introduced Sec Platform Inforamtion2 PPI to hand-off CPU healthy
information from SEC to PEI/DXE phase.
This serial patches will:
A. Add Sec Platform Inforamtion2 PPI in MdePkg.
B. Include PiCis.h in SecPlatformInformation.h, This file references
   EFI_PEI_SERVICES but it will be used by CPU MP DXE driver to get CPU BIST
   information. And PiCis.h could pass build.
C. Update UefiCpuPkg/CpuDxe drive to get CPUs' BIST information by Guided HOB.

Jeff Fan (3):
  MdePkg: Add Sec Platform Information2 PPI
  MdePkg: Include PiCis.h in SecPlatformInformation.h
  UefiCpuPkg/CpuDxe: Get CPU BIST information from Guided HOB

 MdePkg/Include/Ppi/SecPlatformInformation.h  |  4 +-
 MdePkg/Include/Ppi/SecPlatformInformation2.h | 85 ++
 MdePkg/MdePkg.dec|  3 +
 UefiCpuPkg/CpuDxe/CpuDxe.inf |  8 ++-
 UefiCpuPkg/CpuDxe/CpuMp.c| 90 +++-
 UefiCpuPkg/CpuDxe/CpuMp.h|  6 +-
 6 files changed, 192 insertions(+), 4 deletions(-)
 create mode 100644 MdePkg/Include/Ppi/SecPlatformInformation2.h

-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 1/3] MdePkg: Add Sec Platform Information2 PPI

2015-06-11 Thread Jeff Fan

This is a new PPI introduced in PI 1.4 to pass multiple CPU information from
SEC phase to PEI/DXE phases.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
CC: Liming Gao 
---
 MdePkg/Include/Ppi/SecPlatformInformation2.h | 85 
 MdePkg/MdePkg.dec|  3 +
 2 files changed, 88 insertions(+)
 create mode 100644 MdePkg/Include/Ppi/SecPlatformInformation2.h

diff --git a/MdePkg/Include/Ppi/SecPlatformInformation2.h 
b/MdePkg/Include/Ppi/SecPlatformInformation2.h
new file mode 100644
index 000..7596333
--- /dev/null
+++ b/MdePkg/Include/Ppi/SecPlatformInformation2.h
@@ -0,0 +1,85 @@
+/** @file
+  This file declares Sec Platform Information2 PPI.
+
+  This service is the primary handoff state into the PEI Foundation.
+  This service abstracts platform-specific information for many CPU's.
+
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+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.
+
+  @par Revision Reference:
+  This PPI is defined in PI Version 1.4.
+
+**/
+
+#ifndef __SEC_PLATFORM_INFORMATION2_PPI_H__
+#define __SEC_PLATFORM_INFORMATION2_PPI_H__
+
+#include 
+
+#define EFI_SEC_PLATFORM_INFORMATION2_GUID \
+  { \
+0x9e9f374b, 0x8f16, 0x4230, {0x98, 0x24, 0x58, 0x46, 0xee, 0x76, 0x6a, 
0x97 } \
+  }
+
+typedef struct _EFI_SEC_PLATFORM_INFORMATION2_PPI 
EFI_SEC_PLATFORM_INFORMATION2_PPI;
+
+///
+/// EFI_SEC_PLATFORM_INFORMATION_CPU.
+///
+typedef struct {
+  UINT32   CpuLocation;
+  EFI_SEC_PLATFORM_INFORMATION_RECORD  InfoRecord;
+} EFI_SEC_PLATFORM_INFORMATION_CPU;
+
+///
+/// EFI_SEC_PLATFORM_INFORMATION_RECORD2.
+///
+typedef struct {
+  ///
+  /// The CPU location would be the local APIC ID
+  ///
+  UINT32   NumberOfCpus;
+  EFI_SEC_PLATFORM_INFORMATION_CPU CpuInstance[1];
+} EFI_SEC_PLATFORM_INFORMATION_RECORD2;
+
+/**
+  This interface conveys state information out of the Security (SEC) phase 
into PEI.
+
+  This service is published by the SEC phase.
+
+  @param  PeiServicesThe pointer to the PEI Services Table.
+  @param  StructureSize  The pointer to the variable describing 
size of the input buffer.
+  @param  PlatformInformationRecord2 The pointer to the 
EFI_SEC_PLATFORM_INFORMATION_RECORD2.
+
+  @retval EFI_SUCCESSThe data was successfully returned.
+  @retval EFI_BUFFER_TOO_SMALL   The buffer was too small. The current 
buffer size needed to
+ hold the record is returned in 
StructureSize.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_SEC_PLATFORM_INFORMATION2)(
+  IN CONST  EFI_PEI_SERVICES **PeiServices,
+  IN OUTUINT64   *StructureSize,
+  OUT   EFI_SEC_PLATFORM_INFORMATION_RECORD2 *PlatformInformationRecord2
+);
+
+///
+/// This service abstracts platform-specific information for many CPU's.
+/// It is the multi-processor equivalent of PlatformInformation for
+/// implementations that synchronize all CPU's in the SEC phase.
+///
+struct _EFI_SEC_PLATFORM_INFORMATION2_PPI {
+  EFI_SEC_PLATFORM_INFORMATION2  PlatformInformation2;
+};
+
+extern EFI_GUID gEfiSecPlatformInformation2PpiGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 29d7e11..677a82f 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -855,6 +855,9 @@
   ## Include/Ppi/BlockIo2.h
   gEfiPeiVirtualBlockIo2PpiGuid = { 0x26cc0fad, 0xbeb3, 0x478a, { 0x91, 
0xb2, 0xc, 0x18, 0x8f, 0x72, 0x61, 0x98 }}
 
+  ## Include/Ppi/SecPlatformInformation.h
+  gEfiSecPlatformInformation2PpiGuid = { 0x9e9f374b, 0x8f16, 0x4230, {0x98, 
0x24, 0x58, 0x46, 0xee, 0x76, 0x6a, 0x97 } }
+
 [Protocols]
   ## Include/Protocol/Pcd.h
   gPcdProtocolGuid   = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2, 0x90, 
0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL

2015-06-11 Thread Ludovic Rousseau

Hello,

2015-06-11 3:59 GMT+02:00 El-Haj-Mahmoud, Samer :
> I agree that the license is an issue. Having GPL or LGPL code in EDK2 risks 
> implementations that use this code. Even if an implementation choses not to 
> carry this specific driver in binary format, just having the GPL source in 
> the same tree is a risk. What if developers copy fragments of code from the 
> GPL licensed driver and use in another module in the tree that is BSD 
> licensed. Developeers may not pay attention to the license and its 
> implications since EDK2 so far has used only BSD or BSD-like license.

I am not surprise to get some opposition because of the license.
Note that the license is LGPL (Lesser GPL) version 2.1 and not Lesser
GPL version 3 or GPL (I think GPL license would not be accepted in
edk2).

It is a political question. Should edk2 accept non BSD licenses?
Maybe such code can be stored in a "non-BSD/" (or another more
explicit name) sub hierarchy in edk2 to clearly indicates the license
difference?

I will help the edk2 project as much as I can with this integration.

Regards,

> -Original Message-
> From: Tian, Feng [feng.t...@intel.com]
> Received: Wednesday, 10 Jun 2015, 9:52PM
> To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
> Subject: Re: [edk2] [PATCH 0/4] Add an implementation of 
> EFI_SMART_CARD_READER_PROTOCOL
>
> Ludovic,
>
> The license issue is the biggest concern. EDKII project is BSD license, but 
> your proposed patch 1 is using LGPL license which may corrupt EDKII project.
>
> Thanks
> Feng
>
> -Original Message-
> From: Ludovic Rousseau [mailto:ludovic.rouss...@gmail.com]
> Sent: Thursday, June 11, 2015 02:28
> To: edk2-devel@lists.sourceforge.net
> Cc: Ludovic Rousseau
> Subject: [edk2] [PATCH 0/4] Add an implementation of 
> EFI_SMART_CARD_READER_PROTOCOL
>
> This patch serie provides an implementation for the 
> EFI_SMART_CARD_READER_PROTOCOL added in UEFI version 2.5.
>
> It is a port of my CCID driver from Unix to UEFI. Only part of the code has 
> been specifically written for UEFI and edk2. Only this part of the code 
> follows the coding rules. The idea os to keep most of the code common to edk2 
> and my original CCID driver so code is easy to backport from one project to 
> the other.
>
> patch 1: are files from the libccid project [1], GNU LGLP v2.1 patch 2: are 
> files from the pcsc-lite project [2], TianoCore Contribution Agreement 1.0 
> patch 3: are files specifically written for edk2, TianoCore Contribution 
> Agreement 1.0 patch 4: edit MdeModulePkg/MdeModulePkg.dsc to add the driver, 
> TianoCore Contribution Agreement 1.0
>
> The code has been tested on a Dell E6430 with an internal Broadcom smart card 
> reader and also different external USB smart card readers.
>
> [1] https://pcsclite.alioth.debian.org/ccid.html
> [2] https://pcsclite.alioth.debian.org/pcsclite.html
>
>
> Ludovic Rousseau (4):
>   MdeModulePkg/SmartCardReader: Add files from the libccid project
>   MdeModulePkg/SmartCardReader: Add files from pcsc-lite project
>   MdeModulePkg/SmartCardReader: Implement Smart Card Reader Protocol
>   MdeModulePkg: add SmartCardReader.inf
>
>  MdeModulePkg/Library/SmartCardReader/CcidDriver.c  |  819 +++  
> MdeModulePkg/Library/SmartCardReader/CcidDriver.h  |  154 ++
>  .../Library/SmartCardReader/ComponentName.c|  198 ++
>  .../Library/SmartCardReader/ComponentName.h|  128 ++
>  .../Library/SmartCardReader/DriverBinding.h|  211 ++
>  MdeModulePkg/Library/SmartCardReader/License.txt   |   87 +
>  .../Library/SmartCardReader/SmartCardReader.inf|   97 +
>  .../Library/SmartCardReader/SmartCardReader_impl.c |  453 
>  .../Library/SmartCardReader/SmartCardReader_impl.h |   94 +
>  MdeModulePkg/Library/SmartCardReader/config.h  |   64 +
>  MdeModulePkg/Library/SmartCardReader/debug.c   |   62 +
>  MdeModulePkg/Library/SmartCardReader/debuglog.h|   81 +
>  MdeModulePkg/Library/SmartCardReader/ifdhandler.h  |  825 +++
>  .../Library/SmartCardReader/libccid/ccid.c |  659 ++
>  .../Library/SmartCardReader/libccid/ccid.h |  340 +++
>  .../SmartCardReader/libccid/ccid_ifdhandler.h  |   63 +
>  .../Library/SmartCardReader/libccid/ccid_uefi.c|  470 
>  .../Library/SmartCardReader/libccid/ccid_uefi.h|   46 +
>  .../Library/SmartCardReader/libccid/commands.c | 2294 
> 
>  .../Library/SmartCardReader/libccid/commands.h |   64 +
>  .../Library/SmartCardReader/libccid/debug.c|  157 ++
>  .../Library/SmartCardReader/libccid/debug.h|  100 +
>  .../Library/SmartCardReader/libccid/defs.h |  126 ++
>  .../Library/SmartCardReader/libccid/ifdhandler.c   | 2265 +++
>  .../Library/SmartCardReader/libccid/openct/LICENSE |   28 +
>  .../Library/SmartCardReader/libccid/openct/README  |7 +
>  .../SmartCardReader/libccid/openct/buffer.c|   73 +
>  .../SmartCardReader/libccid/openct/buffer.h

[edk2] [Patch 2/3] MdePkg: Include PiCis.h in SecPlatformInformation.h

2015-06-11 Thread Jeff Fan

This file references EFI_PEI_SERVICES but it will be used by CPU MP DXE driver
to get CPU BIST information. And PiCis.h could pass build.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
CC: Liming Gao 
---
 MdePkg/Include/Ppi/SecPlatformInformation.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Ppi/SecPlatformInformation.h 
b/MdePkg/Include/Ppi/SecPlatformInformation.h
index a6a62f4..b43499c 100644
--- a/MdePkg/Include/Ppi/SecPlatformInformation.h
+++ b/MdePkg/Include/Ppi/SecPlatformInformation.h
@@ -6,7 +6,7 @@
   environment and also encapsulates knowledge of at least the 
   location of the Boot Firmware Volume (BFV).
 
-Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
 This program and the accompanying materials are licensed and made available 
under 
 the terms and conditions of the BSD License that accompanies this 
distribution.  
 The full text of the license may be found at
@@ -23,6 +23,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #ifndef __SEC_PLATFORM_INFORMATION_PPI_H__
 #define __SEC_PLATFORM_INFORMATION_PPI_H__
 
+#include 
+
 #define EFI_SEC_PLATFORM_INFORMATION_GUID \
   { \
 0x6f8c2b35, 0xfef4, 0x448d, {0x82, 0x56, 0xe1, 0x1b, 0x19, 0xd6, 0x10, 
0x77 } \
-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [Patch 3/3] UefiCpuPkg/CpuDxe: Get CPU BIST information from Guided HOB

2015-06-11 Thread Jeff Fan

Get CPU BIST information from gEfiSecPlatformInformation2PpiGuid or
gEfiSecPlatformInformationPpiGuid Guided HOB and update the CPU healthy status
for CPU MP Service.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
CC: Feng Tian 
---
 UefiCpuPkg/CpuDxe/CpuDxe.inf |  8 +++-
 UefiCpuPkg/CpuDxe/CpuMp.c| 90 +++-
 UefiCpuPkg/CpuDxe/CpuMp.h|  6 ++-
 3 files changed, 101 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
index 61bc55a..a251922 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Simple CPU driver installs CPU Architecture Protocol.
 #
-#  Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -43,6 +43,8 @@
   CpuExceptionHandlerLib
   TimerLib
   SynchronizationLib
+  HobLib
+  ReportStatusCodeLib
 
 [Sources]
   ApStartup.c
@@ -77,6 +79,10 @@
   gIdleLoopEventGuid## CONSUMES   ## Event
   gEfiVectorHandoffTableGuid## SOMETIMES_CONSUMES ## 
SystemTable
 
+[Ppis]
+  gEfiSecPlatformInformation2PpiGuid## UNDEFINED # HOB
+  gEfiSecPlatformInformationPpiGuid ## UNDEFINED # HOB
+
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize ## CONSUMES
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index fa0ef37..41bf504 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1,7 +1,7 @@
 /** @file
   CPU DXE Module.
 
-  Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2015, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -1521,6 +1521,89 @@ InitMpSystemData (
 }
 
 /**
+  Collects BIST data from HOB.
+
+  This function collects BIST data from HOB built from Sec Platform Information
+  PPI or SEC Platform Information2 PPI.
+
+**/
+VOID
+CollectBistDataFromHob (
+  VOID
+  )
+{
+  EFI_HOB_GUID_TYPE *GuidHob;
+  EFI_SEC_PLATFORM_INFORMATION_RECORD2  *SecPlatformInformation2;
+  EFI_SEC_PLATFORM_INFORMATION_RECORD   *SecPlatformInformation;
+  UINTN NumberOfData;
+  EFI_SEC_PLATFORM_INFORMATION_CPU  *CpuInstance;
+  EFI_SEC_PLATFORM_INFORMATION_CPU  BspCpuInstance;
+  UINTN ProcessorNumber;
+  UINT32InitialLocalApicId;
+  CPU_DATA_BLOCK*CpuData;
+
+  SecPlatformInformation2 = NULL;
+  SecPlatformInformation  = NULL;
+
+  //
+  // Get gEfiSecPlatformInformation2PpiGuid Guided HOB firstly
+  //
+  GuidHob = GetFirstGuidHob (&gEfiSecPlatformInformation2PpiGuid);
+  if (GuidHob != NULL) {
+//
+// Sec Platform Information2 PPI includes BSP/APs' BIST information
+//
+SecPlatformInformation2 = GET_GUID_HOB_DATA (GuidHob);
+NumberOfData = SecPlatformInformation2->NumberOfCpus;
+CpuInstance  = SecPlatformInformation2->CpuInstance;
+  } else {
+//
+// Otherwise, get gEfiSecPlatformInformationPpiGuid Guided HOB
+//
+GuidHob = GetFirstGuidHob (&gEfiSecPlatformInformationPpiGuid);
+if (GuidHob != NULL) {
+  SecPlatformInformation = GET_GUID_HOB_DATA (GuidHob);
+  NumberOfData = 1;
+  //
+  // SEC Platform Information only includes BSP's BIST information
+  // does not have BSP's APIC ID
+  //
+  BspCpuInstance.CpuLocation = GetApicId ();
+  BspCpuInstance.InfoRecord.IA32HealthFlags.Uint32  = 
SecPlatformInformation->IA32HealthFlags.Uint32;
+  CpuInstance = &BspCpuInstance;
+} else {
+  DEBUG ((EFI_D_INFO, "Does not find any HOB stored CPU BIST 
information!\n"));
+  //
+  // Does not find any HOB stored BIST information
+  //
+  return;
+}
+  }
+
+  while (NumberOfData--) {
+for (ProcessorNumber = 0; ProcessorNumber < 
mMpSystemData.NumberOfProcessors; ProcessorNumber++) {
+  CpuData = &mMpSystemData.CpuDatas[ProcessorNumber];
+  InitialLocalApicId = (UINT32) CpuData->Info.ProcessorId;
+  if (InitialLocalApicId == CpuInstance[NumberOfData].CpuLocation) {
+//
+// Update CPU health status for MP Services Protocol according to BIST 
data.
+//
+if (CpuInstance[NumberOfData].InfoRecord.IA32HealthFlags.Uint32 != 0) {
+  CpuData->Info.StatusFlag &= ~PROCESSOR_HEALTH_STATUS_BIT;

[edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

2015-06-11 Thread Yingke Liu

This patch also removed a warning message.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py |  1 -
 BaseTools/Source/Python/GenFds/Fv.py   | 21 +
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 996b654..0e7482a 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2297,7 +2297,6 @@ class ModuleAutoGen(AutoGen):
 if Module.MetaFile == self.MetaFile:
 continue
 if Module.Name == self.Name:
-EdkLogger.warn('build', 'Modules have same BaseName:\n  %s\n  
%s' % (Module.MetaFile, self.MetaFile))
 if uuid.UUID(Module.Guid) == uuid.UUID(self.Guid):
 EdkLogger.error("build", FILE_DUPLICATED, 'Modules have 
same BaseName and FILE_GUID:\n'
 '  %s\n  %s' % (Module.MetaFile, 
self.MetaFile))
diff --git a/BaseTools/Source/Python/GenFds/Fv.py 
b/BaseTools/Source/Python/GenFds/Fv.py
index 03a7426..8f341d3 100644
--- a/BaseTools/Source/Python/GenFds/Fv.py
+++ b/BaseTools/Source/Python/GenFds/Fv.py
@@ -30,6 +30,7 @@ from Common.LongFilePathSupport import CopyLongFilePath
 from Common.LongFilePathSupport import OpenLongFilePath as open
 
 T_CHAR_LF = '\n'
+FV_UI_EXT_ENTY_GUID = 'A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C'
 
 ## generate FV
 #
@@ -295,6 +296,26 @@ class FV (FvClassObject):
 if self.FvNameGuid <> None and self.FvNameGuid <> '':
 TotalSize = 16 + 4
 Buffer = ''
+#
+# Create EXT entry for FV UI name
+# This GUID is used: A67DF1FA-8DE8-4E98-AF09-4BDF2EFFBC7C
+#
+FvUiLen = len(self.UiFvName)
+TotalSize += (FvUiLen + 16 + 4)
+Guid = FV_UI_EXT_ENTY_GUID.split('-')
+#
+# Layout:
+#   EFI_FIRMWARE_VOLUME_EXT_ENTRY : size 4
+#   GUID  : size 16
+#   FV UI name
+#
+Buffer += (pack('HH', (FvUiLen + 16 + 4), 0x0002)
+   + pack('=LHH', int(Guid[0], 16), int(Guid[1], 
16), int(Guid[2], 16),
+  int(Guid[3][-4:-2], 16), int(Guid[3][-2:], 16), 
int(Guid[4][-12:-10], 16),
+  int(Guid[4][-10:-8], 16), int(Guid[4][-8:-6], 
16), int(Guid[4][-6:-4], 16),
+  int(Guid[4][-4:-2], 16), int(Guid[4][-2:], 16))
+   + self.UiFvName)
+
 for Index in range (0, len(self.FvExtEntryType)):
 if self.FvExtEntryType[Index] == 'FILE':
 # check if the path is absolute or relative
-- 
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] USB question: how change to a different alternate setting of an interface?

2015-06-11 Thread Eric Wittmayer

Feng,
Thanks for your quick response.  I'll turn on the debug printing tomorrow and 
let you know what I get. 

Eric



> On Jun 11, 2015, at 12:26 AM, Tian, Feng  wrote:
> 
> Hi, Eric
> 
> It should be enough to get alternative setting through these two steps you 
> did.
> 
> Could you let me know whether you saw this debug message " UsbSelectSetting: 
> setting %d selected for interface %d " got printed ? and which values are in 
> the printed message?
> 
> Thanks
> Feng
> 
> -Original Message-
> From: Eric Wittmayer [mailto:e...@frescologic.com] 
> Sent: Thursday, June 11, 2015 14:20
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] USB question: how change to a different alternate setting of 
> an interface?
> 
> Hello all,
> I'm new to the list and to edk2/uefi.  I'm working on a USB device driver for 
> a device that has interrupt endpoints declared on interface alternate #1.  So 
> the default interface descriptor has zero endpoints and the alternate 1 
> interface descriptor has 2 endpoints.  I am able to use
> UsbIo->UsbControlTransfer to send a Set Interface command to the device 
> UsbIo->and
> I can see on my usb analyzer that it does get sent. 
> After that I call UsbIo->UsbGetInterfaceDescriptor again to get what I 
> expected was the interface descriptor for alternate #1 but I get back the 
> same descriptor as before I set the interface.  
> Looking through the code I can see in the XhciDxe code for XhcControlTransfer 
> that it handles updating the xhci controllers representation of the endpoints 
> when it sees the select interface command but I'm not sure if there is 
> something else I need to do in order to update the data returned by 
> UsbGetInterfaceDescriptor.
> 
> How do I get the correct descriptors for the newly active alternate setting?
> Will they have a different UsbIo protocol handle and if so how do I find it?
> 
> Thanks for any help.
> Eric
> 
> 
> 
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdeModulePkg Variable: Move VariableLock install into SmmVariableReady().

2015-06-11 Thread Yao, Jiewen

Looks good.

Reviewed-by: Yao, Jiewen 

-Original Message-
From: Zeng, Star 
Sent: Wednesday, June 10, 2015 5:23 PM
To: edk2-devel@lists.sourceforge.net
Cc: Yao, Jiewen; Ni, Ruiyu
Subject: [PATCH 2/2] MdeModulePkg Variable: Move VariableLock install into 
SmmVariableReady().

VariableLock in VariableSmmRuntimeDxe.c is installed in EntryPoint now.
It works based on SMM variable handler by SMM communication with payload 
buffer. But the payload buffer and SMM variable handler will be not ready in 
EntryPoint before SmmVariableReady() call back.

VarCheck in VariableSmmRuntimeDxe.c has the same issue, so move VarCheck 
install into SmmVariableReady() also.

Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 .../Variable/RuntimeDxe/VariableSmmRuntimeDxe.c| 41 +++---
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
index 0e0a7c5..30fb5df 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -935,6 +935,26 @@ SmmVariableReady (
   NULL
   );
   ASSERT_EFI_ERROR (Status);
+
+  mVariableLock.RequestToLock = VariableLockRequestToLock;  Status = 
+ gBS->InstallMultipleProtocolInterfaces (
+  &mHandle,
+  &gEdkiiVariableLockProtocolGuid,
+  &mVariableLock,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
+
+  mVarCheck.RegisterSetVariableCheckHandler = 
+ VarCheckRegisterSetVariableCheckHandler;
+  mVarCheck.VariablePropertySet = VarCheckVariablePropertySet;  
+ mVarCheck.VariablePropertyGet = VarCheckVariablePropertyGet;  Status = 
+ gBS->InstallMultipleProtocolInterfaces (
+  &mHandle,
+  &gEdkiiVarCheckProtocolGuid,
+  &mVarCheck,
+  NULL
+  );
+  ASSERT_EFI_ERROR (Status);
 }
 
 
@@ -992,7 +1012,6 @@ VariableSmmRuntimeInitialize (
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
-  EFI_STATUSStatus;
   VOID  *SmmVariableRegistration;
   VOID  *SmmVariableWriteRegistration;
   EFI_EVENT OnReadyToBootEvent;
@@ -1001,26 +1020,6 @@ VariableSmmRuntimeInitialize (
 
   EfiInitializeLock (&mVariableServicesLock, TPL_NOTIFY);
 
-  mVariableLock.RequestToLock = VariableLockRequestToLock;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &mHandle,
-  &gEdkiiVariableLockProtocolGuid,
-  &mVariableLock,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
-
-  mVarCheck.RegisterSetVariableCheckHandler = 
VarCheckRegisterSetVariableCheckHandler;
-  mVarCheck.VariablePropertySet = VarCheckVariablePropertySet;
-  mVarCheck.VariablePropertyGet = VarCheckVariablePropertyGet;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &mHandle,
-  &gEdkiiVarCheckProtocolGuid,
-  &mVarCheck,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
-
   //
   // Smm variable service is ready
   //
--
1.9.5.msysgit.0


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] USB question: how change to a different alternate setting of an interface?

2015-06-11 Thread Tian, Feng

Hi, Eric

It should be enough to get alternative setting through these two steps you did.

Could you let me know whether you saw this debug message " UsbSelectSetting: 
setting %d selected for interface %d " got printed ? and which values are in 
the printed message?

Thanks
Feng

-Original Message-
From: Eric Wittmayer [mailto:e...@frescologic.com] 
Sent: Thursday, June 11, 2015 14:20
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] USB question: how change to a different alternate setting of an 
interface?

Hello all,
I'm new to the list and to edk2/uefi.  I'm working on a USB device driver for a 
device that has interrupt endpoints declared on interface alternate #1.  So the 
default interface descriptor has zero endpoints and the alternate 1 interface 
descriptor has 2 endpoints.  I am able to use
UsbIo->UsbControlTransfer to send a Set Interface command to the device 
UsbIo->and
I can see on my usb analyzer that it does get sent. 
After that I call UsbIo->UsbGetInterfaceDescriptor again to get what I expected 
was the interface descriptor for alternate #1 but I get back the same 
descriptor as before I set the interface.  
Looking through the code I can see in the XhciDxe code for XhcControlTransfer 
that it handles updating the xhci controllers representation of the endpoints 
when it sees the select interface command but I'm not sure if there is 
something else I need to do in order to update the data returned by 
UsbGetInterfaceDescriptor.

How do I get the correct descriptors for the newly active alternate setting?
Will they have a different UsbIo protocol handle and if so how do I find it?

Thanks for any help.
Eric



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] SCT build error

[edk2] [PATCH] MdePkg: Refine the comments for FileHandleIsDirectory.

[edk2] FV FvName in FV Ext Entry

[edk2] Build Tool Changes

Re: [edk2] [Patch] PcAtChipsetPkg: Fix PCD expression build failure

[edk2] [Patch] PcAtChipsetPkg: Fix PCD expression build failure

[edk2] [Basetool][Upt][patch]Update help message of UPT

Re: [edk2] [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Re: [edk2] Show image BMP with UEFI

Re: [edk2] Show image BMP with UEFI

Re: [edk2] [patch 1/3] [CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the patch file for openssl-1.0.2a.

Re: [edk2] "cond" vs. ?

Re: [edk2] [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug

Re: [edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Re: [edk2] [patch 1/3] [CryptoPkg] Remove the old patch file for openssl-0.9.8zf build, and add the patch file for openssl-1.0.2a.

[edk2] Show image BMP with UEFI

Re: [edk2] [patch 3/3] [CryptoPkg] Updates some support header files and wrapper files to support openssl-1.0.2a build, and correct some openssl API usages when handling ASN.1 en/decoding.

[edk2] [Patch 0/2] Fix "reset -s" issue

[edk2] [Patch 2/2] CorebootPayloadPkg: Fix "reset -s" issue.

[edk2] [Patch 1/2] CorebootModulePkg: Get power management register addresses.

Re: [edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL

Re: [edk2] SCT build error

[edk2] SCT build error

[edk2] [Patch 0/3] Add Sec Platform Information2 PPI

[edk2] [Patch 1/3] MdePkg: Add Sec Platform Information2 PPI

Re: [edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL

[edk2] [Patch 2/3] MdePkg: Include PiCis.h in SecPlatformInformation.h

[edk2] [Patch 3/3] UefiCpuPkg/CpuDxe: Get CPU BIST information from Guided HOB

[edk2] [Patch] BaseTools: Generate a FV EXT entry for FV UI name.

Re: [edk2] USB question: how change to a different alternate setting of an interface?

Re: [edk2] [PATCH 2/2] MdeModulePkg Variable: Move VariableLock install into SmmVariableReady().

Re: [edk2] USB question: how change to a different alternate setting of an interface?

34 matches

Site Navigation

Mail list logo

Footer information