Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context
There is an architectural difference between EndOfDxe and SmmReadyToLock events. It's important to have both of them. Here is what PI specification says: == Transition from the environment where all of the components are under the authority of the platform manufacturer to the environment where third party modules are executed is a two-step process: 1.End of DXE Event is signaled. This event presents the last opportunity to use resources or interfaces that are going to be locked or disabled in anticipation of the invocation of 3rd party extensible modules. 2.DXE SMM Ready to Lock Protocol is installed. PI modules that need to lock or protect their resources in anticipation of the invocation of 3rd party extensible modules should register for notification on installation of this protocol and effect the appropriate protections in their notification handlers == -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, Jiewen Sent: Tuesday, March 05, 2019 11:19 AM To: Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context For current X86 world, we do use both SmmReadyToLock and EndOfDxe, for almost all X86 platform. So, let me clarify: If we try to align with PI spec, we can add EndOfDxe/ReadyToBoot/ExitBootService. If we try to align with security, we can add EndOfDxe/SmmReadyToLock. It depends upon the what goal we want to achieve. That is why I ask if we have specific use case. Anyway, I think we can add when it is really needed later. So I am OK with current patch. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ard Biesheuvel > Sent: Tuesday, March 5, 2019 8:07 AM > To: Yao, Jiewen > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal > architected PI events into MM context > > On Tue, 5 Mar 2019 at 17:04, Yao, Jiewen wrote: > > > > OK. To keep the compatibility of existing MM driver. That makes sense. > > > > If it is for security, I think EndOfDxe is the only point. > > ReadyToBoot and ExitBootService cannot be used for security purpose. > > > > OK, good to know. I will keep them for the time being - MM drivers may > be able to release resources or do other useful things when the > non-secure side enters runtime mode. > > > Then do we need SmmReadyToLock ? :-) > > > > Good point. It looked fairly x86 specific to me. Do you think it is > likely to be used in OEM code running in MM mode? > > > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of > > > Ard Biesheuvel > > > Sent: Tuesday, March 5, 2019 7:58 AM > > > To: Yao, Jiewen > > > Cc: edk2-devel@lists.01.org > > > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: > signal > > > architected PI events into MM context > > > > > > On Tue, 5 Mar 2019 at 16:56, Yao, Jiewen > wrote: > > > > > > > > Hi > > > > In original SMM infrastructure, there are lots of interaction that SMM > has > > > to know the DXE status. > > > > > > > > In StandaloneMm, I don't expect we have many interaction. Is there > any > > > specific example? > > > > > > > > I am totally OK to add those. And I just want to know more usage. > > > > > > > > Reviewed-by: jiewen@intel.com > > > > > > > > > > Jiewen, > > > > > > Thanks for the review. > > > > > > It is not 100% clear at the moment, but since existing third party > > > software designed to run in MM context may make assumptions about > > > security of the platform (e.g., before vs after end of dxe) based on > > > these events, we should at least signal the common ones added in this > > > patch. > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > > > Sent: Tuesday, March 5, 2019 5:33 AM > > > > > To: edk2-devel@lists.01.org > > > > > Cc: Ard Biesheuvel ; Achin Gupta > > > > > ; Supreeth Venkatesh > > > > > ; Yao, Jiewen > ; > > > > > Leif Lindholm ; Jagadeesh Ujja > > > > > > > > > > Subject: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal > > > architected > > > > > PI events into MM context > > > > > > > > > > PI defines a few architected events that have significance in the MM > > > > > context as well as in the non-secure DXE context. So register notify > > > > > handlers for these events, and relay them into the standalone MM > world. > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > Signed-off-by: Ard Biesheuvel > > > > > --- > > > > > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf | > 5 > > > +++ > > > > > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c | > 47 > > > > > +++- > > > > > 2 files changed, 50 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git > > > a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunic
Re: [edk2] [Patch] Document: Update the INF spec about [Depex] section
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng,
> Bob C
> Sent: Wednesday, February 27, 2019 9:12 PM
> To: edk2-devel@lists.01.org
> Cc: Liming Gao
> Subject: [edk2] [Patch] Document: Update the INF spec about [Depex] section
>
> ::= {"BEFORE"} {"AFTER"} should be
> ::= [{"BEFORE"} {"AFTER"}]
>
> The "BEFORE" or "AFTER" is optional key words in current implementation.
The proposed definition implies that BEFORE and AFTER can be used at the same
time, which is incorrect.
I think it should be
::= [{"BEFORE"} |{"AFTER"}]
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> ---
> 3_edk_ii_inf_file_format/314_[depex]_sections.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/3_edk_ii_inf_file_format/314_[depex]_sections.md
> b/3_edk_ii_inf_file_format/314_[depex]_sections.md
> index 942bcf9..3c0820a 100644
> --- a/3_edk_ii_inf_file_format/314_[depex]_sections.md
> +++ b/3_edk_ii_inf_file_format/314_[depex]_sections.md
> @@ -179,11 +179,11 @@ and VOID* datum type, and the size of the PCD must be
> 16 bytes.
> ::= {} {} {}
> ::= *
> ["END" ]
> ::= {} {}
> ::=
> - ::= {"BEFORE"} {"AFTER"} []
> + ::= [{"BEFORE"} {"AFTER"}] []
>::= {} {}
> ::= "PUSH" []
> ::= "SOR" []
> ::= {} {}
> ::= {"TRUE"} {"FALSE"} {} {} []
> --
> 2.20.1.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Enable component override functionality
Bob,
Do you know if DSC specification has been updated to document this new behavior?
If not, it should be updated.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of BobCF
Sent: Thursday, January 10, 2019 9:39 PM
To: edk2-devel@lists.01.org
Cc: Carsey Jaben; Liming Gao
Subject: [edk2] [Patch] BaseTools: Enable component override functionality
https://bugzilla.tianocore.org/show_bug.cgi?id=1449
This patch enable build tools to recognize that
when two given files have the same GUID, file path and ARCH in Dsc,
The later one's definition will be used.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Carsey Jaben
---
.../Source/Python/Workspace/DscBuildData.py | 24 ---
.../Source/Python/Workspace/MetaFileParser.py | 5
.../Source/Python/Workspace/MetaFileTable.py | 7 --
3 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 7e82e8e934..f9805f58f5 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -704,36 +704,44 @@ class DscBuildData(PlatformBuildClassObject):
if TAB_DEFAULT_STORES_DEFAULT not in self.DefaultStores:
self.DefaultStores[TAB_DEFAULT_STORES_DEFAULT] = (0,
TAB_DEFAULT_STORES_DEFAULT)
GlobalData.gDefaultStores = sorted(self.DefaultStores.keys())
return self.DefaultStores
+def OverrideDuplicateModule(self):
+RecordList = self._RawData[MODEL_META_DATA_COMPONENT, self._Arch]
+Macros = self._Macros
+Macros["EDK_SOURCE"] = GlobalData.gEcpSource
+Components = {}
+for Record in RecordList:
+ModuleId = Record[6]
+file_guid = self._RawData[MODEL_META_DATA_HEADER, self._Arch,
None, ModuleId]
+file_guid_str = file_guid[0][2] if file_guid else "NULL"
+ModuleFile = PathClass(NormPath(Record[0], Macros),
GlobalData.gWorkspace, Arch=self._Arch)
+if self._Arch != TAB_ARCH_COMMON and
(file_guid_str,str(ModuleFile)) in Components:
+
self._RawData.DisableOverrideComponent(Components[(file_guid_str,str(ModuleFile))])
+Components[(file_guid_str,str(ModuleFile))] = ModuleId
+self._RawData._PostProcessed = False
## Retrieve [Components] section information
@property
def Modules(self):
if self._Modules is not None:
return self._Modules
-
+self.OverrideDuplicateModule()
self._Modules = OrderedDict()
RecordList = self._RawData[MODEL_META_DATA_COMPONENT, self._Arch]
Macros = self._Macros
Macros["EDK_SOURCE"] = GlobalData.gEcpSource
for Record in RecordList:
-DuplicatedFile = False
-
ModuleFile = PathClass(NormPath(Record[0], Macros),
GlobalData.gWorkspace, Arch=self._Arch)
ModuleId = Record[6]
LineNo = Record[7]
# check the file validation
ErrorCode, ErrorInfo = ModuleFile.Validate('.inf')
if ErrorCode != 0:
EdkLogger.error('build', ErrorCode, File=self.MetaFile,
Line=LineNo,
ExtraData=ErrorInfo)
-# Check duplication
-# If arch is COMMON, no duplicate module is checked since all
modules in all component sections are selected
-if self._Arch != TAB_ARCH_COMMON and ModuleFile in self._Modules:
-DuplicatedFile = True
Module = ModuleBuildClassObject()
Module.MetaFile = ModuleFile
# get module private library instance
@@ -792,12 +800,10 @@ class DscBuildData(PlatformBuildClassObject):
else:
OptionString = Module.BuildOptions[ToolChainFamily,
ToolChain]
Module.BuildOptions[ToolChainFamily, ToolChain] =
OptionString + " " + Option
RecordList = self._RawData[MODEL_META_DATA_HEADER, self._Arch,
None, ModuleId]
-if DuplicatedFile and not RecordList:
-EdkLogger.error('build', FILE_DUPLICATED, File=self.MetaFile,
ExtraData=str(ModuleFile), Line=LineNo)
if RecordList:
if len(RecordList) != 1:
EdkLogger.error('build', OPTION_UNKNOWN, 'Only FILE_GUID
can be listed in section.',
File=self.MetaFile,
ExtraData=str(ModuleFile), Line=LineNo)
ModuleFile = ProcessDuplicatedInf(ModuleFile,
RecordList[0][2], GlobalData.gWorkspace)
diff --git a/BaseTools/Source/Python/Workspace/MetaFileParser.py
b/BaseTools/Source/Python/Workspace/MetaFileParser.py
index 032220813b..a52e9229df 100644
--- a/BaseTools/Source/Python/Workspace/MetaFileParser.py
+++ b/BaseTools/Source/Python/Workspace/MetaFileParser.py
@@
Re: [edk2] [Patch] BaseTools: Correct the value assignment for StructurePcd
Bob,
I think silent trimming of input data is not a good idea.
The build tool should either report an error (my preference) or a warning that
DSC or DEC input value is too long.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng,
Bob C
Sent: Saturday, February 16, 2019 12:55 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao
Subject: [edk2] [Patch] BaseTools: Correct the value assignment for StructurePcd
This patch is to fix the code bug in StructurePcd overall
value assignment logic. If a Pcd Array size is fixed but the
size of actual value in Dsc or Dec is bigger than the Pcd
array size, the tool only copy the data as same as that
Pcd Array size.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng
Cc: Liming Gao
---
.../Python/Workspace/BuildClassObject.py | 57 ---
.../Source/Python/Workspace/DscBuildData.py | 145 ++
2 files changed, 147 insertions(+), 55 deletions(-)
diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
b/BaseTools/Source/Python/Workspace/BuildClassObject.py
index 1df042f41c..d6168b62d5 100644
--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
@@ -76,34 +76,45 @@ class PcdClassObject(object):
self.UserDefinedDefaultStoresFlag = UserDefinedDefaultStoresFlag
self._Capacity = None
@property
def Capacity(self):
-self._Capacity = []
-dimension = ArrayIndex.findall(self._DatumType)
-for item in dimension:
-maxsize = item.lstrip("[").rstrip("]").strip()
-if not maxsize:
-maxsize = "-1"
-maxsize = str(int(maxsize,16)) if maxsize.startswith(("0x","0X"))
else maxsize
-self._Capacity.append(maxsize)
-if hasattr(self, "SkuOverrideValues"):
-for sku in self.SkuOverrideValues:
-for defaultstore in self.SkuOverrideValues[sku]:
-fields = self.SkuOverrideValues[sku][defaultstore]
-for demesionattr in fields:
-deme = ArrayIndex.findall(demesionattr)
-for i in range(len(deme)-1):
-if int(deme[i].lstrip("[").rstrip("]").strip()) >
int(self._Capacity[i]):
-print ("error")
-if hasattr(self,"DefaultValues"):
-for demesionattr in self.DefaultValues:
-deme = ArrayIndex.findall(demesionattr)
-for i in range(len(deme)-1):
-if int(deme[i].lstrip("[").rstrip("]").strip()) >
int(self._Capacity[i]):
-print ("error")
+if self._Capacity is None:
+self._Capacity = []
+dimension = ArrayIndex.findall(self._DatumType)
+for item in dimension:
+maxsize = item.lstrip("[").rstrip("]").strip()
+if not maxsize:
+maxsize = "-1"
+maxsize = str(int(maxsize,16)) if
maxsize.startswith(("0x","0X")) else maxsize
+self._Capacity.append(maxsize)
+if hasattr(self, "SkuOverrideValues"):
+for sku in self.SkuOverrideValues:
+for defaultstore in self.SkuOverrideValues[sku]:
+fields = self.SkuOverrideValues[sku][defaultstore]
+for demesionattr in fields:
+deme = ArrayIndex.findall(demesionattr)
+for i in range(len(deme)):
+if
int(deme[i].lstrip("[").rstrip("]").strip()) >= int(self._Capacity[i]):
+if self._Capacity[i] != "-1":
+raise ("error")
+if hasattr(self,"DefaultValues"):
+for demesionattr in self.DefaultValues:
+deme = ArrayIndex.findall(demesionattr)
+for i in range(len(deme)):
+if int(deme[i].lstrip("[").rstrip("]").strip()) >=
int(self._Capacity[i]):
+if self._Capacity[i] != "-1":
+raise ("error")
return self._Capacity
+
+def PcdArraySize(self):
+if self.Capacity[-1] == "-1":
+return -1
+size = 1
+for de in self.Capacity:
+size = size * int(de)
+return size
@property
def DatumType(self):
return self._DatumType
@DatumType.setter
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index e45beb3924..09d917c5db 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1763,27 +1763,41 @@ class DscBuildData(PlatformBuildClassObject):
return Result
def GenerateSizeFunction(self, Pcd):
Re: [edk2] [edk2-announce] Community Meeting Minutes
> -Original Message- > From: Laszlo Ersek > Sent: Friday, February 15, 2019 9:23 AM > > Just a short comment below. > > (Not changing my stance in any way that I've presented thus far; the > comment is only meant in addition to / as a clarification for that.) > > On 02/15/19 09:43, Ard Biesheuvel wrote: > > > I would like to see more engagement from these contributors in the > > actual project before we start rebuilding our infrastructure around > > them. > > Agreed. In my opinion, some public "testimonials" would be nice, such as > > Yes, the mailing list based workflow is the one thing that prevents us > from sharing patches, listening to and addressing reviews, posting > updated patches, and commenting on others' patches. For AMI and for me personally mailing list based workflow is one of the factors that limits our level of engagement. I've done a few patch submissions, but I have yet to figure out how to make applying embedded patches work in my Windwos & Outlook configuration. Please consider the environment before printing this email. The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
Mike, I think EFI_GUID and EFI_STATUS should cover most of the use cases. -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Thursday, January 17, 2019 3:04 PM To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D Cc: edk2-devel@lists.01.org Subject: RE: [edk2] History question about Base.h and its alternate parallel name space Should we change it? Felix, Is there a specific set that would have the most benefit? Is EFI_GUID sufficient? Mike > -Original Message- > From: Felix Polyudov [mailto:fel...@ami.com] > Sent: Wednesday, January 16, 2019 3:10 PM > To: 'Andrew Fish' ; Kinney, Michael D > > Cc: edk2-devel@lists.01.org > Subject: RE: [edk2] History question about Base.h and > its alternate parallel name space Should we change > it? > > I agree with Andrew. > In my opinion, moving alias types to Base.h will help to > overcome certain practical inconveniences without > a significant impact on the ability to detect poorly > written Base libraries. > > -Original Message- > From: edk2-devel [mailto:edk2-devel- > boun...@lists.01.org] On Behalf Of Andrew Fish via edk2- > devel > Sent: Wednesday, January 16, 2019 5:18 PM > To: Mike Kinney > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] History question about Base.h and > its alternate parallel name space Should we change > it? > > > > > On Jan 16, 2019, at 1:19 PM, Kinney, Michael D > wrote: > > > > Hi Andrew, > > > > I though the reason was a bit more technical. We have > a > > MODULE_TYPE of BASE. Library instances that use the > BASE > > MODULE_TYPE are declaring that the library interfaces > are > > safe to be linked against a module of any other type > (SEC, > > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP). > > > > We needed to make sure that a lib of type BASE that > > includes Base.h as its top level include file only has > > visibility to the types that are safe for all the > other > > module types. It is up to the top level include files > > for these other module types to provide the gasket to > > the types in Base.h. > > > > If we add aliases in Base.h, then we may not get build > > breaks when a lib of type BASE includes files that are > > not compatible with BASE. > > > > Mike, > > I don't think having aliases for return types really > helps Base code quality as RETURN_SUCCESS is almost > always just a comment in a header file, and only exists > in a .c file. Thus RETURN_* seem like a needless > duplication, best case it is a comment that the code is > Base. > > I will agree that not having EFI_GUID defined does case > all the PPI and Protocol files to blow up if you try to > include them. The failure case I was helping explain was > some one trying to include a PPI, that included a > Protocol that contained a data structure that was > needed. But I would posit that the definition of a > (EFI_)GUID is state agnostic. Having access to a PPI or > Protocol definition does not break Base code, what > breaks Base code is trying to access some service that > does not exist. To get more that EFI_GUID you are going > to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and > that will block doing anything that is not Base. > > So I'm asking if redefining the name for EFI_GUID to > GUID for Base is really that helpful? > > Thanks, > > Andrew Fish > > > > Thanks, > > > > Mike > > > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel- > >> boun...@lists.01.org] On Behalf Of Andrew Fish via > edk2- > >> devel > >> Sent: Wednesday, January 16, 2019 1:00 PM > >> To: edk2-devel > >> Subject: [edk2] History question about Base.h and its > >> alternate parallel name space Should we change > it? > >> > >> I had some one ask me recently why EFI_GUID does not > >> work with #include . I explained they needed > to > >> use GUID vs. EFI_GUID. That prompted the question of > why > >> we have 2 names for the same thing. Well the > >> historical answer was kind of political as some team > >> wanted to use edk2, but not implement EFI. Thus we > have > >> EFI types without the EFI_ prefix in Base.h. > >> > >> So all this got me thinking Maybe it makes sense > to > >> move some of the renaming from > >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? > Removing > >> the Base.h duplicate types would potentially hit lots > of > >> code [1] and break mer
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
I agree with Andrew. In my opinion, moving alias types to Base.h will help to overcome certain practical inconveniences without a significant impact on the ability to detect poorly written Base libraries. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew Fish via edk2-devel Sent: Wednesday, January 16, 2019 5:18 PM To: Mike Kinney Cc: edk2-devel@lists.01.org Subject: Re: [edk2] History question about Base.h and its alternate parallel name space Should we change it? > On Jan 16, 2019, at 1:19 PM, Kinney, Michael D > wrote: > > Hi Andrew, > > I though the reason was a bit more technical. We have a > MODULE_TYPE of BASE. Library instances that use the BASE > MODULE_TYPE are declaring that the library interfaces are > safe to be linked against a module of any other type (SEC, > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP). > > We needed to make sure that a lib of type BASE that > includes Base.h as its top level include file only has > visibility to the types that are safe for all the other > module types. It is up to the top level include files > for these other module types to provide the gasket to > the types in Base.h. > > If we add aliases in Base.h, then we may not get build > breaks when a lib of type BASE includes files that are > not compatible with BASE. > Mike, I don't think having aliases for return types really helps Base code quality as RETURN_SUCCESS is almost always just a comment in a header file, and only exists in a .c file. Thus RETURN_* seem like a needless duplication, best case it is a comment that the code is Base. I will agree that not having EFI_GUID defined does case all the PPI and Protocol files to blow up if you try to include them. The failure case I was helping explain was some one trying to include a PPI, that included a Protocol that contained a data structure that was needed. But I would posit that the definition of a (EFI_)GUID is state agnostic. Having access to a PPI or Protocol definition does not break Base code, what breaks Base code is trying to access some service that does not exist. To get more that EFI_GUID you are going to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and that will block doing anything that is not Base. So I'm asking if redefining the name for EFI_GUID to GUID for Base is really that helpful? Thanks, Andrew Fish > Thanks, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2- >> devel >> Sent: Wednesday, January 16, 2019 1:00 PM >> To: edk2-devel >> Subject: [edk2] History question about Base.h and its >> alternate parallel name space Should we change it? >> >> I had some one ask me recently why EFI_GUID does not >> work with #include . I explained they needed to >> use GUID vs. EFI_GUID. That prompted the question of why >> we have 2 names for the same thing. Well the >> historical answer was kind of political as some team >> wanted to use edk2, but not implement EFI. Thus we have >> EFI types without the EFI_ prefix in Base.h. >> >> So all this got me thinking Maybe it makes sense to >> move some of the renaming from >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? Removing >> the Base.h duplicate types would potentially hit lots of >> code [1] and break merges with other code bases (break >> other peoples Base libs etc.). >> >> These lines in MdePkg/Include/Uefi/UefiBaseType.h would >> get moved to MdePkg/Include/Base.h: >> typedef GUID EFI_GUID; >> typedef RETURN_STATUS EFI_STATUS; >> #define EFIERR(_a)ENCODE_ERROR(_a) >> #define EFI_ERROR(A) RETURN_ERROR(A) >> >> #define EFI_SUCCESS RETURN_SUCCESS >> #define EFI_LOAD_ERRORRETURN_LOAD_ERROR >> #define EFI_INVALID_PARAMETER >> RETURN_INVALID_PARAMETER >> #define EFI_UNSUPPORTED RETURN_UNSUPPORTED >> #define EFI_BAD_BUFFER_SIZE RETURN_BAD_BUFFER_SIZE >> #define EFI_BUFFER_TOO_SMALL >> RETURN_BUFFER_TOO_SMALL >> #define EFI_NOT_READY RETURN_NOT_READY >> #define EFI_DEVICE_ERROR RETURN_DEVICE_ERROR >> #define EFI_WRITE_PROTECTED RETURN_WRITE_PROTECTED >> #define EFI_OUT_OF_RESOURCES >> RETURN_OUT_OF_RESOURCES >> #define EFI_VOLUME_CORRUPTED >> RETURN_VOLUME_CORRUPTED >> #define EFI_VOLUME_FULL RETURN_VOLUME_FULL >> #define EFI_NO_MEDIA RETURN_NO_MEDIA >> #define EFI_MEDIA_CHANGED RETURN_MEDIA_CHANGED >> #define EFI_NOT_FOUND RETURN_NOT_FOUND >> #define EFI_ACCESS_DENIED RETURN_ACCESS_DENIED >> #define EFI_NO_RESPONSE RETURN_NO_RESPONSE >> #define EFI_NO_MAPPINGRETURN_NO_MAPPING >> #define EFI_TIMEOUT RETURN_TIMEOUT >> #define EFI_NOT_STARTED RETURN_NOT_STARTED >> #define EFI_ALREADY_STARTED RETURN_ALREADY_STARTED >> #define EFI_ABORTED RETURN_AB
[edk2] [Patch v2] BaseTools: Fix incorrect formatting of GenFds command dictionary
GenFdsCommand returned dictionary with elements that
are not compatible with GenFdsApi.
As a result the following options were not processed by GenFdsApi:
-v, -q, -d, --genfds-multi-thread, --ignore-sources
The issue is introduced by commit b3497bad1221704a5dbc5da0b10f42625f1ad2ed.
V2: Remove EFI_SOURCE references
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index cfe2d29..a795492 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3,6 +3,7 @@
#
# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
# Copyright (c) 2018, Hewlett Packard Enterprise Development, L.P.
+# Copyright (c) 2019, American Megatrends, Inc. All rights reserved.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -935,7 +936,56 @@ class WorkspaceAutoGen(AutoGen):
@property
def GenFdsCommandDict(self):
-return GenMake.TopLevelMakefile(self)._TemplateDict
+FdsCommandDict = {}
+LogLevel = EdkLogger.GetLevel()
+if LogLevel == EdkLogger.VERBOSE:
+FdsCommandDict["verbose"] = True
+elif LogLevel <= EdkLogger.DEBUG_9:
+FdsCommandDict["debug"] = LogLevel - 1
+elif LogLevel == EdkLogger.QUIET:
+FdsCommandDict["quiet"] = True
+
+if GlobalData.gEnableGenfdsMultiThread:
+FdsCommandDict["GenfdsMultiThread"] = True
+if GlobalData.gIgnoreSource:
+FdsCommandDict["IgnoreSources"] = True
+
+FdsCommandDict["OptionPcd"] = []
+for pcd in GlobalData.BuildOptionPcd:
+if pcd[2]:
+pcdname = '.'.join(pcd[0:3])
+else:
+pcdname = '.'.join(pcd[0:2])
+if pcd[3].startswith('{'):
+FdsCommandDict["OptionPcd"].append(pcdname + '=' + 'H' + '"' +
pcd[3] + '"')
+else:
+FdsCommandDict["OptionPcd"].append(pcdname + '=' + pcd[3])
+
+MacroList = []
+# macros passed to GenFds
+MacroDict = {}
+MacroDict.update(GlobalData.gGlobalDefines)
+MacroDict.update(GlobalData.gCommandLineDefines)
+for MacroName in MacroDict:
+if MacroDict[MacroName] != "":
+MacroList.append('"%s=%s"' % (MacroName,
MacroDict[MacroName].replace('\\', '')))
+else:
+MacroList.append('"%s"' % MacroName)
+FdsCommandDict["macro"] = MacroList
+
+FdsCommandDict["fdf_file"] = [self.FdfFile]
+FdsCommandDict["build_target"] = self.BuildTarget
+FdsCommandDict["toolchain_tag"] = self.ToolChain
+FdsCommandDict["active_platform"] = str(self)
+
+FdsCommandDict["conf_directory"] = GlobalData.gConfDirectory
+FdsCommandDict["build_architecture_list"] = ','.join(self.ArchList)
+FdsCommandDict["platform_build_directory"] = self.BuildDir
+
+FdsCommandDict["fd"] = self.FdTargetList
+FdsCommandDict["fv"] = self.FvTargetList
+FdsCommandDict["cap"] = self.CapTargetList
+return FdsCommandDict
## Create makefile for the platform and modules in it
#
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] BaseTools: Fix incorrect formatting of GenFds command dictionary
The issue is introduced by commit b3497bad1221704a5dbc5da0b10f42625f1ad2ed.
GenFdsCommand returned dictionary with elements that
are not compatible with GenFdsApi.
As a result the following options were not processed by GenFdsApi:
-v, -q, -d, --genfds-multi-thread, --ignore-sources
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 54 +-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index cfe2d29..db3717d 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3,6 +3,7 @@
#
# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
# Copyright (c) 2018, Hewlett Packard Enterprise Development, L.P.
+# Copyright (c) 2019, American Megatrends, Inc. All rights reserved.
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -935,7 +936,58 @@ class WorkspaceAutoGen(AutoGen):
@property
def GenFdsCommandDict(self):
-return GenMake.TopLevelMakefile(self)._TemplateDict
+FdsCommandDict = {}
+LogLevel = EdkLogger.GetLevel()
+if LogLevel == EdkLogger.VERBOSE:
+FdsCommandDict["verbose"] = True
+elif LogLevel <= EdkLogger.DEBUG_9:
+FdsCommandDict["debug"] = LogLevel - 1
+elif LogLevel == EdkLogger.QUIET:
+FdsCommandDict["quiet"] = True
+
+if GlobalData.gEnableGenfdsMultiThread:
+FdsCommandDict["GenfdsMultiThread"] = True
+if GlobalData.gIgnoreSource:
+FdsCommandDict["IgnoreSources"] = True
+
+FdsCommandDict["OptionPcd"] = []
+for pcd in GlobalData.BuildOptionPcd:
+if pcd[2]:
+pcdname = '.'.join(pcd[0:3])
+else:
+pcdname = '.'.join(pcd[0:2])
+if pcd[3].startswith('{'):
+FdsCommandDict["OptionPcd"].append(pcdname + '=' + 'H' + '"' +
pcd[3] + '"')
+else:
+FdsCommandDict["OptionPcd"].append(pcdname + '=' + pcd[3])
+
+MacroList = []
+# macros passed to GenFds
+MacroList.append('"%s=%s"' % ("EFI_SOURCE",
GlobalData.gEfiSource.replace('\\', '')))
+MacroDict = {}
+MacroDict.update(GlobalData.gGlobalDefines)
+MacroDict.update(GlobalData.gCommandLineDefines)
+MacroDict.pop("EFI_SOURCE", "dummy")
+for MacroName in MacroDict:
+if MacroDict[MacroName] != "":
+MacroList.append('"%s=%s"' % (MacroName,
MacroDict[MacroName].replace('\\', '')))
+else:
+MacroList.append('"%s"' % MacroName)
+FdsCommandDict["macro"] = MacroList
+
+FdsCommandDict["fdf_file"] = [self.FdfFile]
+FdsCommandDict["build_target"] = self.BuildTarget
+FdsCommandDict["toolchain_tag"] = self.ToolChain
+FdsCommandDict["active_platform"] = str(self)
+
+FdsCommandDict["conf_directory"] = GlobalData.gConfDirectory
+FdsCommandDict["build_architecture_list"] = ','.join(self.ArchList)
+FdsCommandDict["platform_build_directory"] = self.BuildDir
+
+FdsCommandDict["fd"] = self.FdTargetList
+FdsCommandDict["fv"] = self.FvTargetList
+FdsCommandDict["cap"] = self.CapTargetList
+return FdsCommandDict
## Create makefile for the platform and modules in it
#
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP
Andrew, I think there are two aspects here: 1) What's the final solution we would like to see? I think DebugLibMpSafe and a fake PEI Services Table that you are proposing are good ideas. Ideally, it should still be possible to use the real PEI Services table by overriding a library class. Please correct me if I'm wrong, but I believe it is legal to call PEI Service from AP if all other CPUs (including BSP) are not-running (halted or sitting in a spin-loop). 2) Should we do something short-term? In my opinion yes, because commit c563077a380437c1 breaks perhaps questionable but working production code. Additionally, as I've mentioned the library itself is broken because it uses DebugLib, which is likely to use PEI Services. The patch I've submitted certainly does not provide a complete solution, but it provides a workaround for the immediate issue. So I think it makes sense to apply the patch. Thanks Felix From: af...@apple.com [mailto:af...@apple.com] Sent: Friday, November 30, 2018 3:37 PM To: Felix Polyudov Cc: Ni, Ruiyu; edk2-devel@lists.01.org; ler...@redhat.com; Dong, Eric Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP Felix, I agree the obfuscation may not really be helpful. I've got a couple of thoughts. 1) I agree that I don't think the DebugLib is inherently safe on APs. I wonder if we could make a library class that was DebugLibMpSafe and have the same API as DebugLib. That way the library class matches how the module was coded. 2) If we want to enforce the rules we should add code to the PEI or DXE Core to CpuBreakpoint() etc. if an AP calls a core service. Adding detection code is possible, but it is not trivial. For example if you have remembered the BSP and if the WhoAmI returns something different you need to check to see if some one changed the BSP. I guess for PEI the other option could be to have a fake PEI Services Table that stubs out all the functions with CpuBreakpoint() or some such? Thanks, Andrew Fish On Nov 30, 2018, at 6:33 AM, Felix Polyudov mailto:fel...@ami.com>> wrote: Ray, I agree with the premise that calling PEI services from AP should generally be avoided. However, the PEI services can be used on AP under certain special circumstances. A couple of examples: 1. For debugging purposes. The MpInitLib contains 12 DEBUG calls and 19 ASSERT calls. Depending on the DebugLib instance used in the project, these calls may lead to PEI services invocation. 2. MpInitLib provides ability to call AP in a serialized manner (only one AP is running, other APs and BSP are waiting), when it is safe to call PEI services. Additionally, I think even if PEI services should not be used on AP, there is still a reason to keep PEI services table pointer initialized. On one hand, given the complexity of modern firmware projects comprised of modules coming from multiple vendors, making sure PEI services are not used on AP can be a challenge. For example, in my case the call was coming from the chipset reference code. On the other hand, with the current implementation, when somebody does try to use PEI services on AP the behavior is unpredictable. Depending on the content of the uninitialized PEI service table pointer, the system may either crash with one of the handful of different exceptions, or it may start executing code from a random location. It's very difficult to debug such issues. One can spend weeks chasing a problem like this. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu Sent: Thursday, November 29, 2018 10:43 PM To: Felix Polyudov; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> Cc: ler...@redhat.com<mailto:ler...@redhat.com>; Dong, Eric Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP Felix, I disagree:) Sorry about that. :) The commit you mentioned might be made by me (didn't checked). Because I aimed to avoid calling PEI services from AP. That's a violation of PI spec and not safe by design. The AP calling standard services concern was raised by Andrew initially. Thanks, Ray -Original Message- From: Felix Polyudov [mailto:fel...@ami.com] Sent: Friday, November 30, 2018 8:36 AM To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Ni, Ruiyu mailto:ruiyu...@intel.com>>; ler...@redhat.com<mailto:ler...@redhat.com> Subject: [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP According to PI specification PEI Services table pointer is stored right before ITD base. Starting from commit c563077a380437c1 BSP and AP have different IDT instances. PEI Services table pointer was not initialized in the AP IDT instance. As a result, any attempt to use functions from PeiServicesTablePointerLib or PeiServicesLib on AP caused CPU exception.
Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP
Ray, I agree with the premise that calling PEI services from AP should generally be avoided. However, the PEI services can be used on AP under certain special circumstances. A couple of examples: 1. For debugging purposes. The MpInitLib contains 12 DEBUG calls and 19 ASSERT calls. Depending on the DebugLib instance used in the project, these calls may lead to PEI services invocation. 2. MpInitLib provides ability to call AP in a serialized manner (only one AP is running, other APs and BSP are waiting), when it is safe to call PEI services. Additionally, I think even if PEI services should not be used on AP, there is still a reason to keep PEI services table pointer initialized. On one hand, given the complexity of modern firmware projects comprised of modules coming from multiple vendors, making sure PEI services are not used on AP can be a challenge. For example, in my case the call was coming from the chipset reference code. On the other hand, with the current implementation, when somebody does try to use PEI services on AP the behavior is unpredictable. Depending on the content of the uninitialized PEI service table pointer, the system may either crash with one of the handful of different exceptions, or it may start executing code from a random location. It's very difficult to debug such issues. One can spend weeks chasing a problem like this. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu Sent: Thursday, November 29, 2018 10:43 PM To: Felix Polyudov; edk2-devel@lists.01.org Cc: ler...@redhat.com; Dong, Eric Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP Felix, I disagree:) Sorry about that. :) The commit you mentioned might be made by me (didn't checked). Because I aimed to avoid calling PEI services from AP. That's a violation of PI spec and not safe by design. The AP calling standard services concern was raised by Andrew initially. Thanks, Ray > -Original Message----- > From: Felix Polyudov [mailto:fel...@ami.com] > Sent: Friday, November 30, 2018 8:36 AM > To: edk2-devel@lists.01.org > Cc: Dong, Eric ; Ni, Ruiyu ; > ler...@redhat.com > Subject: [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP > > According to PI specification PEI Services table pointer is stored right > before ITD > base. Starting from commit c563077a380437c1 BSP and AP have different IDT > instances. > PEI Services table pointer was not initialized in the AP IDT instance. > As a result, any attempt to use functions from PeiServicesTablePointerLib or > PeiServicesLib on AP caused CPU exception. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Felix Polyudov > --- > UefiCpuPkg/Library/MpInitLib/MpLib.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c > b/UefiCpuPkg/Library/MpInitLib/MpLib.c > index 7f4d6e6..0e3e362 100644 > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c > @@ -1567,6 +1567,7 @@ MpInitLibInitialize ( >BufferSize = ApStackSize * MaxLogicalProcessorNumber; >BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber; >BufferSize += ApResetVectorSize; > + BufferSize += sizeof(UINTN); >BufferSize = ALIGN_VALUE (BufferSize, 8); >BufferSize += VolatileRegisters.Idtr.Limit + 1; >BufferSize += sizeof (CPU_MP_DATA); > @@ -1587,6 +1588,8 @@ MpInitLibInitialize ( >// Backup Buffer >//++ >// Padding > + //++ > + //PEI Services Table Pointer >//++ <-- ApIdtBase (8-byte boundary) >// AP IDT All APs share one separate IDT. So AP can get > address of > CPU_MP_DATA from IDT Base. >//++ <-- CpuMpData > @@ -1599,7 +1602,7 @@ MpInitLibInitialize ( >// >MonitorBuffer= (UINT8 *) (Buffer + ApStackSize * > MaxLogicalProcessorNumber); >BackupBufferAddr = (UINTN) MonitorBuffer + MonitorFilterSize * > MaxLogicalProcessorNumber; > - ApIdtBase= ALIGN_VALUE (BackupBufferAddr + ApResetVectorSize, 8); > + ApIdtBase= ALIGN_VALUE (BackupBufferAddr + ApResetVectorSize + > sizeof(UINTN), 8); >CpuMpData= (CPU_MP_DATA *) (ApIdtBase + > VolatileRegisters.Idtr.Limit + > 1); >CpuMpData->Buffer = Buffer; >CpuMpData->CpuApStackSize = ApStackSize; > @@ -1653,6 +1656,11 @@ MpInitLibInitialize ( >Buffer + BufferSize); > >// > + // Initialize PEI Services table pointer. Copy the address from BSP. > + // > + *(UINTN*)(ApIdtBase - sizeof(UINTN)) = > + *(UINTN*)(VolatileRegiste
[edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP
According to PI specification PEI Services table pointer is stored right before ITD base. Starting from commit c563077a380437c1 BSP and AP have different IDT instances. PEI Services table pointer was not initialized in the AP IDT instance. As a result, any attempt to use functions from PeiServicesTablePointerLib or PeiServicesLib on AP caused CPU exception. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Felix Polyudov --- UefiCpuPkg/Library/MpInitLib/MpLib.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c index 7f4d6e6..0e3e362 100644 --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c @@ -1567,6 +1567,7 @@ MpInitLibInitialize ( BufferSize = ApStackSize * MaxLogicalProcessorNumber; BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber; BufferSize += ApResetVectorSize; + BufferSize += sizeof(UINTN); BufferSize = ALIGN_VALUE (BufferSize, 8); BufferSize += VolatileRegisters.Idtr.Limit + 1; BufferSize += sizeof (CPU_MP_DATA); @@ -1587,6 +1588,8 @@ MpInitLibInitialize ( // Backup Buffer //++ // Padding + //++ + //PEI Services Table Pointer //++ <-- ApIdtBase (8-byte boundary) // AP IDT All APs share one separate IDT. So AP can get address of CPU_MP_DATA from IDT Base. //++ <-- CpuMpData @@ -1599,7 +1602,7 @@ MpInitLibInitialize ( // MonitorBuffer= (UINT8 *) (Buffer + ApStackSize * MaxLogicalProcessorNumber); BackupBufferAddr = (UINTN) MonitorBuffer + MonitorFilterSize * MaxLogicalProcessorNumber; - ApIdtBase= ALIGN_VALUE (BackupBufferAddr + ApResetVectorSize, 8); + ApIdtBase= ALIGN_VALUE (BackupBufferAddr + ApResetVectorSize + sizeof(UINTN), 8); CpuMpData= (CPU_MP_DATA *) (ApIdtBase + VolatileRegisters.Idtr.Limit + 1); CpuMpData->Buffer = Buffer; CpuMpData->CpuApStackSize = ApStackSize; @@ -1653,6 +1656,11 @@ MpInitLibInitialize ( Buffer + BufferSize); // + // Initialize PEI Services table pointer. Copy the address from BSP. + // + *(UINTN*)(ApIdtBase - sizeof(UINTN)) = *(UINTN*)(VolatileRegisters.Idtr.Base - sizeof (UINTN)); + + // // Duplicate BSP's IDT to APs. // All APs share one separate IDT. So AP can get the address of CpuMpData by using IDTR.BASE + IDTR.LIMIT + 1 // -- 2.10.0.windows.1 Please consider the environment before printing this email. The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Replace the sqlite database with list
Bob, Does it mean that after this patch the build data is no longer saved to a file and is recreated on every build? Do you have any data regarding build process performance improvements after applying the patch? Does this patch improve full build time and incremental build time? Thanks Felix -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, Bob C Sent: Thursday, November 08, 2018 12:39 AM To: Ni, Ruiyu; edk2-devel@lists.01.org Cc: Carsey, Jaben; Gao, Liming Subject: Re: [edk2] [Patch] BaseTools: Replace the sqlite database with list Hi Ray, Right. No SQL dependency any more after this patch. Thanks, Bob -Original Message- From: Ni, Ruiyu Sent: Thursday, November 8, 2018 1:37 PM To: Feng, Bob C ; edk2-devel@lists.01.org Cc: Carsey, Jaben ; Gao, Liming Subject: Re: [edk2] [Patch] BaseTools: Replace the sqlite database with list On 11/8/2018 11:15 AM, BobCF wrote: > https://bugzilla.tianocore.org/show_bug.cgi?id=1288 > > This patch is one of build tool performance improvement series > patches. > > This patch is going to use python list to store the parser data > instead of using sqlite database. > > The replacement solution is as below: > > SQL insert: list.append() > SQL select: list comprehension. for example: > Select * from table where field = “something” > -> > [ item for item in table if item[3] == “something”] > > SQL update: python map function. for example: > Update table set field1=newvalue where filed2 = “something”. > -> map(lambda x: x[1] = newvalue, > [item for item in table if item[2] == “something”]) > > SQL delete: list comprehension. > > With this change, We can save the time of interpreting SQL statement > and the time of write database to file system > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: BobCF > Cc: Liming Gao > Cc: Jaben Carsey > --- Bob, I am curious. After this patch, there is no SQL dependency in build tool? -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Please consider the environment before printing this email. The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch v3] MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
v3: LaneEqualizationControl is changed to be an array.
v2: The structure is updated to include all the fields defined
in the PCI-E specification.
The header includes Physical Layer PCI Express Extended Capability definitions
described in section 7.7.5 of PCI Express Base Specification rev. 4.0.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
MdePkg/Include/IndustryStandard/PciExpress40.h | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/PciExpress40.h
diff --git a/MdePkg/Include/IndustryStandard/PciExpress40.h
b/MdePkg/Include/IndustryStandard/PciExpress40.h
new file mode 100644
index 000..6a7139f
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/PciExpress40.h
@@ -0,0 +1,89 @@
+/** @file
+Support for the PCI Express 4.0 standard.
+
+This header file may not define all structures. Please extend as required.
+
+Copyright (c) 2018, American Megatrends, Inc. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution. The full text of the license may be
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _PCIEXPRESS40_H_
+#define _PCIEXPRESS40_H_
+
+#include
+
+#pragma pack(1)
+
+/// The Physical Layer PCI Express Extended Capability definitions.
+///
+/// Based on section 7.7.5 of PCI Express Base Specification 4.0.
+///@{
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_ID0x0026
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_VER1 0x1
+
+// Register offsets from Physical Layer PCI-E Ext Cap Header
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES_OFFSET
0x04
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL_OFFSET
0x08
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS_OFFSET
0x0C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LOCAL_DATA_PARITY_STATUS_OFFSET
0x10
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_FIRST_RETIMER_DATA_PARITY_STATUS_OFFSET
0x14
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_SECOND_RETIMER_DATA_PARITY_STATUS_OFFSET
0x18
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL_OFFSET
0x20
+
+typedef union {
+ struct {
+UINT32 Reserved : 32; // Reserved bit 0:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES;
+
+typedef union {
+ struct {
+UINT32 Reserved : 32; // Reserved bit 0:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL;
+
+typedef union {
+ struct {
+UINT32 EqualizationComplete : 1; // bit 0
+UINT32 EqualizationPhase1Success : 1; // bit 1
+UINT32 EqualizationPhase2Success : 1; // bit 2
+UINT32 EqualizationPhase3Success : 1; // bit 3
+UINT32 LinkEqualizationRequest : 1; // bit 4
+UINT32 Reserved : 27; // Reserved bit 5:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS;
+
+typedef union {
+ struct {
+UINT8 DownstreamPortTransmitterPreset : 4; //bit 0..3
+UINT8 UpstreamPortTransmitterPreset : 4; //bit 4..7
+ } Bits;
+ UINT8 Uint8;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL;
+
+typedef struct {
+ PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER Header;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES Capablities;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL Control;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUSStatus;
+ UINT32
LocalDataParityMismatchStatus;
+ UINT32
FirstRetimerDataParityMismatchStatus;
+ UINT32
SecondRetimerDataParityMismatchStatus;
+ UINT32Reserved;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL
LaneEqualizationControl[1];
+} PCI_EXPRESS_EXTENDED_CAPABILITIES_PHYSICAL_LAYER_16_0;
+///@}
+
+#pragma pack()
+
+#endif
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-
Re: [edk2] [Patch v2] MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
I think it should be governed by edk2 conventions.
As far as I'm aware, currently there are no conventions related to packed data
structure decoration.
-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Tuesday, February 27, 2018 4:36 PM
To: edk2-devel@lists.01.org
Cc: Felix Polyudov; michael.d.kin...@intel.com; Manickavasakam
Karpagavinayagam; liming@intel.com
Subject: RE: [edk2] [Patch v2] MdePkg/Include/IndustryStandard: Add PCI Express
4.0 header file
Good day,
Please consider for compatibility with some toolchains, byte-packed structs and
unions must be decorated with the define 'PACKED'.
Thanks,
Marvin.
> -Original Message-
> From: edk2-devel On Behalf Of Felix
> Polyudov
> Sent: Tuesday, February 27, 2018 10:07 PM
> To: edk2-devel@lists.01.org
> Cc: michael.d.kin...@intel.com; manickavasak...@ami.com;
> liming@intel.com
> Subject: [edk2] [Patch v2] MdePkg/Include/IndustryStandard: Add PCI
> Express 4.0 header file
>
> v2: The structure is updated to include all the fields defined in the PCI-E
> specification.
>
> The header includes Physical Layer PCI Express Extended Capability
> definitions described in section 7.7.5 of PCI Express Base Specification rev.
> 4.0.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Felix Polyudov
> ---
> MdePkg/Include/IndustryStandard/PciExpress40.h | 89
> ++
> 1 file changed, 89 insertions(+)
> create mode 100644 MdePkg/Include/IndustryStandard/PciExpress40.h
>
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress40.h
> b/MdePkg/Include/IndustryStandard/PciExpress40.h
> new file mode 100644
> index 000..a832259
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/PciExpress40.h
> @@ -0,0 +1,89 @@
> +/** @file
> +Support for the PCI Express 4.0 standard.
> +
> +This header file may not define all structures. Please extend as required.
> +
> +Copyright (c) 2018, American Megatrends, Inc. All rights reserved.
> +This program and the accompanying materials are licensed and made
> +available under the terms and conditions of the BSD License which
> +accompanies this distribution. The full text of the license may be
> +found at http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _PCIEXPRESS40_H_
> +#define _PCIEXPRESS40_H_
> +
> +#include
> +
> +#pragma pack(1)
> +
> +/// The Physical Layer PCI Express Extended Capability definitions.
> +///
> +/// Based on section 7.7.5 of PCI Express Base Specification 4.0.
> +///@{
> +#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_ID
> 0x0026
> +#define
> PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_VER1 0x1
> +
> +// Register offsets from Physical Layer PCI-E Ext Cap Header
> +#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES_OFFSET
> 0x04
> +#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL_OFFSET
> 0x08
> +#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS_OFFSET
> 0x0C
> +#define
> PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LOCAL_DATA_PARITY_STATUS_
> OFFSET 0x10
> +#define
> PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_FIRST_RETIMER_DATA_PARITY_
> STATUS_OFFSET 0x14
> +#define
> PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_SECOND_RETIMER_DATA_PARIT
> Y_STATUS_OFFSET0x18
> +#define
> PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL
> _OFFSET0x20
> +
> +typedef union {
> + struct {
> +UINT32 Reserved : 32; // Reserved bit 0:31
> + } Bits;
> + UINT32 Uint32;
> +} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES;
> +
> +typedef union {
> + struct {
> +UINT32 Reserved : 32; // Reserved bit 0:31
> + } Bits;
> + UINT32 Uint32;
> +} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL;
> +
> +typedef union {
> + struct {
> +UINT32 EqualizationComplete : 1; // bit 0
> +UINT32 EqualizationPhase1Success : 1; // bit 1
> +UINT32 EqualizationPhase2Success : 1; // bit 2
> +UINT32 EqualizationPhase3Success : 1; // bit 3
> +UINT32 LinkEqualizationRequest : 1; // bit 4
> +UINT32 Reserved : 27; // Reserved bit 5:31
> + } Bits;
> + UINT32 Uint32;
> +} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS;
> +
> +typedef union {
> + struct {
> +UINT8 DownstreamPortTransmitterPreset : 4; //bit 0..3
> +UINT8 UpstreamPortTransmitterPreset : 4; //bit 4..7
> + } Bits;
> + UINT8 Uint8;
> +}
> PCI_EXPRESS
[edk2] [Patch v2] MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
v2: The structure is updated to include all the fields defined
in the PCI-E specification.
The header includes Physical Layer PCI Express Extended Capability definitions
described in section 7.7.5 of PCI Express Base Specification rev. 4.0.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
MdePkg/Include/IndustryStandard/PciExpress40.h | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/PciExpress40.h
diff --git a/MdePkg/Include/IndustryStandard/PciExpress40.h
b/MdePkg/Include/IndustryStandard/PciExpress40.h
new file mode 100644
index 000..a832259
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/PciExpress40.h
@@ -0,0 +1,89 @@
+/** @file
+Support for the PCI Express 4.0 standard.
+
+This header file may not define all structures. Please extend as required.
+
+Copyright (c) 2018, American Megatrends, Inc. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution. The full text of the license may be
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _PCIEXPRESS40_H_
+#define _PCIEXPRESS40_H_
+
+#include
+
+#pragma pack(1)
+
+/// The Physical Layer PCI Express Extended Capability definitions.
+///
+/// Based on section 7.7.5 of PCI Express Base Specification 4.0.
+///@{
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_ID0x0026
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_VER1 0x1
+
+// Register offsets from Physical Layer PCI-E Ext Cap Header
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES_OFFSET
0x04
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL_OFFSET
0x08
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS_OFFSET
0x0C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LOCAL_DATA_PARITY_STATUS_OFFSET
0x10
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_FIRST_RETIMER_DATA_PARITY_STATUS_OFFSET
0x14
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_SECOND_RETIMER_DATA_PARITY_STATUS_OFFSET
0x18
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL_OFFSET
0x20
+
+typedef union {
+ struct {
+UINT32 Reserved : 32; // Reserved bit 0:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES;
+
+typedef union {
+ struct {
+UINT32 Reserved : 32; // Reserved bit 0:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL;
+
+typedef union {
+ struct {
+UINT32 EqualizationComplete : 1; // bit 0
+UINT32 EqualizationPhase1Success : 1; // bit 1
+UINT32 EqualizationPhase2Success : 1; // bit 2
+UINT32 EqualizationPhase3Success : 1; // bit 3
+UINT32 LinkEqualizationRequest : 1; // bit 4
+UINT32 Reserved : 27; // Reserved bit 5:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS;
+
+typedef union {
+ struct {
+UINT8 DownstreamPortTransmitterPreset : 4; //bit 0..3
+UINT8 UpstreamPortTransmitterPreset : 4; //bit 4..7
+ } Bits;
+ UINT8 Uint8;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL;
+
+typedef struct {
+ PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER Header;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES Capablities;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL Control;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUSStatus;
+ UINT32
LocalDataParityMismatchStatus;
+ UINT32
FirstRetimerDataParityMismatchStatus;
+ UINT32
SecondRetimerDataParityMismatchStatus;
+ UINT32Reserved;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL
LaneEqualizationControl;
+} PCI_EXPRESS_EXTENDED_CAPABILITIES_PHYSICAL_LAYER_16_0;
+///@}
+
+#pragma pack()
+
+#endif
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or d
[edk2] [PATCH] MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
The header includes Physical Layer PCI Express Extended Capability definitions
described in section 7.7.5 of PCI Express Base Specification rev. 4.0.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
MdePkg/Include/IndustryStandard/PciExpress40.h | 69 ++
1 file changed, 69 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/PciExpress40.h
diff --git a/MdePkg/Include/IndustryStandard/PciExpress40.h
b/MdePkg/Include/IndustryStandard/PciExpress40.h
new file mode 100644
index 000..e0f4323
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/PciExpress40.h
@@ -0,0 +1,69 @@
+/** @file
+Support for the PCI Express 4.0 standard.
+
+This header file may not define all structures. Please extend as required.
+
+Copyright (c) 2018, American Megatrends, Inc. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution. The full text of the license may be
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _PCIEXPRESS40_H_
+#define _PCIEXPRESS40_H_
+
+#include
+
+#pragma pack(1)
+
+/// The Physical Layer PCI Express Extended Capability definitions.
+///
+/// Based on section 7.7.5 of PCI Express Base Specification 4.0.
+///@{
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_ID0x0026
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_VER1 0x1
+
+// Register offsets from Physical Layer PCI-E Ext Cap Header
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES_OFFSET
0x04
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL_OFFSET
0x08
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS_OFFSET
0x0C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LOCAL_DATA_PARITY_STATUS_OFFSET
0x10
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_FIRST_RETIMER_DATA_PARITY_STATUS_OFFSET
0x14
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_SECOND_RETIMER_DATA_PARITY_STATUS_OFFSET
0x18
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL_OFFSET
0x20
+
+typedef union {
+ struct {
+UINT32 EqualizationComplete : 1; // bit 0
+UINT32 EqualizationPhase1Success : 1; // bit 1
+UINT32 EqualizationPhase2Success : 1; // bit 2
+UINT32 EqualizationPhase3Success : 1; // bit 3
+UINT32 LinkEqualizationRequest : 1; // bit 4
+UINT32 Reserved : 27; // Reserved bit 5:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS;
+
+typedef union {
+ struct {
+UINT8 DownstreamPortTransmitterPreset : 4; //bit 0..3
+UINT8 UpstreamPortTransmitterPreset : 4; //bit 4..7
+ } Bits;
+ UINT8 Uint8;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL;
+
+typedef struct {
+ PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER Header;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS Status;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL Control;
+} PCI_EXPRESS_EXTENDED_CAPABILITIES_PHYSICAL_LAYER_16_0;
+///@}
+
+#pragma pack()
+
+#endif
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
The header includes Physical Layer PCI Express Extended Capability definitions
described in section 7.7.5 of PCI Express Base Specification rev. 4.0.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov
---
MdePkg/Include/IndustryStandard/PciExpress40.h | 69 ++
1 file changed, 69 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/PciExpress40.h
diff --git a/MdePkg/Include/IndustryStandard/PciExpress40.h
b/MdePkg/Include/IndustryStandard/PciExpress40.h
new file mode 100644
index 000..e0f4323
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/PciExpress40.h
@@ -0,0 +1,69 @@
+/** @file
+Support for the PCI Express 4.0 standard.
+
+This header file may not define all structures. Please extend as required.
+
+Copyright (c) 2018, American Megatrends, Inc. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD
License
+which accompanies this distribution. The full text of the license may be
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _PCIEXPRESS40_H_
+#define _PCIEXPRESS40_H_
+
+#include
+
+#pragma pack(1)
+
+/// The Physical Layer PCI Express Extended Capability definitions.
+///
+/// Based on section 7.7.5 of PCI Express Base Specification 4.0.
+///@{
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_ID0x0026
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_16_0_VER1 0x1
+
+// Register offsets from Physical Layer PCI-E Ext Cap Header
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CAPABILITIES_OFFSET
0x04
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_CONTROL_OFFSET
0x08
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS_OFFSET
0x0C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LOCAL_DATA_PARITY_STATUS_OFFSET
0x10
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_FIRST_RETIMER_DATA_PARITY_STATUS_OFFSET
0x14
+#define
PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_SECOND_RETIMER_DATA_PARITY_STATUS_OFFSET
0x18
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL_OFFSET
0x20
+
+typedef union {
+ struct {
+UINT32 EqualizationComplete : 1; // bit 0
+UINT32 EqualizationPhase1Success : 1; // bit 1
+UINT32 EqualizationPhase2Success : 1; // bit 2
+UINT32 EqualizationPhase3Success : 1; // bit 3
+UINT32 LinkEqualizationRequest : 1; // bit 4
+UINT32 Reserved : 27; // Reserved bit 5:31
+ } Bits;
+ UINT32 Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS;
+
+typedef union {
+ struct {
+UINT8 DownstreamPortTransmitterPreset : 4; //bit 0..3
+UINT8 UpstreamPortTransmitterPreset : 4; //bit 4..7
+ } Bits;
+ UINT8 Uint8;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL;
+
+typedef struct {
+ PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER Header;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_STATUS Status;
+ PCI_EXPRESS_REG_PHYSICAL_LAYER_16_0_LANE_EQUALIZATION_CONTROL Control;
+} PCI_EXPRESS_EXTENDED_CAPABILITIES_PHYSICAL_LAYER_16_0;
+///@}
+
+#pragma pack()
+
+#endif
--
2.10.0.windows.1
Please consider the environment before printing this email.
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
