Re: [edk2] [PATCH v2] UefiCpuPkg/MpInitLib: fix AP init issue in 64-bit PEI
On 1/25/2018 3:42 PM, Jian J Wang wrote: v2: Roll back changes (just white spaces) caused by misoperation in git This issue is introduced by a patch at f32bfe6d061420a15bac6083063d227c567e6388 The above patch miss the case of 64-bit PEI, which will link X64/MpFuncs.nasm instead of Ia32/MpFuncs.nasm. For X64/MpFuncs.nasm, ExchangeInfo->ModeHighMemory should be always initialized no matter if separate wakeup buffer is allocated or not. Ia32/MpFuncs.nasm will not need ModeHighMemory during AP init. So the changes made in this patch should not affect the functionality of it. Cc: Ruiyu Ni Cc: Eric Dong Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang --- UefiCpuPkg/Library/MpInitLib/MpLib.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c index 42011d6231..0b7073fd02 100644 --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c @@ -834,14 +834,15 @@ FillExchangeInfoData ( ); ExchangeInfo->ModeTransitionMemory = (UINT32)CpuMpData->WakeupBufferHigh; -ExchangeInfo->ModeHighMemory = (UINT32)CpuMpData->WakeupBufferHigh + - (UINT32)ExchangeInfo->ModeOffset - - (UINT32)CpuMpData->AddressMap.ModeTransitionOffset; -ExchangeInfo->ModeHighSegment = (UINT16)ExchangeInfo->CodeSegment; } else { ExchangeInfo->ModeTransitionMemory = (UINT32) (ExchangeInfo->BufferStart + CpuMpData->AddressMap.ModeTransitionOffset); } + + ExchangeInfo->ModeHighMemory = ExchangeInfo->ModeTransitionMemory + + (UINT32)ExchangeInfo->ModeOffset - + (UINT32)CpuMpData->AddressMap.ModeTransitionOffset; + ExchangeInfo->ModeHighSegment = (UINT16)ExchangeInfo->CodeSegment; } /** Reviewed-by: Ruiyu Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
"You, Benjamin" writes: > Hi Arthur, > > Could you please give more details about your case that > HorizontalResolution * (BitsPerPixel / 8) and pFbInfo->BytesPerScanLine > don't match? > On many devices, notably Intel hardware, the STRIDE needs to be 64 byte aligned when used in linear memory mode, which coreboot does. STRIDE is value that used to determine the line to line increment for the display. So what coreboot does when initializing the hardware to align (HorizontalResolution * (BitsPerPixel / 8)), 64 bytes up. > I did a brief search in Coreboot source and found following comments in > coreboot-4.6\src\lib\edid.c: > > /* In the case of (e.g.) 24 framebuffer bits per pixel, the convention >* nowadays seems to be to round it up to the nearest reasonable >* boundary, because otherwise the byte-packing is hideous. > > So it appears framebuffer BitsPerPixel will likely be 16 or 32, and the > following statement in the same file calculates: > > edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8); > > which results in bytes_per_line (already rounded up to be 32 or 64 byte > aligned) matching x_resolution * (fb_bpp / 8). > > There are cases that even if panel bits_per_pixel is 24, the framebuffer > bits_per_pixel is still 32, as shown in > coreboot-4.6\src\drivers\emulation\qemu\bochs.c: > > edid.panel_bits_per_pixel = 24; > edid_set_framebuffer_bits_per_pixel(&edid, 32, 0); > > It would be good if you could help with more details on how the mismatch > happened in your case as I may have missed something. > So long story short 'bytes_per_line' reflects how the actual hardware is set up, while using '(HorizontalResolution * (BitsPerPixel / 8)' is a guess which is only sometimes correct. To give an example (on which this was actually a problem): let's say we have a display 1366 pixel horizontal resolution with 32 bits per pixel. HorizontalResolution * BitsPerPixel / 8 = 5464 But this value is not 64 byte aligned which the hardware expects so. aligned value = ((HorizontalResolution * (BitsPerPixel / 8) + 63) & ~63 = 5504 So tianocore should use the value coreboot provides it instead of trying to compute/guess it. > Thanks, > > - ben > I hope this clarifies it. Arthur >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> art...@aheymans.xyz >> Sent: Wednesday, January 24, 2018 6:58 PM >> To: edk2-devel@lists.01.org >> Cc: Arthur Heymans >> Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine >> >> From: Arthur Heymans >> >> Fetch BytesPerScanLine from coreboot table to reflect how the actual >> framebuffer is set up instead of guessing it from the horizontal >> resolution. >> >> This fixes a garbled display when HorizontalResolution * (BitsPerPixel >> / 8) and pFbInfo->BytesPerScanLine don't match. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Arthur Heymans >> >> diff --git a/CorebootPayloadPkg/FbGop/FbGop.c >> b/CorebootPayloadPkg/FbGop/FbGop.c >> index 37d6def7f7..6790617033 100644 >> --- a/CorebootPayloadPkg/FbGop/FbGop.c >> +++ b/CorebootPayloadPkg/FbGop/FbGop.c >> @@ -822,7 +822,7 @@ FbGopCheckForVbe ( >>BitsPerPixel = pFbInfo->BitsPerPixel; >>HorizontalResolution = pFbInfo->HorizontalResolution; >>VerticalResolution = pFbInfo->VerticalResolution; >> - BytesPerScanLine = HorizontalResolution * (BitsPerPixel / 8); >> + BytesPerScanLine = pFbInfo->BytesPerScanLine; >> >>ModeBuffer = (FB_VIDEO_MODE_DATA *) AllocatePool ( >> >> >> ModeNumber * sizeof >> (FB_VIDEO_MODE_DATA) >> -- >> 2.16.1 >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel <#secure method=pgpmime mode=sign> -- Arthur Heymans ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdeModulePkg/Partition: Fix media probe
The call in ProbeMediaStatusEx() to the ReadDisk() function of the EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c crashed in DiskIo2ReadWriteDisk() because of the NULL value of the destination buffer pointer. Pass the address of a buffer in the stack instead of a NULL pointer. The similar fix was applied to ProbeMediaStatus in commit df473cc1fc9acd1a623ec7e05276f2f0635c19d2 * MdeModulePkg/PartitionDxe: Fix media probe Somehow ProbeMediaStatusEx() wasn't changed together. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Jian J Wang --- MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c index bb9d0b70ce..46c0877cee 100644 --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c @@ -4,7 +4,7 @@ of the raw block devices media. Currently "El Torito CD-ROM", UDF, Legacy MBR, and GPT partition schemes are supported. -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -777,11 +777,15 @@ ProbeMediaStatusEx ( ) { EFI_STATUS Status; + UINT8 Buffer[1]; // - // Read 1 byte from offset 0 but passing NULL as buffer pointer + // Read 1 byte from offset 0 to check if the MediaId is still valid. + // The reading operation is synchronious thus it is not worth it to + // allocate a buffer from the pool. The destination buffer for the + // data is in the stack. // - Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, NULL); + Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, (VOID*)Buffer); if ((Status == EFI_NO_MEDIA) || (Status == EFI_MEDIA_CHANGED)) { return Status; } -- 2.15.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to 1.02
Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Ruiyu Ni >Sent: Wednesday, January 24, 2018 1:56 PM >To: edk2-devel@lists.01.org >Cc: Carsey, Jaben >Subject: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to >1.02 > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Ruiyu Ni >Cc: Jaben Carsey >--- > ShellPkg/ShellPkg.dec | 4 ++-- > ShellPkg/ShellPkg.dsc | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > >diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec >index 48d50b87b3..0c4f74ff41 100644 >--- a/ShellPkg/ShellPkg.dec >+++ b/ShellPkg/ShellPkg.dec >@@ -2,7 +2,7 @@ > # This Package provides all definitions for EFI and UEFI Shell > # > # (C) Copyright 2013-2014 Hewlett-Packard Development Company, L.P. >-# Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved. >+# Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved. > # > # This program and the accompanying materials are licensed and made >available under > # the terms and conditions of the BSD License which accompanies this >distribution. >@@ -18,7 +18,7 @@ [Defines] > DEC_SPECIFICATION = 0x00010005 > PACKAGE_NAME = ShellPkg > PACKAGE_GUID = C1014BB7-4092-43D4-984F-0738EB424DBF >- PACKAGE_VERSION= 1.01 >+ PACKAGE_VERSION= 1.02 > > [Includes] > Include >diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc >index 86382139a5..29f5376412 100644 >--- a/ShellPkg/ShellPkg.dsc >+++ b/ShellPkg/ShellPkg.dsc >@@ -1,7 +1,7 @@ > ## @file > # Shell Package > # >-# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved. >+# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > # > #This program and the accompanying materials > #are licensed and made available under the terms and conditions of the >BSD License >@@ -16,7 +16,7 @@ > [Defines] > PLATFORM_NAME = Shell > PLATFORM_GUID = E1DC9BF8-7013-4c99-9437-795DAA45F3BD >- PLATFORM_VERSION = 1.01 >+ PLATFORM_VERSION = 1.02 > DSC_SPECIFICATION = 0x00010006 > OUTPUT_DIRECTORY = Build/Shell > SUPPORTED_ARCHITECTURES= IA32|IPF|X64|EBC|ARM|AARCH64 >-- >2.15.1.windows.2 > >___ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTool: Combine the HiiPcd value if they link to same Variable
Reviewed-by: Liming Gao >-Original Message- >From: Feng, Bob C >Sent: Tuesday, January 23, 2018 10:19 AM >To: edk2-devel@lists.01.org >Cc: Feng, Bob C ; Gao, Liming >Subject: [Patch] BaseTool: Combine the HiiPcd value if they link to same >Variable > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Bob Feng >Cc: Liming Gao >--- > BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +- > BaseTools/Source/Python/AutoGen/GenVar.py | 36 >-- > 2 files changed, 35 insertions(+), 3 deletions(-) > >diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py >b/BaseTools/Source/Python/AutoGen/AutoGen.py >index 0f7454f55a..604d38a4d6 100644 >--- a/BaseTools/Source/Python/AutoGen/AutoGen.py >+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py >@@ -1404,11 +1404,11 @@ class PlatformAutoGen(AutoGen): > continue > if len(Sku.VariableName) > 0: > VariableGuidStructure = Sku.VariableGuidValue > VariableGuid = >GuidStructureStringToGuidString(VariableGuidStructure) > for StorageName in Sku.DefaultStoreDict: >- >VariableInfo.append_variable(var_info(Index,pcdname,StorageName,SkuNa >me, StringToArray(Sku.VariableName),VariableGuid, Sku.VariableAttribute , >Sku.HiiDefaultValue,Sku.DefaultStoreDict[StorageName],Pcd.DatumType)) >+ >VariableInfo.append_variable(var_info(Index,pcdname,StorageName,SkuNa >me, StringToArray(Sku.VariableName),VariableGuid, Sku.VariableOffset, >Sku.VariableAttribute , >Sku.HiiDefaultValue,Sku.DefaultStoreDict[StorageName],Pcd.DatumType)) > Index += 1 > return VariableInfo > > def UpdateNVStoreMaxSize(self,OrgVpdFile): > if self.VariableInfo: >diff --git a/BaseTools/Source/Python/AutoGen/GenVar.py >b/BaseTools/Source/Python/AutoGen/GenVar.py >index 65d0bea36c..1389d7ff62 100644 >--- a/BaseTools/Source/Python/AutoGen/GenVar.py >+++ b/BaseTools/Source/Python/AutoGen/GenVar.py >@@ -19,11 +19,11 @@ import collections > import copy > from Common.VariableAttributes import VariableAttributes > from Common.Misc import * > import collections > >-var_info = collections.namedtuple("uefi_var", >"pcdindex,pcdname,defaultstoragename,skuname,var_name, var_guid, >var_attribute,pcd_default_value, default_value, data_type") >+var_info = collections.namedtuple("uefi_var", >"pcdindex,pcdname,defaultstoragename,skuname,var_name, var_guid, >var_offset,var_attribute,pcd_default_value, default_value, data_type") > NvStorageHeaderSize = 28 > VariableHeaderSize = 32 > > def StringArrayToList(StringArray): > StringArray = StringArray[1:-1] >@@ -74,11 +74,42 @@ class VariableMgr(object): > value_str = "{" > default_var_bin_strip = [ data.strip("""'""") for data in > default_var_bin] > value_str += ",".join(default_var_bin_strip) > value_str += "}" > return value_str >- >+def combine_variable(self): >+indexedvarinfo = collections.OrderedDict() >+for item in self.VarInfo: >+if (item.skuname,item.defaultstoragename, >item.var_name,item.var_guid) not in indexedvarinfo: >+indexedvarinfo[(item.skuname,item.defaultstoragename, >item.var_name,item.var_guid) ] = [] >+indexedvarinfo[(item.skuname,item.defaultstoragename, >item.var_name,item.var_guid)].append(item) >+for key in indexedvarinfo: >+sku_var_info_offset_list = indexedvarinfo[key] >+if len(sku_var_info_offset_list) == 1: >+continue >+newvalue = {} >+for item in sku_var_info_offset_list: >+data_type = item.data_type >+value_list = >item.default_value.strip("{").strip("}").split(",") >+if data_type in >["BOOLEAN","UINT8","UINT16","UINT32","UINT64"]: >+if data_type == ["BOOLEAN","UINT8"]: >+data_flag = "=B" >+elif data_type == "UINT16": >+data_flag = "=H" >+elif data_type == "UINT32": >+data_flag = "=L" >+elif data_type == "UINT64": >+data_flag = "=Q" >+data = value_list[0] >+value_list = [] >+for data_byte in pack(data_flag,int(data,16) if >data.upper().startswith('0X') else int(data)): >+value_list += [hex(unpack("B",data_byte)[0])] >+newvalue[int(item.var_offset,16) if >item.var_offset.upper().startswith("0X") else int(item.var_offset)] = >value_list >+newvaluestr = "{" + ",".join(reduce(lambda x,y: x+y, [newvalue[k] >for k >in sorted(newvalue.keys())] )) +"}" >+n = sku_var_info_offset_list[0] >+indexedvarinfo[key] = >[var_info(n.pcdindex,n.pcdname,n.defaultstoragename,n.skuname,n.var_na >me, n.var_guid, "0x00",n.var_attribute,newvaluestr , newvaluestr , "VOID*")] >+
Re: [edk2] [Patch] BaseTools: Add comments for the Structure Pcd definition in PcdValueInit.c file
Reviewed-by: Liming Gao >-Original Message- >From: Feng, Bob C >Sent: Tuesday, January 23, 2018 11:03 AM >To: edk2-devel@lists.01.org >Cc: Feng, Bob C ; Gao, Liming >Subject: [Patch] BaseTools: Add comments for the Structure Pcd definition in >PcdValueInit.c file > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Bob Feng >Cc: Liming Gao >--- > BaseTools/Source/Python/Workspace/BuildClassObject.py | 4 > BaseTools/Source/Python/Workspace/DecBuildData.py | 2 ++ > BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +- > 3 files changed, 7 insertions(+), 1 deletion(-) > >diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py >b/BaseTools/Source/Python/Workspace/BuildClassObject.py >index 0e3081cfc5..8d02e78b27 100644 >--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py >+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py >@@ -117,10 +117,12 @@ class StructurePcd(PcdClassObject): > self.DefaultValues = collections.OrderedDict({}) > self.PcdMode = None > self.SkuOverrideValues = collections.OrderedDict({}) > self.FlexibleFieldName = None > self.StructName = None >+self.PcdDefineLineNo = 0 >+self.PkgPath = "" > def __repr__(self): > return self.TypeName > > def AddDefaultValue (self, FieldName, Value, FileName="", LineNo=0): > if FieldName in self.DefaultValues: >@@ -169,10 +171,12 @@ class StructurePcd(PcdClassObject): > self.PcdMode = PcdObject.PcdMode if PcdObject.PcdMode else >self.PcdMode > self.DefaultFromDSC=None > self.SkuOverrideValues = PcdObject.SkuOverrideValues if >PcdObject.SkuOverrideValues else self.SkuOverrideValues > self.FlexibleFieldName = PcdObject.FlexibleFieldName if >PcdObject.FlexibleFieldName else self.FlexibleFieldName > self.StructName = PcdObject.DatumType if PcdObject.DatumType else >self.StructName >+self.PcdDefineLineNo = PcdObject.PcdDefineLineNo if >PcdObject.PcdDefineLineNo else self.PcdDefineLineNo >+self.PkgPath = PcdObject.PkgPath if PcdObject.PkgPath else >self.PkgPath > > ## LibraryClassObject > # > # This Class defines LibraryClassObject used in BuildDatabase > # >diff --git a/BaseTools/Source/Python/Workspace/DecBuildData.py >b/BaseTools/Source/Python/Workspace/DecBuildData.py >index 13fb8686b6..2fd3820dcc 100644 >--- a/BaseTools/Source/Python/Workspace/DecBuildData.py >+++ b/BaseTools/Source/Python/Workspace/DecBuildData.py >@@ -381,10 +381,12 @@ class DecBuildData(PackageBuildClassObject): > dep_pkgs.append(item.DefaultValue) > elif item.DatumType == item.TokenCName: > struct_pcd.copy(item) > struct_pcd.TokenValue = > struct_pcd.TokenValue.strip("{").strip() > struct_pcd.TokenSpaceGuidCName, struct_pcd.TokenCName = >pcdname.split(".") >+struct_pcd.PcdDefineLineNo = LineNo >+struct_pcd.PkgPath = self.MetaFile.File > else: > struct_pcd.AddDefaultValue(item.TokenCName, >item.DefaultValue,self.MetaFile.File,LineNo) > > struct_pcd.PackageDecs = dep_pkgs > >diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py >b/BaseTools/Source/Python/Workspace/DscBuildData.py >index b042c4306a..60aa4868ed 100644 >--- a/BaseTools/Source/Python/Workspace/DscBuildData.py >+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py >@@ -1284,11 +1284,11 @@ class DscBuildData(PlatformBuildClassObject): > CApp = CApp + ' UINT32 Size;\n' > CApp = CApp + ' UINT32 FieldSize;\n' > CApp = CApp + ' CHAR8 *Value;\n' > CApp = CApp + ' UINT32 OriginalSize;\n' > CApp = CApp + ' VOID*OriginalPcd;\n' >-CApp = CApp + ' %s *Pcd;\n' % (Pcd.DatumType) >+CApp = CApp + ' %s *Pcd; // From %s Line %d \n' % >(Pcd.DatumType, Pcd.PkgPath, Pcd.PcdDefineLineNo) > CApp = CApp + '\n' > > Pcd.DefaultValue = Pcd.DefaultValue.strip() > PcdDefaultValue = StringToArray(Pcd.DefaultValue) > >-- >2.14.3.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Fixed build failure for the case that A pcd is initialized under one SKU but is uninitialized under another SKU.
Reviewed-by: Liming Gao >-Original Message- >From: Feng, Bob C >Sent: Tuesday, January 23, 2018 9:39 AM >To: edk2-devel@lists.01.org >Cc: Feng, Bob C ; Gao, Liming >Subject: [Patch] BaseTools: Fixed build failure for the case that A pcd is >initialized under one SKU but is uninitialized under another SKU. > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Bob Feng >Cc: Liming Gao >--- > BaseTools/Source/Python/AutoGen/GenPcdDb.py | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > >diff --git a/BaseTools/Source/Python/AutoGen/GenPcdDb.py >b/BaseTools/Source/Python/AutoGen/GenPcdDb.py >index 22283ef7fe..82360ae57d 100644 >--- a/BaseTools/Source/Python/AutoGen/GenPcdDb.py >+++ b/BaseTools/Source/Python/AutoGen/GenPcdDb.py >@@ -1022,10 +1022,23 @@ def CreateAutoGen(PcdDriverAutoGenData): > return (PcdDriverAutoGenData[(skuname,skuid)][0],autogenC) > def NewCreatePcdDatabasePhaseSpecificAutoGen(Platform,Phase): > def prune_sku(pcd,skuname): > new_pcd = copy.deepcopy(pcd) > new_pcd.SkuInfoList = {skuname:pcd.SkuInfoList[skuname]} >+new_pcd.isinit = 'INIT' >+if new_pcd.DatumType in ['UINT8','UINT16','UINT32','UINT64']: >+for skuobj in pcd.SkuInfoList.values(): >+if skuobj.DefaultValue: >+defaultvalue = int(skuobj.DefaultValue,16) if >skuobj.DefaultValue.upper().startswith("0X") else int(skuobj.DefaultValue,10) >+if defaultvalue != 0: >+new_pcd.isinit = "INIT" >+break >+elif skuobj.VariableName: >+new_pcd.isinit = "INIT" >+break >+else: >+new_pcd.isinit = "UNINIT" > return new_pcd > DynamicPcds = Platform.DynamicPcdList > DynamicPcdSet_Sku = {(SkuName,skuobj.SkuId):[] for pcd in DynamicPcds >for (SkuName,skuobj) in pcd.SkuInfoList.items() } > for skuname,skuid in DynamicPcdSet_Sku: > DynamicPcdSet_Sku[(skuname,skuid)] = [prune_sku(pcd,skuname) for >pcd in DynamicPcds] >@@ -1399,12 +1412,11 @@ def CreatePcdDatabasePhaseSpecificAutoGen >(Platform, DynamicPcdList, Phase): > if "PCD_TYPE_HII" not in Pcd.TokenTypeList: > Pcd.TokenTypeList += ['PCD_TYPE_DATA'] > if Sku.DefaultValue == 'TRUE': > Pcd.InitString = 'INIT' > else: >-if int(Sku.DefaultValue, 0) != 0: >-Pcd.InitString = 'INIT' >+Pcd.InitString = Pcd.isinit > # > # For UNIT64 type PCD's value, ULL should be append to avoid > # warning under linux building environment. > # > if Pcd.DatumType == "UINT64": >-- >2.14.3.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Fixed incorrect VPD size.
Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >BobCF >Sent: Tuesday, January 23, 2018 4:01 PM >To: edk2-devel@lists.01.org >Subject: [edk2] [Patch] BaseTools: Fixed incorrect VPD size. > >The VPD size is incorrect if that VPD is not used in Module. > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Feng Bob C >Reviewed-by: Liming Gao >--- > BaseTools/Source/Python/AutoGen/AutoGen.py | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > >diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py >b/BaseTools/Source/Python/AutoGen/AutoGen.py >index ce8bc64ca5..848378f3d4 100644 >--- a/BaseTools/Source/Python/AutoGen/AutoGen.py >+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py >@@ -1744,18 +1744,16 @@ class PlatformAutoGen(AutoGen): > > # Not found, it should be signature > if not FoundFlag : > # just pick the a value to determine whether is > unicode string >type > SkuValueMap = {} >+SkuObjList = DscPcdEntry.SkuInfoList.items() > DefaultSku = > DscPcdEntry.SkuInfoList.get('DEFAULT') > if DefaultSku: >-PcdValue = DefaultSku.DefaultValue >-if PcdValue not in SkuValueMap: >-SkuValueMap[PcdValue] = [] >-VpdFile.Add(DscPcdEntry, >'DEFAULT',DefaultSku.VpdOffset) >-SkuValueMap[PcdValue].append(DefaultSku) >-for (SkuName,Sku) in >DscPcdEntry.SkuInfoList.items(): >+defaultindex = >SkuObjList.index(('DEFAULT',DefaultSku)) >+SkuObjList[0],SkuObjList[defaultindex] = >SkuObjList[defaultindex],SkuObjList[0] >+for (SkuName,Sku) in SkuObjList: > Sku.VpdOffset = Sku.VpdOffset.strip() > > # Need to iterate DEC pcd information to get > the value & >datumtype > for eachDec in self.PackageList: > for DecPcd in eachDec.Pcds: >-- >2.14.3.windows.1 > >___ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTool: Fixed the StructurePcd incorrect value.
Reviewed-by: Liming Gao >-Original Message- >From: Feng, Bob C >Sent: Thursday, January 25, 2018 3:42 PM >To: edk2-devel@lists.01.org >Cc: Feng, Bob C ; Gao, Liming >Subject: [Patch] BaseTool: Fixed the StructurePcd incorrect value. > >If user not set Structure overall value in Dsc, >Structure Pcd value would be incorrect. > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Bob Feng >Cc: Liming Gao >--- > BaseTools/Source/Python/Workspace/BuildClassObject.py | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py >b/BaseTools/Source/Python/Workspace/BuildClassObject.py >index e5f1f01556..947ac1f466 100644 >--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py >+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py >@@ -65,11 +65,11 @@ class PcdClassObject(object): > self.validlists = validlists > self.expressions = expressions > self.DscDefaultValue = None > if IsDsc: > self.DscDefaultValue = Value >- >+ > ## Convert the class to a string > # > # Convert each member of the class to string > # Organize to a signle line format string > # >@@ -107,11 +107,15 @@ class PcdClassObject(object): > # > def __hash__(self): > return hash((self.TokenCName, self.TokenSpaceGuidCName)) > > class StructurePcd(PcdClassObject): >-def __init__(self, StructuredPcdIncludeFile="", Packages=None, >Name=None, Guid=None, Type=None, DatumType=None, Value=None, >Token=None, MaxDatumSize=None, SkuInfoList={}, IsOverrided=False, >GuidValue=None, validateranges=[], validlists=[], >expressions=[],default_store = TAB_DEFAULT_STORES_DEFAULT): >+def __init__(self, StructuredPcdIncludeFile=None, Packages=None, >Name=None, Guid=None, Type=None, DatumType=None, Value=None, >Token=None, MaxDatumSize=None, SkuInfoList=None, IsOverrided=False, >GuidValue=None, validateranges=None, validlists=None, >expressions=None,default_store = TAB_DEFAULT_STORES_DEFAULT): >+if SkuInfoList is None: SkuInfoList={} >+if validateranges is None: validateranges=[] >+if validlists is None: validlists=[] >+if expressions is None : expressions=[] > super(StructurePcd, self).__init__(Name, Guid, Type, DatumType, Value, >Token, MaxDatumSize, SkuInfoList, IsOverrided, GuidValue, validateranges, >validlists, expressions) > self.StructuredPcdIncludeFile = StructuredPcdIncludeFile > self.PackageDecs = Packages > self.DefaultStoreName = [default_store] > self.DefaultValues = collections.OrderedDict({}) >@@ -435,6 +439,5 @@ class PlatformBuildClassObject(object): > # > # @retval string Key for hash table > # > def __hash__(self): > return hash(self.MetaFile) >- >-- >2.14.3.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 0/6] Add ARM support for VS2017
Pete: The changes in BaseTools and MdePkg are good to me. You can add my R-B. >-Original Message- >From: Pete Batard [mailto:p...@akeo.ie] >Sent: Friday, January 12, 2018 9:33 PM >To: edk2-devel@lists.01.org >Cc: Gao, Liming ; ard.biesheu...@linaro.org; >eug...@hp.com >Subject: [PATCH v5 0/6] Add ARM support for VS2017 > >(Same as v4, except for the AREA names where we replaced the RVCT macros, >in >patch 4/6, so that it matches what would have been produced with the >macros) > > >The following series adds ARM compilation support for the VS2017 toolchain. >* PATCH 1 targets the disabling of VS Level 4 warnings. The disabled warnings > for ARM are now aligned with IA32 and X64. >* PATCH 2 adds a NULL handler for the base stack check, since this is a GCC > functionality. >* PATCH 3 updates MdePkg/Library/BaseLib so that the RVCT assembly >sources > are also used for MSFT. >* PATCH 4 adds the required compiler intrinsics replacements for division, > shift, by reusing the RVCT code, as well as memset/memcpy. >* PATCH 5 adds variable argument handlers for print output. Note that this > is done without relying on any external headers, with the VA_ARG macro > having been reverse engineered from MSFT ARM assembly output. >* PATCH 6 enables the selection of ARM in the conf templates. > >With these patches, VS2017 toolchain users should be able to compile >regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, >ARM support does not require a specific update of Visual Studio 2017, as >the ARM toolchain has been available from the very first release. > >Additional notes: > >We tested compiling and running the full UEFI Shell with this series, as >well as a small set of applications and drivers, and found no issues. >With an additional patch [1], it is also possible to use this proposal to >compile a complete QEMU ARM firmware. As the patch shows, the changes >that >need to be applied to the EDK2 sources to achieve this are actually very >minimal. > >However, the generated firmware does not currently boot, possibly because >of the following warnings being generated by the MS compiler: >- ArmCpuDxe.dll : warning LNK4072: section count 118 exceeds max (96); >image may not run >- UiApp.dll : warning LNK4072: section count 113 exceeds max (96); image may >not run > >As far as I could see, the section count max is hardcoded so a workaround >would be needed to address those. > >Also, because the VS2017 ARM compiler forces a section alignment of 4096 >bytes (which in turn forces use to use /FILEALIGN:4096 as a linker option >for the firmware generation), the generated firmware exceeds 2MB and we >had to double its size to 4MB. > >At this stage, since the goal of this series is to allow users to compile >regular ARM UEFI applications using the VS2017 toolchain, I have no plans >to spend more time on the QEMU firmware issues, especially as I suspect >that reducing the firmware size back to 2 MB may not be achievable without >Microsoft altering their compiler. I am however hopeful that ARM >specialists can take this matter over eventually... > >Regards, > >/Pete > >[1] >https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a906048 >13f037b13 > >Pete Batard (6): > MdePkg: Disable some Level 4 warnings for VS2017/ARM > MdePkg/Library/BaseStackCheckLib: Add Null handler for VS2017/ARM > MdePkg/Library/BaseLib: Enable VS2017/ARM builds > ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds > MdePkg/Include: Add VA list support for VS2017/ARM > BaseTools/Conf: Add VS2017/ARM support > > ArmPkg/Library/CompilerIntrinsicsLib/Arm/div.asm | 43 +++-- > ArmPkg/Library/CompilerIntrinsicsLib/Arm/ldivmod.asm | 40 ++-- > ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm | 22 +++-- > ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm | 29 +- > ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf | 16 +++- > ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c | 34 +++ > ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c | 33 +++ > BaseTools/Conf/build_rule.template | 31 ++- > BaseTools/Conf/tools_def.template | 31 +++ > MdePkg/Include/Arm/ProcessorBind.h | 96 >+++- > MdePkg/Include/Base.h | 13 +++ > MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm | 5 +- > MdePkg/Library/BaseLib/BaseLib.inf | 16 +++- > MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf | 5 +- > MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c | 18 > 15 files changed, 372 insertions(+), 60 deletions(-) > create mode 100644 ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c > create mode 100644 ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c > create mode 100644 >MdePkg/Library/BaseStackCheckLib/Base
Re: [edk2] [PATCH] MdeModulePkg/Partition: Fix media probe
Tested-by/Reviewed-by: Jian J Wang > -Original Message- > From: Ni, Ruiyu > Sent: Thursday, January 25, 2018 5:45 PM > To: edk2-devel@lists.01.org > Cc: Wang, Jian J > Subject: [PATCH] MdeModulePkg/Partition: Fix media probe > > The call in ProbeMediaStatusEx() to the ReadDisk() function of the > EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c > crashed in DiskIo2ReadWriteDisk() because of the NULL value of > the destination buffer pointer. > > Pass the address of a buffer in the stack instead of a NULL > pointer. > > The similar fix was applied to ProbeMediaStatus in commit > df473cc1fc9acd1a623ec7e05276f2f0635c19d2 > * MdeModulePkg/PartitionDxe: Fix media probe > > Somehow ProbeMediaStatusEx() wasn't changed together. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Jian J Wang > --- > MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c > b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c > index bb9d0b70ce..46c0877cee 100644 > --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c > +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c > @@ -4,7 +4,7 @@ >of the raw block devices media. Currently "El Torito CD-ROM", UDF, Legacy >MBR, and GPT partition schemes are supported. > > -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. > This program and the accompanying materials > are licensed and made available under the terms and conditions of the BSD > License > which accompanies this distribution. The full text of the license may be > found > at > @@ -777,11 +777,15 @@ ProbeMediaStatusEx ( >) > { >EFI_STATUS Status; > + UINT8 Buffer[1]; > >// > - // Read 1 byte from offset 0 but passing NULL as buffer pointer > + // Read 1 byte from offset 0 to check if the MediaId is still valid. > + // The reading operation is synchronious thus it is not worth it to > + // allocate a buffer from the pool. The destination buffer for the > + // data is in the stack. >// > - Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, NULL); > + Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, (VOID*)Buffer); >if ((Status == EFI_NO_MEDIA) || (Status == EFI_MEDIA_CHANGED)) { > return Status; >} > -- > 2.15.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 0/6] Add ARM support for VS2017
Thanks Liming. From the way you framed your comment, I'm not completely sure if there's action still needed on my side... Do I actually need to resubmit a patch set with "Reviewed By"? Or, now that each patch should have flagged as reviewed, are we simply supposed to wait for formal integration? Regards, /Pete On 2018.01.25 10:27, Gao, Liming wrote: Pete: The changes in BaseTools and MdePkg are good to me. You can add my R-B. -Original Message- From: Pete Batard [mailto:p...@akeo.ie] Sent: Friday, January 12, 2018 9:33 PM To: edk2-devel@lists.01.org Cc: Gao, Liming ; ard.biesheu...@linaro.org; eug...@hp.com Subject: [PATCH v5 0/6] Add ARM support for VS2017 (Same as v4, except for the AREA names where we replaced the RVCT macros, in patch 4/6, so that it matches what would have been produced with the macros) The following series adds ARM compilation support for the VS2017 toolchain. * PATCH 1 targets the disabling of VS Level 4 warnings. The disabled warnings for ARM are now aligned with IA32 and X64. * PATCH 2 adds a NULL handler for the base stack check, since this is a GCC functionality. * PATCH 3 updates MdePkg/Library/BaseLib so that the RVCT assembly sources are also used for MSFT. * PATCH 4 adds the required compiler intrinsics replacements for division, shift, by reusing the RVCT code, as well as memset/memcpy. * PATCH 5 adds variable argument handlers for print output. Note that this is done without relying on any external headers, with the VA_ARG macro having been reverse engineered from MSFT ARM assembly output. * PATCH 6 enables the selection of ARM in the conf templates. With these patches, VS2017 toolchain users should be able to compile regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, ARM support does not require a specific update of Visual Studio 2017, as the ARM toolchain has been available from the very first release. Additional notes: We tested compiling and running the full UEFI Shell with this series, as well as a small set of applications and drivers, and found no issues. With an additional patch [1], it is also possible to use this proposal to compile a complete QEMU ARM firmware. As the patch shows, the changes that need to be applied to the EDK2 sources to achieve this are actually very minimal. However, the generated firmware does not currently boot, possibly because of the following warnings being generated by the MS compiler: - ArmCpuDxe.dll : warning LNK4072: section count 118 exceeds max (96); image may not run - UiApp.dll : warning LNK4072: section count 113 exceeds max (96); image may not run As far as I could see, the section count max is hardcoded so a workaround would be needed to address those. Also, because the VS2017 ARM compiler forces a section alignment of 4096 bytes (which in turn forces use to use /FILEALIGN:4096 as a linker option for the firmware generation), the generated firmware exceeds 2MB and we had to double its size to 4MB. At this stage, since the goal of this series is to allow users to compile regular ARM UEFI applications using the VS2017 toolchain, I have no plans to spend more time on the QEMU firmware issues, especially as I suspect that reducing the firmware size back to 2 MB may not be achievable without Microsoft altering their compiler. I am however hopeful that ARM specialists can take this matter over eventually... Regards, /Pete [1] https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a906048 13f037b13 Pete Batard (6): MdePkg: Disable some Level 4 warnings for VS2017/ARM MdePkg/Library/BaseStackCheckLib: Add Null handler for VS2017/ARM MdePkg/Library/BaseLib: Enable VS2017/ARM builds ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds MdePkg/Include: Add VA list support for VS2017/ARM BaseTools/Conf: Add VS2017/ARM support ArmPkg/Library/CompilerIntrinsicsLib/Arm/div.asm | 43 +++-- ArmPkg/Library/CompilerIntrinsicsLib/Arm/ldivmod.asm | 40 ++-- ArmPkg/Library/CompilerIntrinsicsLib/Arm/llsr.asm | 22 +++-- ArmPkg/Library/CompilerIntrinsicsLib/Arm/uldiv.asm | 29 +- ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf | 16 +++- ArmPkg/Library/CompilerIntrinsicsLib/memcpy_ms.c | 34 +++ ArmPkg/Library/CompilerIntrinsicsLib/memset_ms.c | 33 +++ BaseTools/Conf/build_rule.template | 31 ++- BaseTools/Conf/tools_def.template | 31 +++ MdePkg/Include/Arm/ProcessorBind.h | 96 +++- MdePkg/Include/Base.h | 13 +++ MdePkg/Library/BaseLib/Arm/CpuBreakpoint.asm | 5 +- MdePkg/Library/BaseLib/BaseLib.inf | 16 +++- MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf | 5 +- MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c | 18 15
[edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol
Instead of registering a notification callback on the driver binding protocol, and attempting to connect our I2C master handle each time a new driver is registered, switch to the more obvious approach of registering a notification callback on the I2C master protocol directly. The original code was written under the assumption that it would make the RTC available at an earlier time, but given that all handles that are created during the execution of a driver entry point are connected by DXE core right away (i.e., before StartImage() returns), this is not really necessary, and in fact, may result in the driver already having been connected by the time we attempt to connect it. Note that it is now up to the platform to ensure that ConnectController() is called for the handle if DXE core does not call it by itself, or does call it but at a time when no I2C master protocol driver is available yet. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | 31 Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 1 - 2 files changed, 13 insertions(+), 19 deletions(-) diff --git a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c index 6bc4aef28849..fb58e1feb424 100644 --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c @@ -41,7 +41,7 @@ #define EPOCH_BASE2000 STATIC EFI_HANDLE mI2cMasterHandle; -STATIC VOID *mDriverEventRegistration; +STATIC VOID *mI2cMasterEventRegistration; STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster; STATIC EFI_EVENT mRtcVirtualAddrChangeEvent; @@ -263,12 +263,12 @@ LibSetWakeupTime ( STATIC VOID -DriverRegistrationEvent ( +I2cMasterRegistrationEvent ( IN EFI_EVENT Event, IN VOID*Context ) { - EFI_HANDLEHandle[2]; + EFI_HANDLEHandle; UINTN BufferSize; EFI_STATUSStatus; EFI_I2C_MASTER_PROTOCOL *I2cMaster; @@ -280,10 +280,10 @@ DriverRegistrationEvent ( do { BufferSize = sizeof (EFI_HANDLE); Status = gBS->LocateHandle (ByRegisterNotify, -&gEfiDriverBindingProtocolGuid, -mDriverEventRegistration, +&gEfiI2cMasterProtocolGuid, +mI2cMasterEventRegistration, &BufferSize, -Handle); +&Handle); if (EFI_ERROR (Status)) { if (Status != EFI_NOT_FOUND) { DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n", @@ -292,12 +292,7 @@ DriverRegistrationEvent ( break; } -// -// Check if we can connect our handle to this driver. -// -Handle[1] = NULL; -Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE); -if (EFI_ERROR (Status)) { +if (Handle != mI2cMasterHandle) { continue; } @@ -378,16 +373,16 @@ LibRtcInitialize ( ASSERT_EFI_ERROR (Status); // - // Register a protocol registration notification callback on the driver - // binding protocol so we can attempt to connect our I2C master to it - // as soon as it appears. + // Register a protocol registration notification callback on the I2C master + // protocol. This will notify us even if the protocol instance we are looking + // for has already been installed. // EfiCreateProtocolNotifyEvent ( -&gEfiDriverBindingProtocolGuid, +&gEfiI2cMasterProtocolGuid, TPL_CALLBACK, -DriverRegistrationEvent, +I2cMasterRegistrationEvent, NULL, -&mDriverEventRegistration); +&mI2cMasterEventRegistration); // // Register for the virtual address change event diff --git a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf index 1a9a6f6c9cf3..e232902c6b5d 100644 --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf @@ -40,7 +40,6 @@ [Guids] gEfiEventVirtualAddressChangeGuid [Protocols] - gEfiDriverBindingProtocolGuid ## CONSUMES gEfiI2cMasterProtocolGuid ## CONSUMES gPcf8563RealTimeClockLibI2cMasterProtocolGuid ## CONSUMES -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 2/8] Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid
Do a global replace of gPcf8563RealTimeClockLibI2cMasterProtolGuid with gPcf8563RealTimeClockLibI2cMasterProtocolGuid. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | 2 +- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec | 2 +- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 4 ++-- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 2 +- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c index 67f8e7de4025..6bc4aef28849 100644 --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c @@ -373,7 +373,7 @@ LibRtcInitialize ( // BufferSize = sizeof (EFI_HANDLE); Status = gBS->LocateHandle (ByProtocol, - &gPcf8563RealTimeClockLibI2cMasterProtolGuid, NULL, + &gPcf8563RealTimeClockLibI2cMasterProtocolGuid, NULL, &BufferSize, &mI2cMasterHandle); ASSERT_EFI_ERROR (Status); diff --git a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec index 3849056f164a..94c4a3f1ef4c 100644 --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec @@ -22,7 +22,7 @@ [Guids] gPcf8563RealTimeClockLibTokenSpaceGuid = { 0xaaf5b169, 0x93a0, 0x4d60, { 0xba, 0xe4, 0x06, 0x07, 0x92, 0x8e, 0x63, 0xdd }} [Protocols] - gPcf8563RealTimeClockLibI2cMasterProtolGuid = { 0xa6af18ae, 0x3bd5, 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }} + gPcf8563RealTimeClockLibI2cMasterProtocolGuid = { 0xa6af18ae, 0x3bd5, 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }} [PcdsFixedAtBuild] gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress|0x51|UINT8|0x0001 diff --git a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf index 9907e343ba78..1a9a6f6c9cf3 100644 --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf @@ -42,11 +42,11 @@ [Guids] [Protocols] gEfiDriverBindingProtocolGuid ## CONSUMES gEfiI2cMasterProtocolGuid ## CONSUMES - gPcf8563RealTimeClockLibI2cMasterProtolGuid ## CONSUMES + gPcf8563RealTimeClockLibI2cMasterProtocolGuid ## CONSUMES [FixedPcd] gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cBusFrequency [Depex] - gPcf8563RealTimeClockLibI2cMasterProtolGuid + gPcf8563RealTimeClockLibI2cMasterProtocolGuid diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c index 098a4dbd324e..91c1b66ea1f8 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c @@ -183,7 +183,7 @@ PlatformDxeEntryPoint ( // through the I2C driver stack (which cannot be used at runtime) // Status = gBS->InstallProtocolInterface (&Handle, - &gPcf8563RealTimeClockLibI2cMasterProtolGuid, + &gPcf8563RealTimeClockLibI2cMasterProtocolGuid, EFI_NATIVE_INTERFACE, NULL); ASSERT_EFI_ERROR (Status); diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf index 766f4041c826..4d6a1d637922 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf @@ -53,7 +53,7 @@ [Guids] [Protocols] gEdkiiNonDiscoverableDeviceProtocolGuid ## PRODUCES gEfiPciIoProtocolGuid ## CONSUMES - gPcf8563RealTimeClockLibI2cMasterProtolGuid ## PRODUCES + gPcf8563RealTimeClockLibI2cMasterProtocolGuid ## PRODUCES [FixedPcd] gSynQuacerTokenSpaceGuid.PcdNetsecEepromBase -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 0/8] Socionext SynQuacer updates
Some stuff I have collected over the past 2 months or so. Note that this includes the SATA spread spectrum patch I sent out yesterday: I had forgotten all about this backlog, and I only remembered when attempting to apply it to the master branch. Ard Biesheuvel (8): Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061 SATA Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol Silicon/SynQuacerI2cDxe: remove spurious format specifier Silicon/SynQuacer: load I2C driver before platform DXE driver Silicon/SynQuacer/DeviceTree: align uart DT nodes Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 + Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 2 + Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | 33 +++--- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec | 2 +- Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 5 +- Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts | 7 ++ Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 38 +++ Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts | 7 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => Pci.c} | 85 +++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 109 +++- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h | 12 +++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 17 ++- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni | 28 + Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 61 +++ Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +- Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf | 2 +- Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h | 23 + Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h | 28 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf | 2 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c | 25 - Silicon/Socionext/SynQuacer/SynQuacer.dec | 7 ++ 21 files changed, 424 insertions(+), 73 deletions(-) rename Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => Pci.c} (63%) create mode 100644 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni create mode 100644 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr create mode 100644 Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h create mode 100644 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 8/8] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed
Add menu options to the SynQuacer Platform menu screen to limit the maximum PCIe link speed for each RC individually. This may be useful to work around potential PCIe issues. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 + Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 2 + Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c | 4 +- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 107 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h | 12 +++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 11 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni | 28 + Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 61 +++ Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h | 23 + Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h | 28 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf | 2 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c | 25 - Silicon/Socionext/SynQuacer/SynQuacer.dec | 5 + 13 files changed, 304 insertions(+), 6 deletions(-) diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc index 86685d1dec3b..2d46b4515749 100644 --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc index b4b9239143bc..263b6454ff72 100644 --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c index 9af3dd942cdd..2a0fefbd423f 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c @@ -160,7 +160,9 @@ OnPciIoProtocolNotify ( // 2-port sibling of which samples were used in development) needs a // little nudge to get it to train the downstream links at Gen2 speed. // - RetrainAsm1184eDownstreamPort (PciIo); + if (mHiiSettings->Pcie0MaxSpeed != PCIE_MAX_SPEED_GEN1) { +RetrainAsm1184eDownstreamPort (PciIo); + } break; } } diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c index 91c1b66ea1f8..b60607d05861 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c @@ -14,6 +14,36 @@ #include "PlatformDxe.h" +UINT64mHiiSettingsVal; +SYNQUACER_PLATFORM_VARSTORE_DATA *mHiiSettings; + +typedef struct { + VENDOR_DEVICE_PATH VendorDevicePath; + EFI_DEVICE_PATH_PROTOCOLEnd; +} HII_VENDOR_DEVICE_PATH; + +STATIC HII_VENDOR_DEVICE_PATH mPlatformDxeHiiVendorDevicePath = { + { +{ + HARDWARE_DEVICE_PATH, + HW_VENDOR_DP, + { +(UINT8) (sizeof (VENDOR_DEVICE_PATH)), +(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) + } +}, +SYNQUACER_PLATFORM_FORMSET_GUID + }, + { +END_DEVICE_PATH_TYPE, +END_ENTIRE_DEVICE_PATH_SUBTYPE, +{ + (UINT8) (END_DEVICE_PATH_LENGTH), + (UINT8)
[edk2] [PATCH edk2-platforms 1/8] Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061 SATA
The ASM1061 SATA controller integrated into the DeveloperBox board emits too much electromagnetic radiation, so it needs spread spectrum mode enabled. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm --- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/{Asmedia118x.c => Pci.c} | 83 +++- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 +- 2 files changed, 64 insertions(+), 21 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c similarity index 64% rename from Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c rename to Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c index 874e83a649b5..9af3dd942cdd 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Asmedia118x.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c @@ -15,9 +15,12 @@ #include "PlatformDxe.h" #define ASMEDIA_VID 0x1b21 +#define ASM1061_PID 0x0612 #define ASM1182E_PID0x1182 #define ASM1184E_PID0x1184 +#define ASM1061_SSC_OFFSET 0xA10 + #define ASM118x_PCIE_CAPABILITY_OFFSET 0x80 #define ASM118x_PCIE_LINK_CONTROL_OFFSET(ASM118x_PCIE_CAPABILITY_OFFSET + \ OFFSET_OF (PCI_CAPABILITY_PCIEXP, \ @@ -39,24 +42,10 @@ RetrainAsm1184eDownstreamPort ( IN EFI_PCI_IO_PROTOCOL *PciIo ) { - UINT16PciVidPid[2]; EFI_STATUSStatus; PCIE_CAP Cap; PCI_REG_PCIE_LINK_CONTROL LinkControl; - Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET, -ARRAY_SIZE (PciVidPid), &PciVidPid); - if (EFI_ERROR (Status)) { -DEBUG ((DEBUG_WARN, "%a: failed to read PCI vendor/product ID - %r\n", - __FUNCTION__, Status)); -return; - } - - if (PciVidPid[0] != ASMEDIA_VID || - (PciVidPid[1] != ASM1182E_PID && PciVidPid[1] != ASM1184E_PID)) { -return; - } - // // The upstream and downstream ports share the same PID/VID, so check // the port type. This assumes the PCIe Express capability block lives @@ -91,6 +80,34 @@ RetrainAsm1184eDownstreamPort ( STATIC VOID +EnableAsm1061SpreadSpectrum ( + IN EFI_PCI_IO_PROTOCOL *PciIo + ) +{ + EFI_STATUS Status; + UINT8 SscVal; + + DEBUG ((DEBUG_INFO, "%a: enabling spread spectrum mode 0 for ASM1061\n", +__FUNCTION__)); + + // SSC mode 0~-4000 ppm, 1:1 modulation + + SscVal = 0; + Status = PciIo->Pci.Write (PciIo, EfiPciIoWidthUint8, ASM1061_SSC_OFFSET, 1, +&SscVal); + ASSERT_EFI_ERROR (Status); + + MemoryFence (); + gBS->Stall (1); // delay at least 100 ns between writes of the same register + + SscVal = 1; + Status = PciIo->Pci.Write (PciIo, EfiPciIoWidthUint8, ASM1061_SSC_OFFSET, 1, +&SscVal); + ASSERT_EFI_ERROR (Status); +} + +STATIC +VOID EFIAPI OnPciIoProtocolNotify ( IN EFI_EVENT Event, @@ -101,6 +118,7 @@ OnPciIoProtocolNotify ( EFI_STATUSStatus; EFI_HANDLEHandleBuffer; UINTN BufferSize; + UINT16PciVidPid[2]; while (TRUE) { BufferSize = sizeof (EFI_HANDLE); @@ -114,12 +132,37 @@ OnPciIoProtocolNotify ( (VOID **)&PciIo); ASSERT_EFI_ERROR (Status); -// -// The ASM1184E 4-port PCIe switch on the DeveloperBox board (and its -// 2-port sibling of which samples were used in development) needs a -// little nudge to get it to train the downstream links at Gen2 speed. -// -RetrainAsm1184eDownstreamPort (PciIo); +Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET, + ARRAY_SIZE (PciVidPid), &PciVidPid); +if (EFI_ERROR (Status)) { + DEBUG ((DEBUG_WARN, "%a: failed to read PCI vendor/product ID - %r\n", +__FUNCTION__, Status)); + continue; +} + +if (PciVidPid[0] != ASMEDIA_VID) { + continue; +} + +switch (PciVidPid[1]) { +case ASM1061_PID: + // + // The ASM1061 SATA controller as integrated into the DeveloperBox design + // emits too much electromagnetic radiation. So enable spread spectrum + // mode. + // + EnableAsm1061SpreadSpectrum (PciIo); + break; +case ASM1182E_PID: +case ASM1184E_PID: + // + // The ASM1184E 4-port PCIe switch on the DeveloperBox board (and its + // 2-port sibling of which samples were used in development) needs a + // little nudge to get it to train the downstream links at Gen2 speed. + // + RetrainAsm1184eDownstreamPort (PciIo); + break; +} } } diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf b/Silicon/Socionext/SynQuac
[edk2] [PATCH edk2-platforms 4/8] Silicon/SynQuacerI2cDxe: remove spurious format specifier
Remove a %r without an associated parameter. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c index c3703dfb6c33..46c512a20151 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c @@ -335,7 +335,7 @@ SynQuacerI2cStartRequest ( } if (MmioRead8 (I2c->MmioBase + F_I2C_REG_BSR) & F_I2C_BSR_LRB) { - BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received - %r\n", __FUNCTION__)); + BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received\n", __FUNCTION__)); Status = EFI_DEVICE_ERROR; break; } -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding
The upstream version of the Linux NETSEC driver expects the PHY DT node to appear under a MDIO subnode, so fix this in the device tree. Fix the node name as well, this should be 'ethernet' not 'netsec', and add a clock-names property describing the single clock reference as 'phy_ref_clk'. Also, move the PHY subnode into the per-platform .dts file so we can set the unit address in the node name. This is necessary because recent versions of the DT compiler are more finicky about this. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts | 7 + Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 +--- Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts | 7 + 3 files changed, 28 insertions(+), 16 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts index d2cd7ef90e6f..488c51a0f793 100644 --- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts +++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts @@ -44,3 +44,10 @@ "GPIO-K", "GPIO-L", "PEC-PD26", "PEC-PD27", "PEC-PD28", "PEC-PD29", "PEC-PD30", "PEC-PD31"; }; + +&mdio_netsec { +phy_netsec: ethernet-phy@7 { +compatible = "ethernet-phy-ieee802.3-c22"; +reg = <7>; +}; +}; diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi index 7c3518facb98..6ee7a0b7ccb4 100644 --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi @@ -457,25 +457,23 @@ #clock-cells = <0>; }; -eth0: netsec@522D { -compatible = "socionext,synquacer-netsec"; -reg = <0 0x522d 0x0 0x1>, - <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; -interrupts = ; -clocks = <&clk_netsec>; -phy-mode = "rgmii"; -max-speed = <1000>; -max-frame-size = <9000>; -phy-handle = <ðphy0>; -dma-coherent; +ethernet@522d { +compatible = "socionext,synquacer-netsec"; +reg = <0 0x522d 0x0 0x1>, + <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; +interrupts = ; +clocks = <&clk_netsec>; +clock-names = "phy_ref_clk"; +phy-mode = "rgmii"; +max-speed = <1000>; +max-frame-size = <9000>; +phy-handle = <&phy_netsec>; +dma-coherent; +mdio_netsec: mdio { #address-cells = <1>; #size-cells = <0>; - -ethphy0: ethernet-phy { -compatible = "ethernet-phy-ieee802.3-c22"; -reg = ; -}; +}; }; smmu: iommu@582c { diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts index 132fd370a71b..97fddfedcb46 100644 --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts @@ -34,3 +34,10 @@ &sdhci { status = "okay"; }; + +&mdio_netsec { +phy_netsec: ethernet-phy@1 { +compatible = "ethernet-phy-ieee802.3-c22"; +reg = <1>; +}; +}; -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 5/8] Silicon/SynQuacer: load I2C driver before platform DXE driver
To ensure that the I2C master protocol is installed immediately onto the handles created by PlatformDxe in its entry point, force the SynQuacerI2cDxe driver to be loaded before PlatformDxe. These handles are recursively connected by the DXE core as soon as they appear, and so ensuring that the I2C master protocol driver is available at this time will ensure that these handles will be connected to it right away. This is useful when implementations of architectural protocols such as RTC or the EFI variable store, which should become available long before the ordinary dispatch of UEFI driver model drivers is started at the end of DXE, are based on I2C. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 +- Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf | 2 +- Silicon/Socionext/SynQuacer/SynQuacer.dec | 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf index 4d6a1d637922..f075957d7456 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf @@ -17,7 +17,7 @@ [Defines] INF_VERSION= 0x0001001A BASE_NAME = PlatformDxe - FILE_GUID = ac422cc1-d916-489a-b165-536fdfc633c2 + FILE_GUID = ac422cc1-d916-489a-b165-536fdfc633c2 # gSynQuacerPlatformDxeFileGuid MODULE_TYPE= DXE_DRIVER VERSION_STRING = 1.0 ENTRY_POINT= PlatformDxeEntryPoint diff --git a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf index fa715366878c..325816ba0b88 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf @@ -56,4 +56,4 @@ [FixedPcd] gSynQuacerTokenSpaceGuid.PcdI2cReferenceClock [Depex] - TRUE + BEFORE gSynQuacerPlatformDxeFileGuid diff --git a/Silicon/Socionext/SynQuacer/SynQuacer.dec b/Silicon/Socionext/SynQuacer/SynQuacer.dec index a21f12b5bc32..76529e3c2164 100644 --- a/Silicon/Socionext/SynQuacer/SynQuacer.dec +++ b/Silicon/Socionext/SynQuacer/SynQuacer.dec @@ -25,6 +25,8 @@ [Guids] gSynQuacerNonDiscoverableI2cMasterGuid = { 0x364ee675, 0x9e44, 0x42b7, { 0xa5, 0xe4, 0x92, 0x84, 0xdb, 0x85, 0xda, 0x09 } } gSynQuacerNonDiscoverableRuntimeI2cMasterGuid = { 0x5f35aa9b, 0x8c6f, 0x4828, { 0xbd, 0x44, 0x7c, 0xc0, 0xeb, 0x2d, 0xfe, 0xb9 } } + gSynQuacerPlatformDxeFileGuid = { 0xac422cc1, 0xd916, 0x489a, { 0xb1, 0x65, 0x53, 0x6f, 0xdf, 0xc6, 0x33, 0xc2 } } + [Ppis] gSynQuacerDramInfoPpiGuid = { 0x3e1d7356, 0xdda4, 0x4b1a, { 0x93, 0x46, 0xbf, 0x89, 0x1c, 0x86, 0x46, 0xcc } } -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/DeviceTree: align uart DT nodes
Align the UART DT nodes: - use 'uart' not 'fuart' as node name for the second serial port - create an alias 'serial1' for the second serial port - use UART clock reference instead of hardcoded frequency - split 'clocks' property into 1 cell per phandle Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi index 37a3981f0360..7c3518facb98 100644 --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi @@ -32,6 +32,7 @@ aliases { serial0 = &soc_uart0; +serial1 = &fuart; }; chosen { @@ -436,15 +437,16 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0x2a40 0x0 0x1000>; interrupts = ; -clocks = <&clk_uart &clk_apb>; +clocks = <&clk_uart>, <&clk_apb>; clock-names = "uartclk", "apb_pclk"; }; -fuart: fuart@5104 { +fuart: uart@5104 { compatible = "snps,dw-apb-uart"; reg = <0x0 0x5104 0x0 0x1000>; interrupts = ; -clock-frequency = <6250>; +clocks = <&clk_uart>, <&clk_apb>; +clock-names = "baudclk", "apb_pclk"; reg-io-width = <4>; reg-shift = <2>; }; -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] setting the TLS cipher list for HTTPS booting
On 01/25/18 05:52, Wu, Jiaxin wrote: > Hi Laszlo, > > The HttpDxe driver needs to install the Driver Binding Protocol so as > to check if a specific controller is supported by HttpDxe. HttpDxe > can only be started if the TcpServiceBindingProtocol existed. So, it > has to follow the UEFI Driver Model. > > For the PCD usage, I think it should be fine to cover the > configuration of UEFI Drivers through the PCD settings. The > requirement of *.inf needs to include the PcdLib and the section of > [Pcd]. We already have the similar pattern for this usage, for > example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in > MdeModulePkg. Besides, there are some advantages by using PCD > compared to the variable. First, PCD is one kind of interface that > more formal than a private variable, the setting by PCD is more > acceptable by the consumer. Secondly, from a *security* standpoint, > variable can be dumped easily from the flash region. Here, even > though it's no security impact towards the cipher list storage > because it will be public shared to remote server, but we need to > think and *align* with other configurations for TLS in HTTPS level. > For example, in the future, we might support the HTTPS mutual > authentication, than the host PrivateKey/Password > (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable > due to its confidentiality, while PCD is good choice. At that time, > we will also provide the PCD for EfiTlsConfigDataTypeCACertificate, > which is currently setting by the variable (TlsCaCertificate), so as > to align all the configuration setting on one line, which can reduce > the complexity of platform usage. Finally, we can also save the > variable space. > > From the above, the dynamic PCD is a solution I still preferred. OK, it works for me. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase
On 01/25/18 05:56, Bi, Dandan wrote: > Hi Laszlo, > > Thank you for your comments. > > Yes. The PERF_INMODULE_START_ID macro is from "ExtendedFirmwarePerformance.h" > which is added in the new performance infrastructure patches([ mail subject: > patch 0/8] Update EDKII Performance infrastructure based on ACPI FPDT table). > That is the dependency I mean. > > I will send V2 of this patch and the patch which remove Pref code after "new > performance infrastructure" patches have been committed . Then I will refine > the commit message of these two patches, add commit hash value of "new > performance infrastructure" patches if I need to reference it. Thank you. I had some other questions lower down, about the PERF_START_EX() arguments. Can you please help me understand those better? Thanks! Laszlo > > Thanks, > Dandan > > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, January 24, 2018 11:45 PM > To: Bi, Dandan ; edk2-devel@lists.01.org > Cc: Dong, Eric ; Gao, Liming > Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase > > On 01/24/18 08:59, Dandan Bi wrote: >> Add more perf entry to hook BootScriptDonePpi/EndOfPeiPpi/ >> EndOfS3Resume. >> >> Notes: This patch depends on the new performance infrastructure. > > Since this statement is going into the commit log, please be more specific > about the "new performance infrastructure" (TianoCore BZ or commit hashes > etc). > > Also, how is the dependency established? For example, OVMF uses > BasePerformanceLibNull; so I think it will see no changes. > > Do you mean the PERF_INMODULE_START_ID macro, from > "ExtendedFirmwarePerformance.h"? Ah, that's not committed yet. In this case, > please add a reference to the mailing list message (subject and archive URL) > that adds it. > > (Actually, the best solution is to reference the TianoCore BZ, and then add > the mailing list URL for each patch set submission to the TianoCore BZ.) > >> >> Cc: Eric Dong >> Cc: Laszlo Ersek >> Cc: Liming Gao >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Dandan Bi >> --- >> UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 15 >> ++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> >> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >> index b597ac7..d7d2a4d 100644 >> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >> @@ -2,11 +2,11 @@ >>This module produces the EFI_PEI_S3_RESUME2_PPI. >>This module works with StandAloneBootScriptExecutor to S3 resume to OS. >>This module will execute the boot script saved during last boot and after >> that, >>control is passed to OS waking up handler. >> >> - Copyright (c) 2006 - 2017, Intel Corporation. All rights >> reserved. >> + Copyright (c) 2006 - 2018, Intel Corporation. All rights >> + reserved. >>Copyright (c) 2017, AMD Incorporated. 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 @@ >> -21,10 +21,11 @@ #include >> >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> #include >> #include >> @@ -551,13 +552,17 @@ S3ResumeBootOs ( >>PERF_END (NULL, "ScriptExec", NULL, 0); >> >>// >>// Install BootScriptDonePpi >>// >> + PERF_START_EX (NULL, "BootScriptDonePpi", NULL, 0, >> + PERF_INMODULE_START_ID); >> + > > My question here is not really specific to this patch, but I guess asking it > this time is just as good as any other time: > > - Why do we pass NULL for Module, rather than gEfiCallerBaseName? > > - We already have START and END calls for the performance measurement; why do > we use different Identifier values for the records added? > > (These questions are more for my education than about possible issues in the > patch.) > > Thanks! > Laszlo > > >>Status = PeiServicesInstallPpi (&mPpiListPostScriptTable); >>ASSERT_EFI_ERROR (Status); >> >> + PERF_END_EX (NULL, "BootScriptDonePpi", NULL, 0, >> + PERF_INMODULE_END_ID); >> + >>// >>// Get ACPI Table Address >>// >>Facs = (EFI_ACPI_4_0_FIRMWARE_ACPI_CONTROL_STRUCTURE *) ((UINTN) >> (AcpiS3Context->AcpiFacsTable)); >> >> @@ -576,18 +581,26 @@ S3ResumeBootOs ( >>} >> >>// >>// Install EndOfPeiPpi >>// >> + PERF_START_EX (NULL, "EndOfPeiPpi", NULL, 0, >> + PERF_INMODULE_START_ID); >> + >>Status = PeiServicesInstallPpi (&mPpiListEndOfPeiTable); >>ASSERT_EFI_ERROR (Status); >> >> + PERF_END_EX (NULL, "EndOfPeiPpi", NULL, 0, PERF_INMODULE_END_ID); >> + >>// >>// Signal EndOfS3Resume event. >>// >> + PERF_START_EX (NULL, "EndOfS3Resume", NULL, 0, >> + PERF_INMODULE_ST
Re: [edk2] [PATCH edk2-platforms 2/8] Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid
On Thu, Jan 25, 2018 at 12:27:30PM +, Ard Biesheuvel wrote: > Do a global replace of gPcf8563RealTimeClockLibI2cMasterProtolGuid with > gPcf8563RealTimeClockLibI2cMasterProtocolGuid. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | 2 > +- > Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec | 2 > +- > Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 4 > ++-- > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 2 > +- > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 > +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git > a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > index 67f8e7de4025..6bc4aef28849 100644 > --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > @@ -373,7 +373,7 @@ LibRtcInitialize ( >// >BufferSize = sizeof (EFI_HANDLE); >Status = gBS->LocateHandle (ByProtocol, > - &gPcf8563RealTimeClockLibI2cMasterProtolGuid, NULL, > + &gPcf8563RealTimeClockLibI2cMasterProtocolGuid, NULL, >&BufferSize, &mI2cMasterHandle); >ASSERT_EFI_ERROR (Status); > > diff --git > a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec > b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec > index 3849056f164a..94c4a3f1ef4c 100644 > --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec > +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.dec > @@ -22,7 +22,7 @@ [Guids] >gPcf8563RealTimeClockLibTokenSpaceGuid = { 0xaaf5b169, 0x93a0, 0x4d60, { > 0xba, 0xe4, 0x06, 0x07, 0x92, 0x8e, 0x63, 0xdd }} > > [Protocols] > - gPcf8563RealTimeClockLibI2cMasterProtolGuid = { 0xa6af18ae, 0x3bd5, > 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }} > + gPcf8563RealTimeClockLibI2cMasterProtocolGuid = { 0xa6af18ae, 0x3bd5, > 0x4af9, { 0xbb, 0x6a, 0xdb, 0x85, 0x07, 0x62, 0x81, 0x38 }} > > [PcdsFixedAtBuild] > > gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress|0x51|UINT8|0x0001 > diff --git > a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > index 9907e343ba78..1a9a6f6c9cf3 100644 > --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > @@ -42,11 +42,11 @@ [Guids] > [Protocols] >gEfiDriverBindingProtocolGuid ## CONSUMES >gEfiI2cMasterProtocolGuid ## CONSUMES > - gPcf8563RealTimeClockLibI2cMasterProtolGuid ## CONSUMES > + gPcf8563RealTimeClockLibI2cMasterProtocolGuid ## CONSUMES > > [FixedPcd] >gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cSlaveAddress >gPcf8563RealTimeClockLibTokenSpaceGuid.PcdI2cBusFrequency > > [Depex] > - gPcf8563RealTimeClockLibI2cMasterProtolGuid > + gPcf8563RealTimeClockLibI2cMasterProtocolGuid > diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > index 098a4dbd324e..91c1b66ea1f8 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > @@ -183,7 +183,7 @@ PlatformDxeEntryPoint ( >// through the I2C driver stack (which cannot be used at runtime) >// >Status = gBS->InstallProtocolInterface (&Handle, > - &gPcf8563RealTimeClockLibI2cMasterProtolGuid, > + &gPcf8563RealTimeClockLibI2cMasterProtocolGuid, >EFI_NATIVE_INTERFACE, NULL); >ASSERT_EFI_ERROR (Status); > > diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > index 766f4041c826..4d6a1d637922 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > @@ -53,7 +53,7 @@ [Guids] > [Protocols] >gEdkiiNonDiscoverableDeviceProtocolGuid ## PRODUCES >gEfiPciIoProtocolGuid ## CONSUMES > - gPcf8563RealTimeClockLibI2cMasterProtolGuid ## PRODUCES > + gPcf8563RealTimeClockLibI2cMasterProtocolGuid ## PRODUCES > > [FixedPcd] >gSynQuacerTokenSpaceGuid.PcdNetsecEepromBase > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol
On Thu, Jan 25, 2018 at 12:27:31PM +, Ard Biesheuvel wrote: > Instead of registering a notification callback on the driver binding > protocol, and attempting to connect our I2C master handle each time > a new driver is registered, switch to the more obvious approach of > registering a notification callback on the I2C master protocol directly. > > The original code was written under the assumption that it would make > the RTC available at an earlier time, but given that all handles that > are created during the execution of a driver entry point are connected > by DXE core right away (i.e., before StartImage() returns), this is not > really necessary, and in fact, may result in the driver already having > been connected by the time we attempt to connect it. > > Note that it is now up to the platform to ensure that ConnectController() > is called for the handle if DXE core does not call it by itself, or does > call it but at a time when no I2C master protocol driver is available > yet. Presumably the platforms in edk2-platforms using this library already follow these constraints? If so: Reviewed-by: Leif Lindholm > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | 31 > > Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | 1 > - > 2 files changed, 13 insertions(+), 19 deletions(-) > > diff --git > a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > index 6bc4aef28849..fb58e1feb424 100644 > --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c > @@ -41,7 +41,7 @@ > #define EPOCH_BASE2000 > > STATIC EFI_HANDLE mI2cMasterHandle; > -STATIC VOID *mDriverEventRegistration; > +STATIC VOID *mI2cMasterEventRegistration; > STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster; > STATIC EFI_EVENT mRtcVirtualAddrChangeEvent; > > @@ -263,12 +263,12 @@ LibSetWakeupTime ( > > STATIC > VOID > -DriverRegistrationEvent ( > +I2cMasterRegistrationEvent ( >IN EFI_EVENT Event, >IN VOID*Context >) > { > - EFI_HANDLEHandle[2]; > + EFI_HANDLEHandle; >UINTN BufferSize; >EFI_STATUSStatus; >EFI_I2C_MASTER_PROTOCOL *I2cMaster; > @@ -280,10 +280,10 @@ DriverRegistrationEvent ( >do { > BufferSize = sizeof (EFI_HANDLE); > Status = gBS->LocateHandle (ByRegisterNotify, > -&gEfiDriverBindingProtocolGuid, > -mDriverEventRegistration, > +&gEfiI2cMasterProtocolGuid, > +mI2cMasterEventRegistration, > &BufferSize, > -Handle); > +&Handle); > if (EFI_ERROR (Status)) { >if (Status != EFI_NOT_FOUND) { > DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n", > @@ -292,12 +292,7 @@ DriverRegistrationEvent ( >break; > } > > -// > -// Check if we can connect our handle to this driver. > -// > -Handle[1] = NULL; > -Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE); > -if (EFI_ERROR (Status)) { > +if (Handle != mI2cMasterHandle) { >continue; > } > > @@ -378,16 +373,16 @@ LibRtcInitialize ( >ASSERT_EFI_ERROR (Status); > >// > - // Register a protocol registration notification callback on the driver > - // binding protocol so we can attempt to connect our I2C master to it > - // as soon as it appears. > + // Register a protocol registration notification callback on the I2C master > + // protocol. This will notify us even if the protocol instance we are > looking > + // for has already been installed. >// >EfiCreateProtocolNotifyEvent ( > -&gEfiDriverBindingProtocolGuid, > +&gEfiI2cMasterProtocolGuid, > TPL_CALLBACK, > -DriverRegistrationEvent, > +I2cMasterRegistrationEvent, > NULL, > -&mDriverEventRegistration); > +&mI2cMasterEventRegistration); > >// >// Register for the virtual address change event > diff --git > a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > index 1a9a6f6c9cf3..e232902c6b5d 100644 > --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf > @@ -40,7 +40,6 @@ [Guids] >gEfiEventVirtualAddressChangeGuid > > [Protocols] > - gEfiDriverBindingPr
Re: [edk2] [PATCH edk2-platforms 4/8] Silicon/SynQuacerI2cDxe: remove spurious format specifier
On Thu, Jan 25, 2018 at 12:27:32PM +, Ard Biesheuvel wrote: > Remove a %r without an associated parameter. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > index c3703dfb6c33..46c512a20151 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > @@ -335,7 +335,7 @@ SynQuacerI2cStartRequest ( > } > > if (MmioRead8 (I2c->MmioBase + F_I2C_REG_BSR) & F_I2C_BSR_LRB) { > - BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received - %r\n", > __FUNCTION__)); > + BOOTTIME_DEBUG ((DEBUG_WARN, "%a: No ack received\n", __FUNCTION__)); >Status = EFI_DEVICE_ERROR; >break; > } > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 5/8] Silicon/SynQuacer: load I2C driver before platform DXE driver
On Thu, Jan 25, 2018 at 12:27:33PM +, Ard Biesheuvel wrote: > To ensure that the I2C master protocol is installed immediately onto > the handles created by PlatformDxe in its entry point, force the > SynQuacerI2cDxe driver to be loaded before PlatformDxe. These handles > are recursively connected by the DXE core as soon as they appear, and > so ensuring that the I2C master protocol driver is available at this > time will ensure that these handles will be connected to it right away. > > This is useful when implementations of architectural protocols such as > RTC or the EFI variable store, which should become available long before > the ordinary dispatch of UEFI driver model drivers is started at the end > of DXE, are based on I2C. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 2 > +- > Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf | 2 > +- > Silicon/Socionext/SynQuacer/SynQuacer.dec | 2 > ++ > 3 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > index 4d6a1d637922..f075957d7456 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > @@ -17,7 +17,7 @@ > [Defines] >INF_VERSION= 0x0001001A >BASE_NAME = PlatformDxe > - FILE_GUID = ac422cc1-d916-489a-b165-536fdfc633c2 > + FILE_GUID = ac422cc1-d916-489a-b165-536fdfc633c2 # > gSynQuacerPlatformDxeFileGuid >MODULE_TYPE= DXE_DRIVER >VERSION_STRING = 1.0 >ENTRY_POINT= PlatformDxeEntryPoint > diff --git > a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf > b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf > index fa715366878c..325816ba0b88 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf > +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.inf > @@ -56,4 +56,4 @@ [FixedPcd] >gSynQuacerTokenSpaceGuid.PcdI2cReferenceClock > > [Depex] > - TRUE > + BEFORE gSynQuacerPlatformDxeFileGuid > diff --git a/Silicon/Socionext/SynQuacer/SynQuacer.dec > b/Silicon/Socionext/SynQuacer/SynQuacer.dec > index a21f12b5bc32..76529e3c2164 100644 > --- a/Silicon/Socionext/SynQuacer/SynQuacer.dec > +++ b/Silicon/Socionext/SynQuacer/SynQuacer.dec > @@ -25,6 +25,8 @@ [Guids] >gSynQuacerNonDiscoverableI2cMasterGuid = { 0x364ee675, 0x9e44, 0x42b7, { > 0xa5, 0xe4, 0x92, 0x84, 0xdb, 0x85, 0xda, 0x09 } } >gSynQuacerNonDiscoverableRuntimeI2cMasterGuid = { 0x5f35aa9b, 0x8c6f, > 0x4828, { 0xbd, 0x44, 0x7c, 0xc0, 0xeb, 0x2d, 0xfe, 0xb9 } } > > + gSynQuacerPlatformDxeFileGuid = { 0xac422cc1, 0xd916, 0x489a, { 0xb1, > 0x65, 0x53, 0x6f, 0xdf, 0xc6, 0x33, 0xc2 } } > + > [Ppis] >gSynQuacerDramInfoPpiGuid = { 0x3e1d7356, 0xdda4, 0x4b1a, { 0x93, 0x46, > 0xbf, 0x89, 0x1c, 0x86, 0x46, 0xcc } } > > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/DeviceTree: align uart DT nodes
On Thu, Jan 25, 2018 at 12:27:34PM +, Ard Biesheuvel wrote: > Align the UART DT nodes: > - use 'uart' not 'fuart' as node name for the second serial port > - create an alias 'serial1' for the second serial port > - use UART clock reference instead of hardcoded frequency > - split 'clocks' property into 1 cell per phandle > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > index 37a3981f0360..7c3518facb98 100644 > --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > @@ -32,6 +32,7 @@ > > aliases { > serial0 = &soc_uart0; > +serial1 = &fuart; > }; > > chosen { > @@ -436,15 +437,16 @@ > compatible = "arm,pl011", "arm,primecell"; > reg = <0x0 0x2a40 0x0 0x1000>; > interrupts = ; > -clocks = <&clk_uart &clk_apb>; > +clocks = <&clk_uart>, <&clk_apb>; > clock-names = "uartclk", "apb_pclk"; > }; > > -fuart: fuart@5104 { > +fuart: uart@5104 { > compatible = "snps,dw-apb-uart"; > reg = <0x0 0x5104 0x0 0x1000>; > interrupts = ; > -clock-frequency = <6250>; > +clocks = <&clk_uart>, <&clk_apb>; > +clock-names = "baudclk", "apb_pclk"; > reg-io-width = <4>; > reg-shift = <2>; > }; > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding
On Thu, Jan 25, 2018 at 12:27:35PM +, Ard Biesheuvel wrote: > The upstream version of the Linux NETSEC driver expects the PHY DT > node to appear under a MDIO subnode, so fix this in the device tree. > Fix the node name as well, this should be 'ethernet' not 'netsec', > and add a clock-names property describing the single clock reference > as 'phy_ref_clk'. > > Also, move the PHY subnode into the per-platform .dts file so we can > set the unit address in the node name. This is necessary because recent > versions of the DT compiler are more finicky about this. Presumably the only kernels this may break are using non-upstream code? If so: Reviewed-by: Leif Lindholm > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts | 7 + > Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 > +--- > Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts | 7 + > 3 files changed, 28 insertions(+), 16 deletions(-) > > diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts > b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts > index d2cd7ef90e6f..488c51a0f793 100644 > --- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts > +++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts > @@ -44,3 +44,10 @@ >"GPIO-K", "GPIO-L", "PEC-PD26", "PEC-PD27", >"PEC-PD28", "PEC-PD29", "PEC-PD30", "PEC-PD31"; > }; > + > +&mdio_netsec { > +phy_netsec: ethernet-phy@7 { > +compatible = "ethernet-phy-ieee802.3-c22"; > +reg = <7>; > +}; > +}; > diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > index 7c3518facb98..6ee7a0b7ccb4 100644 > --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi > @@ -457,25 +457,23 @@ > #clock-cells = <0>; > }; > > -eth0: netsec@522D { > -compatible = "socionext,synquacer-netsec"; > -reg = <0 0x522d 0x0 0x1>, > - <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; > -interrupts = ; > -clocks = <&clk_netsec>; > -phy-mode = "rgmii"; > -max-speed = <1000>; > -max-frame-size = <9000>; > -phy-handle = <ðphy0>; > -dma-coherent; > +ethernet@522d { > +compatible = "socionext,synquacer-netsec"; > +reg = <0 0x522d 0x0 0x1>, > + <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; > +interrupts = ; > +clocks = <&clk_netsec>; > +clock-names = "phy_ref_clk"; > +phy-mode = "rgmii"; > +max-speed = <1000>; > +max-frame-size = <9000>; > +phy-handle = <&phy_netsec>; > +dma-coherent; > > +mdio_netsec: mdio { > #address-cells = <1>; > #size-cells = <0>; > - > -ethphy0: ethernet-phy { > -compatible = "ethernet-phy-ieee802.3-c22"; > -reg = ; > -}; > +}; > }; > > smmu: iommu@582c { > diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts > b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts > index 132fd370a71b..97fddfedcb46 100644 > --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts > +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts > @@ -34,3 +34,10 @@ > &sdhci { > status = "okay"; > }; > + > +&mdio_netsec { > +phy_netsec: ethernet-phy@1 { > +compatible = "ethernet-phy-ieee802.3-c22"; > +reg = <1>; > +}; > +}; > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 7/8] Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding
On 25 January 2018 at 13:00, Leif Lindholm wrote: > On Thu, Jan 25, 2018 at 12:27:35PM +, Ard Biesheuvel wrote: >> The upstream version of the Linux NETSEC driver expects the PHY DT >> node to appear under a MDIO subnode, so fix this in the device tree. >> Fix the node name as well, this should be 'ethernet' not 'netsec', >> and add a clock-names property describing the single clock reference >> as 'phy_ref_clk'. >> >> Also, move the PHY subnode into the per-platform .dts file so we can >> set the unit address in the node name. This is necessary because recent >> versions of the DT compiler are more finicky about this. > > Presumably the only kernels this may break are using non-upstream code? Yes. The upstream version is not quite upstream yet - it is now [finally] queued, for inclusion in v4.16 > If so: > Reviewed-by: Leif Lindholm > Thanks >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel >> --- >> Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts | 7 + >> Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 30 >> +--- >> Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts | 7 + >> 3 files changed, 28 insertions(+), 16 deletions(-) >> >> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts >> b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts >> index d2cd7ef90e6f..488c51a0f793 100644 >> --- a/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts >> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/DeveloperBox.dts >> @@ -44,3 +44,10 @@ >>"GPIO-K", "GPIO-L", "PEC-PD26", >> "PEC-PD27", >>"PEC-PD28", "PEC-PD29", "PEC-PD30", >> "PEC-PD31"; >> }; >> + >> +&mdio_netsec { >> +phy_netsec: ethernet-phy@7 { >> +compatible = "ethernet-phy-ieee802.3-c22"; >> +reg = <7>; >> +}; >> +}; >> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> index 7c3518facb98..6ee7a0b7ccb4 100644 >> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi >> @@ -457,25 +457,23 @@ >> #clock-cells = <0>; >> }; >> >> -eth0: netsec@522D { >> -compatible = "socionext,synquacer-netsec"; >> -reg = <0 0x522d 0x0 0x1>, >> - <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; >> -interrupts = ; >> -clocks = <&clk_netsec>; >> -phy-mode = "rgmii"; >> -max-speed = <1000>; >> -max-frame-size = <9000>; >> -phy-handle = <ðphy0>; >> -dma-coherent; >> +ethernet@522d { >> +compatible = "socionext,synquacer-netsec"; >> +reg = <0 0x522d 0x0 0x1>, >> + <0 FixedPcdGet32 (PcdNetsecEepromBase) 0x0 0x1>; >> +interrupts = ; >> +clocks = <&clk_netsec>; >> +clock-names = "phy_ref_clk"; >> +phy-mode = "rgmii"; >> +max-speed = <1000>; >> +max-frame-size = <9000>; >> +phy-handle = <&phy_netsec>; >> +dma-coherent; >> >> +mdio_netsec: mdio { >> #address-cells = <1>; >> #size-cells = <0>; >> - >> -ethphy0: ethernet-phy { >> -compatible = "ethernet-phy-ieee802.3-c22"; >> -reg = ; >> -}; >> +}; >> }; >> >> smmu: iommu@582c { >> diff --git a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts >> b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts >> index 132fd370a71b..97fddfedcb46 100644 >> --- a/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts >> +++ b/Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts >> @@ -34,3 +34,10 @@ >> &sdhci { >> status = "okay"; >> }; >> + >> +&mdio_netsec { >> +phy_netsec: ethernet-phy@1 { >> +compatible = "ethernet-phy-ieee802.3-c22"; >> +reg = <1>; >> +}; >> +}; >> -- >> 2.11.0 >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 3/8] Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol
On 25 January 2018 at 12:54, Leif Lindholm wrote: > On Thu, Jan 25, 2018 at 12:27:31PM +, Ard Biesheuvel wrote: >> Instead of registering a notification callback on the driver binding >> protocol, and attempting to connect our I2C master handle each time >> a new driver is registered, switch to the more obvious approach of >> registering a notification callback on the I2C master protocol directly. >> >> The original code was written under the assumption that it would make >> the RTC available at an earlier time, but given that all handles that >> are created during the execution of a driver entry point are connected >> by DXE core right away (i.e., before StartImage() returns), this is not >> really necessary, and in fact, may result in the driver already having >> been connected by the time we attempt to connect it. >> >> Note that it is now up to the platform to ensure that ConnectController() >> is called for the handle if DXE core does not call it by itself, or does >> call it but at a time when no I2C master protocol driver is available >> yet. > > Presumably the platforms in edk2-platforms using this library already > follow these constraints? > There aren't any. But I did CC the NXP guys on this patch when I sent it the first time around, to give them the head's up that they probably shouldn't copy the original pattern. > If so: > Reviewed-by: Leif Lindholm > Thanks. >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel >> --- >> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c | >> 31 >> Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf | >> 1 - >> 2 files changed, 13 insertions(+), 19 deletions(-) >> >> diff --git >> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c >> b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c >> index 6bc4aef28849..fb58e1feb424 100644 >> --- a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c >> +++ b/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.c >> @@ -41,7 +41,7 @@ >> #define EPOCH_BASE2000 >> >> STATIC EFI_HANDLE mI2cMasterHandle; >> -STATIC VOID *mDriverEventRegistration; >> +STATIC VOID *mI2cMasterEventRegistration; >> STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster; >> STATIC EFI_EVENT mRtcVirtualAddrChangeEvent; >> >> @@ -263,12 +263,12 @@ LibSetWakeupTime ( >> >> STATIC >> VOID >> -DriverRegistrationEvent ( >> +I2cMasterRegistrationEvent ( >>IN EFI_EVENT Event, >>IN VOID*Context >>) >> { >> - EFI_HANDLEHandle[2]; >> + EFI_HANDLEHandle; >>UINTN BufferSize; >>EFI_STATUSStatus; >>EFI_I2C_MASTER_PROTOCOL *I2cMaster; >> @@ -280,10 +280,10 @@ DriverRegistrationEvent ( >>do { >> BufferSize = sizeof (EFI_HANDLE); >> Status = gBS->LocateHandle (ByRegisterNotify, >> -&gEfiDriverBindingProtocolGuid, >> -mDriverEventRegistration, >> +&gEfiI2cMasterProtocolGuid, >> +mI2cMasterEventRegistration, >> &BufferSize, >> -Handle); >> +&Handle); >> if (EFI_ERROR (Status)) { >>if (Status != EFI_NOT_FOUND) { >> DEBUG ((DEBUG_WARN, "%a: gBS->LocateHandle () returned %r\n", >> @@ -292,12 +292,7 @@ DriverRegistrationEvent ( >>break; >> } >> >> -// >> -// Check if we can connect our handle to this driver. >> -// >> -Handle[1] = NULL; >> -Status = gBS->ConnectController (mI2cMasterHandle, Handle, NULL, FALSE); >> -if (EFI_ERROR (Status)) { >> +if (Handle != mI2cMasterHandle) { >>continue; >> } >> >> @@ -378,16 +373,16 @@ LibRtcInitialize ( >>ASSERT_EFI_ERROR (Status); >> >>// >> - // Register a protocol registration notification callback on the driver >> - // binding protocol so we can attempt to connect our I2C master to it >> - // as soon as it appears. >> + // Register a protocol registration notification callback on the I2C >> master >> + // protocol. This will notify us even if the protocol instance we are >> looking >> + // for has already been installed. >>// >>EfiCreateProtocolNotifyEvent ( >> -&gEfiDriverBindingProtocolGuid, >> +&gEfiI2cMasterProtocolGuid, >> TPL_CALLBACK, >> -DriverRegistrationEvent, >> +I2cMasterRegistrationEvent, >> NULL, >> -&mDriverEventRegistration); >> +&mI2cMasterEventRegistration); >> >>// >>// Register for the virtual address change event >> diff --git >> a/Silicon/NXP/Library/Pcf8563RealTimeClockLib/Pcf8563RealTimeClockLib.inf >> b/Silicon/NXP/Library/Pcf8563RealT
Re: [edk2] [PATCH 00/15] BaseTools: One step toward python3
Hi Gary, Thanks for your patches. I am still in evaluating these changes and do some verification for it. I still need some more days to give you comment. Thanks. Best Regards, Zhu Yonghong -Original Message- From: Gary Lin [mailto:g...@suse.com] Sent: Friday, January 19, 2018 12:43 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong ; Gao, Liming Subject: [PATCH 00/15] BaseTools: One step toward python3 Since python2 will be EOF in 2020, we start to evaluate the impact of the python2 removal. As expected, OMVF building failed the test. It's actually a task noted in the wiki page: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-BaseTools-Python3-Support Maybe it's time to convert the python scripts gradully. This patchset doesn't make the python scripts in BaseTools compatible with python3 immediately. It aims to do the trivial and safe conversion and replacement to make some statements compatible with both python2 and python3, so we can deal with the difficult cases later. With the help of "futurize" from python-future, it's easier to refactor the statements. This patchset is basically equivalent to "futurize -1" plus "StringIO.StringIO => io.BytesIO" and minus "fix_absolute_import". The reason to skip "fix_absolute_import" is that python2 failed to find some modules after converting to absolute import, and it might take time to figure out a proper fix. For the "io.BytesIO" change, it MIGHT introduce slow down to the build time since io.BytesIO is slower than StringIO.StringIO in python2(*). For a quick test, I built OVMF with the following command based on 8ab0bd2397c9d3922e0c7dbb1aa6f7e08799079f: $ rm -rf Build && make -C BaseTools/ clean $ time ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE \ -D NETWORK_IP6_ENABLE \ -D HTTP_BOOT_ENABLE \ -D TLS_ENABLE Before io.BytesIO: Build total time: 00:03:56 real4m22.991s user3m55.874s sys 0m27.250s After io.BytesIO: Build total time: 00:03:57 real4m23.953s user3m57.526s sys 0m27.192s The difference is only 1 second, and I would say the impact is subtle. The next step will be fixing relative import and maybe applying more futurize fixes. We won't get there soon but at least we are moving... (*) https://stackoverflow.com/questions/37462075/confusing-about-stringio-cstringio-and-byteio Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Yonghong Zhu Cc: Liming Gao Signed-off-by: Gary Lin Gary Lin (15): BaseTools: Refactor python except statements BaseTools: Refactor python print statements BaseTools: Remove the old python "not-equal" BaseTools: Use the python3-range functions BaseTools: Remove tuple parameter in python scripts BaseTools: Remove the deprecated hash_key() BaseTools: Import reduce() from functools BaseTools: Replace StandardError with Expression BaseTools: Remove types.TypeType BaseTools: Refactor python raise statement BaseTools: Adjust the spaces around commas and colons BaseTools: Migrate to the new octal literal BaseTools: Unify long int and int in python scripts BaseTools: Adjust old python2 idioms BaseTools: Replace StringIO.StringIO with io.BytesIO BaseTools/Bin/CYGWIN_NT-5.1-i686/armcc_wrapper.py | 5 +- BaseTools/Scripts/BinToPcd.py | 46 +++--- BaseTools/Scripts/ConvertMasmToNasm.py | 1 + BaseTools/Scripts/ConvertUni.py| 5 - BaseTools/Scripts/MemoryProfileSymbolGen.py| 22 +-- BaseTools/Scripts/PatchCheck.py| 7 +- BaseTools/Scripts/RunMakefile.py | 2 +- BaseTools/Scripts/SmiHandlerProfileSymbolGen.py| 20 +-- BaseTools/Scripts/UpdateBuildVersions.py | 18 +- BaseTools/Source/Python/AutoGen/AutoGen.py | 91 +- BaseTools/Source/Python/AutoGen/BuildEngine.py | 38 +++-- BaseTools/Source/Python/AutoGen/GenC.py| 5 +- BaseTools/Source/Python/AutoGen/GenDepex.py| 8 +- BaseTools/Source/Python/AutoGen/GenMake.py | 8 +- BaseTools/Source/Python/AutoGen/GenPcdDb.py| 142 BaseTools/Source/Python/AutoGen/GenVar.py | 165 +-- BaseTools/Source/Python/AutoGen/IdfClassObject.py | 1 - BaseTools/Source/Python/AutoGen/InfSectionParser.py| 1 + BaseTools/Source/Python/AutoGen/StrGather.py | 5 +- BaseTools/Source/Python/AutoGen/UniClassObject.py | 18 +- BaseTools/Source/Python/AutoGen/ValidCheckingInfoObjec
Re: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to 1.02
Reviewed-by: Jaben Carsey > -Original Message- > From: Gao, Liming > Sent: Thursday, January 25, 2018 1:54 AM > To: Ni, Ruiyu ; edk2-devel@lists.01.org > Cc: Carsey, Jaben > Subject: RE: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 > to 1.02 > Importance: High > > Reviewed-by: Liming Gao > > >-Original Message- > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >Ruiyu Ni > >Sent: Wednesday, January 24, 2018 1:56 PM > >To: edk2-devel@lists.01.org > >Cc: Carsey, Jaben > >Subject: [edk2] [PATCH v2] ShellPkg: Update package version from 1.01 to > >1.02 > > > >Contributed-under: TianoCore Contribution Agreement 1.1 > >Signed-off-by: Ruiyu Ni > >Cc: Jaben Carsey > >--- > > ShellPkg/ShellPkg.dec | 4 ++-- > > ShellPkg/ShellPkg.dsc | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > >diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec > >index 48d50b87b3..0c4f74ff41 100644 > >--- a/ShellPkg/ShellPkg.dec > >+++ b/ShellPkg/ShellPkg.dec > >@@ -2,7 +2,7 @@ > > # This Package provides all definitions for EFI and UEFI Shell > > # > > # (C) Copyright 2013-2014 Hewlett-Packard Development Company, > L.P. > >-# Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved. > >+# Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials are licensed and made > >available under > > # the terms and conditions of the BSD License which accompanies this > >distribution. > >@@ -18,7 +18,7 @@ [Defines] > > DEC_SPECIFICATION = 0x00010005 > > PACKAGE_NAME = ShellPkg > > PACKAGE_GUID = C1014BB7-4092-43D4-984F-0738EB424DBF > >- PACKAGE_VERSION= 1.01 > >+ PACKAGE_VERSION= 1.02 > > > > [Includes] > > Include > >diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc > >index 86382139a5..29f5376412 100644 > >--- a/ShellPkg/ShellPkg.dsc > >+++ b/ShellPkg/ShellPkg.dsc > >@@ -1,7 +1,7 @@ > > ## @file > > # Shell Package > > # > >-# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved. > >+# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > > # > > #This program and the accompanying materials > > #are licensed and made available under the terms and conditions of the > >BSD License > >@@ -16,7 +16,7 @@ > > [Defines] > > PLATFORM_NAME = Shell > > PLATFORM_GUID = E1DC9BF8-7013-4c99-9437-795DAA45F3BD > >- PLATFORM_VERSION = 1.01 > >+ PLATFORM_VERSION = 1.02 > > DSC_SPECIFICATION = 0x00010006 > > OUTPUT_DIRECTORY = Build/Shell > > SUPPORTED_ARCHITECTURES= IA32|IPF|X64|EBC|ARM|AARCH64 > >-- > >2.15.1.windows.2 > > > >___ > >edk2-devel mailing list > >edk2-devel@lists.01.org > >https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 01/14] Hisilicon/D05: Add PPTT support
Hi, On 01/24/2018 11:56 PM, Huangming (Mark) wrote: On 2018/1/24 5:29, Jeremy Linton wrote: Hi, On 01/18/2018 09:01 AM, Ming Huang wrote: From: Jason Zhang Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jason Zhang Signed-off-by: Ming Huang Signed-off-by: Heyi Guo --- Platform/Hisilicon/D05/D05.dsc | 1 + Platform/Hisilicon/D05/D05.fdf | 1 + Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h | 27 ++ Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc | 31 +- Silicon/Hisilicon/Hi1616/Pptt/Pptt.c| 447 Silicon/Hisilicon/Hi1616/Pptt/Pptt.h| 142 +++ Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf | 55 +++ 7 files changed, 677 insertions(+), 27 deletions(-) diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc index 77a89fd..710339c 100644 --- a/Platform/Hisilicon/D05/D05.dsc +++ b/Platform/Hisilicon/D05/D05.dsc @@ -506,6 +506,7 @@ MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf Silicon/Hisilicon/Hi1616/D05AcpiTables/AcpiTablesHi1616.inf + Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf # diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf index 78ab0c8..97de4d2 100644 --- a/Platform/Hisilicon/D05/D05.fdf +++ b/Platform/Hisilicon/D05/D05.fdf @@ -241,6 +241,7 @@ READ_LOCK_STATUS = TRUE INF Silicon/Hisilicon/Drivers/HisiAcpiPlatformDxe/AcpiPlatformDxe.inf INF RuleOverride=ACPITABLE Silicon/Hisilicon/Hi1616/D05AcpiTables/AcpiTablesHi1616.inf + INF Silicon/Hisilicon/Hi1616/Pptt/Pptt.inf INF Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf # diff --git a/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h b/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h index 808219a..f1927e8 100644 --- a/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h +++ b/Silicon/Hisilicon/Hi1616/D05AcpiTables/Hi1616Platform.h @@ -19,6 +19,7 @@ #ifndef _HI1610_PLATFORM_H_ #define _HI1610_PLATFORM_H_ +#include // // ACPI table information used to initialize tables. @@ -44,5 +45,31 @@ } #define HI1616_WATCHDOG_COUNT 2 +#define HI1616_GIC_STRUCTURE_COUNT 64 + +#define HI1616_MPID_TA_BASE 0x1 +#define HI1616_MPID_TB_BASE 0x3 +#define HI1616_MPID_TA_2_BASE 0x5 +#define HI1616_MPID_TB_2_BASE 0x7 + +// Differs from Juno, we have another affinity level beyond cluster and core +#define PLATFORM_GET_MPID_TA(ClusterId, CoreId) (HI1616_MPID_TA_BASE | ((ClusterId) << 8) | (CoreId)) +#define PLATFORM_GET_MPID_TB(ClusterId, CoreId) (HI1616_MPID_TB_BASE | ((ClusterId) << 8) | (CoreId)) +#define PLATFORM_GET_MPID_TA_2(ClusterId, CoreId) (HI1616_MPID_TA_2_BASE | ((ClusterId) << 8) | (CoreId)) +#define PLATFORM_GET_MPID_TB_2(ClusterId, CoreId) (HI1616_MPID_TB_2_BASE | ((ClusterId) << 8) | (CoreId)) + +// +// Multiple APIC Description Table +// +#pragma pack (1) + +typedef struct { + EFI_ACPI_6_1_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER Header; + EFI_ACPI_6_1_GIC_STRUCTURE GicInterfaces[HI1616_GIC_STRUCTURE_COUNT]; + EFI_ACPI_6_1_GIC_DISTRIBUTOR_STRUCTUREGicDistributor; + EFI_ACPI_6_1_GIC_ITS_STRUCTUREGicITS[8]; +} EFI_ACPI_6_1_MULTIPLE_APIC_DESCRIPTION_TABLE; + +#pragma pack () #endif diff --git a/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc b/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc index 169ee72..33dca03 100644 --- a/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc +++ b/Silicon/Hisilicon/Hi1616/D05AcpiTables/MadtHi1616.aslc @@ -1,9 +1,9 @@ /** @file * Multiple APIC Description Table (MADT) * -* Copyright (c) 2012 - 2014, ARM Limited. All rights reserved. -* Copyright (c) 2015 - 2016, Hisilicon Limited. All rights reserved. -* Copyright (c) 2015 - 2016, Linaro Limited. All rights reserved. +* Copyright (c) 2012 - 2018, ARM Limited. All rights reserved. +* Copyright (c) 2015 - 2018, Hisilicon Limited. All rights reserved. +* Copyright (c) 2015 - 2018, Linaro Limited. All rights reserved. * * This program and the accompanying materials * @@ -19,34 +19,11 @@ * **/ - -#include +#include "Hi1616Platform.h" #include #include #include #include -#include "Hi1616Platform.h" - -// Differs from Juno, we have another affinity level beyond cluster and core -// 0x2 is only for socket 0 -#define PLATFORM_GET_MPID_TA(ClusterId, CoreId) (0x1 | ((ClusterId) << 8) | (CoreId)) -#define PLATFORM_GET_MPID_TB(ClusterId, CoreId) (0x3 | ((ClusterId) << 8) | (CoreId)) -#define PLATFORM_GET_MPID_TA_2(ClusterId, CoreId) (0x5 | ((ClusterId) << 8) | (CoreId)) -#define PLATFORM_GET_MPID_TB_2(ClusterId, CoreId) (0x7 | ((ClusterId) << 8) | (CoreId)) - -//
[edk2] [PATCH edk2-platforms v2] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed
Add menu options to the SynQuacer Platform menu screen to limit the maximum PCIe link speed for each slot individually. This may be useful to work around potential PCIe issues. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- v2: Make the speed limit per-slot instead of per-RC. That does make this implementation more specific to DeveloperBox than it was before, but given the special knowledge about the on-board ASM1184e switch and the need for enabling spread-spectrum on the ASM1061, we're already past the point where PlatformDxe is a generic SynQuacer driver, and we may need to move it into Platform/Socionext (and clone it for each platform) in the future. Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 + Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 2 + Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c | 24 - Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 107 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h | 13 +++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 11 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni | 29 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 69 + Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h | 23 + Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h | 5 + Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h | 29 ++ Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf | 2 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c | 35 ++- Silicon/Socionext/SynQuacer/SynQuacer.dec | 5 + 14 files changed, 349 insertions(+), 7 deletions(-) diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc index 86685d1dec3b..2d46b4515749 100644 --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc index b4b9239143bc..263b6454ff72 100644 --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c index 9af3dd942cdd..4e1b4a6f9080 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort ( EFI_STATUSStatus; PCIE_CAP Cap; PCI_REG_PCIE_LINK_CONTROL LinkControl; + UINTN SegmentNumber; + UINTN BusNumber; + UINTN DeviceNumber; + UINTN FunctionNumber; + UINTN Location; // // The upstream and downstream ports share the same PID/VID, so check @@ -64,8 +69,23 @@ RetrainAsm1184eDownstreamPort ( return; } - DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream PCIe port\n", -__FUNCTION__)); + Status = PciIo->GetLocation (PciIo, &SegmentNumber, &BusNumber, &DeviceNumber, +&FunctionNumber); + ASSERT_EFI_ERROR (Status); + + Location = SYNQUACER_PCI_LOCATION (SegmentNumber, BusNumber, DeviceNumber); + if ((Location == SYNQUACER_
Re: [edk2] [PATCH edk2-platforms v2] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed
On Thu, Jan 25, 2018 at 03:31:19PM +, Ard Biesheuvel wrote: > Add menu options to the SynQuacer Platform menu screen to limit the > maximum PCIe link speed for each slot individually. This may be useful > to work around potential PCIe issues. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > v2: > Make the speed limit per-slot instead of per-RC. That does make this > implementation more specific to DeveloperBox than it was before, but > given the special knowledge about the on-board ASM1184e switch and the > need for enabling spread-spectrum on the ASM1061, we're already past the > point where PlatformDxe is a generic SynQuacer driver, and we may need to > move it into Platform/Socionext (and clone it for each platform) in the > future. > > Platform/Socionext/DeveloperBox/DeveloperBox.dsc > | 2 + > Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > | 2 + > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > | 24 - > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > | 107 > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h > | 13 +++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > | 11 ++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni > | 29 ++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > | 69 + > Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h > | 23 + > Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h > | 5 + > Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h > | 29 ++ > > Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf > | 2 + > > Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c > | 35 ++- > Silicon/Socionext/SynQuacer/SynQuacer.dec > | 5 + > 14 files changed, 349 insertions(+), 7 deletions(-) > > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > index 86685d1dec3b..2d46b4515749 100644 > --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT] > [PcdsDynamicHii] > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 > > + > gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS > + > [PcdsDynamicDefault] >gArmTokenSpaceGuid.PcdSystemMemoryBase|0x >gArmTokenSpaceGuid.PcdSystemMemorySize|0x > diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > index b4b9239143bc..263b6454ff72 100644 > --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT] > [PcdsDynamicHii] > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 > > + > gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS > + > [PcdsDynamicDefault] >gArmTokenSpaceGuid.PcdSystemMemoryBase|0x >gArmTokenSpaceGuid.PcdSystemMemorySize|0x > diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > index 9af3dd942cdd..4e1b4a6f9080 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort ( >EFI_STATUSStatus; >PCIE_CAP Cap; >PCI_REG_PCIE_LINK_CONTROL LinkControl; > + UINTN SegmentNumber; > + UINTN BusNumber; > + UINTN DeviceNumber; > + UINTN FunctionNumber; > + UINTN Location; > >// >// The upstream and downstream ports share the same PID/VID, so check > @@ -64,8 +69,23 @@ RetrainAsm1184eDownstreamPort ( > return; >} > > - DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream PCIe port\n", > -__FUNCTIO
[edk2] [PATCH edk2-platforms v3] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed
Add menu options to the SynQuacer Platform menu screen to limit the maximum PCIe link speed for each slot individually. This may be useful to work around potential PCIe issues. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- v3: deobfuscate the slot speed limit check, using a switch rather than a convoluted if(), and a comment that describes what goes on v2: Make the speed limit per-slot instead of per-RC. That does make this implementation more specific to DeveloperBox than it was before, but given the special knowledge about the on-board ASM1184e switch and the need for enabling spread-spectrum on the ASM1061, we're already past the point where PlatformDxe is a generic SynQuacer driver, and we may need to move it into Platform/Socionext (and clone it for each platform) in the future. Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 + Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 2 + Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c | 35 ++- Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 107 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h | 13 +++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 11 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni | 29 ++ Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 69 + Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h | 23 + Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h | 5 + Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h | 29 ++ Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf | 2 + Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c | 40 +++- Silicon/Socionext/SynQuacer/SynQuacer.dec | 5 + 14 files changed, 365 insertions(+), 7 deletions(-) diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc index 86685d1dec3b..2d46b4515749 100644 --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc index b4b9239143bc..263b6454ff72 100644 --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT] [PcdsDynamicHii] gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 + gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS + [PcdsDynamicDefault] gArmTokenSpaceGuid.PcdSystemMemoryBase|0x gArmTokenSpaceGuid.PcdSystemMemorySize|0x diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c index 9af3dd942cdd..7c69a8051a56 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort ( EFI_STATUSStatus; PCIE_CAP Cap; PCI_REG_PCIE_LINK_CONTROL LinkControl; + UINTN SegmentNumber; + UINTN BusNumber; + UINTN DeviceNumber; + UINTN FunctionNumber; + UINT8 MaxSpeed; // // The upstream and downstream ports share the same PID/VID, so check @@ -64,8 +69,34 @@ RetrainAsm1184eDownstreamPort ( return; } - DEBUG ((DEBUG_INFO, "%a: retraining ASM118x downstream PCIe port\n", -__FUNCTION__)); + Status = PciIo->GetLocation (PciIo, &SegmentNumber, &BusNumber, &DeviceNumber, +&FunctionNumber); + AS
Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.
Marvin, Thanks for your comments. As per PI v1.6 specification, EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM Traditional Mode.) This is traditional MM mode, which ARM is not supporting at this point. We are more interested in MM_CORE_STANDALONE mode. However, I have no issues in adding this in the patch, but would prefer if this is added when MM traditional mode is supported in ARM. Further, w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't want to break backwards compatibility with existing SMM traditional mode implementations. I will be happy to let folks who have migrated to _MM_ definitions from _SMM_ definitions to send the patch across. Thanks, Supreeth -Original Message- From: Marvin H?user [mailto:marvin.haeu...@outlook.com] Sent: Tuesday, January 23, 2018 6:34 PM To: edk2-devel@lists.01.org Cc: Supreeth Venkatesh ; michael.d.kin...@intel.com; liming@intel.com Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex. Good day, I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE" (0x0C). Furthermore, may I suggest changing the *_SMM_* definitions to be defined via the *_MM_* definitions? Best regards, Marvin. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Supreeth Venkatesh > Sent: Tuesday, January 23, 2018 9:03 PM > To: edk2-devel@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV > file type and depex. > > As per PI specification v1.6, > The following new file types are added: > EFI_FV_FILETYPE_MM_STANDALONE > EFI_FV_FILETYPE_MM_CORE_STANDALONE > > The following new section type is added: > EFI_SECTION_MM_DEPEX > > This patch adds the management mode FV file type and depex. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Achin Gupta > Signed-off-by: Supreeth Venkatesh > Reviewed-by: Jiewen Yao > --- > MdePkg/Include/Pi/PiFirmwareFile.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h > b/MdePkg/Include/Pi/PiFirmwareFile.h > index b982c9eda3..6086d1bb2f 100644 > --- a/MdePkg/Include/Pi/PiFirmwareFile.h > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE; #define > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 > #define EFI_FV_FILETYPE_APPLICATION 0x09 > #define EFI_FV_FILETYPE_SMM 0x0A > +#define EFI_FV_FILETYPE_MM0x0A > #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B > #define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C > +#define EFI_FV_FILETYPE_COMBINED_MM_DXE 0x0C > #define EFI_FV_FILETYPE_SMM_CORE 0x0D > +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E > #define EFI_FV_FILETYPE_OEM_MIN 0xc0 > #define EFI_FV_FILETYPE_OEM_MAX 0xdf > #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0 > @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE; > #define EFI_SECTION_RAW 0x19 > #define EFI_SECTION_PEI_DEPEX 0x1B > #define EFI_SECTION_SMM_DEPEX 0x1C > +#define EFI_SECTION_MM_DEPEX 0x1C > > /// > /// Common section header. > -- > 2.14.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.
Supreeth -- Doesn't Appendix A of the PI 1.6 define this as: #define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM #define EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE Thanks, Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Supreeth Venkatesh Sent: Thursday, January 25, 2018 9:45 AM To: Marvin H?user ; edk2-devel@lists.01.org Cc: michael.d.kin...@intel.com; liming@intel.com Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex. Marvin, Thanks for your comments. As per PI v1.6 specification, EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM Traditional Mode.) This is traditional MM mode, which ARM is not supporting at this point. We are more interested in MM_CORE_STANDALONE mode. However, I have no issues in adding this in the patch, but would prefer if this is added when MM traditional mode is supported in ARM. Further, w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't want to break backwards compatibility with existing SMM traditional mode implementations. I will be happy to let folks who have migrated to _MM_ definitions from _SMM_ definitions to send the patch across. Thanks, Supreeth -Original Message- From: Marvin H?user [mailto:marvin.haeu...@outlook.com] Sent: Tuesday, January 23, 2018 6:34 PM To: edk2-devel@lists.01.org Cc: Supreeth Venkatesh ; michael.d.kin...@intel.com; liming@intel.com Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex. Good day, I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE" (0x0C). Furthermore, may I suggest changing the *_SMM_* definitions to be defined via the *_MM_* definitions? Best regards, Marvin. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Supreeth Venkatesh > Sent: Tuesday, January 23, 2018 9:03 PM > To: edk2-devel@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV > file type and depex. > > As per PI specification v1.6, > The following new file types are added: > EFI_FV_FILETYPE_MM_STANDALONE > EFI_FV_FILETYPE_MM_CORE_STANDALONE > > The following new section type is added: > EFI_SECTION_MM_DEPEX > > This patch adds the management mode FV file type and depex. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Achin Gupta > Signed-off-by: Supreeth Venkatesh > Reviewed-by: Jiewen Yao > --- > MdePkg/Include/Pi/PiFirmwareFile.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h > b/MdePkg/Include/Pi/PiFirmwareFile.h > index b982c9eda3..6086d1bb2f 100644 > --- a/MdePkg/Include/Pi/PiFirmwareFile.h > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE; #define > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 > #define EFI_FV_FILETYPE_APPLICATION 0x09 > #define EFI_FV_FILETYPE_SMM 0x0A > +#define EFI_FV_FILETYPE_MM0x0A > #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B > #define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C > +#define EFI_FV_FILETYPE_COMBINED_MM_DXE 0x0C > #define EFI_FV_FILETYPE_SMM_CORE 0x0D > +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E > #define EFI_FV_FILETYPE_OEM_MIN 0xc0 > #define EFI_FV_FILETYPE_OEM_MAX 0xdf > #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0 > @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE; > #define EFI_SECTION_RAW 0x19 > #define EFI_SECTION_PEI_DEPEX 0x1B > #define EFI_SECTION_SMM_DEPEX 0x1C > +#define EFI_SECTION_MM_DEPEX 0x1C > > /// > /// Common section header. > -- > 2.14.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.
Hey Tim and Supreeth, Sorry, 0x0C was a typo, 0x0D is the correct one. The values of the SMM and MM constants are identical, this is just a naming update plus the introduction of the new value, MM Standalone Core, so backwards-compatibility is given. Regarding the traditional MM Core, I just assumed it was an oversight as MdePkg is generic. If it wasn't, sorry. Thanks, Marvin > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Thursday, January 25, 2018 6:53 PM > To: 'Supreeth Venkatesh' ; 'Marvin H?user' > ; edk2-devel@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV file type and depex. > > Supreeth -- > > Doesn't Appendix A of the PI 1.6 define this as: > > #define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM #define > EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE > > Thanks, > > Tim > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Supreeth Venkatesh > Sent: Thursday, January 25, 2018 9:45 AM > To: Marvin H?user ; edk2- > de...@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management > mode FV file type and depex. > > Marvin, > > Thanks for your comments. > As per PI v1.6 specification, > EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support > MM Traditional Mode.) > > This is traditional MM mode, which ARM is not supporting at this point. We > are more interested in MM_CORE_STANDALONE mode. > However, I have no issues in adding this in the patch, but would prefer if > this > is added when MM traditional mode is supported in ARM. > > Further, > w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't > want to break backwards compatibility with existing SMM traditional mode > implementations. > I will be happy to let folks who have migrated to _MM_ definitions from > _SMM_ definitions to send the patch across. > > Thanks, > Supreeth > > -Original Message- > From: Marvin H?user [mailto:marvin.haeu...@outlook.com] > Sent: Tuesday, January 23, 2018 6:34 PM > To: edk2-devel@lists.01.org > Cc: Supreeth Venkatesh ; > michael.d.kin...@intel.com; liming@intel.com > Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV file type and depex. > > Good day, > > I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE" > (0x0C). > Furthermore, may I suggest changing the *_SMM_* definitions to be > defined via the *_MM_* definitions? > > Best regards, > Marvin. > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Supreeth Venkatesh > > Sent: Tuesday, January 23, 2018 9:03 PM > > To: edk2-devel@lists.01.org > > Cc: michael.d.kin...@intel.com; liming@intel.com > > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV > > file type and depex. > > > > As per PI specification v1.6, > > The following new file types are added: > > EFI_FV_FILETYPE_MM_STANDALONE > > EFI_FV_FILETYPE_MM_CORE_STANDALONE > > > > The following new section type is added: > > EFI_SECTION_MM_DEPEX > > > > This patch adds the management mode FV file type and depex. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Achin Gupta > > Signed-off-by: Supreeth Venkatesh > > Reviewed-by: Jiewen Yao > > --- > > MdePkg/Include/Pi/PiFirmwareFile.h | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h > > b/MdePkg/Include/Pi/PiFirmwareFile.h > > index b982c9eda3..6086d1bb2f 100644 > > --- a/MdePkg/Include/Pi/PiFirmwareFile.h > > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h > > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE; #define > > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 > > #define EFI_FV_FILETYPE_APPLICATION 0x09 > > #define EFI_FV_FILETYPE_SMM 0x0A > > +#define EFI_FV_FILETYPE_MM0x0A > > #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B > > #define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C > > +#define EFI_FV_FILETYPE_COMBINED_MM_DXE 0x0C > > #define EFI_FV_FILETYPE_SMM_CORE 0x0D > > +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E > > #define EFI_FV_FILETYPE_OEM_MIN 0xc0 > > #define EFI_FV_FILETYPE_OEM_MAX 0xdf > > #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0 > > @@ -218,6 +221,7 @@ typedef UINT8 EFI_SECTION_TYPE; > > #define EFI_SECTION_RAW 0x19 > > #define EFI_SECTION_PEI_DEPEX 0x1B > > #define EFI_SECTION_SMM_DEPEX 0x1C > > +#define EFI_SECTION_MM_DEPEX 0x1C > > > > /// > > /// Common section header. > > -- > > 2.14.1 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listi
Re: [edk2] [PATCH edk2-platforms v3] Silicon/Socionext/SynQuacer: implement menu option to set max PCIe speed
On Thu, Jan 25, 2018 at 05:13:17PM +, Ard Biesheuvel wrote: > Add menu options to the SynQuacer Platform menu screen to limit the > maximum PCIe link speed for each slot individually. This may be useful > to work around potential PCIe issues. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > v3: > deobfuscate the slot speed limit check, using a switch rather than a > convoluted if(), and a comment that describes what goes on Thanks for this. Reviewed-by: Leif Lindholm > v2: > Make the speed limit per-slot instead of per-RC. That does make this > implementation more specific to DeveloperBox than it was before, but > given the special knowledge about the on-board ASM1184e switch and the > need for enabling spread-spectrum on the ASM1061, we're already past the > point where PlatformDxe is a generic SynQuacer driver, and we may need to > move it into Platform/Socionext (and clone it for each platform) in the > future. > > Platform/Socionext/DeveloperBox/DeveloperBox.dsc > | 2 + > Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > | 2 + > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > | 35 ++- > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c > | 107 > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h > | 13 +++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf > | 11 ++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni > | 29 ++ > Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > | 69 + > Silicon/Socionext/SynQuacer/Include/Guid/SynQuacerPlatformFormSet.h > | 23 + > Silicon/Socionext/SynQuacer/Include/Platform/Pcie.h > | 5 + > Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h > | 29 ++ > > Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLib.inf > | 2 + > > Silicon/Socionext/SynQuacer/Library/SynQuacerPciHostBridgeLib/SynQuacerPciHostBridgeLibConstructor.c > | 40 +++- > Silicon/Socionext/SynQuacer/SynQuacer.dec > | 5 + > 14 files changed, 365 insertions(+), 7 deletions(-) > > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > index 86685d1dec3b..2d46b4515749 100644 > --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc > @@ -405,6 +405,8 @@ [PcdsDynamicExDefault.common.DEFAULT] > [PcdsDynamicHii] > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 > > + > gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS > + > [PcdsDynamicDefault] >gArmTokenSpaceGuid.PcdSystemMemoryBase|0x >gArmTokenSpaceGuid.PcdSystemMemorySize|0x > diff --git a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > index b4b9239143bc..263b6454ff72 100644 > --- a/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > +++ b/Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc > @@ -397,6 +397,8 @@ [PcdsDynamicExDefault.common.DEFAULT] > [PcdsDynamicHii] > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|30 > > + > gSynQuacerTokenSpaceGuid.PcdPlatformSettings|L"SynQuacerPlatformSettings"|gSynQuacerPlatformFormSetGuid|0x0|0x0|NV,BS > + > [PcdsDynamicDefault] >gArmTokenSpaceGuid.PcdSystemMemoryBase|0x >gArmTokenSpaceGuid.PcdSystemMemorySize|0x > diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > index 9af3dd942cdd..7c69a8051a56 100644 > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Pci.c > @@ -45,6 +45,11 @@ RetrainAsm1184eDownstreamPort ( >EFI_STATUSStatus; >PCIE_CAP Cap; >PCI_REG_PCIE_LINK_CONTROL LinkControl; > + UINTN SegmentNumber; > + UINTN BusNumber; > + UINTN DeviceNumber; > + UINTN FunctionNumber; > + UINT8 MaxSpeed; > >// >// The upstream and downstream ports share the same
Re: [edk2] [PATCH edk2-platforms 0/8] Socionext SynQuacer updates
On 25 January 2018 at 12:27, Ard Biesheuvel wrote: > Some stuff I have collected over the past 2 months or so. Note that this > includes the SATA spread spectrum patch I sent out yesterday: I had forgotten > all about this backlog, and I only remembered when attempting to apply it to > the master branch. > > Ard Biesheuvel (8): > Silicon/SynQuacer/PlatformDxe: enable spread spectrum mode for ASM1061 > SATA > Silicon: fix typo in gPcf8563RealTimeClockLibI2cMasterProtocolGuid > Silicon/NXP/Pcf8563RealTimeClockLib: avoid driver binding protocol > Silicon/SynQuacerI2cDxe: remove spurious format specifier > Silicon/SynQuacer: load I2C driver before platform DXE driver > Silicon/SynQuacer/DeviceTree: align uart DT nodes > Silicon/SynQuacer/DeviceTree: update NETSEC DT node to latest binding > Silicon/Socionext/SynQuacer: implement menu option to set max PCIe > speed > All pushed. Thanks. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] DMA Buffer write operation not persisted
Hi everyone. I'm currently work on a task, and I need to write some data at a DMA buffer. At the UEFI Driver Writer's guide, at page 359 there is a sample code of how to do that. Considering that code and adapting to my scenario I got the following function (some debug prints are present for clarification): EFI_STATUS EFIAPI DoBusMasterWrite ( IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo, IN UINT8 *HostAddress, IN UINTN *Length, IN UINT32 Value ) { EFI_STATUS Status; UINTN NumberOfBytes; EFI_PHYSICAL_ADDRESS DeviceAddress; VOID *Mapping; UINT64 ReadValue; // // Call Map() to retrieve the DeviceAddress to use for the bus // master write operation. The Map() function may not support // performing a DMA operation for the entire length, so it may // be broken up into smaller DMA operations. // NumberOfBytes = *Length; Status = PciIo->Map (PciIo, // This EfiPciIoOperationBusMasterCommonBuffer, // Operation (VOID *)HostAddress, // HostAddress &NumberOfBytes, // NumberOfBytes &DeviceAddress, //DeviceAddress &Mapping //Mapping); if (EFI_ERROR (Status)) { return Status; } // // Write the data to the desired address // This write operation also starts the DMA transaction // Status = PciIo->Mem.Write (PciIo, // This EfiPciIoWidthUint32, // Width *HostAddress, 1, // Count &Value // Buffer ); Print(L"NumberOfBytes: %d\r\n", NumberOfBytes); Print(L"address: 0x%x\r\n", HostAddress); Print(L"Value: 0x%x\r\n", Value); Print(L"Status: %r\r\n", Status); if (EFI_ERROR (Status)) { return Status; } // // The operations performed by PollMem() also flush all posted // writes from the PCI bus master and through PCI-to-PCI bridges. // Status = PciIo->PollMem (PciIo, // This EfiPciIoWidthUint32, // Width *HostAddress, // Offset 0x,// Mask Value,// Value EFI_TIMER_PERIOD_SECONDS (1), // Timeout &ReadValue // Result ); Print(L"Status2: %r\r\n", Status); if (EFI_ERROR (Status)) { return Status; } // // Call Flush() to flush all write transactions to system memory // Status = PciIo->Flush (PciIo); Print(L"Status3: %r\r\n", Status); if (EFI_ERROR (Status)) { return Status; } // // Call Unmap() to complete the bus master write operation // Status = PciIo->Unmap (PciIo, Mapping); Print(L"Status4: %r\r\n", Status); if (EFI_ERROR (Status)) { return Status; } return Status; } The output of this function is this: NumberOfBytes: 4 address: 0xCCCAC000 Value: 0xA Status: Success Status2: Success Status3: Success Status4: Success The problem is that when I try to read this memory content using the dmem command at the efiShell the value 0xA cannot be found. Seems something is locking the DMA trasaction. Can someone give me some light? Thanks and Regard Rafael R. Machado ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DMA Buffer write operation not persisted
Rafeal, There are some good summaries in the UEFI Spec that really help. DMA Bus Master Common Buffer Operation • Call AllocateBuffer() to allocate a common buffer. • Call Map() for EfiPciOperationBusMasterCommonBuffer or EfiPciOperationBusMasterCommonBuffer64. • Program the DMA Bus Master with the DeviceAddress returned by Map(). • The common buffer can now be accessed equally by the processor and the DMA bus master. • Call Unmap(). • Call FreeBuffer(). Did you miss the PciIo->AllocateBuffer() call? For x86 it can abstract things like DMA only supported < 4GB. For ARM it may need to change the cacheability of the region etc. Thanks, Andrew Fish > On Jan 25, 2018, at 10:53 AM, Rafael Machado > wrote: > > Hi everyone. > > I'm currently work on a task, and I need to write some data at a DMA buffer. > At the UEFI Driver Writer's guide, at page 359 there is a sample code of > how to do that. > > Considering that code and adapting to my scenario I got the following > function (some debug prints are present for clarification): > > EFI_STATUS > EFIAPI > DoBusMasterWrite ( > IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo, > IN UINT8 *HostAddress, > IN UINTN *Length, > IN UINT32 Value > ) > { > EFI_STATUS Status; > UINTN NumberOfBytes; > EFI_PHYSICAL_ADDRESS DeviceAddress; > VOID *Mapping; > UINT64 ReadValue; > > // > // Call Map() to retrieve the DeviceAddress to use for the bus > // master write operation. The Map() function may not support > // performing a DMA operation for the entire length, so it may > // be broken up into smaller DMA operations. > // > NumberOfBytes = *Length; > Status = PciIo->Map (PciIo, // This > > EfiPciIoOperationBusMasterCommonBuffer, // Operation > (VOID *)HostAddress, // HostAddress > &NumberOfBytes, // NumberOfBytes > &DeviceAddress, //DeviceAddress > &Mapping //Mapping); > > if (EFI_ERROR (Status)) { >return Status; > } > > // > // Write the data to the desired address > // This write operation also starts the DMA transaction > // > Status = PciIo->Mem.Write (PciIo, // This > EfiPciIoWidthUint32, // Width > *HostAddress, > 1, // Count > &Value // Buffer > ); > > Print(L"NumberOfBytes: %d\r\n", NumberOfBytes); > Print(L"address: 0x%x\r\n", HostAddress); > Print(L"Value: 0x%x\r\n", Value); > Print(L"Status: %r\r\n", Status); > > if (EFI_ERROR (Status)) { > return Status; > } > > // > // The operations performed by PollMem() also flush all posted > // writes from the PCI bus master and through PCI-to-PCI bridges. > // > Status = PciIo->PollMem (PciIo, // This > EfiPciIoWidthUint32, // Width > *HostAddress, // Offset > 0x,// Mask > Value,// Value > EFI_TIMER_PERIOD_SECONDS > (1), // Timeout > &ReadValue // Result > ); > Print(L"Status2: %r\r\n", Status); > > if (EFI_ERROR (Status)) { > return Status; > } > > // > // Call Flush() to flush all write transactions to system memory > // > Status = PciIo->Flush (PciIo); > Print(L"Status3: %r\r\n", Status); > > if (EFI_ERROR (Status)) { > return Status; > } > > // > // Call Unmap() to complete the bus master write operation > // > Status = PciIo->Unmap (PciIo, Mapping); > Print(L"Status4: %r\r\n", Status); > > if (EFI_ERROR (Status)) { > return Status; > } > return Status; > } > > The output of this function is this: > NumberOfBytes: 4 > address: 0xCCCAC000 > Value: 0xA > Status: Success > Status2: Success > Status3: Success > Status4: Success > > The problem is that when I try to read this memory content using the dmem > command at the efiShell the value 0xA cannot be found. Seems something > is locking the DMA trasaction. > Can someone give me some light? > > Thanks and Regard > Rafael R. Machado > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DMA Buffer write operation not persisted
Hi Andrew Thanks for the answer. The allocation was done at other part of the code. But yet, I used the PciI->AllocateBuffer() function. One question, about the topics retrieved from the spec. When the spec says "• The common buffer can now be accessed equally by the processor and the DMA bus master." Does this means that I can write some data using a simple pointer, like for example copying some data using MemCopy? Or should I still use the PciIo->Mem.Write...? I'll really this part of the spec carefully. Thanks and Regards Rafael R. Machado Em qui, 25 de jan de 2018 às 17:04, Andrew Fish escreveu: > Rafeal, > > There are some good summaries in the UEFI Spec that really help. > > DMA Bus Master Common Buffer Operation > • Call AllocateBuffer() to allocate a common buffer. > • Call Map() for EfiPciOperationBusMasterCommonBuffer or > EfiPciOperationBusMasterCommonBuffer64. > • Program the DMA Bus Master with the DeviceAddress returned by Map(). > • The common buffer can now be accessed equally by the processor and the > DMA bus master. > • Call Unmap(). > • Call FreeBuffer(). > > Did you miss the PciIo->AllocateBuffer() call? > > For x86 it can abstract things like DMA only supported < 4GB. > For ARM it may need to change the cacheability of the region etc. > > Thanks, > > Andrew Fish > > > On Jan 25, 2018, at 10:53 AM, Rafael Machado < > rafaelrodrigues.mach...@gmail.com> wrote: > > > > Hi everyone. > > > > I'm currently work on a task, and I need to write some data at a DMA > buffer. > > At the UEFI Driver Writer's guide, at page 359 there is a sample code of > > how to do that. > > > > Considering that code and adapting to my scenario I got the following > > function (some debug prints are present for clarification): > > > > EFI_STATUS > > EFIAPI > > DoBusMasterWrite ( > > IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo, > > IN UINT8 *HostAddress, > > IN UINTN *Length, > > IN UINT32 Value > > ) > > { > > EFI_STATUS Status; > > UINTN NumberOfBytes; > > EFI_PHYSICAL_ADDRESS DeviceAddress; > > VOID *Mapping; > > UINT64 ReadValue; > > > > // > > // Call Map() to retrieve the DeviceAddress to use for the bus > > // master write operation. The Map() function may not support > > // performing a DMA operation for the entire length, so it may > > // be broken up into smaller DMA operations. > > // > > NumberOfBytes = *Length; > > Status = PciIo->Map (PciIo, // This > > > > EfiPciIoOperationBusMasterCommonBuffer, // Operation > > (VOID *)HostAddress, // HostAddress > > &NumberOfBytes, // NumberOfBytes > > &DeviceAddress, //DeviceAddress > > &Mapping //Mapping); > > > > if (EFI_ERROR (Status)) { > >return Status; > > } > > > > // > > // Write the data to the desired address > > // This write operation also starts the DMA transaction > > // > > Status = PciIo->Mem.Write (PciIo, // This > > EfiPciIoWidthUint32, // > Width > > *HostAddress, > > 1, // Count > > &Value // Buffer > > ); > > > > Print(L"NumberOfBytes: %d\r\n", NumberOfBytes); > > Print(L"address: 0x%x\r\n", HostAddress); > > Print(L"Value: 0x%x\r\n", Value); > > Print(L"Status: %r\r\n", Status); > > > > if (EFI_ERROR (Status)) { > > return Status; > > } > > > > // > > // The operations performed by PollMem() also flush all posted > > // writes from the PCI bus master and through PCI-to-PCI bridges. > > // > > Status = PciIo->PollMem (PciIo, // This > > EfiPciIoWidthUint32, // > Width > > *HostAddress, // Offset > > 0x,// Mask > > Value,// Value > > EFI_TIMER_PERIOD_SECONDS > > (1), // Timeout > > &ReadValue // Result > > ); > > Print(L"Status2: %r\r\n", Status); > > > > if (EFI_ERROR (Status)) { > > return Status; > > } > > > > // > > // Call Flush() to flush all write transactions to system memory > > // > > Status = PciIo->Flush (PciIo); > > Print(L"Status3: %r\r\n", Status); > > > > if (EFI_ERROR (Status)) { > > return Status; > > } > > > > // > > // Call Unmap() to complete the bus master write operation > > // > > Status = PciIo->Unmap (PciIo, Mapping); > > Print(L"Status4: %r\r\n", Status); > > > > if (EFI_ERROR (Status)) { > > return Status; > > } > > return Status; > > } > > > > The output of this function is this: > > NumberOfBytes: 4 > > address: 0xCCCAC000 > > Value: 0xA > > Status: Succ
Re: [edk2] [PATCH] SecurityPkg/DxePhysicalPresenceLib: Reject illegal PCR bank allocation
Of all the gin joints in all the towns in all the world, Zhang, Chao B had to walk into mine at 20:53 on Wednesday 24 January 2018 and say: > According to TCG PP1.3 spec, error PCR bank allocation input should be > rejected by Physical Presence. Firmware has to ensure that at least one > PCR banks is active. > > Cc: Long Qin > Cc: Yao Jiewen > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Chao Zhang > --- > .../DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.c | 12 > 1 file changed, 12 insertions(+) > > diff --git > a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi > b.c > b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi > b.c index 5bf95a1..830266b 100644 > --- > a/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi > b.c +++ > b/SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLi > b.c @@ -186,6 +186,18 @@ Tcg2ExecutePhysicalPresence ( > case TCG2_PHYSICAL_PRESENCE_SET_PCR_BANKS: >Status = Tpm2GetCapabilitySupportedAndActivePcrs > (&TpmHashAlgorithmBitmap, &ActivePcrBanks); ASSERT_EFI_ERROR (Status); > + > + // > + // PP spec requirements: > + //Firmware should check that all requested (set) hashing > algorithms are supported with respective PCR banks. + //Firmware > has to ensure that at least one PCR banks is active + // If not, an > error is returned and no action is taken > + // > + if (CommandParameter == 0 || (CommandParameter & > (~TpmHashAlgorithmBitmap)) != 0) { +DEBUG((DEBUG_ERROR, "PCR banks > %x to allocate are not supported by TPM. Skip operation\n", > CommandParameter)); +return TCG_PP_OPERATION_RESPONSE_BIOS_FAILURE > + } > + DEBUG((DEBUG_ERROR, "zhangchao TpmHashAlgorithmBitmap %x Was it your intention to have the debug error message string identify you by name? :) -Bill > CommandParameter %x\n", TpmHashAlgorithmBitmap, CommandParameter)); Status > = Tpm2PcrAllocateBanks (PlatformAuth, TpmHashAlgorithmBitmap, > CommandParameter); if (EFI_ERROR (Status)) { > return TCG_PP_OPERATION_RESPONSE_BIOS_FAILURE; -- = -Bill Paul(510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems = "I put a dollar in a change machine. Nothing changed." - George Carlin = ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DMA Buffer write operation not persisted
On January 25, 2018 4:53:06 PM GMT-02:00, Rafael Machado wrote: >Hi everyone. > >I'm currently work on a task, and I need to write some data at a DMA >buffer. >At the UEFI Driver Writer's guide, at page 359 there is a sample code >of >how to do that. > >Considering that code and adapting to my scenario I got the following >function (some debug prints are present for clarification): > >EFI_STATUS >EFIAPI >DoBusMasterWrite ( > IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciIo, > IN UINT8 *HostAddress, > IN UINTN *Length, > IN UINT32 Value >) >{ > EFI_STATUS Status; > UINTN NumberOfBytes; > EFI_PHYSICAL_ADDRESS DeviceAddress; > VOID *Mapping; > UINT64 ReadValue; > > // > // Call Map() to retrieve the DeviceAddress to use for the bus > // master write operation. The Map() function may not support > // performing a DMA operation for the entire length, so it may > // be broken up into smaller DMA operations. > // > NumberOfBytes = *Length; > Status = PciIo->Map (PciIo, // This > > EfiPciIoOperationBusMasterCommonBuffer, // Operation >(VOID *)HostAddress, // HostAddress > &NumberOfBytes, // NumberOfBytes > &DeviceAddress, //DeviceAddress > &Mapping //Mapping); > > if (EFI_ERROR (Status)) { >return Status; > } > > // > // Write the data to the desired address > // This write operation also starts the DMA transaction > // > Status = PciIo->Mem.Write (PciIo, // This > EfiPciIoWidthUint32, // Width > *HostAddress, > 1, // Count > &Value // Buffer > ); I'm not sure, but I think you're passing the wrong value to the 3rd parameter (Address). Shouldn't that be "(UINT64)(UINTN)HostAddress"? Paulo > > Print(L"NumberOfBytes: %d\r\n", NumberOfBytes); > Print(L"address: 0x%x\r\n", HostAddress); > Print(L"Value: 0x%x\r\n", Value); > Print(L"Status: %r\r\n", Status); > > if (EFI_ERROR (Status)) { >return Status; > } > > // > // The operations performed by PollMem() also flush all posted > // writes from the PCI bus master and through PCI-to-PCI bridges. > // > Status = PciIo->PollMem (PciIo, // This > EfiPciIoWidthUint32, // Width > *HostAddress, // Offset > 0x,// Mask > Value,// Value > EFI_TIMER_PERIOD_SECONDS >(1), // Timeout > &ReadValue // Result > ); > Print(L"Status2: %r\r\n", Status); > > if (EFI_ERROR (Status)) { >return Status; > } > > // > // Call Flush() to flush all write transactions to system memory > // > Status = PciIo->Flush (PciIo); > Print(L"Status3: %r\r\n", Status); > > if (EFI_ERROR (Status)) { >return Status; > } > > // > // Call Unmap() to complete the bus master write operation > // > Status = PciIo->Unmap (PciIo, Mapping); > Print(L"Status4: %r\r\n", Status); > > if (EFI_ERROR (Status)) { >return Status; > } > return Status; >} > >The output of this function is this: > NumberOfBytes: 4 > address: 0xCCCAC000 > Value: 0xA > Status: Success > Status2: Success > Status3: Success > Status4: Success > >The problem is that when I try to read this memory content using the >dmem >command at the efiShell the value 0xA cannot be found. Seems >something >is locking the DMA trasaction. >Can someone give me some light? > >Thanks and Regard >Rafael R. Machado >___ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex.
Marvin/Tim, Thanks. Apologies, if I didn't mention that this patch was just addition of new values EFI_FV_FILETYPE_MM_STANDALONE EFI_FV_FILETYPE_MM_CORE_STANDALONE and EFI_SECTION_MM_DEPEX No other changes. In existing code, EFI_FV_FILETYPE_SMM and EFI_FV_FILETYPE_MM are same already. Supreeth -Original Message- From: Marvin H?user [mailto:marvin.haeu...@outlook.com] Sent: Thursday, January 25, 2018 12:32 PM To: edk2-devel@lists.01.org; tim.le...@insyde.com; Supreeth Venkatesh Cc: michael.d.kin...@intel.com; liming@intel.com Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode FV file type and depex. Hey Tim and Supreeth, Sorry, 0x0C was a typo, 0x0D is the correct one. The values of the SMM and MM constants are identical, this is just a naming update plus the introduction of the new value, MM Standalone Core, so backwards-compatibility is given. Regarding the traditional MM Core, I just assumed it was an oversight as MdePkg is generic. If it wasn't, sorry. Thanks, Marvin > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Thursday, January 25, 2018 6:53 PM > To: 'Supreeth Venkatesh' ; 'Marvin H?user' > ; edk2-devel@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV file type and depex. > > Supreeth -- > > Doesn't Appendix A of the PI 1.6 define this as: > > #define EFI_FV_FILETYPE_SMM EFI_FV_FILETYPE_MM #define > EFI_FV_FILETYPE_SMM_CORE EFI_FV_FILETYPE_MM_CORE > > Thanks, > > Tim > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Supreeth Venkatesh > Sent: Thursday, January 25, 2018 9:45 AM > To: Marvin H?user ; edk2- > de...@lists.01.org > Cc: michael.d.kin...@intel.com; liming@intel.com > Subject: Re: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV file type and depex. > > Marvin, > > Thanks for your comments. > As per PI v1.6 specification, > EFI_FV_FILETYPE_MM_CORE value is 0x0D (MM Foundation that support MM > Traditional Mode.) > > This is traditional MM mode, which ARM is not supporting at this > point. We are more interested in MM_CORE_STANDALONE mode. > However, I have no issues in adding this in the patch, but would > prefer if this is added when MM traditional mode is supported in ARM. > > Further, > w.r.t defining *_SMM_* definitions via the *_MM_* definitions. I don't > want to break backwards compatibility with existing SMM traditional > mode implementations. > I will be happy to let folks who have migrated to _MM_ definitions > from _SMM_ definitions to send the patch across. > > Thanks, > Supreeth > > -Original Message- > From: Marvin H?user [mailto:marvin.haeu...@outlook.com] > Sent: Tuesday, January 23, 2018 6:34 PM > To: edk2-devel@lists.01.org > Cc: Supreeth Venkatesh ; > michael.d.kin...@intel.com; liming@intel.com > Subject: RE: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV file type and depex. > > Good day, > > I noticed this patch lacks the definition of "EFI_FV_FILETYPE_MM_CORE" > (0x0C). > Furthermore, may I suggest changing the *_SMM_* definitions to be > defined via the *_MM_* definitions? > > Best regards, > Marvin. > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Supreeth Venkatesh > > Sent: Tuesday, January 23, 2018 9:03 PM > > To: edk2-devel@lists.01.org > > Cc: michael.d.kin...@intel.com; liming@intel.com > > Subject: [edk2] [PATCH v1 1/1] MdePkg/Include: Add management mode > FV > > file type and depex. > > > > As per PI specification v1.6, > > The following new file types are added: > > EFI_FV_FILETYPE_MM_STANDALONE > > EFI_FV_FILETYPE_MM_CORE_STANDALONE > > > > The following new section type is added: > > EFI_SECTION_MM_DEPEX > > > > This patch adds the management mode FV file type and depex. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Achin Gupta > > Signed-off-by: Supreeth Venkatesh > > Reviewed-by: Jiewen Yao > > --- > > MdePkg/Include/Pi/PiFirmwareFile.h | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/MdePkg/Include/Pi/PiFirmwareFile.h > > b/MdePkg/Include/Pi/PiFirmwareFile.h > > index b982c9eda3..6086d1bb2f 100644 > > --- a/MdePkg/Include/Pi/PiFirmwareFile.h > > +++ b/MdePkg/Include/Pi/PiFirmwareFile.h > > @@ -72,9 +72,12 @@ typedef UINT8 EFI_FFS_FILE_STATE; #define > > EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 > > #define EFI_FV_FILETYPE_APPLICATION 0x09 > > #define EFI_FV_FILETYPE_SMM 0x0A > > +#define EFI_FV_FILETYPE_MM0x0A > > #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B > > #define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C > > +#define EFI_FV_FILETYPE_COMBINED_MM_DXE 0x0C > > #define EFI_FV_FILETYPE_SMM_CORE 0x0D > > +#define EFI_FV_FILETYPE_MM_STANDALONE 0x0E > > #define EFI_
[edk2] [Patch 0/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module
https://bugzilla.tianocore.org/show_bug.cgi?id=802 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that produces ESRT entries based only on FMP Protocol instances. Update Quark and Vlv2 platforms to use EsrtFmpDxe. Cc: Sean Brogan Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Michael D Kinney (3): MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module QuarkPlatformPkg: Switch from EsrtDxe to EsrtFmpDxe Vlv2TbltDevicePkg: Switch from EsrtDxe to EsrtFmpDxe MdeModulePkg/MdeModulePkg.dsc | 1 + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 + .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c | 161 +++ MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf | 68 +++ QuarkPlatformPkg/Quark.dsc | 4 +- QuarkPlatformPkg/Quark.fdf | 4 +- Vlv2TbltDevicePkg/PlatformPkg.fdf | 4 +- Vlv2TbltDevicePkg/PlatformPkgGcc.fdf | 4 +- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc| 4 +- Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 4 +- Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 4 +- 11 files changed, 728 insertions(+), 14 deletions(-) create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf -- 2.14.2.windows.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 3/3] Vlv2TbltDevicePkg: Switch from EsrtDxe to EsrtFmpDxe
From: Michael D Kinney https://bugzilla.tianocore.org/show_bug.cgi?id=802 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that produces ESRT entries based only on FMP Protocol instances. Cc: Sean Brogan Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney --- Vlv2TbltDevicePkg/PlatformPkg.fdf | 4 ++-- Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 4 ++-- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 4 ++-- Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 4 ++-- Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Vlv2TbltDevicePkg/PlatformPkg.fdf b/Vlv2TbltDevicePkg/PlatformPkg.fdf index 5ed85f4dee..148553828c 100644 --- a/Vlv2TbltDevicePkg/PlatformPkg.fdf +++ b/Vlv2TbltDevicePkg/PlatformPkg.fdf @@ -1,7 +1,7 @@ #/** @file # FDF file of Platform. # -# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved. +# Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made available under # the terms and conditions of the BSD License that accompanies this distribution. @@ -773,7 +773,7 @@ FILE FREEFORM = 878AC2CC-5343-46F2-B563-51F89DAF56BA { !endif !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE) -INF MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf +INF MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf !endif !if $(CAPSULE_ENABLE) INF SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf diff --git a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf index a02a4f6286..d208871ae6 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf +++ b/Vlv2TbltDevicePkg/PlatformPkgGcc.fdf @@ -1,7 +1,7 @@ #/** @file # FDF file of Platform. # -# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved. +# Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made available under # the terms and conditions of the BSD License that accompanies this distribution. @@ -730,7 +730,7 @@ FILE FREEFORM = 878AC2CC-5343-46F2-B563-51F89DAF56BA { !endif !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE) -INF MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf +INF MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf !endif !if $(CAPSULE_ENABLE) INF SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc index f98263d8a5..7a431130a3 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc @@ -1,7 +1,7 @@ #/** @file # Platform description. # -# Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved. +# Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made available under # the terms and conditions of the BSD License that accompanies this distribution. @@ -1567,7 +1567,7 @@ $(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE) - MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf !endif diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc index c755df2fe2..d27fc49df7 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc @@ -1,7 +1,7 @@ #/** @file # Platform description. # -# Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved. +# Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made available under # the terms and conditions of the BSD License that accompanies this distribution. @@ -1555,7 +1555,7 @@ $(PLATFORM_BINARY_PACKAGE)/$(DXE_ARCHITECTURE)$(TARGET)/IA32/fTPMInitPeim.inf Vlv2TbltDevicePkg/Application/FirmwareUpdate/FirmwareUpdate.inf !if $(CAPSULE_ENABLE) || $(MICOCODE_CAPSULE_ENABLE) - MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf !endif diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc index dda8216e6a..ca68928b23 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc @@ -1,7 +1,7 @@ #/** @file # Platform description. # -# Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved. +# Copyright (c) 2012 - 2018, Intel Corpor
[edk2] [Patch 2/3] QuarkPlatformPkg: Switch from EsrtDxe to EsrtFmpDxe
From: Michael D Kinney https://bugzilla.tianocore.org/show_bug.cgi?id=802 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that produces ESRT entries based only on FMP Protocol instances. Cc: Sean Brogan Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney --- QuarkPlatformPkg/Quark.dsc | 4 ++-- QuarkPlatformPkg/Quark.fdf | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/QuarkPlatformPkg/Quark.dsc b/QuarkPlatformPkg/Quark.dsc index 5624451e12..2176c8c9db 100644 --- a/QuarkPlatformPkg/Quark.dsc +++ b/QuarkPlatformPkg/Quark.dsc @@ -2,7 +2,7 @@ # Clanton Peak CRB platform with 32-bit DXE for 4MB/8MB flash devices. # # This package provides Clanton Peak CRB platform specific modules. -# Copyright (c) 2013 - 2017 Intel Corporation. +# Copyright (c) 2013 - 2018 Intel Corporation. # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -921,7 +921,7 @@ } !if $(CAPSULE_ENABLE) - MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf { diff --git a/QuarkPlatformPkg/Quark.fdf b/QuarkPlatformPkg/Quark.fdf index ab0f84b860..609f6e9b35 100644 --- a/QuarkPlatformPkg/Quark.fdf +++ b/QuarkPlatformPkg/Quark.fdf @@ -2,7 +2,7 @@ # FDF file of Clanton Peak CRB platform with 32-bit DXE # # This package provides QuarkNcSocId platform specific modules. -# Copyright (c) 2013 - 2017 Intel Corporation. +# Copyright (c) 2013 - 2018 Intel Corporation. # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -598,7 +598,7 @@ INF RuleOverride = DRIVER_ACPITABLE SecurityPkg/Tcg/TcgSmm/TcgSmm.inf !endif !if $(CAPSULE_ENABLE) -INF MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf +INF MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf INF SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareReportDxe.inf !endif -- 2.14.2.windows.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module
From: Michael D Kinney https://bugzilla.tianocore.org/show_bug.cgi?id=802 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that produces ESRT entries based only on FMP Protocol instances. Cc: Sean Brogan Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney --- MdeModulePkg/MdeModulePkg.dsc | 1 + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 + .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c | 161 +++ MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf | 68 +++ 4 files changed, 714 insertions(+) create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5988..c7dd76b774 100644 --- a/MdeModulePkg/MdeModulePkg.dsc +++ b/MdeModulePkg/MdeModulePkg.dsc @@ -417,6 +417,7 @@ MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf { diff --git a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c new file mode 100644 index 00..9fb281c666 --- /dev/null +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c @@ -0,0 +1,484 @@ +/** @file + Publishes ESRT table from Firmware Management Protocol instances + + Copyright (c) 2016, Microsoft Corporation + Copyright (c) 2018, Intel Corporation. All rights reserved. + + All rights reserved. + 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. + + 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. + +**/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + Print ESRT to debug console +*/ +VOID +EFIAPI +PrintTable ( + IN EFI_SYSTEM_RESOURCE_TABLE *Table + ); + +// +// Number of ESRT entries to grow by each time we run out of room +// +#define GROWTH_STEP 10 + +// +// Module globals. +// +EFI_EVENT mEsrtReadyToBootEvent; +EFI_SYSTEM_RESOURCE_TABLE *mTable = NULL; +BOOLEANmEsrtInstalled = FALSE; +EFI_EVENT mFmpInstallEvent; +VOID *mFmpInstallEventRegistration = NULL; + +/** + Install EFI System Resource Table into the UEFI Configuration Table + + @return Status code. + +**/ +EFI_STATUS +InstallEfiSystemResourceTableInUefiConfigurationTable ( + VOID + ) +{ + EFI_STATUS Status; + + Status = EFI_SUCCESS; + if (!mEsrtInstalled) { +if (mTable == NULL) { + DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table because it is NULL. \n")); + Status = EFI_OUT_OF_RESOURCES; +} else if (mTable->FwResourceCount == 0) { + DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table because it has zero Entries. \n")); + Status = EFI_UNSUPPORTED; +} else { + // + // Install the pointer into config table + // + Status = gBS->InstallConfigurationTable (&gEfiSystemResourceTableGuid, mTable); + if (EFI_ERROR (Status)) { +DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table. Status: %r. \n", Status)); + } else { +DEBUG ((DEBUG_INFO, "EsrtFmpDxe: Installed ESRT table. \n")); +mEsrtInstalled = TRUE; + } +} + } + return Status
Re: [edk2] [PATCH 00/15] BaseTools: One step toward python3
On Thu, Jan 25, 2018 at 01:37:39PM +, Zhu, Yonghong wrote: > Hi Gary, > > Thanks for your patches. I am still in evaluating these changes and do some > verification for it. > I still need some more days to give you comment. Thanks. I forgot to mention my branch in the cover letter. https://github.com/lcp/edk2/tree/python3-futurize It would be easier to review/apply patches from a git branch. Thanks, Gary Lin > > Best Regards, > Zhu Yonghong > > > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Friday, January 19, 2018 12:43 PM > To: edk2-devel@lists.01.org > Cc: Zhu, Yonghong ; Gao, Liming > Subject: [PATCH 00/15] BaseTools: One step toward python3 > > Since python2 will be EOF in 2020, we start to evaluate the impact of the > python2 removal. As expected, OMVF building failed the test. It's actually a > task noted in the wiki page: > > https://github.com/tianocore/tianocore.github.io/wiki/Tasks-BaseTools-Python3-Support > > Maybe it's time to convert the python scripts gradully. > > This patchset doesn't make the python scripts in BaseTools compatible with > python3 immediately. It aims to do the trivial and safe conversion and > replacement to make some statements compatible with both python2 and python3, > so we can deal with the difficult cases later. > > With the help of "futurize" from python-future, it's easier to refactor the > statements. This patchset is basically equivalent to "futurize -1" > plus "StringIO.StringIO => io.BytesIO" and minus "fix_absolute_import". > The reason to skip "fix_absolute_import" is that python2 failed to find some > modules after converting to absolute import, and it might take time to figure > out a proper fix. > > For the "io.BytesIO" change, it MIGHT introduce slow down to the build time > since io.BytesIO is slower than StringIO.StringIO in python2(*). > For a quick test, I built OVMF with the following command based on > 8ab0bd2397c9d3922e0c7dbb1aa6f7e08799079f: > > $ rm -rf Build && make -C BaseTools/ clean $ time ./OvmfPkg/build.sh -D > SECURE_BOOT_ENABLE \ > -D NETWORK_IP6_ENABLE \ > -D HTTP_BOOT_ENABLE \ > -D TLS_ENABLE > > Before io.BytesIO: > > Build total time: 00:03:56 > real4m22.991s > user3m55.874s > sys 0m27.250s > > After io.BytesIO: > > Build total time: 00:03:57 > real4m23.953s > user3m57.526s > sys 0m27.192s > > The difference is only 1 second, and I would say the impact is subtle. > > The next step will be fixing relative import and maybe applying more futurize > fixes. We won't get there soon but at least we are moving... > > (*) > https://stackoverflow.com/questions/37462075/confusing-about-stringio-cstringio-and-byteio > > Contributed-under: TianoCore Contribution Agreement 1.1 > Cc: Yonghong Zhu > Cc: Liming Gao > Signed-off-by: Gary Lin > > Gary Lin (15): > BaseTools: Refactor python except statements > BaseTools: Refactor python print statements > BaseTools: Remove the old python "not-equal" > BaseTools: Use the python3-range functions > BaseTools: Remove tuple parameter in python scripts > BaseTools: Remove the deprecated hash_key() > BaseTools: Import reduce() from functools > BaseTools: Replace StandardError with Expression > BaseTools: Remove types.TypeType > BaseTools: Refactor python raise statement > BaseTools: Adjust the spaces around commas and colons > BaseTools: Migrate to the new octal literal > BaseTools: Unify long int and int in python scripts > BaseTools: Adjust old python2 idioms > BaseTools: Replace StringIO.StringIO with io.BytesIO > > BaseTools/Bin/CYGWIN_NT-5.1-i686/armcc_wrapper.py | 5 > +- > BaseTools/Scripts/BinToPcd.py | 46 > +++--- > BaseTools/Scripts/ConvertMasmToNasm.py | 1 > + > BaseTools/Scripts/ConvertUni.py| 5 > - > BaseTools/Scripts/MemoryProfileSymbolGen.py| 22 > +-- > BaseTools/Scripts/PatchCheck.py| 7 > +- > BaseTools/Scripts/RunMakefile.py | 2 > +- > BaseTools/Scripts/SmiHandlerProfileSymbolGen.py| 20 > +-- > BaseTools/Scripts/UpdateBuildVersions.py | 18 > +- > BaseTools/Source/Python/AutoGen/AutoGen.py | 91 > +- > BaseTools/Source/Python/AutoGen/BuildEngine.py | 38 > +++-- > BaseTools/Source/Python/AutoGen/GenC.py| 5 > +- > BaseTools/Source/Python/AutoGen/GenDepex.py| 8 > +- > BaseTools/Source/Python/AutoGen/GenMake.py | 8 > +- > BaseTools/Source/Python/AutoGen/GenPcdDb.py|
[edk2] [PATCH] IntelSiliconPkg MicrocodeUpdateDxe: TotalSize must be multiples of 1KB
TotalSize must be multiples of 1024 bytes (1 KBytes) according to SDM. Also enhance the debug message for DataSize that must be multiples of DWORDs. Cc: Jiewen Yao Cc: Rangasai V Chaganty Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng --- .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c index 11a51106fdd2..46b55088285f 100644 --- a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c +++ b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c @@ -8,7 +8,7 @@ MicrocodeWrite() and VerifyMicrocode() will receive untrusted input and do basic validation. - Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved. + Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -421,7 +421,7 @@ VerifyMicrocode ( return EFI_INCOMPATIBLE_VERSION; } // - // Check Size + // Check TotalSize // if (MicrocodeEntryPoint->DataSize == 0) { TotalSize = 2048; @@ -436,6 +436,14 @@ VerifyMicrocode ( } return EFI_VOLUME_CORRUPTED; } + if ((TotalSize & (SIZE_1KB - 1)) != 0) { +DEBUG((DEBUG_ERROR, "VerifyMicrocode - TotalSize is not multiples of 1024 bytes (1 KBytes)\n")); +*LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; +if (AbortReason != NULL) { + *AbortReason = AllocateCopyPool(sizeof(L"InvalidTotalSize"), L"InvalidTotalSize"); +} +return EFI_VOLUME_CORRUPTED; + } if (TotalSize != ImageSize) { DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on TotalSize\n")); *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; @@ -445,7 +453,7 @@ VerifyMicrocode ( return EFI_VOLUME_CORRUPTED; } // - // Check CheckSum32 + // Check DataSize // if (MicrocodeEntryPoint->DataSize == 0) { DataSize = 2048 - sizeof(CPU_MICROCODE_HEADER); @@ -461,13 +469,16 @@ VerifyMicrocode ( return EFI_VOLUME_CORRUPTED; } if ((DataSize & 0x3) != 0) { -DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize not aligned\n")); +DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize is not multiples of DWORDs\n")); *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; if (AbortReason != NULL) { *AbortReason = AllocateCopyPool(sizeof(L"InvalidDataSize"), L"InvalidDataSize"); } return EFI_VOLUME_CORRUPTED; } + // + // Check CheckSum32 + // CheckSum32 = CalculateSum32((UINT32 *)MicrocodeEntryPoint, DataSize + sizeof(CPU_MICROCODE_HEADER)); if (CheckSum32 != 0) { DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on CheckSum32\n")); -- 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] IntelSiliconPkg MicrocodeUpdateDxe: TotalSize must be multiples of 1KB
Reviewed-by: jiewen@intel.com > -Original Message- > From: Zeng, Star > Sent: Friday, January 26, 2018 11:50 AM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Yao, Jiewen ; > Chaganty, Rangasai V > Subject: [PATCH] IntelSiliconPkg MicrocodeUpdateDxe: TotalSize must be > multiples of 1KB > > TotalSize must be multiples of 1024 bytes (1 KBytes) according to SDM. > > Also enhance the debug message for DataSize that must be > multiples of DWORDs. > > Cc: Jiewen Yao > Cc: Rangasai V Chaganty > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c | 19 > +++ > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git > a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c > b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c > index 11a51106fdd2..46b55088285f 100644 > --- a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c > +++ > b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c > @@ -8,7 +8,7 @@ > >MicrocodeWrite() and VerifyMicrocode() will receive untrusted input and do > basic validation. > > - Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved. > + Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved. >This program and the accompanying materials >are licensed and made available under the terms and conditions of the BSD > License >which accompanies this distribution. The full text of the license may be > found at > @@ -421,7 +421,7 @@ VerifyMicrocode ( > return EFI_INCOMPATIBLE_VERSION; >} >// > - // Check Size > + // Check TotalSize >// >if (MicrocodeEntryPoint->DataSize == 0) { > TotalSize = 2048; > @@ -436,6 +436,14 @@ VerifyMicrocode ( > } > return EFI_VOLUME_CORRUPTED; >} > + if ((TotalSize & (SIZE_1KB - 1)) != 0) { > +DEBUG((DEBUG_ERROR, "VerifyMicrocode - TotalSize is not multiples of > 1024 bytes (1 KBytes)\n")); > +*LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; > +if (AbortReason != NULL) { > + *AbortReason = AllocateCopyPool(sizeof(L"InvalidTotalSize"), > L"InvalidTotalSize"); > +} > +return EFI_VOLUME_CORRUPTED; > + } >if (TotalSize != ImageSize) { > DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on TotalSize\n")); > *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; > @@ -445,7 +453,7 @@ VerifyMicrocode ( > return EFI_VOLUME_CORRUPTED; >} >// > - // Check CheckSum32 > + // Check DataSize >// >if (MicrocodeEntryPoint->DataSize == 0) { > DataSize = 2048 - sizeof(CPU_MICROCODE_HEADER); > @@ -461,13 +469,16 @@ VerifyMicrocode ( > return EFI_VOLUME_CORRUPTED; >} >if ((DataSize & 0x3) != 0) { > -DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize not aligned\n")); > +DEBUG((DEBUG_ERROR, "VerifyMicrocode - DataSize is not multiples of > DWORDs\n")); > *LastAttemptStatus = LAST_ATTEMPT_STATUS_ERROR_INVALID_FORMAT; > if (AbortReason != NULL) { >*AbortReason = AllocateCopyPool(sizeof(L"InvalidDataSize"), > L"InvalidDataSize"); > } > return EFI_VOLUME_CORRUPTED; >} > + // > + // Check CheckSum32 > + // >CheckSum32 = CalculateSum32((UINT32 *)MicrocodeEntryPoint, DataSize + > sizeof(CPU_MICROCODE_HEADER)); >if (CheckSum32 != 0) { > DEBUG((DEBUG_ERROR, "VerifyMicrocode - fail on CheckSum32\n")); > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module
Hi Mike, Some MINOR comments at my first sight. 1. Should *.uni and *Extra.uni be added for this module? 2. Could EfiCreateEventReadyToBootEx() be used instead of below code? Then gEfiEventReadyToBootGuid reference in *.inf could be also removed. + Status = gBS->CreateEventEx ( + EVT_NOTIFY_SIGNAL, + TPL_CALLBACK, + EsrtReadyToBootEventNotify, + NULL, + &gEfiEventReadyToBootGuid, + &mEsrtReadyToBootEvent + ); 3. Is it better to have the MODULE_TYPE to be DXE_DRIVER? + MODULE_TYPE= UEFI_DRIVER Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, Michael D Sent: Friday, January 26, 2018 7:08 AM To: edk2-devel@lists.01.org Cc: Ni, Ruiyu ; Dong, Eric ; Yao, Jiewen ; Kinney, Michael D ; Zeng, Star Subject: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module From: Michael D Kinney https://bugzilla.tianocore.org/show_bug.cgi?id=802 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that produces ESRT entries based only on FMP Protocol instances. Cc: Sean Brogan Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney --- MdeModulePkg/MdeModulePkg.dsc | 1 + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 + .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c | 161 +++ MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf | 68 +++ 4 files changed, 714 insertions(+) create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5988..c7dd76b774 100644 --- a/MdeModulePkg/MdeModulePkg.dsc +++ b/MdeModulePkg/MdeModulePkg.dsc @@ -417,6 +417,7 @@ MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttributesDxe.inf MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf { diff --git a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c new file mode 100644 index 00..9fb281c666 --- /dev/null +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c @@ -0,0 +1,484 @@ +/** @file + Publishes ESRT table from Firmware Management Protocol instances + + Copyright (c) 2016, Microsoft Corporation Copyright (c) 2018, Intel + Corporation. All rights reserved. + + All rights reserved. + 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. + + 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. + +**/ + +#include +#include +#include +#include #include + +#include +#include +#include +#include #include +#include + +/* + Print ESRT to debug console +*/ +VOID +EFIAPI +PrintTable ( + IN EFI_SYSTEM_RESOURCE_TABLE *Table + ); + +// +// Number of ESRT entries to grow by each time we run out of room // +#define GROWTH_STEP 10 + +// +// Module globals. +// +EFI_EVENT mEsrtReadyToBootEvent; +EFI_SYSTEM_RESOURCE_TABLE *mTable = NULL; +BOOLEANmEsrtInstalled = FALSE; +EFI_EVENT mFmpInstallEvent; +VOID *mFmpInstallEventRegistration = NULL; + +/** + Install EFI System Resource Table into the UEFI Configuration Table +
Re: [edk2] [PATCH v2] PcAtChipsetPkg: Add PeiAcpiTimerLib to save PerformanceCounterFrequency in HOB
Hi Liming, Reviewed-by: Star Zeng Two minor comments. Just for your information. 1. Notice the title, it may be too long. 2. In PeiAcpiTimerLib.c, you may need to add ASSERT (PerformanceCounterFrequency != NULL) after BuildGuidHob. And you can move " PerformanceCounterFrequency = (UINT64*)GET_GUID_HOB_DATA (GuidHob); " to the else condition, then only one "return" is needed. + PerformanceCounterFrequency = NULL; + GuidHob = GetFirstGuidHob (&mFrequencyHobGuid); + if (GuidHob == NULL) { +PerformanceCounterFrequency = (UINT64*)BuildGuidHob(&mFrequencyHobGuid, sizeof (*PerformanceCounterFrequency)); +*PerformanceCounterFrequency = InternalCalculateTscFrequency (); +return *PerformanceCounterFrequency; + } + PerformanceCounterFrequency = (UINT64*)GET_GUID_HOB_DATA (GuidHob); + + return *PerformanceCounterFrequency; +} Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Tuesday, January 23, 2018 10:24 AM To: edk2-devel@lists.01.org Cc: Zeng, Star Subject: [edk2] [PATCH v2] PcAtChipsetPkg: Add PeiAcpiTimerLib to save PerformanceCounterFrequency in HOB In V2: 1) Update PeiAcpiTimerLib base name to PeiAcpiTimerLib 2) Update PeiAcpiTimerLib to add the missing constructor to enable ACPI IO space 3) Update DxeAcpiTimerLib to cache frequency in constructor. PeiAcpiTimerLib caches PerformanceCounterFrequency in HOB, then Pei and Dxe AcpiTimerLib can share the same PerformanceCounterFrequency. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao Cc: Star Zeng --- PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c | 4 +- .../Library/AcpiTimerLib/DxeAcpiTimerLib.c | 57 +- .../Library/AcpiTimerLib/DxeAcpiTimerLib.inf | 7 ++- .../Library/AcpiTimerLib/PeiAcpiTimerLib.c | 68 ++ .../Library/AcpiTimerLib/PeiAcpiTimerLib.inf | 56 ++ .../Library/AcpiTimerLib/PeiAcpiTimerLib.uni | 23 PcAtChipsetPkg/PcAtChipsetPkg.dsc | 4 +- 7 files changed, 211 insertions(+), 8 deletions(-) create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.c create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf create mode 100644 PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.uni diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c index 792781a33f..2f3cb4bca4 100644 --- a/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c +++ b/PcAtChipsetPkg/Library/AcpiTimerLib/AcpiTimerLib.c @@ -1,7 +1,7 @@ /** @file ACPI Timer implements one instance of Timer Library. - Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved. + Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -21,6 +21,8 @@ #include #include +GUID mFrequencyHobGuid = { 0x3fca54f6, 0xe1a2, 0x4b20, { 0xbe, 0x76, 0x92, 0x6b, 0x4b, 0x48, 0xbf, 0xaa }}; + /** Internal function to retrieves the 64-bit frequency in Hz. diff --git a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c index b141c680fb..67e18a1360 100644 --- a/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c +++ b/PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.c @@ -12,9 +12,27 @@ **/ -#include +#include #include #include +#include + +extern GUID mFrequencyHobGuid; + +/** + The constructor function enables ACPI IO space. + + If ACPI I/O space not enabled, this function will enable it. + It will always return RETURN_SUCCESS. + + @retval EFI_SUCCESS The constructor always returns RETURN_SUCCESS. + +**/ +RETURN_STATUS +EFIAPI +AcpiTimerLibConstructor ( + VOID + ); /** Calculate TSC frequency. @@ -54,8 +72,41 @@ InternalGetPerformanceCounterFrequency ( VOID ) { - if (mPerformanceCounterFrequency == 0) { + return mPerformanceCounterFrequency; +} + +/** + The constructor function enables ACPI IO space, and caches PerformanceCounterFrequency. + + @param ImageHandle The firmware allocated handle for the EFI image. + @param SystemTable A pointer to the EFI System Table. + + @retval EFI_SUCCESS The constructor always returns RETURN_SUCCESS. + +**/ +EFI_STATUS +EFIAPI +DxeAcpiTimerLibConstructor ( + IN EFI_HANDLEImageHandle, + IN EFI_SYSTEM_TABLE *SystemTable + ) +{ + EFI_HOB_GUID_TYPE *GuidHob; + + // + // Enable ACPI IO space. + // + AcpiTimerLibConstructor (); + + // + // Initialize PerformanceCounterFrequency + // + GuidHob = GetFirstGuidHob (&mFrequencyHobGuid); + if (GuidHob != NULL) { +mPerformanceCounterFrequency = *(UINT64*)GET_GUID_HOB_DATA (GuidHob); + } else {
Re: [edk2] [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase
Laszlo: Here is PERF macro PERF_START_EX(Handle, Token, Module, TimeStamp, Identifier). Handle is the image handle or device handle. PerfLib can base on Handle to get its FILE guid. Token is the measured token name. Module is the measured module name. PERF_START macro is added before gEfiCallerBaseName is supported. Some old PERF_START uses Token only. This patch just copies one and add it. So, it doesn't use gEfiCallerBaseName. I agree to use gEfiCallerBaseName better. TimeStamp is current tick. Identifier will be mapped into progressId in edk2 extended FPDT record from new performance https://lists.01.org/pipermail/edk2-devel/2018-January/020345.html. New performance will save each PERF into one record. It means START PERF entry is one record, END PERF entry is another record. When DP or OS tool parses record, they need to know the record is Start or End. Then, the different ProgressId will be used for Start and End. Thanks Liming >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Thursday, January 25, 2018 8:44 PM >To: Bi, Dandan ; edk2-devel@lists.01.org >Cc: Dong, Eric ; Gao, Liming >Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase > >On 01/25/18 05:56, Bi, Dandan wrote: >> Hi Laszlo, >> >> Thank you for your comments. >> >> Yes. The PERF_INMODULE_START_ID macro is from >"ExtendedFirmwarePerformance.h" which is added in the new performance >infrastructure patches([ mail subject: patch 0/8] Update EDKII Performance >infrastructure based on ACPI FPDT table). That is the dependency I mean. >> >> I will send V2 of this patch and the patch which remove Pref code after "new >performance infrastructure" patches have been committed . Then I will refine >the commit message of these two patches, add commit hash value of "new >performance infrastructure" patches if I need to reference it. > >Thank you. > >I had some other questions lower down, about the PERF_START_EX() >arguments. Can you please help me understand those better? > >Thanks! >Laszlo > >> >> Thanks, >> Dandan >> >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Wednesday, January 24, 2018 11:45 PM >> To: Bi, Dandan ; edk2-devel@lists.01.org >> Cc: Dong, Eric ; Gao, Liming >> Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 >phase >> >> On 01/24/18 08:59, Dandan Bi wrote: >>> Add more perf entry to hook BootScriptDonePpi/EndOfPeiPpi/ >>> EndOfS3Resume. >>> >>> Notes: This patch depends on the new performance infrastructure. >> >> Since this statement is going into the commit log, please be more specific >about the "new performance infrastructure" (TianoCore BZ or commit hashes >etc). >> >> Also, how is the dependency established? For example, OVMF uses >BasePerformanceLibNull; so I think it will see no changes. >> >> Do you mean the PERF_INMODULE_START_ID macro, from >"ExtendedFirmwarePerformance.h"? Ah, that's not committed yet. In this >case, please add a reference to the mailing list message (subject and archive >URL) that adds it. >> >> (Actually, the best solution is to reference the TianoCore BZ, and then add >the mailing list URL for each patch set submission to the TianoCore BZ.) >> >>> >>> Cc: Eric Dong >>> Cc: Laszlo Ersek >>> Cc: Liming Gao >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Dandan Bi >>> --- >>> UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 15 >>> ++- >>> 1 file changed, 14 insertions(+), 1 deletion(-) >>> >>> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >>> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >>> index b597ac7..d7d2a4d 100644 >>> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >>> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c >>> @@ -2,11 +2,11 @@ >>>This module produces the EFI_PEI_S3_RESUME2_PPI. >>>This module works with StandAloneBootScriptExecutor to S3 resume to >OS. >>>This module will execute the boot script saved during last boot and after >that, >>>control is passed to OS waking up handler. >>> >>> - Copyright (c) 2006 - 2017, Intel Corporation. All rights >>> reserved. >>> + Copyright (c) 2006 - 2018, Intel Corporation. All rights >>> + reserved. >>>Copyright (c) 2017, AMD Incorporated. 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 @@ >>> -21,10 +21,11 @@ #include >>> >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> #include >>> #include >>> @@ -551,13 +552,17 @@ S3ResumeBootOs ( >>>PERF_END (NULL, "ScriptExec", NULL, 0); >>> >>>// >>>// Install BootScriptDonePpi >>>// >>> + PERF_START_EX (NULL, "BootScriptDonePpi", NULL, 0, >>> + PERF_INMODULE_START_ID); >>> + >> >> My question here is not reall
Re: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe module
Mike, Should all code use BSD licenses? > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Kinney, Michael D > Sent: Friday, January 26, 2018 7:08 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Dong, Eric ; Yao, > Jiewen ; Kinney, Michael D > ; Zeng, Star > Subject: [edk2] [Patch 1/3] MdeModulePkg/EsrtFmpDxe: Add EsrtFmpDxe > module > > From: Michael D Kinney > > https://bugzilla.tianocore.org/show_bug.cgi?id=802 > > Based on content from the following branch/commits: > https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport > > The EsrtFmpDxe module is a lightweight version of the EsrtDxe module that > produces ESRT entries based only on FMP Protocol instances. > > Cc: Sean Brogan > Cc: Jiewen Yao > Cc: Star Zeng > Cc: Eric Dong > Cc: Ruiyu Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Michael D Kinney > --- > MdeModulePkg/MdeModulePkg.dsc | 1 + > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c| 484 > + > .../Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c | 161 +++ > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf | 68 +++ > 4 files changed, 714 insertions(+) > create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c > create mode 100644 > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDebugPrint.c > create mode 100644 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5988..c7dd76b774 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -417,6 +417,7 @@ > >MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf >MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf > + MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf > > > MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu > tesDxe.inf >MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf { diff --git > a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c > b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c > new file mode 100644 > index 00..9fb281c666 > --- /dev/null > +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c > @@ -0,0 +1,484 @@ > +/** @file > + Publishes ESRT table from Firmware Management Protocol instances > + > + Copyright (c) 2016, Microsoft Corporation Copyright (c) 2018, Intel > + Corporation. All rights reserved. > + > + All rights reserved. > + 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. > + > + 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. > + > +**/ > + > +#include > +#include > +#include > +#include #include > + > +#include > +#include > +#include > +#include #include > +#include > + > +/* > + Print ESRT to debug console > +*/ > +VOID > +EFIAPI > +PrintTable ( > + IN EFI_SYSTEM_RESOURCE_TABLE *Table > + ); > + > +// > +// Number of ESRT entries to grow by each time we run out of room // > +#define GROWTH_STEP 10 > + > +// > +// Module globals. > +// > +EFI_EVENT mEsrtReadyToBootEvent; > +EFI_SYSTEM_RESOURCE_TABLE *mTable = NULL; > +BOOLEANmEsrtInstalled = FALSE; > +EFI_EVENT mFmpInstallEvent; > +VOID *mFmpInstallEventRegistration = NULL; > + > +/** > + Install EFI System Resource Table into the UEFI Configuration Table > + > + @return Status code. > + > +**/ > +EFI_STATUS > +InstallEfiSystemResourceTableInUefiConfigurationTable ( > + VOID > + ) > +{ > + EFI_STATUS Status; > + > + Status = EFI_SUCCESS; > + if (!mEsrtInstalled) { > +if (mTable == NULL) { > + DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Can't install ESRT table because it > is > NULL. \n")); > + Status = EFI_OUT_