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

[Eric Wittmayer]

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 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] [patch] MdeModulePkg/NvmExpressDxe: Add SecurityStorageProtocl support

[Tian Feng]

Produce this protocol for each namespace at NVMe controller.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tian Feng 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c|  68 -
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|  39 ++-
 .../Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c  | 326 +
 .../Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.h  | 160 +-
 .../Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf|   1 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c |   8 +-
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h |  32 +-
 .../Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c |  36 ++-
 8 files changed, 628 insertions(+), 42 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index d107d96..9938bf4 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -155,6 +155,12 @@ EnumerateNvmeDevNamespace (
 Device->BlockIo.FlushBlocks  = NvmeBlockIoFlushBlocks;
 
 //
+// Create StorageSecurityProtocol Instance
+//
+Device->StorageSecurity.ReceiveData = NvmeStorageSecurityReceiveData;
+Device->StorageSecurity.SendData= NvmeStorageSecuritySendData;
+
+//
 // Create DiskInfo Protocol instance
 //
 InitializeDiskInfo (Device);
@@ -211,6 +217,32 @@ EnumerateNvmeDevNamespace (
 if(EFI_ERROR(Status)) {
   goto Exit;
 }
+
+//
+// Check if the NVMe controller supports the Security Send and Security 
Receive commands
+//
+if ((Private->ControllerData->Oacs & SECURITY_SEND_RECEIVE_SUPPORTED) != 
0) {
+  Status = gBS->InstallProtocolInterface (
+  &Device->DeviceHandle,
+  &gEfiStorageSecurityCommandProtocolGuid,
+  EFI_NATIVE_INTERFACE,
+  &Device->StorageSecurity
+  );
+  if(EFI_ERROR(Status)) {
+gBS->UninstallMultipleProtocolInterfaces (
+   &Device->DeviceHandle,
+   &gEfiDevicePathProtocolGuid,
+   Device->DevicePath,
+   &gEfiBlockIoProtocolGuid,
+   &Device->BlockIo,
+   &gEfiDiskInfoProtocolGuid,
+   &Device->DiskInfo,
+   NULL
+   );
+goto Exit;
+  }
+}
+
 gBS->OpenProtocol (
Private->ControllerHandle,
&gEfiNvmExpressPassThruProtocolGuid,
@@ -339,6 +371,7 @@ UnregisterNvmeNamespace (
   EFI_BLOCK_IO_PROTOCOL*BlockIo;
   NVME_DEVICE_PRIVATE_DATA *Device;
   NVME_CONTROLLER_PRIVATE_DATA *Private;
+  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL*StorageSecurity;
 
   BlockIo = NULL;
 
@@ -394,6 +427,37 @@ UnregisterNvmeNamespace (
 return Status;
   }
 
+  //
+  // If Storage Security Command Protocol is installed, then uninstall this 
protocol.
+  //
+  Status = gBS->OpenProtocol (
+  Handle,
+  &gEfiStorageSecurityCommandProtocolGuid,
+  (VOID **) &StorageSecurity,
+  This->DriverBindingHandle,
+  Controller,
+  EFI_OPEN_PROTOCOL_GET_PROTOCOL
+  );
+
+  if (!EFI_ERROR (Status)) {
+Status = gBS->UninstallProtocolInterface (
+Handle,
+&gEfiStorageSecurityCommandProtocolGuid,
+&Device->StorageSecurity
+);
+if (EFI_ERROR (Status)) {
+  gBS->OpenProtocol (
+Controller,
+&gEfiNvmExpressPassThruProtocolGuid,
+(VOID **) &Private->Passthru,
+This->DriverBindingHandle,
+Handle,
+EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
+);
+  return Status;
+}
+  }
+
   if(Device->DevicePath != NULL) {
 FreePool (Device->DevicePath);
   }
@@ -480,8 +544,8 @@ NvmExpressDriverBindingSupported (
 
   if ((DevicePathNode.DevPath->Type!= MESSAGING_DEVICE_PATH) ||
   (DevicePathNode.DevPath->SubType != MSG_NVME_NAMESPACE_DP) ||
-   DevicePathNodeLength(DevicePathNode.DevPath) != 
sizeof(NVME_NAMESPACE_DEVICE_PATH)) {
-return EFI_UNSUPPORTED;
+  (DevicePathNodeLength(DevicePathNode.DevPath) != 
sizeof(NVME_NAMESPACE_DEVICE_PATH))) {
+ return EFI_UNSUPPORTED;
   }
 }
   }
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
index 54baac6..21c6255 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -152,29 +153,30 @@ struct _NVME_CONTROLLER_PRIVATE_DATA {
 // Nvme device private data structure
 //
 struct _NVME_DEVICE_PRIVATE_DATA {
-  UINT32Signature;
+  UINT32   Signature;
 
-  EF

[edk2] [patch] MdeModulePkg/NvmExpressDxe: Open NVME_PASS_THRU with BY_CHILD attr

[Tian Feng]

Open NVM_EXPRESS_PASS_THRU rather than PCI_IO to create parent-child
relationship.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tian Feng 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c | 27 ++---
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
index 99f89f1..d107d96 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c
@@ -213,8 +213,8 @@ EnumerateNvmeDevNamespace (
 }
 gBS->OpenProtocol (
Private->ControllerHandle,
-   &gEfiPciIoProtocolGuid,
-   (VOID **) &Private->PciIo,
+   &gEfiNvmExpressPassThruProtocolGuid,
+   (VOID **) &Private->Passthru,
Private->DriverBindingHandle,
Device->DeviceHandle,
EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
@@ -336,9 +336,9 @@ UnregisterNvmeNamespace (
   )
 {
   EFI_STATUS   Status;
-  EFI_PCI_IO_PROTOCOL  *PciIo;
   EFI_BLOCK_IO_PROTOCOL*BlockIo;
   NVME_DEVICE_PRIVATE_DATA *Device;
+  NVME_CONTROLLER_PRIVATE_DATA *Private;
 
   BlockIo = NULL;
 
@@ -354,14 +354,15 @@ UnregisterNvmeNamespace (
 return Status;
   }
 
-  Device = NVME_DEVICE_PRIVATE_DATA_FROM_BLOCK_IO (BlockIo);
+  Device  = NVME_DEVICE_PRIVATE_DATA_FROM_BLOCK_IO (BlockIo);
+  Private = Device->Controller;
 
   //
   // Close the child handle
   //
   gBS->CloseProtocol (
  Controller,
- &gEfiPciIoProtocolGuid,
+ &gEfiNvmExpressPassThruProtocolGuid,
  This->DriverBindingHandle,
  Handle
  );
@@ -384,8 +385,8 @@ UnregisterNvmeNamespace (
   if (EFI_ERROR (Status)) {
 gBS->OpenProtocol (
Controller,
-   &gEfiPciIoProtocolGuid,
-   (VOID **) &PciIo,
+   &gEfiNvmExpressPassThruProtocolGuid,
+   (VOID **) &Private->Passthru,
This->DriverBindingHandle,
Handle,
EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
@@ -844,22 +845,24 @@ NvmExpressDriverBindingStop (
   BOOLEAN AllChildrenStopped;
   UINTN   Index;
   NVME_CONTROLLER_PRIVATE_DATA*Private;
+  EFI_NVM_EXPRESS_PASS_THRU_PROTOCOL  *PassThru;
 
   if (NumberOfChildren == 0) {
 Status = gBS->OpenProtocol (
 Controller,
-&gEfiCallerIdGuid,
-(VOID **) &Private,
+&gEfiNvmExpressPassThruProtocolGuid,
+(VOID **) &PassThru,
 This->DriverBindingHandle,
 Controller,
 EFI_OPEN_PROTOCOL_GET_PROTOCOL
 );
 
 if (!EFI_ERROR (Status)) {
+  Private = NVME_CONTROLLER_PRIVATE_DATA_FROM_PASS_THRU (PassThru);
   gBS->UninstallMultipleProtocolInterfaces (
 Controller,
-&gEfiCallerIdGuid,
-Private,
+&gEfiNvmExpressPassThruProtocolGuid,
+PassThru,
 NULL
 );
 
@@ -940,7 +943,7 @@ NvmExpressUnload (
   DeviceHandleBuffer = NULL;
   Status = gBS->LocateHandleBuffer (
   ByProtocol,
-  &gEfiCallerIdGuid,
+  &gEfiNvmExpressPassThruProtocolGuid,
   NULL,
   &DeviceHandleCount,
   &DeviceHandleBuffer
-- 
1.9.5.msysgit.0


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

[edk2] [patch] MdeModulePkg/NvmExpressDxe: local variable naming uniformed

[Tian Feng]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tian Feng 
---
 .../Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c  | 64 +++---
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
index 0b17ebd..e7d7651 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c
@@ -35,7 +35,7 @@ ReadSectors (
   IN UINT32 Blocks
   )
 {
-  NVME_CONTROLLER_PRIVATE_DATA *Controller;
+  NVME_CONTROLLER_PRIVATE_DATA *Private;
   UINT32   Bytes;
   EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET CommandPacket;
   EFI_NVM_EXPRESS_COMMAND  Command;
@@ -43,7 +43,7 @@ ReadSectors (
   EFI_STATUS   Status;
   UINT32   BlockSize;
 
-  Controller = Device->Controller;
+  Private= Device->Controller;
   BlockSize  = Device->Media.BlockSize;
   Bytes  = Blocks * BlockSize;
 
@@ -68,12 +68,12 @@ ReadSectors (
 
   CommandPacket.NvmeCmd->Flags = CDW10_VALID | CDW11_VALID | CDW12_VALID;
 
-  Status = Controller->Passthru.PassThru (
-  &Controller->Passthru,
-  Device->NamespaceId,
-  &CommandPacket,
-  NULL
-  );
+  Status = Private->Passthru.PassThru (
+   &Private->Passthru,
+   Device->NamespaceId,
+   &CommandPacket,
+   NULL
+   );
 
   return Status;
 }
@@ -98,7 +98,7 @@ WriteSectors (
   IN UINT32Blocks
   )
 {
-  NVME_CONTROLLER_PRIVATE_DATA *Controller;
+  NVME_CONTROLLER_PRIVATE_DATA *Private;
   EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET CommandPacket;
   EFI_NVM_EXPRESS_COMMAND  Command;
   EFI_NVM_EXPRESS_COMPLETION   Completion;
@@ -106,7 +106,7 @@ WriteSectors (
   UINT32   Bytes;
   UINT32   BlockSize;
 
-  Controller = Device->Controller;
+  Private= Device->Controller;
   BlockSize  = Device->Media.BlockSize;
   Bytes  = Blocks * BlockSize;
 
@@ -134,12 +134,12 @@ WriteSectors (
 
   CommandPacket.NvmeCmd->Flags = CDW10_VALID | CDW11_VALID | CDW12_VALID;
 
-  Status = Controller->Passthru.PassThru (
-  &Controller->Passthru,
-  Device->NamespaceId,
-  &CommandPacket,
-  NULL
-  );
+  Status = Private->Passthru.PassThru (
+   &Private->Passthru,
+   Device->NamespaceId,
+   &CommandPacket,
+   NULL
+   );
 
   return Status;
 }
@@ -166,17 +166,17 @@ NvmeRead (
 {
   EFI_STATUS   Status;
   UINT32   BlockSize;
-  NVME_CONTROLLER_PRIVATE_DATA *Controller;
+  NVME_CONTROLLER_PRIVATE_DATA *Private;
   UINT32   MaxTransferBlocks;
   UINTNOrginalBlocks;
 
   Status= EFI_SUCCESS;
-  Controller= Device->Controller;
+  Private   = Device->Controller;
   BlockSize = Device->Media.BlockSize;
   OrginalBlocks = Blocks;
 
-  if (Controller->ControllerData->Mdts != 0) {
-MaxTransferBlocks = (1 << (Controller->ControllerData->Mdts)) * (1 << 
(Controller->Cap.Mpsmin + 12)) / BlockSize;
+  if (Private->ControllerData->Mdts != 0) {
+MaxTransferBlocks = (1 << (Private->ControllerData->Mdts)) * (1 << 
(Private->Cap.Mpsmin + 12)) / BlockSize;
   } else {
 MaxTransferBlocks = 1024;
   }
@@ -225,17 +225,17 @@ NvmeWrite (
 {
   EFI_STATUS   Status;
   UINT32   BlockSize;
-  NVME_CONTROLLER_PRIVATE_DATA *Controller;
+  NVME_CONTROLLER_PRIVATE_DATA *Private;
   UINT32   MaxTransferBlocks;
   UINTNOrginalBlocks;
 
   Status= EFI_SUCCESS;
-  Controller= Device->Controller;
+  Private   = Device->Controller;
   BlockSize = Device->Media.BlockSize;
   OrginalBlocks = Blocks;
 
-  if (Controller->ControllerData->Mdts != 0) {
-MaxTransferBlocks = (1 << (Controller->ControllerData->Mdts)) * (1 << 
(Controller->Cap.Mpsmin + 12)) / BlockSize;
+  if (Private->ControllerData->Mdts != 0) {
+MaxTransferBlocks = (1 << (Private->ControllerData->Mdts)) * (1 << 
(Private->Cap.Mpsmin + 12)) / BlockSize;
   } else {
 MaxTransferBlocks = 1024;
   }
@@ -276,13 +276,13 @@ NvmeFlush (

Re: [edk2] [Patch] BaseTools: Generate a binary file and list it in Binary section of As Built INF.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Wednesday, June 10, 2015 3:25 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Generate a binary file and list it in Binary 
section of As Built INF.

This binary file contains offset of VFR and UNI data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index a2a8e7e..996b654 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3116,6 +3116,76 @@ class ModuleAutoGen(AutoGen):
 
 return HiiExPcds
 
+def _GenOffsetBin(self):
+VfrUniBaseName = {}
+for SourceFile in self.Module.Sources:
+if SourceFile.Type.upper() == ".VFR" :
+#
+# search the .map file to find the offset of vfr binary in the 
PE32+/TE file. 
+#
+VfrUniBaseName[SourceFile.BaseName] = (SourceFile.BaseName + 
"Bin")
+if SourceFile.Type.upper() == ".UNI" :
+#
+# search the .map file to find the offset of Uni strings 
binary in the PE32+/TE file. 
+#
+VfrUniBaseName["UniOffsetName"] = (self.Name + "Strings")
+
+if len(VfrUniBaseName) == 0:
+return None
+MapFileName = os.path.join(self.OutputDir, self.Name + ".map")
+EfiFileName = os.path.join(self.OutputDir, self.Name + ".efi")
+VfrUniOffsetList = GetVariableOffset(MapFileName, EfiFileName, 
VfrUniBaseName.values())
+if not VfrUniOffsetList:
+return None
+
+OutputName = '%sOffset.bin' % self.Name
+UniVfrOffsetFileName=  os.path.join( self.OutputDir, OutputName)
+
+try:
+fInputfile = open(UniVfrOffsetFileName, "wb+", 0)
+except:
+EdkLogger.error("build", FILE_OPEN_FAILURE, "File open failed for 
%s" % UniVfrOffsetFileName,None)
+
+# Use a instance of StringIO to cache data
+fStringIO = StringIO('')  
+
+for Item in VfrUniOffsetList:
+if (Item[0].find("Strings") != -1):
+#
+# UNI offset in image.
+# GUID + Offset
+# { 0x8913c5e0, 0x33f6, 0x4d86, { 0x9b, 0xf1, 0x43, 0xef, 
0x89, 0xfc, 0x6, 0x66 } }
+#
+UniGuid = [0xe0, 0xc5, 0x13, 0x89, 0xf6, 0x33, 0x86, 0x4d, 
0x9b, 0xf1, 0x43, 0xef, 0x89, 0xfc, 0x6, 0x66]
+UniGuid = [chr(ItemGuid) for ItemGuid in UniGuid]
+fStringIO.write(''.join(UniGuid))
+UniValue = pack ('Q', int (Item[1], 16))
+fStringIO.write (UniValue)
+else:
+#
+# VFR binary offset in image.
+# GUID + Offset
+# { 0xd0bc7cb4, 0x6a47, 0x495f, { 0xaa, 0x11, 0x71, 0x7, 0x46, 
0xda, 0x6, 0xa2 } };
+#
+VfrGuid = [0xb4, 0x7c, 0xbc, 0xd0, 0x47, 0x6a, 0x5f, 0x49, 
0xaa, 0x11, 0x71, 0x7, 0x46, 0xda, 0x6, 0xa2]
+VfrGuid = [chr(ItemGuid) for ItemGuid in VfrGuid]
+fStringIO.write(''.join(VfrGuid))   
+type (Item[1]) 
+VfrValue = pack ('Q', int (Item[1], 16))
+fStringIO.write (VfrValue)
+#
+# write data into file.
+#
+try :  
+fInputfile.write (fStringIO.getvalue())
+except:
+EdkLogger.error("build", FILE_WRITE_FAILURE, "Write data to file 
%s failed, please check whether the "
+"file been locked or using by other applications." 
%UniVfrOffsetFileName,None)
+
+fStringIO.close ()
+fInputfile.close ()
+return OutputName
+
 ## Create AsBuilt INF file the module
 #
 def CreateAsBuiltInf(self):
@@ -3270,6 +3340,10 @@ class ModuleAutoGen(AutoGen):
 if self.ModuleType in ['DXE_SMM_DRIVER']:
   AsBuiltInfDict['binary_item'] += ['SMM_DEPEX|' + self.Name + 
'.depex']
 
+Bin = self._GenOffsetBin()
+if Bin:
+AsBuiltInfDict['binary_item'] += ['BIN|%s' % Bin]
+
 for Root, Dirs, Files in os.walk(OutputDir):
 for File in Files:
 if File.lower().endswith('.pdb'):
-- 
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
e

Re: [edk2] [Patch] BaseTools: Fixed an error reported during generating report.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Wednesday, June 10, 2015 7:28 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Fixed an error reported during generating 
report.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/build/BuildReport.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 327d5a5..264607b 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -1237,10 +1237,10 @@ class FdRegionReport(object):
 #
 # Collect PCDs defined in DSC common section
 #
-for Platform in Wa.BuildDatabase.WorkspaceDb.PlatformList:
-for (TokenCName, TokenSpaceGuidCName) in Platform.Pcds:
-DscDefaultValue = Platform.Pcds[(TokenCName, 
TokenSpaceGuidCName)].DefaultValue
-PlatformPcds[(TokenCName, TokenSpaceGuidCName)] = 
DscDefaultValue
+Platform = Wa.BuildDatabase[Wa.MetaFile, 'COMMON']
+for (TokenCName, TokenSpaceGuidCName) in Platform.Pcds:
+DscDefaultValue = Platform.Pcds[(TokenCName, 
TokenSpaceGuidCName)].DefaultValue
+PlatformPcds[(TokenCName, TokenSpaceGuidCName)] = DscDefaultValue
 
 #
 # Add PEI and DXE a priori files GUIDs defined in PI specification.
-- 
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] BaseTools: Support build options for specific module type in DSC.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Wednesday, June 10, 2015 10:20 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Support build options for specific module 
type in DSC.

This patch extended BuildOptions section in DSC to support 
[BuildOptions.$(arch).CodeBase.$(MODULE_TYPE)]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 11 ---
 BaseTools/Source/Python/Workspace/WorkspaceDatabase.py | 14 ++
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index d1ed0a6..a2a8e7e 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -2074,8 +2074,11 @@ class PlatformAutoGen(AutoGen):
 # Get the different options for the different style module
 if Module.AutoGenVersion < 0x00010005:
 PlatformOptions = self.EdkBuildOption
+ModuleTypeOptions = 
self.Platform.GetBuildOptionsByModuleType(EDK_NAME, Module.ModuleType)
 else:
 PlatformOptions = self.EdkIIBuildOption
+ModuleTypeOptions = 
self.Platform.GetBuildOptionsByModuleType(EDKII_NAME, Module.ModuleType)
+ModuleTypeOptions = self._ExpandBuildOption(ModuleTypeOptions)
 ModuleOptions = self._ExpandBuildOption(Module.BuildOptions)
 if Module in self.Platform.Modules:
 PlatformModule = self.Platform.Modules[str(Module)]
@@ -2084,19 +2087,21 @@ class PlatformAutoGen(AutoGen):
 PlatformModuleOptions = {}
 
 BuildRuleOrder = None
-for Options in [self.ToolDefinition, ModuleOptions, PlatformOptions, 
PlatformModuleOptions]:
+for Options in [self.ToolDefinition, ModuleOptions, PlatformOptions, 
ModuleTypeOptions, PlatformModuleOptions]:
 for Tool in Options:
 for Attr in Options[Tool]:
 if Attr == TAB_TOD_DEFINES_BUILDRULEORDER:
 BuildRuleOrder = Options[Tool][Attr]
 
-AllTools = set(ModuleOptions.keys() + PlatformOptions.keys() + 
PlatformModuleOptions.keys() + self.ToolDefinition.keys())
+AllTools = set(ModuleOptions.keys() + PlatformOptions.keys() +
+   PlatformModuleOptions.keys() + ModuleTypeOptions.keys() 
+
+   self.ToolDefinition.keys())
 BuildOptions = {}
 for Tool in AllTools:
 if Tool not in BuildOptions:
 BuildOptions[Tool] = {}
 
-for Options in [self.ToolDefinition, ModuleOptions, 
PlatformOptions, PlatformModuleOptions]:
+for Options in [self.ToolDefinition, ModuleOptions, 
PlatformOptions, ModuleTypeOptions, PlatformModuleOptions]:
 if Tool not in Options:
 continue
 for Attr in Options[Tool]:
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
index 14cd22d..1371bb0 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
@@ -147,6 +147,7 @@ class DscBuildData(PlatformBuildClassObject):
 self._Pcds  = None
 self._DecPcds   = None
 self._BuildOptions  = None
+self._ModuleTypeOptions = None
 self._LoadFixAddress= None
 self._RFCLanguages  = None
 self._ISOLanguages  = None
@@ -767,6 +768,19 @@ class DscBuildData(PlatformBuildClassObject):
 self._BuildOptions[ToolChainFamily, ToolChain, EDK_NAME] = 
Option
 return self._BuildOptions
 
+def GetBuildOptionsByModuleType(self, Edk, ModuleType):
+if self._ModuleTypeOptions == None:
+self._ModuleTypeOptions = sdict()
+if (Edk, ModuleType) not in self._ModuleTypeOptions:
+options = sdict()
+self._ModuleTypeOptions[Edk, ModuleType] = options
+DriverType = '%s.%s' % (Edk, ModuleType)
+RecordList = self._RawData[MODEL_META_DATA_BUILD_OPTION, 
self._Arch, DriverType]
+for ToolChainFamily, ToolChain, Option, Arch, Type, Dummy3, Dummy4 
in RecordList:
+if Arch == self._Arch and Type == DriverType:
+options[ToolChainFamily, ToolChain, Edk] = Option
+return self._ModuleTypeOptions[Edk, ModuleType]
+
 ## Retrieve non-dynamic PCD settings
 #
 #   @param  TypePCD type
-- 
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

[Andrew Fish]

> On Jun 10, 2015, at 7:17 PM, Blibbet  wrote:
> 
> FAT has a non-BSD license and UEFI Forum found a way to accomodate that
> one vendor's legal/licensing issues, and found a separate way for that
> to be distributed under Tiano umbrella.

The UEFI Forum owns the specifications, not the edk2 open source site. The 
edk2/Tinao core is an independent open source site. The edk2 is one of many 
possible implementations of the UEFI Forums specifications. 

It is probably confusing due to the overlap of people who are members of the 
UEFI Forum, and work on the open source site. 

> 
> All OS vendors don't hate GPL. Some Linux platforms have non-BSD tools
> in use today.
> 

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

> 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.  

> 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. There 
are a set of conformance requirements required to get a discount on the 
pre-installed Windows, but as far as I know these are mostly quality of 
implementation tests. 

Microsoft also happens to be the CA for UEFI Secure Boot. They have no concern 
about licensing of the code. They, as a good CA must, care about how secure the 
code is. The UEFI CA will not sign the UEFI Shell for example, as you could use 
a script to launch code that is not secure. So yes you can’t write a virus 
(code the loads unsigned code) and get it signed by the CA. That is exactly how 
UEFI Secure Boot is supposed to work. 

Thanks,

Andrew Fish

> There are about 168 UEFI projects on Github today. A few dozen would be
> useful to have under Tiano umbrella, current BSD-only licensing issues
> would prevent that. A GPL-friendly Tiano subproject would be useful to
> gather some code from rEFInd, VirtualBox, and various other Github
> projects into one place. Ignoring non-BSD licensed code will continue to
> spread UEFI projects in non-Tiano umbrellas and not fix the problem.
> 
> On 06/10/2015 06:59 PM, El-Haj-Mahmoud, Samer wrote:
>> 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.
>> 
>> -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.
> 
> 
> --
> ___
> 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 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL

[Blibbet]

FAT has a non-BSD license and UEFI Forum found a way to accomodate that
one vendor's legal/licensing issues, and found a separate way for that
to be distributed under Tiano umbrella.

All OS vendors don't hate GPL. Some Linux platforms have non-BSD tools
in use today.

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?

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.

There are about 168 UEFI projects on Github today. A few dozen would be
useful to have under Tiano umbrella, current BSD-only licensing issues
would prevent that. A GPL-friendly Tiano subproject would be useful to
gather some code from rEFInd, VirtualBox, and various other Github
projects into one place. Ignoring non-BSD licensed code will continue to
spread UEFI projects in non-Tiano umbrellas and not fix the problem.

On 06/10/2015 06:59 PM, El-Haj-Mahmoud, Samer wrote:
> 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.
>
> -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.


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

Re: [edk2] [ShellPkg] I think there is an issue in ls.

[Blibbet]

On 06/10/2015 06:38 PM, Andrew Fish wrote:
> I’m guessing more modern filesystems probably store the time in UTC?

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290%28v=vs.85%29.aspx

says FAT uses local time, NTFS uses UTC, and CDFS (CDs/DVDs) use local time.

I haven't found info on ZFS, or Ext2, or Apple's HFS+, nor the other
half dozen that're actively used...

Unfortunately the timezone epoc column is missing from the Wikipedia page...

http://en.wikipedia.org/wiki/Comparison_of_file_systems

Is there some existing file system perf/diagnostic tool that'd help dump
out this info, to help augment their docs/specs?



--
___
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

[Tian, Feng]

Reviewed-by: Feng Tian 

-Original Message-
From: Ni, Ruiyu 
Sent: Wednesday, June 10, 2015 12:11
To: edk2-devel@lists.sourceforge.net
Cc: Ni, Ruiyu; Tian, Feng; Gao, Liming; Kinney, Michael D
Subject: [Patch] PcAtChipsetPkg/PcRtc: Fix a Y2K bug

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  
+ gPcAtChipsetPkgTokenSpaceGuid.PcdMaximalValidYear|2097|UINT16|0x00
+ 0E
   
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Defines the ACPI register set base address.
@@ -168,4 +169,4 @@
   gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPortBaseAddressMask 
|0xFFFE|UINT16|0x0018
 
 [UserExtensions.TianoCore."ExtraFiles"]
-  PcAtChipsetPkgExtra.uni
\ No newline at end of file
+  PcAtChipsetPkgExtra.uni
diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c 
b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
index 23f8d3b..9ec309c 100644
--- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
+++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
@@ -100,7 +100,6 @@ PcRtcInit (
   RTC_REGISTER_A  RegisterA;
   RTC_REGISTER_B  RegisterB;
   RTC_REGISTER_D  RegisterD;
-  UINT8   Century;
   EFI_TIMETime;
   UINTN   DataSize;
   UINT32  TimerVar;
@@ -163,8 +162,6 @@ PcRtcInit (
   Time.Month  = RtcRead (RTC_ADDRESS_MONTH);
   Time.Year   = RtcRead (RTC_ADDRESS_YEAR);
 
-  Century = RtcRead (RTC_ADDRESS_CENTURY);
-  
   //
   // Set RTC configuration after get original time
   // The value of bit AIE should be reserved.
@@ -201,7 +198,7 @@ PcRtcInit (
   //
   // Validate time fields
   //
-  Status = ConvertRtcTimeToEfiTime (&Time, Century, RegisterB);
+  Status = ConvertRtcTimeToEfiTime (&Time, RegisterB);
   if (!EFI_ERROR (Status)) {
 Status = RtcTimeFieldsValid (&Time);
   }
@@ -218,7 +215,7 @@ PcRtcInit (
 Time.Hour   = RTC_INIT_HOUR;
 Time.Day= RTC_INIT_DAY;
 Time.Month  = RTC_INIT_MONTH;
-Time.Year   = RTC_INIT_YEAR;
+Time.Year   = PcdGet16 (PcdMinimalValidYear);
 Time.Nanosecond  = 0;
 Time.TimeZone = EFI_UNSPECIFIED_TIMEZONE;
 Time.Daylight = 0;
@@ -251,7 +248,7 @@ PcRtcInit (
   Time.Hour   = RTC_INIT_HOUR;
   Time.Day= RTC_INIT_DAY;
   Time.Month  = RTC_INIT_MONTH;
-  Time.Year   = RTC_INIT_YEAR;
+  Time.Year   = PcdGet16 (PcdMinimalValidYear);
   Time.Nanosecond  = 0;
   Time.TimeZone = Global->SavedTimeZone;
   Time.Daylight = Global->Daylight;;
@@ -272,8 +269,8 @@ PcRtcInit (
 }
 return EFI_DEVICE_ERROR;
   }
-
-  ConvertEfiTimeToRtcTime (&Time, RegisterB, &Century);
+
+  ConvertEfiTimeToRtcTime (&Time, RegisterB);
 
   //
   // Set the Y/M/D info to variable as it has no corresponding hw registers.
@@ -343,7 +340,6 @@ PcRtcGetTime (
 {
   EFI_STATUS  Status;
   RTC_REGISTER_B  RegisterB;
-  UINT8   Century;
 
   //
   // Check parameters for null pointer
@@ -383,8 +379,6 @@ PcRtcGetTime (
   Time->Month   = RtcRead (RTC_ADDRESS_MONTH);
   Time->Year= RtcRead (RTC_ADDRESS_YEAR);
 
-  Century = RtcRead (RTC_ADDRESS_CENTURY);
-  
   //
   // Release RTC Lock.
   //
@@ -401,7 +395,7 @@ PcRtcGetTime (
   //
   // Make sure all field values are in correct range
   //
-  Status = ConvertRtcTimeToEfiTime (Time, Century, RegisterB);
+  Status = ConvertRtcTimeToEfiTime (Time, RegisterB);
   if (!EFI_ERROR (Status)) {
 Status = RtcTimeFieldsValid (Time);
   }
@@ -447,7 +441,6 @@ PcRtcSetTime (
   EFI_STATUS  Status;
   EFI_TIMERtcTime;
   RTC_REGISTER_B  RegisterB;
-  UINT8   Century;
   UINT32  TimerVar;
 
   if (Time

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

[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.



-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|   36 +
 .../SmartCardReader/libccid/openct/checksum.c  |   95 +
 .../SmartCardReader/libccid/openct/checksum.h  |   37 +
 .../SmartCardReader/libccid/openct/proto-t1.c  |  800 +++
 .../SmartCardReader/libccid/openct/proto-t1.h  |   85 +
 .../SmartCardReader/libccid/towitoko/COPYING   |  505 +
 .../SmartCardReader/libccid/towitoko/README|   14 +
 .../Library/SmartCardReader/libccid/towitoko/atr.c |  365   
.../Library/SmartCardReader/libccid/towitoko/atr.h |  111 +
 .../SmartCardReader/libccid/towitoko/defines.h |   56 +
 .../Library/SmartCardReader/libccid/towitoko/pps.c |  136 ++
 .../Library/SmartCardReader/libccid/towitoko/pps.h |   71 +
 .../Library/SmartCardRea

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

[Tian, Feng]

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|   36 +
 .../SmartCardReader/libccid/openct/checksum.c  |   95 +
 .../SmartCardReader/libccid/openct/checksum.h  |   37 +
 .../SmartCardReader/libccid/openct/proto-t1.c  |  800 +++
 .../SmartCardReader/libccid/openct/proto-t1.h  |   85 +
 .../SmartCardReader/libccid/towitoko/COPYING   |  505 +
 .../SmartCardReader/libccid/towitoko/README|   14 +
 .../Library/SmartCardReader/libccid/towitoko/atr.c |  365   
.../Library/SmartCardReader/libccid/towitoko/atr.h |  111 +
 .../SmartCardReader/libccid/towitoko/defines.h |   56 +
 .../Library/SmartCardReader/libccid/towitoko/pps.c |  136 ++
 .../Library/SmartCardReader/libccid/towitoko/pps.h |   71 +
 .../Library/SmartCardReader/libccid/utils.c|   85 +
 .../Library/SmartCardReader/libccid/utils.h|   33 +
 MdeModulePkg/Library/SmartCardReader/misc.h|   88 +
 MdeModulePkg/Library/SmartCardReader/pcsclite.h|   65 +
 MdeModulePkg/Library/SmartCardReader/reader.h  |  285 +++
 MdeModulePkg/Library/SmartCardReader/wintypes.h|  120 +
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 46 files changed, 12953 insertions(+)
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.h
 create mode 100644 MdeMod

Re: [edk2] [ShellPkg] I think there is an issue in ls.

[Andrew Fish]

> On Jun 10, 2015, at 6:33 PM, Carsey, Jaben  wrote:
> 
> Andrew,
> 
> I agree, that looks like an issue.  Can you submit a patch with this fixed?

Sorry don’t have time right now. 

>  I will put this on the list of issues.
> 

Thanks, I hit this issue in another location and look to see what the shell 
did. Since the shell seemed to be doing the wrong thing I decided to at least 
report it to the mailing list. 

I’m guessing more modern filesystems probably store the time in UTC?

Thanks,

Andrew Fish

> -Jaben
> 
>> -Original Message-
>> From: Andrew Fish [mailto:af...@apple.com]
>> Sent: Wednesday, June 10, 2015 6:26 PM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: [edk2] [ShellPkg] I think there is an issue in ls.
>> Importance: High
>> 
>> Dear ShellPkg maintainer,
>> 
>> I think there is an issue with the ls command. It does not use the TImeZone,
>> so it seems it is hard coded to assume that a filesystem stores time like 
>> FAT, in
>> local time. The FAT driver always returns EFI_UNSPECIFIED_TIMEZONE, which
>> implies the values are local time. But what if a filesystem is storing time 
>> in UTC
>> (EFI_TIME.TimeZone == 0)? it seems the current path in the shell assumes
>> EFI_UNSPECIFIED_TIMEZONE (thus all time is local time). I don’t think this
>> follows the UEFI spec. I think the correct algorithm is:
>> 
>> if FileSystemTime.TimeZone == EFI_UNSPECIFIED_TIMEZONE
>>  // This is the current path in the code
>> Assume time is local time, and print it out
>> else:
>> // This is the missing path.
>> Adjust the FileSystemTime.TimeZone for the System.TimeZone (and
>> System.Daylight), thus display the time in local time.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> --
>> ___
>> 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] [ShellPkg] I think there is an issue in ls.

[Carsey, Jaben]

Andrew,

I agree, that looks like an issue.  Can you submit a patch with this fixed?  I 
will put this on the list of issues.

-Jaben

>-Original Message-
>From: Andrew Fish [mailto:af...@apple.com]
>Sent: Wednesday, June 10, 2015 6:26 PM
>To: edk2-devel@lists.sourceforge.net
>Subject: [edk2] [ShellPkg] I think there is an issue in ls.
>Importance: High
>
>Dear ShellPkg maintainer,
>
>I think there is an issue with the ls command. It does not use the TImeZone,
>so it seems it is hard coded to assume that a filesystem stores time like FAT, 
>in
>local time. The FAT driver always returns EFI_UNSPECIFIED_TIMEZONE, which
>implies the values are local time. But what if a filesystem is storing time in 
>UTC
>(EFI_TIME.TimeZone == 0)? it seems the current path in the shell assumes
>EFI_UNSPECIFIED_TIMEZONE (thus all time is local time). I don’t think this
>follows the UEFI spec. I think the correct algorithm is:
>
>if FileSystemTime.TimeZone == EFI_UNSPECIFIED_TIMEZONE
>   // This is the current path in the code
>  Assume time is local time, and print it out
>else:
>  // This is the missing path.
>  Adjust the FileSystemTime.TimeZone for the System.TimeZone (and
>System.Daylight), thus display the time in local time.
>
>Thanks,
>
>Andrew Fish
>
>
>--
>___
>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] MdePkg/Library/UefiFileHandleLib: Do the validation for DirHandle before get file information.

[Ni, Ruiyu]

Depending on whether the low-layer produces BlockIo2 protocol, the Fat driver 
doesn't always produce REVISION_2 for FileHandle/DirHandle.
So either we can check both the REVISION_1 and REVISION_2, or we can remove 
this check because the rubbish data can happen to be REVISION_1 or REVISION_2 
but it doesn't mean the rubbish data is valid.

Thanks,
Ray
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Thursday, June 11, 2015 1:29 AM
> To: Qiu, Shumin; edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH 2/2] MdePkg/Library/UefiFileHandleLib: Do the
> validation for DirHandle before get file information.
> 
> Why do we need to check against the latest revision?  Can't we use the
> version of the protocol that we need the feature from?
> 
> I like the idea of the check.
> 
> -Jaben
> 
> > -Original Message-
> > From: Qiu, Shumin
> > Sent: Wednesday, June 10, 2015 1:22 AM
> > To: edk2-devel@lists.sourceforge.net
> > Cc: Gao, Liming; Carsey, Jaben
> > Subject: [PATCH 2/2] MdePkg/Library/UefiFileHandleLib: Do the validation
> > for DirHandle before get file information.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Qiu Shumin 
> > ---
> >  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> > b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> > index 7687ca3..25bb8fb 100644
> > --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> > +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> > @@ -407,7 +407,14 @@ FileHandleIsDirectory (
> >if (DirHandle == NULL) {
> >  return (EFI_INVALID_PARAMETER);
> >}
> > -
> > +
> > +  //
> > +  // check whether the DirHandle is valid
> > +  //
> > +  if (DirHandle->Revision != EFI_FILE_PROTOCOL_LATEST_REVISION) {
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> >//
> >// get the file information for DirHandle
> >//
> > --
> > 1.9.5.msysgit.1
> >
> 
> 
> --
> ___
> 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] [ShellPkg] I think there is an issue in ls.

[Andrew Fish]

Dear ShellPkg maintainer,

I think there is an issue with the ls command. It does not use the TImeZone, so 
it seems it is hard coded to assume that a filesystem stores time like FAT, in 
local time. The FAT driver always returns EFI_UNSPECIFIED_TIMEZONE, which 
implies the values are local time. But what if a filesystem is storing time in 
UTC (EFI_TIME.TimeZone == 0)? it seems the current path in the shell assumes 
EFI_UNSPECIFIED_TIMEZONE (thus all time is local time). I don’t think this 
follows the UEFI spec. I think the correct algorithm is:

if FileSystemTime.TimeZone == EFI_UNSPECIFIED_TIMEZONE
   // This is the current path in the code
  Assume time is local time, and print it out
else:
  // This is the missing path.
  Adjust the FileSystemTime.TimeZone for the System.TimeZone (and 
System.Daylight), thus display the time in local time. 

Thanks,

Andrew Fish


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

[edk2] [PATCH 3/4] MdeModulePkg/SmartCardReader: Implement Smart Card Reader Protocol

[Ludovic Rousseau]

Add SmartCardReader specific files. These files have been written
specifically for UEFI.

This provides an implementation of the "Smart Card Reader Protocol" or
EFI_SMART_CARD_READER_PROTOCOL as described in "Unified Extensible
Firmware Interface Specification", version 2.5, April 2015, chapter
"35.6.1 Smart Card Reader Protocol".

The code heavily reuse an existing CCID driver from the CCID project
http://pcsclite.alioth.debian.org/ccid.html

CCID and ICCD are a protocols defined by the USB working group. All
modern USB smart card readers use CCID (or its variation ICCD for tokens).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ludovic Rousseau 
---
 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 ++
 12 files changed, 2448 insertions(+)
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/DriverBinding.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/License.txt
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader.inf
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader_impl.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader_impl.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/config.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/debug.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/debuglog.h

diff --git a/MdeModulePkg/Library/SmartCardReader/CcidDriver.c 
b/MdeModulePkg/Library/SmartCardReader/CcidDriver.c
new file mode 100644
index 000..9c60211
--- /dev/null
+++ b/MdeModulePkg/Library/SmartCardReader/CcidDriver.c
@@ -0,0 +1,819 @@
+/*
+Copyright (c) 2014, Gemalto. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in
+  the documentation and/or other materials provided with the
+  distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/** @file
+  Entry points for the UEFI CCID driver
+
+  When a USB CCID device is inserted or removed then Start or Stop
+  functions from this file are called.
+
+**/
+
+#include 
+#include 
+
+#include "CcidDriver.h"
+#include "SmartCardReader_impl.h"
+
+#include "ifdhandler.h"
+#include "debuglog.h"
+#include "defs.h"
+#include "utils.h"
+#include "ccid_ifdhandler.h"
+#include "ccid.h"
+#include "ccid_uefi.h"
+
+static int Lun = 0;
+
+///
+/// Driver Binding Protocol instance
+///
+EFI_DRIVER_BINDING_PROTOCOL gSmartCardReaderDriverBinding = {
+  SmartCardReaderDriverBindingSupported,
+  SmartCardReaderDriverBindingStart,
+  SmartCardReaderDriverBindingStop,
+  CCID_DRIVER_VERSION,
+  NULL,
+  NULL
+};
+
+
+/**
+  Unloads an image.
+
+  @param  ImageHandle   Handle that identifies the image to be 
unloaded.
+
+  @retval EFI_SUCCESS   The image has been unloaded.
+  @retval EFI_INVALID_PARAMETER ImageHandle is not a valid image handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmartCardReaderUnload (
+  IN EFI_HANDLE  ImageHandle
+  )
+{
+  

[edk2] [PATCH 2/4] MdeModulePkg/SmartCardReader: Add files from pcsc-lite project

[Ludovic Rousseau]

pcsc-lite project is hosted at http://pcsclite.alioth.debian.org/pcsclite.html

The pcsc-lite project uses the BSD 3-clauses license. This license
should be compatible with the TianoCore Contribution Agreement 1.0 (but
I am not a lawyer).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ludovic Rousseau 
---
 MdeModulePkg/Library/SmartCardReader/ifdhandler.h | 825 ++
 MdeModulePkg/Library/SmartCardReader/misc.h   |  88 +++
 MdeModulePkg/Library/SmartCardReader/pcsclite.h   |  65 ++
 MdeModulePkg/Library/SmartCardReader/reader.h | 285 
 MdeModulePkg/Library/SmartCardReader/wintypes.h   | 120 
 5 files changed, 1383 insertions(+)
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ifdhandler.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/misc.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/pcsclite.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/reader.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/wintypes.h

diff --git a/MdeModulePkg/Library/SmartCardReader/ifdhandler.h 
b/MdeModulePkg/Library/SmartCardReader/ifdhandler.h
new file mode 100644
index 000..f47e018
--- /dev/null
+++ b/MdeModulePkg/Library/SmartCardReader/ifdhandler.h
@@ -0,0 +1,825 @@
+/*
+ * MUSCLE SmartCard Development ( 
http://pcsclite.alioth.debian.org/pcsclite.html )
+ *
+ * Copyright (C) 1999-2004
+ *  David Corcoran 
+ * Copyright (C) 2003-2004
+ *  Damien Sauveron 
+ * Copyright (C) 2002-2011
+ *  Ludovic Rousseau 
+ *
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. The name of the author may not be used to endorse or promote products
+   derived from this software without specific prior written permission.
+
+Changes to this license can be made only by the copyright author with
+explicit written consent.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $Id: ifdhandler.h 6965 2014-09-01 14:52:42Z rousseau $
+ */
+
+/**
+ * @file
+ * @defgroup IFDHandler IFDHandler
+ * @brief This provides reader specific low-level calls.
+
+The routines specified hereafter will allow you to write an IFD handler
+for the PC/SC Lite resource manager. Please use the complement
+developer's kit complete with headers and Makefile at:
+http://www.musclecard.com/drivers.html
+
+This gives a common API for communication to most readers in a
+homogeneous fashion. This document assumes that the driver developer is
+experienced with standards such as ISO-7816-(1, 2, 3, 4), EMV and MCT
+specifications. For listings of these specifications please access the
+above web site.
+
+@section UsbReaders USB readers
+
+USB readers use the bundle approach so that the reader can be loaded
+and unloaded upon automatic detection of the device. The bundle
+approach is simple: the actual library is just embedded in a
+directory so additional information can be gathered about the device.
+
+A bundle looks like the following:
+
+@verbatim
+GenericReader.bundle/
+  Contents/
+Info.plist  - XML file describing the reader
+MacOS/  - Driver directory for OS X
+Solaris/- Driver directory for Solaris
+Linux/  - Driver directory for Linux
+HPUX/   - Driver directory for HPUX
+@endverbatim
+
+The @c Info.plist file describes the driver and gives the loader
+all the necessary information. The following must be contained in the
+@c Info.plist file:
+
+@subsection ifdVendorID
+
+The vendor ID of the USB device.
+
+Example:
+
+@verbatim
+ifdVendorID
+0x04E6
+@endverbatim
+
+You may have an OEM of this reader in which an additional @c 
+can be used like in the below example:
+
+@verbatim
+ifdVendorID
+
+  0x04E6
+  0x0973
+
+@endverbatim
+
+If multiples exist all the other parameters must have a second value
+also. You may chose not to support this feature but it is useful when
+reader vendors OEM products so

[edk2] [PATCH 4/4] MdeModulePkg: add SmartCardReader.inf

[Ludovic Rousseau]

MdeModulePkg/Library/SmartCardReader/ provides an implementation of
EFI_SMART_CARD_READER_PROTOCOL.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ludovic Rousseau 
---
 MdeModulePkg/MdeModulePkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index f718b3e..3b0981a 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -358,6 +358,7 @@
   MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
   
   
MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf
+  MdeModulePkg/Library/SmartCardReader/SmartCardReader.inf
 
 [Components.IA32, Components.X64, Components.IPF]  
   MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
-- 
2.1.4


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

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

[Ludovic Rousseau]

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|   36 +
 .../SmartCardReader/libccid/openct/checksum.c  |   95 +
 .../SmartCardReader/libccid/openct/checksum.h  |   37 +
 .../SmartCardReader/libccid/openct/proto-t1.c  |  800 +++
 .../SmartCardReader/libccid/openct/proto-t1.h  |   85 +
 .../SmartCardReader/libccid/towitoko/COPYING   |  505 +
 .../SmartCardReader/libccid/towitoko/README|   14 +
 .../Library/SmartCardReader/libccid/towitoko/atr.c |  365 
 .../Library/SmartCardReader/libccid/towitoko/atr.h |  111 +
 .../SmartCardReader/libccid/towitoko/defines.h |   56 +
 .../Library/SmartCardReader/libccid/towitoko/pps.c |  136 ++
 .../Library/SmartCardReader/libccid/towitoko/pps.h |   71 +
 .../Library/SmartCardReader/libccid/utils.c|   85 +
 .../Library/SmartCardReader/libccid/utils.h|   33 +
 MdeModulePkg/Library/SmartCardReader/misc.h|   88 +
 MdeModulePkg/Library/SmartCardReader/pcsclite.h|   65 +
 MdeModulePkg/Library/SmartCardReader/reader.h  |  285 +++
 MdeModulePkg/Library/SmartCardReader/wintypes.h|  120 +
 MdeModulePkg/MdeModulePkg.dsc  |1 +
 46 files changed, 12953 insertions(+)
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/CcidDriver.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/ComponentName.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/DriverBinding.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/License.txt
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader.inf
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader_impl.c
 create mode 100644 MdeModulePkg/Library/SmartCardReader/SmartCardReader_impl.h
 create mode 100644 MdeModulePkg/Library/SmartCardReader/config.h
 create mode 100644 MdeModulePkg/Libr

Re: [edk2] attention git users: a productivity boost for edk2

[Laszlo Ersek]

On 06/10/15 16:34, Kirkendall, Garrett wrote:
> On my internal projects, I use for example *.inc.dsc.  This allows
> any special filetype parsing in my tools to recognize it for its
> intended use, and allows me to easily tell visually that it is
> intended to be included in another file of the same final extension
> type.

I'm not trying to dictate what suffixes the include files should have.
My only point is that *whatever* the suffixes are, those should be
listed in .git/info/attributes, with diff=FOOBAR, and then the
.git/config file should assign "diff.FOOBAR.xfuncname" such that the ini
format section names show up in the patches.

I don't really care:
- about the particular suffixes
- the actual value of FOOBAR
- the actual regular expression used in xfuncname

as long as the patches I have to look at carry the section names in the
hunk headers. Note that the two files mentioned above,
".git/info/attributes" and ".git/config" are private to everyone's own
git clone.

*If* we wanted to store the attribute assignment inside the tree itself
(ie. in a ".gitattributes" file right under the project root dir),
*then* we'd have to agree on the (common subset of) suffixes, and the
actual value of FOOBAR. (The git config, that is, the
diff.FOOBAR.xfuncname regular expression, would remain private
nevertheless.) If we don't insist on centralizing the attributes (and I
don't), then we don't have to agree about the suffixes and the actual
FOOBAR value.

It's also possible to place only the following in the central (ie.
tracked) .gitattributes file:

*.dec diff=ini
*.dsc diff=ini
*.fdf diff=ini
*.inf diff=ini

And the less standard extensions (dsc.inc, fdf.inc, inc.dsc) can be
specified privately *in addition*, in ".git/info/attributes".

Thanks
Laszlo


> GARRETT KIRKENDALL   
> SMTS Firmware Engineer | CTE
> 7171 Southwest Parkway, Austin, TX 78735 USA 
>facebook  |  amd.com
> 
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com] 
> Sent: Wednesday, June 10, 2015 9:24 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] attention git users: a productivity boost for edk2
> 
> BKM: Best known method. 
> 
> I mean .dsc.inc is not standard file postfix. Other people may not use it. 
> Our internal project stills use *.dsc file as the subset of DSC to be 
> included in the full DSC file. 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, June 10, 2015 7:32 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] attention git users: a productivity boost for edk2
> 
> On 06/10/15 03:34, Gao, Liming wrote:
>> Good BKM sharing. 
> 
> What does BKM mean?
> 
>> EDKII meta data file has .inf, .dec, *.dsc and *.fdf. What's *.dsc.inc 
>> and *.fdf.inc? They are the part of DSC and FDF files that included in 
>> the full DSC and FDF files?
> 
> Yes. We have a few examples for them:
> 
> - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc
> - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
> - ArmVirtPkg/ArmVirt.dsc.inc
> - OvmfPkg/OvmfPkg.fdf.inc
> - OvmfPkg/VarStore.fdf.inc
> 
> They are included by DSC and FDF files with the !include directive.
> 
> Hm, actually, I just grepped for !include per se, and the suffixes of include 
> files are not very consistent. Beyond those listed above, we have:
> 
> AppPkg/AppPkg.dsc:!include StdLib/StdLib.inc AppPkg/AppPkg.dsc:!include 
> AppPkg/Applications/Sockets/Sockets.inc
> StdLib/StdLib.dsc:!include StdLib/StdLib.inc
> 
> ie. the full suffix is just .inc. Then,
> 
> Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
> $(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
> Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
> $(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
> Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
> $(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
> 
> ie. just .dsc. Finally,
> 
> Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
> $(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
> Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
> $(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
> Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
> $(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
> 
> ... I think choosing .txt for DSC include files was a really bad choice.
> 
> In any case, I'm adding *.inc to my .git/info/attributes file (which in turn 
> obviates *.dsc.inc and *.fdf.inc).
> 
> ... Hm, no I'm not. For example, BeagleBoardPkg has a number of .inc files 
> that don't follow the INI format... Sigh. I guess I'll stick with my current 
> entries, and accept that they won't cover the AppPkg and StdLib DSC include 
> files.
> 
> Thanks!
> Laszlo
> 
>>
>> Thanks
>> Liming
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, June 10, 2015 1:38 AM
>> To: edk2-devel list
>> Subject: [edk2] attention git users: a productivity boost for edk2
>>
>> (Sorry about the sensationalist subject line, I don't have a degree in 
>> marketing :))
>>
>> Edk2 uses a large number of te

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.

[Long, Qin]

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


Best Regards & Thanks,
LONG, Qin

-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/CryptPkcs7Verify.c
>> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
>> index a9665d5..06e4bb2 100644
>> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
>> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
> [...]
>> @@ -618,7 +618,8 @@ Pkcs7Verify (
>>//
>>// Read DER-encoded root certificate and Construct X509 Certificate
>>//
>> -  Cer

Re: [edk2] [PATCH 2/2] MdePkg/Library/UefiFileHandleLib: Do the validation for DirHandle before get file information.

[Carsey, Jaben]

Why do we need to check against the latest revision?  Can't we use the version 
of the protocol that we need the feature from?

I like the idea of the check.

-Jaben

> -Original Message-
> From: Qiu, Shumin
> Sent: Wednesday, June 10, 2015 1:22 AM
> To: edk2-devel@lists.sourceforge.net
> Cc: Gao, Liming; Carsey, Jaben
> Subject: [PATCH 2/2] MdePkg/Library/UefiFileHandleLib: Do the validation
> for DirHandle before get file information.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> index 7687ca3..25bb8fb 100644
> --- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> +++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
> @@ -407,7 +407,14 @@ FileHandleIsDirectory (
>if (DirHandle == NULL) {
>  return (EFI_INVALID_PARAMETER);
>}
> -
> +
> +  //
> +  // check whether the DirHandle is valid
> +  //
> +  if (DirHandle->Revision != EFI_FILE_PROTOCOL_LATEST_REVISION) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
>//
>// get the file information for DirHandle
>//
> --
> 1.9.5.msysgit.1
> 


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

Re: [edk2] [patch 2/3] [CryptoPkg] Update INF file, installation scripts and HOWTO for openssl-1.0.2a support.

[Long, Qin]

I agree. Thanks, Ard.
Sorry for the obfuscation caused by this. :-)

Best Regards  & Thanks,
LONG, Qin

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Wednesday, June 10, 2015 6:21 PM
To: Long, Qin
Cc: Ye, Ting; edk2-devel@lists.sourceforge.net
Subject: Re: [patch 2/3] [CryptoPkg] Update INF file, installation scripts and 
HOWTO for openssl-1.0.2a support.

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 
> ---
>  CryptoPkg/Library/OpensslLib/Install.cmd | 146 ---
>  CryptoPkg/Library/OpensslLib/Install.sh  | 146 ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf  | 620 
> +++
>  CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt |  46 +-
>  4 files changed, 608 insertions(+), 350 deletions(-)
>
> diff --git a/CryptoPkg/Library/OpensslLib/Install.cmd 
> b/CryptoPkg/Library/OpensslLib/Install.cmd
> index 8f1d016..a633f57 100755
> --- a/CryptoPkg/Library/OpensslLib/Install.cmd
> +++ b/CryptoPkg/Library/OpensslLib/Install.cmd
> @@ -1,71 +1,77 @@
> -cd openssl-0.9.8zf
> -copy e_os2.h  ..\..\..\Include\openssl
> -copy crypto\crypto.h  ..\..\..\Include\openssl
> -copy crypto\tmdiff.h  ..\..\..\Include\openssl
> -copy crypto\opensslv.h ..\..\..\Include\openssl
> -copy crypto\opensslconf.h ..\..\..\Include\openssl
> -copy crypto\ebcdic.h ..\..\..\Include\openssl
> -copy crypto\symhacks.h ..\..\..\Include\openssl
> -copy crypto\ossl_typ.h ..\..\..\Include\openssl
> -copy crypto\md2\md2.h ..\..\..\Include\openssl
> -copy crypto\md4\md4.h ..\..\..\Include\openssl
> -copy crypto\md5\md5.h ..\..\..\Include\openssl
> -copy crypto\sha\sha.h ..\..\..\Include\openssl
> -copy crypto\hmac\hmac.h ..\..\..\Include\openssl
> -copy crypto\ripemd\ripemd.h ..\..\..\Include\openssl
> -copy crypto\des\des.h ..\..\..\Include\openssl
> -copy crypto\des\des_old.h ..\..\..\Include\openssl
> -copy crypto\rc2\rc2.h ..\..\..\Include\openssl
> -copy crypto\rc4\rc4.h ..\..\..\Include\openssl
> -copy crypto\idea\idea.h ..\..\..\Include\openssl
> -copy crypto\bf\blowfish.h ..\..\..\Include\openssl
> -copy crypto\cast\cast.h ..\..\..\Include\openssl
> -copy crypto\aes\aes.h ..\..\..\Include\openssl
> -copy crypto\bn\bn.h ..\..\..\Include\openssl
> -copy crypto\rsa\rsa.h ..\..\..\Include\openssl
> -copy crypto\dsa\dsa.h ..\..\..\Include\openssl
> -copy crypto\dso\dso.h ..\..\..\Include\openssl
> -copy crypto\dh\dh.h ..\..\..\Include\openssl
> -copy crypto\ec\ec.h ..\..\..\Include\openssl
> -copy crypto\ecdh\ecdh.h ..\..\..\Include\openssl
> -copy crypto\ecdsa\ecdsa.h ..\..\..\Include\openssl
> -copy crypto\buffer\buffer.h ..\..\..\Include\openssl
> -copy crypto\bio\bio.h ..\..\..\Include\openssl
> -copy crypto\stack\stack.h ..\..\..\Include\openssl
> -copy crypto\stack\safestack.h ..\..\..\Include\openssl
> -copy crypto\lhash\lhash.h ..\..\..\Include\openssl
> -copy crypto\rand\rand.h ..\..\..\Include\openssl
> -copy crypto\err\err.h ..\..\..\Include\openssl
> -copy crypto\objects\objects.h ..\..\..\Include\openssl
> -copy crypto\objects\obj_mac.h ..\..\..\Include\openssl
> -copy crypto\evp\evp.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1_mac.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1t.h ..\..\..\Include\openssl
> -copy crypto\pem\pem.h ..\..\..\Include\openssl
> -copy crypto\pem\pem2.h ..\..\..\Include\openssl
> -copy crypto\x509\x509.h ..\..\..\Include\openssl
> -copy crypto\x509\x509_vfy.h ..\..\..\Include\openssl
> -copy crypto\x509v3\x509v3.h ..\..\..\Include\openssl
> -copy crypto\conf\conf.h ..\..\..\Include\openssl
> -copy crypto\conf\conf_api.h ..\..\..\Include\openssl
> -copy crypto\txt_db\txt_db.h ..\..\..\Include\openssl
> -copy crypto\pkcs7\pkcs7.h ..\..\..\Include\openssl
> -copy crypto\pkcs12\pkcs12.h ..\..\..\Include\openssl
> -copy crypto\comp\comp.h ..\..\..\Include\openssl
> -copy crypto\engine\engine.h ..\..\..\Include\openssl
> -copy crypto\ocsp\ocsp.h ..\..\..\Include\openssl
> -copy crypto\ui\ui.h ..\..\..\Include\openssl
> -copy crypto\ui\ui_compat.h ..\..\..\Include\openssl
> -copy crypto\krb5\krb5_asn.h ..\..\..\Include\openssl
> -copy crypto\store\store.h ..\..\..\Include\openssl
> -copy crypto\pqueue\pqueue.h ..\..\..\Include\openssl
> -copy crypto\pqueue\pq_compat.h ..\..\..\Include\openssl
> -copy ssl\ssl.h ..\..\..\Include\openssl
> -copy ssl\ssl2.h ..\..\..\Include\openssl
> -copy ssl\ssl3.h ..\..\..\Include\openssl
> -copy ssl\ssl23.h ..\..\..\Include\openssl
> -copy ssl\tls1.h ..\..\..\Include\openssl
> -copy ssl\dtls1.h ..\..\..\Include\openssl
> -copy ssl\kssl.h ..\..\..\Include\openssl
> +cd openssl-1.0.2a
> +copy e_os2.h..\..\..\Include\openssl
> +copy crypto\crypto.h..\..\..\Include\openssl

I understand that it is neater to line up the paths on the right hand
side, but it completely obfuscates the actual changes you made.

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.

[Long, Qin]

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.  :-(

I keep this for all later updates.


Best Regards & Thanks,
LONG, Qin

-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,(int)num,NULL,0)
>> - # define OPENSSL_freeFuncCRYPTO_free
>> - # define OPENSSL_free(addr)  CRYPTO_free(addr)
>> -
>> - # define OPENSSL_malloc_locked(num) \
>> --CRYPTO_malloc_locked((int)num,__FILE__,__LINE__)
>> -+CRYPTO_malloc_locked((int)num,NULL,0)
>

Re: [edk2] UEFI HTTP Boot and Redfish support?

[Blibbet]

Ting and Samer: Thanks for your replies.

http://firmwaresecurity.com/2015/06/10/more-info-on-uefi-2-5-http-boot-implementations/

If any other vendors has upcoming UEFI HTTP Boot support -- and/or DMTF
Redfish support -- please speak up.

Thanks,
Lee
RSS: http://firmwaresecurity.com/feed



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

Re: [edk2] [RFC 0/4] OvmfPkg: (almost) enable >= 64 GB guests

[Wei Liu]

On Wed, Jun 10, 2015 at 03:18:50PM +0100, Wei Liu wrote:
> On Mon, Jun 08, 2015 at 11:46:47PM +0200, Laszlo Ersek wrote:
> > This is in response to
> > 
> > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15253
> > http://thread.gmane.org/gmane.comp.emulators.xen.devel/245623
> > 
> > It's an RFC only because the last patch doesn't actually work. Ideas
> > welcome.
> > 
> > Cc: Maoming 
> > Cc: Huangpeng (Peter) 
> > Cc: Wei Liu 
> > 
> > Thanks
> > Laszlo
> > 
> 
> Thanks Laszlo.
> 
> I think only the first two patches matter to Xen so I only tested those.
> Now I'm able to boot a guest with more than 64GB ram.
> 
> Here is what it looks like from a 128 GB guest.
> 
> root@debianhvm:~# free -m
>  total   used   free sharedbuffers cached
> Mem: 12640116  12523  0  6 27
> -/+ buffers/cache: 82  12558
> Swap:26486  0  26486
> 

The above output is wrong because I mistyped guest memory size in
configuration (131072 vs 13172).

Here is the real thing:

root@debianhvm:~# free -m
 total   used   free sharedbuffers cached
Mem:128928 122424   6503  0  7 121883
-/+ buffers/cache:532 128395
Swap:26486  0  26486
root@debianhvm:~# 

Wei.

> Nice work!
> 
> Wei.
> 
> 
> > Laszlo Ersek (4):
> >   OvmfPkg: PlatformPei: enable larger permanent PEI RAM
> >   OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space
> > width
> >   OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
> >   OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> > 
> >  OvmfPkg/PlatformPei/Platform.h  |   7 +++
> >  OvmfPkg/PlatformPei/MemDetect.c | 115 
> > +++-
> >  OvmfPkg/PlatformPei/Platform.c  |   7 ++-
> >  3 files changed, 114 insertions(+), 15 deletions(-)
> > 
> > -- 
> > 1.8.3.1

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

Re: [edk2] [RFC 0/4] OvmfPkg: (almost) enable >= 64 GB guests

[Wei Liu]

On Wed, Jun 10, 2015 at 03:18:50PM +0100, Wei Liu wrote:
> On Mon, Jun 08, 2015 at 11:46:47PM +0200, Laszlo Ersek wrote:
> > This is in response to
> > 
> > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15253
> > http://thread.gmane.org/gmane.comp.emulators.xen.devel/245623
> > 
> > It's an RFC only because the last patch doesn't actually work. Ideas
> > welcome.
> > 
> > Cc: Maoming 
> > Cc: Huangpeng (Peter) 
> > Cc: Wei Liu 
> > 
> > Thanks
> > Laszlo
> > 
> 
> Thanks Laszlo.
> 
> I think only the first two patches matter to Xen so I only tested those.
> Now I'm able to boot a guest with more than 64GB ram.
> 
> Here is what it looks like from a 128 GB guest.
> 
> root@debianhvm:~# free -m
>  total   used   free sharedbuffers cached
> Mem: 12640116  12523  0  6 27
> -/+ buffers/cache: 82  12558
> Swap:26486  0  26486
> 

Spoke too soon and miscounted. It was only 12GB of ram instead of 128GB.
I need to investigate this a bit more.

But anyway this is improvement from previous situation.

Wei.

> Nice work!
> 
> Wei.
> 
> 
> > Laszlo Ersek (4):
> >   OvmfPkg: PlatformPei: enable larger permanent PEI RAM
> >   OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space
> > width
> >   OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
> >   OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> > 
> >  OvmfPkg/PlatformPei/Platform.h  |   7 +++
> >  OvmfPkg/PlatformPei/MemDetect.c | 115 
> > +++-
> >  OvmfPkg/PlatformPei/Platform.c  |   7 ++-
> >  3 files changed, 114 insertions(+), 15 deletions(-)
> > 
> > -- 
> > 1.8.3.1

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

Re: [edk2] attention git users: a productivity boost for edk2

[Kirkendall, Garrett]

On my internal projects, I use for example *.inc.dsc.  This allows any special 
filetype parsing in my tools to recognize it for its intended use, and allows 
me to easily tell visually that it is intended to be included in another file 
of the same final extension type.

GARRETT KIRKENDALL   
SMTS Firmware Engineer | CTE
7171 Southwest Parkway, Austin, TX 78735 USA 
   facebook  |  amd.com

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Wednesday, June 10, 2015 9:24 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] attention git users: a productivity boost for edk2

BKM: Best known method. 

I mean .dsc.inc is not standard file postfix. Other people may not use it. Our 
internal project stills use *.dsc file as the subset of DSC to be included in 
the full DSC file. 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, June 10, 2015 7:32 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] attention git users: a productivity boost for edk2

On 06/10/15 03:34, Gao, Liming wrote:
> Good BKM sharing. 

What does BKM mean?

> EDKII meta data file has .inf, .dec, *.dsc and *.fdf. What's *.dsc.inc 
> and *.fdf.inc? They are the part of DSC and FDF files that included in 
> the full DSC and FDF files?

Yes. We have a few examples for them:

- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc
- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
- ArmVirtPkg/ArmVirt.dsc.inc
- OvmfPkg/OvmfPkg.fdf.inc
- OvmfPkg/VarStore.fdf.inc

They are included by DSC and FDF files with the !include directive.

Hm, actually, I just grepped for !include per se, and the suffixes of include 
files are not very consistent. Beyond those listed above, we have:

AppPkg/AppPkg.dsc:!include StdLib/StdLib.inc AppPkg/AppPkg.dsc:!include 
AppPkg/Applications/Sockets/Sockets.inc
StdLib/StdLib.dsc:!include StdLib/StdLib.inc

ie. the full suffix is just .inc. Then,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc

ie. just .dsc. Finally,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt

... I think choosing .txt for DSC include files was a really bad choice.

In any case, I'm adding *.inc to my .git/info/attributes file (which in turn 
obviates *.dsc.inc and *.fdf.inc).

... Hm, no I'm not. For example, BeagleBoardPkg has a number of .inc files that 
don't follow the INI format... Sigh. I guess I'll stick with my current 
entries, and accept that they won't cover the AppPkg and StdLib DSC include 
files.

Thanks!
Laszlo

> 
> Thanks
> Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, June 10, 2015 1:38 AM
> To: edk2-devel list
> Subject: [edk2] attention git users: a productivity boost for edk2
> 
> (Sorry about the sensationalist subject line, I don't have a degree in 
> marketing :))
> 
> Edk2 uses a large number of text files with *sections*:
> 
> [Section.LOL]
> 
> I'm sure you've been annoyed quite a few times, while reviewing patches, that 
> you couldn't immediately see the section that a hunk modified. (I know I 
> have.) We used to have two solutions for this:
> 
> - On the reviewer side, apply the patchset and review it patch-wise,
>   against the full source code as context.
> 
> - On the sender side, generate the patches with a larger context.
>   Options are -U, --inter-hunk-context=, and even
>   --function-context. Unfortunately, these don't resolve the question of
>   sections reliably (or they produce overkill output).
> 
> Turns out git has a trick for this up its sleeve: see gitattributes(5).
> 
> (1) Edit your .git/info/attributes file, adding the following lines:
> 
> *.dec diff=ini
> *.dsc diff=ini
> *.dsc.inc diff=ini
> *.fdf diff=ini
> *.fdf.inc diff=ini
> *.inf diff=ini
> 
> (2) in your .git/config, add
> 
> [diff "ini"]
>   xfuncname = "^\\[[A-Za-z0-9_., ]+]"
> 
> I just set these in my edk2 clone, and tested them on my local branch 
> where I had applied Ard's series
> 
>   [PATCH 0/7] ArmPkg/ArmVirtPkg: GIC revision detection
> 
> for review. A good example is patch #4, "ArmPkg: copy ArmGicArchLib to 
> ArmGicArchSecLib". Now I can immediately see, in the hunk headers (@@), what 
> section each change belongs to.
> 
> Here it is (git show output trimmed to relevant files):
> 
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> index 0859bc3..6e6687c 100644
>> --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.

Re: [edk2] [RFC 0/4] OvmfPkg: (almost) enable >= 64 GB guests

[Wei Liu]

On Mon, Jun 08, 2015 at 11:46:47PM +0200, Laszlo Ersek wrote:
> This is in response to
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15253
> http://thread.gmane.org/gmane.comp.emulators.xen.devel/245623
> 
> It's an RFC only because the last patch doesn't actually work. Ideas
> welcome.
> 
> Cc: Maoming 
> Cc: Huangpeng (Peter) 
> Cc: Wei Liu 
> 
> Thanks
> Laszlo
> 

Thanks Laszlo.

I think only the first two patches matter to Xen so I only tested those.
Now I'm able to boot a guest with more than 64GB ram.

Here is what it looks like from a 128 GB guest.

root@debianhvm:~# free -m
 total   used   free sharedbuffers cached
Mem: 12640116  12523  0  6 27
-/+ buffers/cache: 82  12558
Swap:26486  0  26486

Nice work!

Wei.


> Laszlo Ersek (4):
>   OvmfPkg: PlatformPei: enable larger permanent PEI RAM
>   OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space
> width
>   OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
>   OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> 
>  OvmfPkg/PlatformPei/Platform.h  |   7 +++
>  OvmfPkg/PlatformPei/MemDetect.c | 115 
> +++-
>  OvmfPkg/PlatformPei/Platform.c  |   7 ++-
>  3 files changed, 114 insertions(+), 15 deletions(-)
> 
> -- 
> 1.8.3.1

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

Re: [edk2] attention git users: a productivity boost for edk2

[Gao, Liming]

BKM: Best known method. 

I mean .dsc.inc is not standard file postfix. Other people may not use it. Our 
internal project stills use *.dsc file as the subset of DSC to be included in 
the full DSC file. 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, June 10, 2015 7:32 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] attention git users: a productivity boost for edk2

On 06/10/15 03:34, Gao, Liming wrote:
> Good BKM sharing. 

What does BKM mean?

> EDKII meta data file has .inf, .dec, *.dsc and *.fdf. What's *.dsc.inc 
> and *.fdf.inc? They are the part of DSC and FDF files that included in 
> the full DSC and FDF files?

Yes. We have a few examples for them:

- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc
- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
- ArmVirtPkg/ArmVirt.dsc.inc
- OvmfPkg/OvmfPkg.fdf.inc
- OvmfPkg/VarStore.fdf.inc

They are included by DSC and FDF files with the !include directive.

Hm, actually, I just grepped for !include per se, and the suffixes of include 
files are not very consistent. Beyond those listed above, we have:

AppPkg/AppPkg.dsc:!include StdLib/StdLib.inc AppPkg/AppPkg.dsc:!include 
AppPkg/Applications/Sockets/Sockets.inc
StdLib/StdLib.dsc:!include StdLib/StdLib.inc

ie. the full suffix is just .inc. Then,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc

ie. just .dsc. Finally,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt

... I think choosing .txt for DSC include files was a really bad choice.

In any case, I'm adding *.inc to my .git/info/attributes file (which in turn 
obviates *.dsc.inc and *.fdf.inc).

... Hm, no I'm not. For example, BeagleBoardPkg has a number of .inc files that 
don't follow the INI format... Sigh. I guess I'll stick with my current 
entries, and accept that they won't cover the AppPkg and StdLib DSC include 
files.

Thanks!
Laszlo

> 
> Thanks
> Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, June 10, 2015 1:38 AM
> To: edk2-devel list
> Subject: [edk2] attention git users: a productivity boost for edk2
> 
> (Sorry about the sensationalist subject line, I don't have a degree in 
> marketing :))
> 
> Edk2 uses a large number of text files with *sections*:
> 
> [Section.LOL]
> 
> I'm sure you've been annoyed quite a few times, while reviewing patches, that 
> you couldn't immediately see the section that a hunk modified. (I know I 
> have.) We used to have two solutions for this:
> 
> - On the reviewer side, apply the patchset and review it patch-wise,
>   against the full source code as context.
> 
> - On the sender side, generate the patches with a larger context.
>   Options are -U, --inter-hunk-context=, and even
>   --function-context. Unfortunately, these don't resolve the question of
>   sections reliably (or they produce overkill output).
> 
> Turns out git has a trick for this up its sleeve: see gitattributes(5).
> 
> (1) Edit your .git/info/attributes file, adding the following lines:
> 
> *.dec diff=ini
> *.dsc diff=ini
> *.dsc.inc diff=ini
> *.fdf diff=ini
> *.fdf.inc diff=ini
> *.inf diff=ini
> 
> (2) in your .git/config, add
> 
> [diff "ini"]
>   xfuncname = "^\\[[A-Za-z0-9_., ]+]"
> 
> I just set these in my edk2 clone, and tested them on my local branch 
> where I had applied Ard's series
> 
>   [PATCH 0/7] ArmPkg/ArmVirtPkg: GIC revision detection
> 
> for review. A good example is patch #4, "ArmPkg: copy ArmGicArchLib to 
> ArmGicArchSecLib". Now I can immediately see, in the hunk headers (@@), what 
> section each change belongs to.
> 
> Here it is (git show output trimmed to relevant files):
> 
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> index 0859bc3..6e6687c 100644
>> --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> @@ -138,6 +138,7 @@ [LibraryClasses.common.SEC]
>>
>> PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
>>
>> PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
>>PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
>> +  ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
>>
>>  [LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
>>MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc
>> b/ArmPlatformPkg/ArmPlatformPkg.dsc
>> ind

Re: [edk2] UEFI HTTP Boot and Redfish support?

[El-Haj-Mahmoud, Samer]

Lee,

Both HTTP Boot and Redfish are very new standards. HTTP Boot got standardized 
as part of UEFI 2.5 in March. Redfish is still not even 1.0 (last published 
spec is 0.96.0a, with a target 1.0 spec sometime this month according to DMTF). 
It is expected that implementation will take some time to catch up to the spec. 
At the same time, PXE and IPMI have been there for quite some time, are 
implemented across the board on servers (and many clients), and are already in 
wide use. I do not expect them to go away anytime soon. But the goal is to 
switch over to HTTP and Redfish/REST over time, especially as they enable new 
use cases and capabilities that were not possible (or easy to do) before.

The first step though is to get the specs implemented. As Ting explained, Intel 
is working on UEFI 2.5 HTTP Boot implementation (that I expect will show up in 
EDK2. I see the header files submitted already). DMTF is also working on a 
Redfish mockup/simulator that can be used to exercise clients.

HP ProLiant Gen9 servers already support proprietary flavors of both HTTP Boot 
(or "Boot from URL") and Redfish (or the "HP RESTful API"). I do not know of 
any other servers that implement such technologies at this time. 

As to your more general question, that is harder to answer. Usually, OEMs and 
IBVs declare standards supported in their firmware. But even then, the level of 
support and specific firmware versions make are not easy to pinpoint. This is 
the case with any new standard (UEFI/PI included) until the adoption is high 
and the support becomes widely available across the industry.

Thanks,
--Samer


-Original Message-
From: Blibbet [mailto:blib...@gmail.com] 
Sent: Friday, June 05, 2015 7:00 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] UEFI HTTP Boot and Redfish support?

HP gave a talk at the Spring UEFI Forum event titled "Goodbye PXE and IPMI. 
Welcome HTTP Boot and Redfish!".

But a few days ago AMI just released a new IPMI-based product, so "Goodbye 
IPMI" is apparently not a universally agreed upon, pehaps "Welcome to the 
party, pal!" is more approrpiate? :-)

Besides HP, who supports UEFI 2.5 HTTP Boot?

Besides HP, who supports Redfish with their UEFI implementation?

DNS/DHCP/HTTP[S] servers aside, is there enough code in TianoCore to support 
HTTP Boot, or is additional non-TianoCore code required, including HTTPS TLS 
support?

More generally, how do people figure out which IBV/OEMs support UEFI's various 
features? Except for a few OEMs, most consumer merchant pages for hardware 
rarely includes information about firmware, and the main consumer resource 
AFAICT (Consumer Reports) is also ignoring firmware in it's data. The UEFI.org 
pages don't have any information on this. It's hard to determine what features 
in the UEFI Forum spec are in Tianocore, and what are only in commercial 
products. I wish the UEFI Forum would work with its vendor members to help 
clarify the features their products include.

Heck, I'd create a new page on Wikipedia or elsewhere, if I had the data.

Thanks,
Lee
RSS: http://firmwaresecurity.com/feed




--
___
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] [RFC 4/4] OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()

[Laszlo Ersek]

On 06/09/15 04:15, Laszlo Ersek wrote:
> On 06/08/15 23:46, Laszlo Ersek wrote:
>> At the moment we work with a UC default MTRR type, and set three memory
>> ranges to WB:
>> - [0, 640 KB),
>> - [1 MB, LowerMemorySize),
>> - [4 GB, 4 GB + UpperMemorySize).
>>
>> Unfortunately, coverage for the third range can fail with a high
>> likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
>> the size (UpperMemorySize) differ, then MtrrLib creates a series of
>> variable MTRR entries, with power-of-two sized MTRR masks. And, it's
>> really easy to run out of variable MTRR entries, dependent on the
>> alignment difference.
>>
>> This is a problem because a Linux guest will loudly reject any high memory
>> that is not covered my MTRR.
>>
>> So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
>> - flip the MTRR default type to WB,
>> - set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
>>   type and variable MTRRs, so we can't avoid this,
>> - set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
>> - set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
>>   more likely than the other scheme (due to less chaotic alignment
>>   differences).
>>
>> Effects of this patch can be observed by setting DEBUG_CACHE (0x0020)
>> in PcdDebugPrintErrorLevel.
>>
>> BUG: Although the MTRRs look good to me in the OVMF debug log, I still
>> can't boot >= 64 GB guests with this. Instead of the complaints mentioned
>> above, the Linux guest apparently spirals into an infinite loop (on KVM),
>> or hangs with no CPU load (on TCG).
> 
> No, actually there is no bug in this patch (so s/RFC/PATCH/). I did more
> testing and these are the findings:
> - I can reproduce the same issue on KVM with SeaBIOS guests.
> - The exact symptoms are that as soon as the highest guest-phys address
>   is >= 64 GB, then the guest kernel doesn't boot. It gets stuck
>   somewhere after hitting Enter in grub.
> - Normally 3 GB of the guest RAM is mapped under 4 GB in guest-phys
>   address space, then there's a 1 GB PCI hole, and the rest is above
>   4 GB. This means that a 63 GB guest can be started (because 63 - 3 + 4
>   == 64), but if you add just 1 MB more, it won't boot.
> - (This was the big discovery:) I flipped the "ept" parameter of the
>   kvm_intel module on my host to N, and then things started to work. I
>   just booted a 128 GB Linux guest with this patchset. (I have 4 GB
>   RAM in my host, plus approx 250 GB swap.) The guest could see it all.
> - The TCG boot didn't hang either; I just couldn't wait earlier for
>   network initialization to complete.
> 
> I'm CC'ing Paolo for help with the EPT question. Other than that, this
> series is functional. (For QEMU/KVM at least; Xen will likely need more
> fixes from others.)

We have a root cause, it seems. The issue is that the processor in my
laptop, on which I tested, has only 36 bits for physical addresses:

  $ grep 'address sizes' /proc/cpuinfo
  address sizes   : 36 bits physical, 48 bits virtual
  ...

Which matches where the problem surfaces (64 GB guest-phys address
space) with hw-supported nested paging (EPT) enabled on the host.

In order to confirm this, a colleague of mine gave me access to a server
with 96 GB of RAM, and:

  address sizes : 46 bits physical, 48 bits virtual

On this host I booted a 72 GB OVMF guest on QEMU/KVM, with EPT enabled,
and according to the guest dmesg, the guest saw it all.

  Memory: 74160924K/75493820K available (7735K kernel code, 1149K
  rwdata, 3340K rodata, 1500K init, 1524K bss, 1332896K reserved, 0K
  cma-reserved)

Maoming: since you reported this issue, please confirm that the patch
series resolves it for you as well. In that case, I'll repost the series
with "PATCH" as subject-prefix instead of "RFC", and I'll drop the BUG
note from the last commit message.

Thanks
Laszlo

>> Cc: Maoming 
>> Cc: Huangpeng (Peter) 
>> Cc: Wei Liu 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  OvmfPkg/PlatformPei/MemDetect.c | 43 
>> +
>>  1 file changed, 39 insertions(+), 4 deletions(-)
>>
>> diff --git a/OvmfPkg/PlatformPei/MemDetect.c 
>> b/OvmfPkg/PlatformPei/MemDetect.c
>> index 3ceb142..cceab22 100644
>> --- a/OvmfPkg/PlatformPei/MemDetect.c
>> +++ b/OvmfPkg/PlatformPei/MemDetect.c
>> @@ -194,6 +194,8 @@ QemuInitializeRam (
>>  {
>>UINT64  LowerMemorySize;
>>UINT64  UpperMemorySize;
>> +  MTRR_SETTINGS   MtrrSettings;
>> +  EFI_STATUS  Status;
>>  
>>DEBUG ((EFI_D_INFO, "%a called\n", __FUNCTION__));
>>  
>> @@ -214,12 +216,45 @@ QemuInitializeRam (
>>  }
>>}
>>  
>> -  MtrrSetMemoryAttribute (BASE_1MB, LowerMemorySize - BASE_1MB, 
>> CacheWriteBack);
>> +  //
>> +  // We'd like to keep the following ranges uncached:
>> +  // - [640 KB, 1 MB)
>> +  // - [LowerMemorySize, 4 GB)
>> +  //
>> +  // Ever

Re: [edk2] PXB fixes for QEMU, and extra root buses for OVMF

[Laszlo Ersek]

On 06/10/15 13:55, Marcel Apfelbaum wrote:
> On 06/10/2015 02:04 PM, Laszlo Ersek wrote:
>> On 06/10/15 11:09, Marcel Apfelbaum wrote:
>>> On 06/06/2015 02:45 AM, Laszlo Ersek wrote:
>>
 (7) At least one issue remains to be solved (designed) in QEMU, for
 both
   SeaBIOS's and OVMF's sake: booting off devices that are
 located on
   the PXB. The problem is with the "bootorder" fw_cfg file.
 Consider
   the following example:

 /pci@i0cf8/scsi@3/channel@0/disk@0,0
 /pci/pci-bridge@0/ethernet@2/ethernet-phy@0

   which is generated for the options

 -device virtio-scsi-pci,id=scsi0 \
 -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
 \
 -device pxb,id=bridge1,bus_nr=4 \
 -device
 e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=1

   While the first entry is recognized by both SeaBIOS and OVMF, the
   second entry (generated for the NIC hanging off the PXB, see
 above)
   is recognized by neither. (I tested OVMF, and investigated the
   SeaBIOS source, for this claim.)

   For the SeaBIOS explanation, grep the source code for
 FW_PCI_DOMAIN.
>>> Thanks for bringing it to my attention.
>>>

   The OVMF explanation is that OVMF simply rejects the initial
   OpenFirmware device path node "/pci" with a controlled parse
 error
   (as opposed to the "/pci@i0cf8" node, which it recognizes and
   translates to UEFI in combination with the rest of that OFW
 device
   path).

   The "/pci" node comes from QEMU's sysbus_get_fw_dev_path()
 function,
   file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) and
   (s->num_pio) branches apply. (The (s->num_pio) branch applies for
   the first entry, ie. "/pci@i0cf8".)

   Something has to be invented here to clue in both firmwares as to
   the root bus number (here bus_nr=4), in a format that is
 compliant
   with the "OpenFirmware unit address" concept. (Note that
   "/pci-bridge@0" only gives away the slot number *on* the extra
 root
   bus, not the number of the root bus itself.) For example:

 /pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0

   would be acceptable. However, I don't know how to implement
 this in
   sysbus_get_fw_dev_path().
>>> I'll look into it. What is the OpenFirmware unit address" concept ? :)
>>
>> Okay, I looked it up again (also rechecked the OVMF parser code) -- in
>> fact the example I gave would not be preferable.
>>
>> * Background:
>>
>> For the specification, please see "3.2.1.1 Node names" in
>>
>>IEEE Standard for Boot (Initialization Configuration)
>>Firmware: Core Requirements and Practices
>>
>> The notation is
>>
>>driver-name@unit-address:device-arguments
>>
>> It says (excerpt):
>>
>>The /driver name/ field is a sequence of between one and 31 letters,
>>digits, and punctuation characters from the set “, . _ + - ”.
>>Uppercase and lowercase characters are distinct. [...]
>>
>>[...]
>>
>>The /unit address/ field is the text representation of the physical
>>address of the device within the address space defined by its parent
>>node. The form of the text representation is bus-dependent.
>>
>> Please see the TranslatePciOfwNodes() function in OVMF, for the
>> "PCI-like" OFW device paths that OVMF currently recognizes -- just
>> scroll through the function to see the comments:
>>
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c#L582
>>
>>
>> * Therefore, the only kind of /unit address/ that OVMF has faced,
>> exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF
>> uses the helper function ParseUnitAddressHexList() to parse them. (It is
>> defined in the same file linked above.)
>>
>> It would be preferable to stick with this assumption. Therefore, let me
>> revise my earlier recommendation, and ask for:
>>
>>/pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0
>> ^
>> bus_nr (hex, without 0x prefix)
>>
>> instead. Providing "pxb" as /driver name/ in the very first OFW node
>> would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize
>> the extra root bus. The single hex integer in the /unit address/ of the
>> first node would identify bus_nr. The rest of the nodes in the OFW
>> devpath are already recognized by OVMF.
>>
>> An alternative would be simply
>>
>>/pci@4
>>
>> (quoting just the first node), because I can still tell apart the
>> numeric ("4") /unit address/ from the "i0cf8" one that identifies the
>> main root bus.
>>
>> Summary: either of the following would be okay:
>>
>>/pxb@4
>>/pci@4
> Thanks a lot for the pointer. I prefer the latest.

Indeed, the current initial no

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.

[Ard Biesheuvel]

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,(int)num,NULL,0)
>> - # define OPENSSL_freeFuncCRYPTO_free
>> - # define OPENSSL_free(addr)  CRYPTO_free(addr)
>> -
>> - # define OPENSSL_malloc_locked(num) \
>> --CRYPTO_malloc_locked((int)num,__FILE__,__LINE__)
>> -+CRYPTO_malloc_locked((int)num,NULL,0)
>> - # define OPENSSL_free_locked(addr) CRYPTO_free_locked(addr)
>> -
>> - const char *SSLeay_version(int type);
>> -@@ -531,7 +531,7 @@
>> - long CRYPTO_get_mem_debug_options(void);
>> -
>> - # define CRYPTO_push_info(info) \
>> --CRYPTO_push_info_(info, __FILE__, __LINE__);
>> -+CRYPTO_push_info_(info, NULL, 0);
>> - int CRYPTO_push_info_(const char *info, const char *file, int line);
>> - int CRYPTO_pop_info(void);
>> - int CRYPTO_remove_all_info(void);
>> -@@ -578,7 +578,7 @@
>> -
>> - /* die if we have to */
>> - void OpenSSLDie(const char *file, int line, const char *assertion);
>> --# define OPENSSL_assert(e)   (void)((e) ? 0 : (OpenSSLDie(__FILE__, 
>> __LINE__, #e),1))
>> -+# defi

Re: [edk2] PXB fixes for QEMU, and extra root buses for OVMF

[Marcel Apfelbaum]

On 06/10/2015 02:04 PM, Laszlo Ersek wrote:
> On 06/10/15 11:09, Marcel Apfelbaum wrote:
>> On 06/06/2015 02:45 AM, Laszlo Ersek wrote:
>
>>> (7) At least one issue remains to be solved (designed) in QEMU, for both
>>>   SeaBIOS's and OVMF's sake: booting off devices that are located on
>>>   the PXB. The problem is with the "bootorder" fw_cfg file. Consider
>>>   the following example:
>>>
>>> /pci@i0cf8/scsi@3/channel@0/disk@0,0
>>> /pci/pci-bridge@0/ethernet@2/ethernet-phy@0
>>>
>>>   which is generated for the options
>>>
>>> -device virtio-scsi-pci,id=scsi0 \
>>> -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
>>> \
>>> -device pxb,id=bridge1,bus_nr=4 \
>>> -device
>>> e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=1
>>>
>>>   While the first entry is recognized by both SeaBIOS and OVMF, the
>>>   second entry (generated for the NIC hanging off the PXB, see above)
>>>   is recognized by neither. (I tested OVMF, and investigated the
>>>   SeaBIOS source, for this claim.)
>>>
>>>   For the SeaBIOS explanation, grep the source code for FW_PCI_DOMAIN.
>> Thanks for bringing it to my attention.
>>
>>>
>>>   The OVMF explanation is that OVMF simply rejects the initial
>>>   OpenFirmware device path node "/pci" with a controlled parse error
>>>   (as opposed to the "/pci@i0cf8" node, which it recognizes and
>>>   translates to UEFI in combination with the rest of that OFW device
>>>   path).
>>>
>>>   The "/pci" node comes from QEMU's sysbus_get_fw_dev_path() function,
>>>   file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) and
>>>   (s->num_pio) branches apply. (The (s->num_pio) branch applies for
>>>   the first entry, ie. "/pci@i0cf8".)
>>>
>>>   Something has to be invented here to clue in both firmwares as to
>>>   the root bus number (here bus_nr=4), in a format that is compliant
>>>   with the "OpenFirmware unit address" concept. (Note that
>>>   "/pci-bridge@0" only gives away the slot number *on* the extra root
>>>   bus, not the number of the root bus itself.) For example:
>>>
>>> /pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0
>>>
>>>   would be acceptable. However, I don't know how to implement this in
>>>   sysbus_get_fw_dev_path().
>> I'll look into it. What is the OpenFirmware unit address" concept ? :)
>
> Okay, I looked it up again (also rechecked the OVMF parser code) -- in
> fact the example I gave would not be preferable.
>
> * Background:
>
> For the specification, please see "3.2.1.1 Node names" in
>
>IEEE Standard for Boot (Initialization Configuration)
>Firmware: Core Requirements and Practices
>
> The notation is
>
>driver-name@unit-address:device-arguments
>
> It says (excerpt):
>
>The /driver name/ field is a sequence of between one and 31 letters,
>digits, and punctuation characters from the set “, . _ + - ”.
>Uppercase and lowercase characters are distinct. [...]
>
>[...]
>
>The /unit address/ field is the text representation of the physical
>address of the device within the address space defined by its parent
>node. The form of the text representation is bus-dependent.
>
> Please see the TranslatePciOfwNodes() function in OVMF, for the
> "PCI-like" OFW device paths that OVMF currently recognizes -- just
> scroll through the function to see the comments:
>
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c#L582
>
> * Therefore, the only kind of /unit address/ that OVMF has faced,
> exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF
> uses the helper function ParseUnitAddressHexList() to parse them. (It is
> defined in the same file linked above.)
>
> It would be preferable to stick with this assumption. Therefore, let me
> revise my earlier recommendation, and ask for:
>
>/pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0
> ^
> bus_nr (hex, without 0x prefix)
>
> instead. Providing "pxb" as /driver name/ in the very first OFW node
> would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize
> the extra root bus. The single hex integer in the /unit address/ of the
> first node would identify bus_nr. The rest of the nodes in the OFW
> devpath are already recognized by OVMF.
>
> An alternative would be simply
>
>/pci@4
>
> (quoting just the first node), because I can still tell apart the
> numeric ("4") /unit address/ from the "i0cf8" one that identifies the
> main root bus.
>
> Summary: either of the following would be okay:
>
>/pxb@4
>/pci@4
Thanks a lot for the pointer. I prefer the latest.
I'll get to it.

Thanks,
Marcel

>
> Thanks
> Laszlo
>


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

Re: [edk2] attention git users: a productivity boost for edk2

[Laszlo Ersek]

On 06/10/15 03:34, Gao, Liming wrote:
> Good BKM sharing. 

What does BKM mean?

> EDKII meta data file has .inf, .dec, *.dsc and *.fdf. What's
> *.dsc.inc and *.fdf.inc? They are the part of DSC and FDF files that
> included in the full DSC and FDF files?

Yes. We have a few examples for them:

- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc
- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc
- ArmVirtPkg/ArmVirt.dsc.inc
- OvmfPkg/OvmfPkg.fdf.inc
- OvmfPkg/VarStore.fdf.inc

They are included by DSC and FDF files with the !include directive.

Hm, actually, I just grepped for !include per se, and the suffixes of include 
files are not very consistent. Beyond those listed above, we have:

AppPkg/AppPkg.dsc:!include StdLib/StdLib.inc
AppPkg/AppPkg.dsc:!include AppPkg/Applications/Sockets/Sockets.inc
StdLib/StdLib.dsc:!include StdLib/StdLib.inc

ie. the full suffix is just .inc. Then,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/PlatformPkgConfig.dsc

ie. just .dsc. Finally,

Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt
Vlv2TbltDevicePkg/PlatformPkgX64.dsc:  !include 
$(PLATFORM_PACKAGE)/AutoPlatformCFG.txt

... I think choosing .txt for DSC include files was a really bad choice.

In any case, I'm adding *.inc to my .git/info/attributes file (which in turn 
obviates *.dsc.inc and *.fdf.inc).

... Hm, no I'm not. For example, BeagleBoardPkg has a number of .inc files that 
don't follow the INI format... Sigh. I guess I'll stick with my current 
entries, and accept that they won't cover the AppPkg and StdLib DSC include 
files.

Thanks!
Laszlo

> 
> Thanks
> Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Wednesday, June 10, 2015 1:38 AM
> To: edk2-devel list
> Subject: [edk2] attention git users: a productivity boost for edk2
> 
> (Sorry about the sensationalist subject line, I don't have a degree in 
> marketing :))
> 
> Edk2 uses a large number of text files with *sections*:
> 
> [Section.LOL]
> 
> I'm sure you've been annoyed quite a few times, while reviewing patches, that 
> you couldn't immediately see the section that a hunk modified. (I know I 
> have.) We used to have two solutions for this:
> 
> - On the reviewer side, apply the patchset and review it patch-wise,
>   against the full source code as context.
> 
> - On the sender side, generate the patches with a larger context.
>   Options are -U, --inter-hunk-context=, and even
>   --function-context. Unfortunately, these don't resolve the question of
>   sections reliably (or they produce overkill output).
> 
> Turns out git has a trick for this up its sleeve: see gitattributes(5).
> 
> (1) Edit your .git/info/attributes file, adding the following lines:
> 
> *.dec diff=ini
> *.dsc diff=ini
> *.dsc.inc diff=ini
> *.fdf diff=ini
> *.fdf.inc diff=ini
> *.inf diff=ini
> 
> (2) in your .git/config, add
> 
> [diff "ini"]
>   xfuncname = "^\\[[A-Za-z0-9_., ]+]"
> 
> I just set these in my edk2 clone, and tested them on my local branch where I 
> had applied Ard's series
> 
>   [PATCH 0/7] ArmPkg/ArmVirtPkg: GIC revision detection
> 
> for review. A good example is patch #4, "ArmPkg: copy ArmGicArchLib to 
> ArmGicArchSecLib". Now I can immediately see, in the hunk headers (@@), what 
> section each change belongs to.
> 
> Here it is (git show output trimmed to relevant files):
> 
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc 
>> b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> index 0859bc3..6e6687c 100644
>> --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc
>> @@ -138,6 +138,7 @@ [LibraryClasses.common.SEC]
>>
>> PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
>>
>> PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
>>PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
>> +  ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
>>
>>  [LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
>>MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
>> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc 
>> b/ArmPlatformPkg/ArmPlatformPkg.dsc
>> index be31025..14d82f6 100644
>> --- a/ArmPlatformPkg/ArmPlatformPkg.dsc
>> +++ b/ArmPlatformPkg/ArmPlatformPkg.dsc
>> @@ -134,6 +134,8 @@ [LibraryClasses.common.SEC]
>>
>> DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
>>
>> DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/D
>> efaultExceptionHandlerLibBase.inf
>>
>> +  ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLi

[edk2] [Patch] BaseTools: Fixed an error reported during generating report.

[Yingke Liu]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/build/BuildReport.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index 327d5a5..264607b 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -1237,10 +1237,10 @@ class FdRegionReport(object):
 #
 # Collect PCDs defined in DSC common section
 #
-for Platform in Wa.BuildDatabase.WorkspaceDb.PlatformList:
-for (TokenCName, TokenSpaceGuidCName) in Platform.Pcds:
-DscDefaultValue = Platform.Pcds[(TokenCName, 
TokenSpaceGuidCName)].DefaultValue
-PlatformPcds[(TokenCName, TokenSpaceGuidCName)] = 
DscDefaultValue
+Platform = Wa.BuildDatabase[Wa.MetaFile, 'COMMON']
+for (TokenCName, TokenSpaceGuidCName) in Platform.Pcds:
+DscDefaultValue = Platform.Pcds[(TokenCName, 
TokenSpaceGuidCName)].DefaultValue
+PlatformPcds[(TokenCName, TokenSpaceGuidCName)] = DscDefaultValue
 
 #
 # Add PEI and DXE a priori files GUIDs defined in PI specification.
-- 
1.9.5.msysgit.0


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

Re: [edk2] PXB fixes for QEMU, and extra root buses for OVMF

[Laszlo Ersek]

On 06/10/15 11:09, Marcel Apfelbaum wrote:
> On 06/06/2015 02:45 AM, Laszlo Ersek wrote:

>> (7) At least one issue remains to be solved (designed) in QEMU, for both
>>  SeaBIOS's and OVMF's sake: booting off devices that are located on
>>  the PXB. The problem is with the "bootorder" fw_cfg file. Consider
>>  the following example:
>>
>>/pci@i0cf8/scsi@3/channel@0/disk@0,0
>>/pci/pci-bridge@0/ethernet@2/ethernet-phy@0
>>
>>  which is generated for the options
>>
>>-device virtio-scsi-pci,id=scsi0 \
>>-device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
>>\
>>-device pxb,id=bridge1,bus_nr=4 \
>>-device
>> e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=1
>>
>>  While the first entry is recognized by both SeaBIOS and OVMF, the
>>  second entry (generated for the NIC hanging off the PXB, see above)
>>  is recognized by neither. (I tested OVMF, and investigated the
>>  SeaBIOS source, for this claim.)
>>
>>  For the SeaBIOS explanation, grep the source code for FW_PCI_DOMAIN.
> Thanks for bringing it to my attention.
> 
>>
>>  The OVMF explanation is that OVMF simply rejects the initial
>>  OpenFirmware device path node "/pci" with a controlled parse error
>>  (as opposed to the "/pci@i0cf8" node, which it recognizes and
>>  translates to UEFI in combination with the rest of that OFW device
>>  path).
>>
>>  The "/pci" node comes from QEMU's sysbus_get_fw_dev_path() function,
>>  file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) and
>>  (s->num_pio) branches apply. (The (s->num_pio) branch applies for
>>  the first entry, ie. "/pci@i0cf8".)
>>
>>  Something has to be invented here to clue in both firmwares as to
>>  the root bus number (here bus_nr=4), in a format that is compliant
>>  with the "OpenFirmware unit address" concept. (Note that
>>  "/pci-bridge@0" only gives away the slot number *on* the extra root
>>  bus, not the number of the root bus itself.) For example:
>>
>>/pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0
>>
>>  would be acceptable. However, I don't know how to implement this in
>>  sysbus_get_fw_dev_path().
> I'll look into it. What is the OpenFirmware unit address" concept ? :)

Okay, I looked it up again (also rechecked the OVMF parser code) -- in
fact the example I gave would not be preferable.

* Background:

For the specification, please see "3.2.1.1 Node names" in

  IEEE Standard for Boot (Initialization Configuration)
  Firmware: Core Requirements and Practices

The notation is

  driver-name@unit-address:device-arguments

It says (excerpt):

  The /driver name/ field is a sequence of between one and 31 letters,
  digits, and punctuation characters from the set “, . _ + - ”.
  Uppercase and lowercase characters are distinct. [...]

  [...]

  The /unit address/ field is the text representation of the physical
  address of the device within the address space defined by its parent
  node. The form of the text representation is bus-dependent.

Please see the TranslatePciOfwNodes() function in OVMF, for the
"PCI-like" OFW device paths that OVMF currently recognizes -- just
scroll through the function to see the comments:

https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c#L582

* Therefore, the only kind of /unit address/ that OVMF has faced,
exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF
uses the helper function ParseUnitAddressHexList() to parse them. (It is
defined in the same file linked above.)

It would be preferable to stick with this assumption. Therefore, let me
revise my earlier recommendation, and ask for:

  /pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0
   ^
   bus_nr (hex, without 0x prefix)

instead. Providing "pxb" as /driver name/ in the very first OFW node
would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize
the extra root bus. The single hex integer in the /unit address/ of the
first node would identify bus_nr. The rest of the nodes in the OFW
devpath are already recognized by OVMF.

An alternative would be simply

  /pci@4

(quoting just the first node), because I can still tell apart the
numeric ("4") /unit address/ from the "i0cf8" one that identifies the
main root bus.

Summary: either of the following would be okay:

  /pxb@4
  /pci@4

Thanks
Laszlo

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

Re: [edk2] "cond" vs. ?

[Ard Biesheuvel]

On 10 June 2015 at 12:45, Tim Lewis  wrote:
> There is already an example in the VFR specification. But there is no
> comment to indicate which is “TRUE” and which is “FALSE”
>

Just adding my 2 cents here: I think it's ludicrous to adopt the C
syntax for a conditional expression (i.e., ? and :) but invert the
meaning.

Is there anything that could be done about that?

>
>
> 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
>

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

Re: [edk2] "cond" vs. ?

[Tim Lewis]

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

[edk2] AARCH64: Timer Dxe

[Sharma Bhupesh]

Hi Olivier,

1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE driver and 
seeing how the timer interrupts are registered:

  // Install secure and Non-secure interrupt handlers
  // Note: Because it is not possible to determine the security state of the
  // CPU dynamically, we just install interrupt handler for both sec and non-sec
  // timer PPI
  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerVirtIntrNum), TimerInterruptHandler);
  ASSERT_EFI_ERROR (Status);

  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerHypIntrNum), TimerInterruptHandler);
  ASSERT_EFI_ERROR (Status);

  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerSecIntrNum), TimerInterruptHandler);
  ASSERT_EFI_ERROR (Status);

  Status = gInterrupt->RegisterInterruptSource (gInterrupt, PcdGet32 
(PcdArmArchTimerIntrNum), TimerInterruptHandler);
  ASSERT_EFI_ERROR (Status);

I wanted to understand how the Interrupt registration changes for PPI or SPI 
interrupt sources.
As usually the Virtual, Hypervisor, Physical and Physical Non-Secure interrupts 
are PPI does the PPI number
need to be defined as the PCD values in the same way as linux. The Linux gicv3 
documentation says
(Documentation/devicetree/bindings/arm/gic-v3.txt):

SPI interrupts are in the range [0-987]. PPI interrupts are in the range [0-15].

2. Also one related question is whether on Juno Rev1, you are able to get the 
BootDelay to work via timer based events? If yes, can you please share if you 
achieve this by using the ARMv8 generic timer or the SP804 timer.

Regards,
Bhupesh

--
___
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.

[Ard Biesheuvel]

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 

> ---
>  .../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,(int)num,NULL,0)
> - # define OPENSSL_freeFuncCRYPTO_free
> - # define OPENSSL_free(addr)  CRYPTO_free(addr)
> -
> - # define OPENSSL_malloc_locked(num) \
> --CRYPTO_malloc_locked((int)num,__FILE__,__LINE__)
> -+CRYPTO_malloc_locked((int)num,NULL,0)
> - # define OPENSSL_free_locked(addr) CRYPTO_free_locked(addr)
> -
> - const char *SSLeay_version(int type);
> -@@ -531,7 +531,7 @@
> - long CRYPTO_get_mem_debug_options(void);
> -
> - # define CRYPTO_push_info(info) \
> --CRYPTO_push_info_(info, __FILE__, __LINE__);
> -+CRYPTO_push_info_(info, NULL, 0);
> - int CRYPTO_push_info_(const char *info, const char *file, int line);
> - int CRYPTO_pop_info(void);
> - int CRYPTO_remove_all_info(void);
> -@@ -578,7 +578,7 @@
> -
> - /* die if we have to */
> - void OpenSSLDie(const char *file, int line, const char *assertion);
> --# define OPENSSL_assert(e)   (void)((e) ? 0 : (OpenSSLDie(__FILE__, 
> __LINE__, #e),1))
> -+# define OPENSSL_assert(e)   (void)((e) ? 0 : (OpenSSLDie(NULL, 0, 
> #e),1))
> -
> - unsigned long *OPENSSL_ia32cap_loc(void);
> - # define OPENSSL_ia32cap (*(OPENSSL_ia32cap_loc()))
> -@@ -585,10 +585,10 @@
> - int OPENSSL_isservice(void);
> -
> - # ifdef OPENSSL_FIPS
> --#  define FIPS_ERROR_IGNORED(alg) OpenSSLDie(__FILE__, __LINE__, \
> -+#  define FIPS_ERROR_IGNORED(alg) OpenS

Re: [edk2] [patch 2/3] [CryptoPkg] Update INF file, installation scripts and HOWTO for openssl-1.0.2a support.

[Ard Biesheuvel]

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 
> ---
>  CryptoPkg/Library/OpensslLib/Install.cmd | 146 ---
>  CryptoPkg/Library/OpensslLib/Install.sh  | 146 ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf  | 620 
> +++
>  CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt |  46 +-
>  4 files changed, 608 insertions(+), 350 deletions(-)
>
> diff --git a/CryptoPkg/Library/OpensslLib/Install.cmd 
> b/CryptoPkg/Library/OpensslLib/Install.cmd
> index 8f1d016..a633f57 100755
> --- a/CryptoPkg/Library/OpensslLib/Install.cmd
> +++ b/CryptoPkg/Library/OpensslLib/Install.cmd
> @@ -1,71 +1,77 @@
> -cd openssl-0.9.8zf
> -copy e_os2.h  ..\..\..\Include\openssl
> -copy crypto\crypto.h  ..\..\..\Include\openssl
> -copy crypto\tmdiff.h  ..\..\..\Include\openssl
> -copy crypto\opensslv.h ..\..\..\Include\openssl
> -copy crypto\opensslconf.h ..\..\..\Include\openssl
> -copy crypto\ebcdic.h ..\..\..\Include\openssl
> -copy crypto\symhacks.h ..\..\..\Include\openssl
> -copy crypto\ossl_typ.h ..\..\..\Include\openssl
> -copy crypto\md2\md2.h ..\..\..\Include\openssl
> -copy crypto\md4\md4.h ..\..\..\Include\openssl
> -copy crypto\md5\md5.h ..\..\..\Include\openssl
> -copy crypto\sha\sha.h ..\..\..\Include\openssl
> -copy crypto\hmac\hmac.h ..\..\..\Include\openssl
> -copy crypto\ripemd\ripemd.h ..\..\..\Include\openssl
> -copy crypto\des\des.h ..\..\..\Include\openssl
> -copy crypto\des\des_old.h ..\..\..\Include\openssl
> -copy crypto\rc2\rc2.h ..\..\..\Include\openssl
> -copy crypto\rc4\rc4.h ..\..\..\Include\openssl
> -copy crypto\idea\idea.h ..\..\..\Include\openssl
> -copy crypto\bf\blowfish.h ..\..\..\Include\openssl
> -copy crypto\cast\cast.h ..\..\..\Include\openssl
> -copy crypto\aes\aes.h ..\..\..\Include\openssl
> -copy crypto\bn\bn.h ..\..\..\Include\openssl
> -copy crypto\rsa\rsa.h ..\..\..\Include\openssl
> -copy crypto\dsa\dsa.h ..\..\..\Include\openssl
> -copy crypto\dso\dso.h ..\..\..\Include\openssl
> -copy crypto\dh\dh.h ..\..\..\Include\openssl
> -copy crypto\ec\ec.h ..\..\..\Include\openssl
> -copy crypto\ecdh\ecdh.h ..\..\..\Include\openssl
> -copy crypto\ecdsa\ecdsa.h ..\..\..\Include\openssl
> -copy crypto\buffer\buffer.h ..\..\..\Include\openssl
> -copy crypto\bio\bio.h ..\..\..\Include\openssl
> -copy crypto\stack\stack.h ..\..\..\Include\openssl
> -copy crypto\stack\safestack.h ..\..\..\Include\openssl
> -copy crypto\lhash\lhash.h ..\..\..\Include\openssl
> -copy crypto\rand\rand.h ..\..\..\Include\openssl
> -copy crypto\err\err.h ..\..\..\Include\openssl
> -copy crypto\objects\objects.h ..\..\..\Include\openssl
> -copy crypto\objects\obj_mac.h ..\..\..\Include\openssl
> -copy crypto\evp\evp.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1_mac.h ..\..\..\Include\openssl
> -copy crypto\asn1\asn1t.h ..\..\..\Include\openssl
> -copy crypto\pem\pem.h ..\..\..\Include\openssl
> -copy crypto\pem\pem2.h ..\..\..\Include\openssl
> -copy crypto\x509\x509.h ..\..\..\Include\openssl
> -copy crypto\x509\x509_vfy.h ..\..\..\Include\openssl
> -copy crypto\x509v3\x509v3.h ..\..\..\Include\openssl
> -copy crypto\conf\conf.h ..\..\..\Include\openssl
> -copy crypto\conf\conf_api.h ..\..\..\Include\openssl
> -copy crypto\txt_db\txt_db.h ..\..\..\Include\openssl
> -copy crypto\pkcs7\pkcs7.h ..\..\..\Include\openssl
> -copy crypto\pkcs12\pkcs12.h ..\..\..\Include\openssl
> -copy crypto\comp\comp.h ..\..\..\Include\openssl
> -copy crypto\engine\engine.h ..\..\..\Include\openssl
> -copy crypto\ocsp\ocsp.h ..\..\..\Include\openssl
> -copy crypto\ui\ui.h ..\..\..\Include\openssl
> -copy crypto\ui\ui_compat.h ..\..\..\Include\openssl
> -copy crypto\krb5\krb5_asn.h ..\..\..\Include\openssl
> -copy crypto\store\store.h ..\..\..\Include\openssl
> -copy crypto\pqueue\pqueue.h ..\..\..\Include\openssl
> -copy crypto\pqueue\pq_compat.h ..\..\..\Include\openssl
> -copy ssl\ssl.h ..\..\..\Include\openssl
> -copy ssl\ssl2.h ..\..\..\Include\openssl
> -copy ssl\ssl3.h ..\..\..\Include\openssl
> -copy ssl\ssl23.h ..\..\..\Include\openssl
> -copy ssl\tls1.h ..\..\..\Include\openssl
> -copy ssl\dtls1.h ..\..\..\Include\openssl
> -copy ssl\kssl.h ..\..\..\Include\openssl
> +cd openssl-1.0.2a
> +copy e_os2.h..\..\..\Include\openssl
> +copy crypto\crypto.h..\..\..\Include\openssl

I understand that it is neater to line up the paths on the right hand
side, but it completely obfuscates the actual changes you made.

For now, I think it is fine, but next time, please try to split
unrelated white space changes into a separate patch so reviewers can
actually tell easily what you changed.

> +copy crypto\opensslv.h  ..\..\..\Include\openssl
> +copy crypto\opensslconf.h   ..\..\..\Include\openssl
> +copy crypto\ebcdic.h..\..\..\Include\openssl
> +copy crypto\symhacks.h  ..\..\..\Incl

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.

[Ard Biesheuvel]

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 

This builds correctly now under GCC/AArch64.

Reviewed-by: Ard Biesheuvel 

> ---
>  CryptoPkg/Include/OpenSslSupport.h|  8 +++-
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c |  6 --
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c| 10 +-
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c  | 13 +++--
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c   | 12 
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c |  8 +---
>  6 files changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/CryptoPkg/Include/OpenSslSupport.h 
> b/CryptoPkg/Include/OpenSslSupport.h
> index ed889e9..b5a8b58 100644
> --- a/CryptoPkg/Include/OpenSslSupport.h
> +++ b/CryptoPkg/Include/OpenSslSupport.h
> @@ -1,7 +1,7 @@
>  /** @file
>Root include file to support building OpenSSL Crypto Library.
>
> -Copyright (c) 2010 - 2011, Intel Corporation. All rights reserved.
> +Copyright (c) 2010 - 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
> @@ -109,6 +109,11 @@ struct tm {
>char  *tm_zone;   /* timezone abbreviation */
>  };
>
> +struct timeval {
> +  long tv_sec;  /* time value, in seconds */
> +  long tv_usec; /* time value, in microseconds */
> +} timeval;
> +
>  struct dirent {
>UINT32  d_fileno; /* file number of entry */
>UINT16  d_reclen; /* length of this record */
> @@ -240,5 +245,6 @@ extern FILE  *stdout;
>  #define assert(expression)
>  #define localtime(timer)  NULL
>  #define gmtime_r(timer,result)(result = NULL)
> +#define atoi(nptr)AsciiStrDecimalToUintn(nptr)
>
>  #endif
> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c 
> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
> index 4ce2b06..9e93355 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;
> +  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  = AuthData;
> +  Pkcs7 = d2i_PKCS7 (NULL, &Temp, (int)DataSize);
>if (Pkcs7 == NULL) {
>  goto _Exit;
>}
> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c 
> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
> index 63fe78f..704eb4e 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c
> @@ -1,7 +1,7 @@
>  /** @file
>PKCS#7 SignedData Sign Wrapper Implementation over OpenSSL.
>
> -Copyright (c) 2009 - 2013, 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
> @@ -116,9 +116,9 @@ Pkcs7Sign (
>if (Key == NULL) {
>  goto _Exit;
>}
> -  Key->save_type = EVP_PKEY_RSA;
> -  Key->type  = EVP_PKEY_type (EVP_PKEY_RSA);
> -  Key->pkey.rsa  = (RSA *) RsaContext;
> +  if (EVP_PKEY_assign_RSA (Key, (RSA *) RsaContext) == 0) {
> +goto _Exit;
> +  }
>
>//
>// Convert the data to be signed to BIO format.
> @@ -175,7 +175,7 @@ Pkcs7Sign (
>}
>
>CopyMem (*SignedData, P7Data + 19, *SignedDataSize);
> -
> +
>OPENSSL_free (P7Data);
>
>Status = TRUE;
> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c 
> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
> index a9665d5..863e4b7 100644
> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c
> @@ -10,7 +10,7 @@
>WrapPkcs7Data(), Pkcs7GetSigners(), Pkcs7Verify() will get UEFI 
>

Re: [edk2] "cond" vs. ?

[Gao, Liming]

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

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

[Star Zeng]

Cc: Jiewen Yao 
Cc: Ruiyu Ni 
Star Zeng (2):
  SecurityPkg Variable: Move VariableLock install into
SmmVariableReady().
  MdeModulePkg Variable: Move VariableLock install into
SmmVariableReady().

 .../Variable/RuntimeDxe/VariableSmmRuntimeDxe.c| 41 +++---
 .../RuntimeDxe/VariableSmmRuntimeDxe.c | 41 +++---
 2 files changed, 40 insertions(+), 42 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] MdeModulePkg Variable: Move VariableLock install into SmmVariableReady().

[Star Zeng]

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

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

[Star Zeng]

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 
---
 .../RuntimeDxe/VariableSmmRuntimeDxe.c | 41 +++---
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableSmmRuntimeDxe.c 
b/SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableSmmRuntimeDxe.c
index 94b60bf..ffa0b07 100644
--- a/SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableSmmRuntimeDxe.c
+++ b/SecurityPkg/VariableAuthenticated/RuntimeDxe/VariableSmmRuntimeDxe.c
@@ -961,6 +961,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);
 }
 
 
@@ -1018,7 +1038,6 @@ VariableSmmRuntimeInitialize (
   IN EFI_SYSTEM_TABLE   *SystemTable
   )
 {
-  EFI_STATUSStatus;
   VOID  *SmmVariableRegistration;
   VOID  *SmmVariableWriteRegistration;
   EFI_EVENT OnReadyToBootEvent;
@@ -1027,26 +1046,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] "cond" vs. ?

[Tim Lewis]

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]Vlv2TbltDevicePkg: Remove runtime attribute for PlatformInfo Variable and Fix Timeout variable issue

[Wei, David]

It looks good.


Thanks,
David | SSG BIOS

From: He, Tim
Sent: Wednesday, June 10, 2015 5:06 PM
To: 'edk2-devel@lists.sourceforge.net'
Cc: Wei, David; Wu, Mike; Lu, ShifeiX A
Subject: [edk2][Patch]Vlv2TbltDevicePkg: Remove runtime attribute for 
PlatformInfo Variable and Fix Timeout variable issue

Remove Runtime access attribute for PlatformInfo variable, and fix the boot 
issue in case "Timeout" variable is corrupted.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He mailto:tim...@intel.com>>

Best Regards,
Tim

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

Re: [edk2] PXB fixes for QEMU, and extra root buses for OVMF

[Marcel Apfelbaum]

On 06/06/2015 02:45 AM, Laszlo Ersek wrote:
> Following up on this cross-posted message, I will send two patch sets,
> one for QEMU (to qemu-devel) and another for OVMF (to edk2-devel). With
> both in place, OVMF supports multiple PCI root buses.
Hi Laszlo,
Thank you for the patches.

>
> Below I'm writing up the way I tested the feature, plus a few random
> notes.
>
> (1) Interrupt line assignments. I patched SeaBIOS (temporarily) to print
>  interrupt line assignments, and I also patched OVMF (permanently) to
>  print the same. (See both patches in the OVMF patch
>
>OvmfPkg: PlatformBdsLib: debug log interrupt line assignments
>
>  in one of the followup series; the commit message contains the
>  ad-hoc SeaBIOS patch.) The QEMU command line was:
>
>  qemu-system-x86_64 \
>-m 2048 \
>-M pc \
>-enable-kvm \
>-device qxl-vga \
>\
>$FIRMWARE_OPTIONS \
>\
>-drive id=cdrom,if=none,readonly,format=raw,file=$ISO \
>-device virtio-scsi-pci,id=scsi0 \
>-device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
>\
>-debugcon file:debug.log \
>-global isa-debugcon.iobase=0x402 \
>\
>-monitor stdio \
>\
>-device pxb,id=bridge1,bus_nr=4 \
>\
>-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:-:22 \
>-device e1000,netdev=netdev0,bus=bridge1,addr=2,romfile= \
>\
>-netdev user,id=netdev1,hostfwd=tcp:127.0.0.1:2223-:22 \
>-device e1000,netdev=netdev1,bus=bridge1,addr=3,romfile= \
>\
>-netdev user,id=netdev2,hostfwd=tcp:127.0.0.1:2224-:22 \
>-device e1000,netdev=netdev2,bus=bridge1,addr=4,romfile= \
>\
>-netdev user,id=netdev3,hostfwd=tcp:127.0.0.1:2225-:22 \
>-device e1000,netdev=netdev3,bus=bridge1,addr=5,romfile=
>
>  The ISO variable pointed to a Fedora 20 LiveCD (although it is not
>  relevant for this test). FIRMWARE_OPTIONS were
>
>-bios .../out/bios.bin
>
>  for the (debug-patched, see above) SeaBIOS test case, and
>
>-drive if=pflash,readonly,format=raw,file=.../OVMF_CODE.fd \
>-drive if=pflash,format=raw,file=.../COPY_OF_OVMF_VARS.fd
>
>  for the OVMF test case.
>
>  As you can see the QEMU command line places four e1000 NICs on one
>  PXB (I used e1000 because that's what Marcel recommended for all
>  testing). SeaBIOS then printed
>
>PCI: init bdf=00:01.3 id=8086:7113
>assigned irq line 10
>
>PCI: init bdf=00:02.0 id=1b36:0100
>assigned irq line 10
>
>PCI: init bdf=00:03.0 id=1af4:1004
>assigned irq line 11
>
>PCI: init bdf=04:00.0 id=1b36:0001
>assigned irq line 11
>
>PCI: init bdf=05:02.0 id=8086:100e
>assigned irq line 10
>
>PCI: init bdf=05:03.0 id=8086:100e
>assigned irq line 11
>
>PCI: init bdf=05:04.0 id=8086:100e
>assigned irq line 11
>
>PCI: init bdf=05:05.0 id=8086:100e
>assigned irq line 10
>
>  whereas OVMF printed
>
>SetPciIntLine: PciRoot(0x0)/Pci(0x1,0x3) -> 0x0A
>SetPciIntLine: PciRoot(0x0)/Pci(0x2,0x0) -> 0x0A
>SetPciIntLine: PciRoot(0x0)/Pci(0x3,0x0) -> 0x0B
>SetPciIntLine: PciRoot(0x4)/Pci(0x0,0x0) -> 0x0B
>SetPciIntLine: PciRoot(0x4)/Pci(0x0,0x0)/Pci(0x2,0x0) -> 0x0A
>SetPciIntLine: PciRoot(0x4)/Pci(0x0,0x0)/Pci(0x3,0x0) -> 0x0B
>SetPciIntLine: PciRoot(0x4)/Pci(0x0,0x0)/Pci(0x4,0x0) -> 0x0B
>SetPciIntLine: PciRoot(0x4)/Pci(0x0,0x0)/Pci(0x5,0x0) -> 0x0A
>
>  (Note that the bus number assigned to the devices on the pxb is 5 in
>  the OVMF case too. This is not visible from the device paths logged
>  above, but it is clear from edk2's PCI bus driver's log, and the
>  output of the "PCI" UEFI shell command.)
>
>  Therefore I concluded that the IRQ line assignment logic in OVMF
>  that Gabriel had contributed earlier (and that I updated very
>  slightly in the OVMF patchset here) continued to work correctly.
>
> (2) Marcel, no new fw_cfg file is necessary for exposing the bus numbers
>  of the extra root buses to OVMF. OVMF probes all buses and all
>  devices (function 0) to locate the extra root buses. This procedure
>  is shortened by adhering to the "etc/extra-pci-roots" fw_cfg file,
>  which is already there.
Sure. It would not be a problem to add it, but if there is no need for it...

>
>  This recommendation came from both Michael & Marcel, and it was
>  "surprisingly easy" to implement with edk2's PciLib.
>
> (3) We discussed earlier the idea to flip the PXB's _HID and _UID
>  objects to numeric values in QEMU; I implemented and tested that
>  (see more test cases below).
>
> (4) Ping test was successful from the OVMF-booted Fedora 20 LivecD
>  environment, using one e1000 NIC on a PXB.
>
> (5) Ping test was successful from the UEFI 

[edk2] [Patch]Vlv2TbltDevicePkg: Remove runtime attribute for PlatformInfo Variable and Fix Timeout variable issue

[He, Tim]

Remove Runtime access attribute for PlatformInfo variable, and fix the boot 
issue in case "Timeout" variable is corrupted.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He mailto:tim...@intel.com>>

Best Regards,
Tim



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

Re: [edk2] "cond" vs. ?

[Gao, Liming]

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

[edk2] [PATCH 1/2] MdePkg: Make function comments in UefiHandleLib consistent with instance implementation.

[Qiu Shumin]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
Reviewed-by: Jaben Carsey 
---
 MdePkg/Include/Library/FileHandleLib.h   | 4 ++--
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 4 ++--
 2 files changed, 4 insertions(+), 4 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..7687ca3 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.
-- 
1.9.5.msysgit.1



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

[edk2] [PATCH 0/2] Refine the code logic of UefiHandleLib and update the function comments.

[Qiu Shumin]

*** BLURB HERE ***

Qiu Shumin (2):
  MdePkg: Make function comments in UefiHandleLib consistent with
instance implementation.
  MdePkg/Library/UefiFileHandleLib: Do the validation for DirHandle
before get file information.

 MdePkg/Include/Library/FileHandleLib.h   |  4 ++--
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 13 ++---
 2 files changed, 12 insertions(+), 5 deletions(-)

-- 
1.9.5.msysgit.1



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

[edk2] [PATCH 2/2] MdePkg/Library/UefiFileHandleLib: Do the validation for DirHandle before get file information.

[Qiu Shumin]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c 
b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
index 7687ca3..25bb8fb 100644
--- a/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
+++ b/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c
@@ -407,7 +407,14 @@ FileHandleIsDirectory (
   if (DirHandle == NULL) {
 return (EFI_INVALID_PARAMETER);
   }
-
+  
+  //
+  // check whether the DirHandle is valid
+  //
+  if (DirHandle->Revision != EFI_FILE_PROTOCOL_LATEST_REVISION) {
+return EFI_INVALID_PARAMETER;
+  }
+  
   //
   // get the file information for DirHandle
   //
-- 
1.9.5.msysgit.1



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

Re: [edk2] [PATCH] MdeModulePkg PcdDxe: TokenNumber should start from 1.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Zeng, Star 
Sent: Wednesday, June 10, 2015 2:33 PM
To: edk2-devel@lists.sourceforge.net
Cc: Gao, Liming
Subject: [PATCH] MdeModulePkg PcdDxe: TokenNumber should start from 1.

Because 0 is reserved as invalid token number.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 Universal/PCD/Dxe/Service.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Universal/PCD/Dxe/Service.c b/Universal/PCD/Dxe/Service.c index 
9b4701b..cf5f244 100644
--- a/Universal/PCD/Dxe/Service.c
+++ b/Universal/PCD/Dxe/Service.c
@@ -1864,7 +1864,7 @@ VariableLockDynamicHiiPcd (
   //
   // Go through PCD database to find out DynamicHii PCDs.
   //
-  for (TokenNumber = 0; TokenNumber < LocalTokenCount; TokenNumber++) {
+  for (TokenNumber = 1; TokenNumber <= LocalTokenCount; TokenNumber++) 
+ {
 if (IsPeiDb) {
   LocalTokenNumber = GetLocalTokenNumber (TRUE, TokenNumber);
 } else {
--
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] BaseTools: Append FILE_GUID to BaseName.

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Yingke Liu [mailto:yingke.d@intel.com] 
Sent: Tuesday, June 09, 2015 1:31 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] BaseTools: Append FILE_GUID to BaseName.

This patch makes sure the EFI file in $(BIN_DIR) is unique. If there are 
modules with same BaseName, the FILE_GUID is appended.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Conf/build_rule.template | 14 --
 BaseTools/Source/Python/AutoGen/AutoGen.py | 15 +++  
BaseTools/Source/Python/AutoGen/GenMake.py |  4 
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 3b054c4..596d41d 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -66,6 +66,8 @@
 #   $(LIBS) Static library files of current module
 #   $(_FLAGS) Tools flags of current module
 #   $(MODULE_NAME)  Current module name
+#   $(MODULE_NAME_GUID) Current module name with module FILE_GUID if same 
$(MODULE_NAME) exists
+#   in different modules, otherwise its value is same as 
$(MODULE_NAME)
 #   $(MODULE_TYPE)  Current module type
 #   $(MODULE_GUID)  Current module guid
 #   $(ARCH) Architecture of current module
@@ -334,7 +336,7 @@
   
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
 $(CP) ${dst} $(OUTPUT_DIR)
-$(CP) ${dst} $(BIN_DIR)
+$(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 -$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR) 
 
@@ -345,11 +347,11 @@
 #The below 2 lines are only needed for UNIXGCC tool chain, which 
genereates PE image directly
 #
 -$(OBJCOPY) $(OBJCOPY_ADDDEBUGFLAG) ${src}
--$(CP) $(DEBUG_DIR)(+)$(MODULE_NAME).debug $(BIN_DIR)
+-$(CP) $(DEBUG_DIR)(+)$(MODULE_NAME).debug 
+ $(BIN_DIR)(+)$(MODULE_NAME_GUID).debug
 
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
 $(CP) ${dst} $(OUTPUT_DIR)
-$(CP) ${dst} $(BIN_DIR)
+$(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 
 
@@ -359,7 +361,7 @@
 -$(DSYMUTIL) ${src}
 "$(GENFW)" -e $(MODULE_TYPE) -o ${dst} 
$(DEBUG_DIR)(+)$(MODULE_NAME).pecoff $(GENFW_FLAGS)
 $(CP) ${dst} $(OUTPUT_DIR)
-$(CP) ${dst} $(BIN_DIR)
+$(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 
 [Dependency-Expression-File]
@@ -516,7 +518,7 @@
 
 
 "$(GENFW)" -o ${dst} -j $(MICROCODE_BINARY_FILES) $(GENFW_FLAGS)
--$(CP) ${dst} $(BIN_DIR)
+-$(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).bin
 
 [EFI-Image-File]
 
@@ -542,7 +544,7 @@
 ?.efi, ?.EFI, ?.Efi
 
 
-$(BIN_DIR)(+)$(MODULE_NAME).rom
+$(BIN_DIR)(+)$(MODULE_NAME_GUID).rom
 
 
 $(OPTROM) -i $(PCI_DEVICE_ID) -f $(PCI_VENDOR_ID) -l $(PCI_CLASS_CODE) 
-r $(PCI_REVISION) -o $dst $(OPTROM_FLAGS) $src diff --git 
a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index b2d9f6a..d1ed0a6 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -17,6 +17,7 @@ import Common.LongFilePathOs as os  import re  import os.path 
as path  import copy
+import uuid
 
 import GenC
 import GenMake
@@ -2285,12 +2286,26 @@ class ModuleAutoGen(AutoGen):
 
 return self._FixedAtBuildPcds
 
+def _GetUniqueBaseName(self):
+BaseName = self.Name
+for Module in self.PlatformInfo.ModuleAutoGenList:
+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))
+BaseName = '%s_%s' % (self.Name, self.Guid)
+return BaseName
+
 # Macros could be used in build_rule.txt (also Makefile)
 def _GetMacros(self):
 if self._Macro == None:
 self._Macro = sdict()
 self._Macro["WORKSPACE" ] = self.WorkspaceDir
 self._Macro["MODULE_NAME"   ] = self.Name
+self._Macro["MODULE_NAME_GUID"  ] = self._GetUniqueBaseName()
 self._Macro["MODULE_GUID"   ] = self.Guid
 self._Macro["MODULE_VERSION"] = self.Version
 self._Macro["MODULE_TYPE"   ] = self.ModuleTy

[edk2] [Patch] BaseTools: Generate a binary file and list it in Binary section of As Built INF.

[Yingke Liu]

This binary file contains offset of VFR and UNI data.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yingke Liu 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index a2a8e7e..996b654 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3116,6 +3116,76 @@ class ModuleAutoGen(AutoGen):
 
 return HiiExPcds
 
+def _GenOffsetBin(self):
+VfrUniBaseName = {}
+for SourceFile in self.Module.Sources:
+if SourceFile.Type.upper() == ".VFR" :
+#
+# search the .map file to find the offset of vfr binary in the 
PE32+/TE file. 
+#
+VfrUniBaseName[SourceFile.BaseName] = (SourceFile.BaseName + 
"Bin")
+if SourceFile.Type.upper() == ".UNI" :
+#
+# search the .map file to find the offset of Uni strings 
binary in the PE32+/TE file. 
+#
+VfrUniBaseName["UniOffsetName"] = (self.Name + "Strings")
+
+if len(VfrUniBaseName) == 0:
+return None
+MapFileName = os.path.join(self.OutputDir, self.Name + ".map")
+EfiFileName = os.path.join(self.OutputDir, self.Name + ".efi")
+VfrUniOffsetList = GetVariableOffset(MapFileName, EfiFileName, 
VfrUniBaseName.values())
+if not VfrUniOffsetList:
+return None
+
+OutputName = '%sOffset.bin' % self.Name
+UniVfrOffsetFileName=  os.path.join( self.OutputDir, OutputName)
+
+try:
+fInputfile = open(UniVfrOffsetFileName, "wb+", 0)
+except:
+EdkLogger.error("build", FILE_OPEN_FAILURE, "File open failed for 
%s" % UniVfrOffsetFileName,None)
+
+# Use a instance of StringIO to cache data
+fStringIO = StringIO('')  
+
+for Item in VfrUniOffsetList:
+if (Item[0].find("Strings") != -1):
+#
+# UNI offset in image.
+# GUID + Offset
+# { 0x8913c5e0, 0x33f6, 0x4d86, { 0x9b, 0xf1, 0x43, 0xef, 
0x89, 0xfc, 0x6, 0x66 } }
+#
+UniGuid = [0xe0, 0xc5, 0x13, 0x89, 0xf6, 0x33, 0x86, 0x4d, 
0x9b, 0xf1, 0x43, 0xef, 0x89, 0xfc, 0x6, 0x66]
+UniGuid = [chr(ItemGuid) for ItemGuid in UniGuid]
+fStringIO.write(''.join(UniGuid))
+UniValue = pack ('Q', int (Item[1], 16))
+fStringIO.write (UniValue)
+else:
+#
+# VFR binary offset in image.
+# GUID + Offset
+# { 0xd0bc7cb4, 0x6a47, 0x495f, { 0xaa, 0x11, 0x71, 0x7, 0x46, 
0xda, 0x6, 0xa2 } };
+#
+VfrGuid = [0xb4, 0x7c, 0xbc, 0xd0, 0x47, 0x6a, 0x5f, 0x49, 
0xaa, 0x11, 0x71, 0x7, 0x46, 0xda, 0x6, 0xa2]
+VfrGuid = [chr(ItemGuid) for ItemGuid in VfrGuid]
+fStringIO.write(''.join(VfrGuid))   
+type (Item[1]) 
+VfrValue = pack ('Q', int (Item[1], 16))
+fStringIO.write (VfrValue)
+#
+# write data into file.
+#
+try :  
+fInputfile.write (fStringIO.getvalue())
+except:
+EdkLogger.error("build", FILE_WRITE_FAILURE, "Write data to file 
%s failed, please check whether the "
+"file been locked or using by other applications." 
%UniVfrOffsetFileName,None)
+
+fStringIO.close ()
+fInputfile.close ()
+return OutputName
+
 ## Create AsBuilt INF file the module
 #
 def CreateAsBuiltInf(self):
@@ -3270,6 +3340,10 @@ class ModuleAutoGen(AutoGen):
 if self.ModuleType in ['DXE_SMM_DRIVER']:
   AsBuiltInfDict['binary_item'] += ['SMM_DEPEX|' + self.Name + 
'.depex']
 
+Bin = self._GenOffsetBin()
+if Bin:
+AsBuiltInfDict['binary_item'] += ['BIN|%s' % Bin]
+
 for Root, Dirs, Files in os.walk(OutputDir):
 for File in Files:
 if File.lower().endswith('.pdb'):
-- 
1.9.5.msysgit.0


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