[edk2-devel][Patch 3/3] MdePkg/UefiDebugLibStdErr: Add destructor to CloseEvent
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2012
When driver is unloaded, the ExitBootSerivesEvent must be closed at
the same time. Otherwise exception will occur when ExitBootServices.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Wei6 Xu
---
.../UefiDebugLibStdErr/DebugLibConstructor.c | 23 ++
.../UefiDebugLibStdErr/UefiDebugLibStdErr.inf | 1 +
2 files changed, 24 insertions(+)
diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
index 8005370372..ed73f92818 100644
--- a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
+++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
@@ -73,5 +73,28 @@ DxeDebugLibConstructor(
);
return EFI_SUCCESS;
}
+
+/**
+ The destructor closes Exit Boot Services Event.
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The destructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+DxeDebugLibDestructor(
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ if (mExitBootServicesEvent != NULL) {
+SystemTable->BootServices->CloseEvent (mExitBootServicesEvent);
+ }
+
+ return EFI_SUCCESS;
+}
diff --git a/MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
b/MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
index deaa3427f6..11f7594626 100644
--- a/MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
+++ b/MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
@@ -20,10 +20,11 @@
MODULE_TYPE= UEFI_DRIVER
VERSION_STRING = 1.0
LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER
DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
CONSTRUCTOR= DxeDebugLibConstructor
+ DESTRUCTOR = DxeDebugLibDestructor
#
# VALID_ARCHITECTURES = IA32 X64 EBC
#
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44435): https://edk2.groups.io/g/devel/message/44435
Mute This Topic: https://groups.io/mt/32605741/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel][Patch 2/3] MdePkg/UefiDebugLibDebugPortProtocol: Add destructor to CloseEvent
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2012
When driver is unloaded, the ExitBootSerivesEvent must be closed at
the same time. Otherwise exception will occur when ExitBootServices.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Wei6 Xu
---
.../DebugLibConstructor.c | 23 ++
.../UefiDebugLibDebugPortProtocol.inf | 1 +
2 files changed, 24 insertions(+)
diff --git a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
index de60d339a8..6ea0912f2b 100644
--- a/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
+++ b/MdePkg/Library/UefiDebugLibDebugPortProtocol/DebugLibConstructor.c
@@ -73,5 +73,28 @@ DxeDebugLibConstructor(
);
return EFI_SUCCESS;
}
+
+/**
+ The destructor closes Exit Boot Services Event.
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The destructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+DxeDebugLibDestructor(
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ if (mExitBootServicesEvent != NULL) {
+SystemTable->BootServices->CloseEvent (mExitBootServicesEvent);
+ }
+
+ return EFI_SUCCESS;
+}
diff --git
a/MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf
b/MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf
index 10a8f2a857..ff09a12ce4 100644
---
a/MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf
+++
b/MdePkg/Library/UefiDebugLibDebugPortProtocol/UefiDebugLibDebugPortProtocol.inf
@@ -20,10 +20,11 @@
MODULE_TYPE= UEFI_DRIVER
VERSION_STRING = 1.0
LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER
DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
CONSTRUCTOR= DxeDebugLibConstructor
+ DESTRUCTOR = DxeDebugLibDestructor
#
# VALID_ARCHITECTURES = IA32 X64 EBC
#
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44434): https://edk2.groups.io/g/devel/message/44434
Mute This Topic: https://groups.io/mt/32605739/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel][Patch 0/3] Add destructor to CloseEvent
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2012 This patch set adds missing destructor for following libraries: MdePkg\Library\UefiDebugLibStdErr MdePkg\Library\UefiDebugLibConOut MdePkg\Library\UefiDebugLibDebugPortProtocol When driver is unloaded, the ExitBootSerivesEvent must be closed at the same time. Otherwise exception will occur when ExitBootServices. Cc: Michael D Kinney Cc: Liming Gao Wei6 Xu (3): MdePkg/UefiDebugLibConOut: Add destructor to CloseEvent MdePkg/UefiDebugLibDebugPortProtocol: Add destructor to CloseEvent MdePkg/UefiDebugLibStdErr: Add destructor to CloseEvent .../UefiDebugLibConOut/DebugLibConstructor.c | 23 ++ .../UefiDebugLibConOut/UefiDebugLibConOut.inf | 1 + .../DebugLibConstructor.c | 23 ++ .../UefiDebugLibDebugPortProtocol.inf | 1 + .../UefiDebugLibStdErr/DebugLibConstructor.c | 23 ++ .../UefiDebugLibStdErr/UefiDebugLibStdErr.inf | 1 + 6 files changed, 72 insertions(+) -- 2.16.2.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44432): https://edk2.groups.io/g/devel/message/44432 Mute This Topic: https://groups.io/mt/32605737/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel][Patch 1/3] MdePkg/UefiDebugLibConOut: Add destructor to CloseEvent
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2012
When driver is unloaded, the ExitBootSerivesEvent must be closed at
the same time. Otherwise exception will occur when ExitBootServices.
Cc: Michael D Kinney
Cc: Liming Gao
Signed-off-by: Wei6 Xu
---
.../UefiDebugLibConOut/DebugLibConstructor.c | 23 ++
.../UefiDebugLibConOut/UefiDebugLibConOut.inf | 1 +
2 files changed, 24 insertions(+)
diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
b/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
index 8005370372..ed73f92818 100644
--- a/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
+++ b/MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c
@@ -73,5 +73,28 @@ DxeDebugLibConstructor(
);
return EFI_SUCCESS;
}
+
+/**
+ The destructor closes Exit Boot Services Event.
+
+ @param ImageHandle The firmware allocated handle for the EFI image.
+ @param SystemTable A pointer to the EFI System Table.
+
+ @retval EFI_SUCCESS The destructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+DxeDebugLibDestructor(
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ if (mExitBootServicesEvent != NULL) {
+SystemTable->BootServices->CloseEvent (mExitBootServicesEvent);
+ }
+
+ return EFI_SUCCESS;
+}
diff --git a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
index 4c279a5bf2..b577d52ac6 100644
--- a/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
+++ b/MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
@@ -20,10 +20,11 @@
MODULE_TYPE= UEFI_DRIVER
VERSION_STRING = 1.0
LIBRARY_CLASS = DebugLib|DXE_CORE DXE_DRIVER
DXE_RUNTIME_DRIVER UEFI_APPLICATION UEFI_DRIVER
CONSTRUCTOR= DxeDebugLibConstructor
+ DESTRUCTOR = DxeDebugLibDestructor
#
# VALID_ARCHITECTURES = IA32 X64 EBC
#
--
2.16.2.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44433): https://edk2.groups.io/g/devel/message/44433
Mute This Topic: https://groups.io/mt/32605738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] CryptoPkg/BaseCryptLib: Wrap OpenSSL HKDF algorithm
Gary, See my comment below. > -Original Message- > From: West, Gary > Sent: Tuesday, July 23, 2019 8:04 PM > To: devel@edk2.groups.io > Cc: West, Gary ; West, Gary ; > Wang, Jian J ; Ye, Ting > Subject: [PATCH 1/1] CryptoPkg/BaseCryptLib: Wrap OpenSSL HKDF > algorithm > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1928 > > 1. Implement OpenSSL HKDF wrapped function in CryptHkdf.c file. > 2. Implement stub implementation function in CryptHkdfNull.c file. > 3. Add wrapped HKDF function declaration to BaseCryptLib.h file. > 4. Add CryptHkdf.c to module information BaseCryptLib.inf file. > 5. Add CryptHkdfNull.c to module information PeiCryptLib.inf, >RuntimeCryptLib.inf and SmmCryptLib.inf > > Signed-off-by: Gary West > Cc: Jian Wang > Cc: Ting Ye > --- > .../Library/BaseCryptLib/BaseCryptLib.inf | 1 + > .../Library/BaseCryptLib/PeiCryptLib.inf | 4 +- > .../Library/BaseCryptLib/RuntimeCryptLib.inf | 1 + > .../Library/BaseCryptLib/SmmCryptLib.inf | 1 + > CryptoPkg/Include/Library/BaseCryptLib.h | 33 > .../Library/BaseCryptLib/Kdf/CryptHkdf.c | 80 +++ > .../Library/BaseCryptLib/Kdf/CryptHkdfNull.c | 43 ++ > 7 files changed, 160 insertions(+), 3 deletions(-) > create mode 100644 CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdf.c > create mode 100644 CryptoPkg/Library/BaseCryptLib/Kdf/CryptHkdfNull.c > > diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > index 020df3c19b3c..8d4988e8c6b4 100644 > --- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > @@ -37,6 +37,7 @@ [Sources] >Hmac/CryptHmacMd5.c >Hmac/CryptHmacSha1.c >Hmac/CryptHmacSha256.c > + Kdf/CryptHkdf.c >Cipher/CryptAes.c >Cipher/CryptTdes.c >Cipher/CryptArc4.c > diff --git a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > index 4c4353747622..d26161d79ae5 100644 > --- a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > @@ -43,10 +43,10 @@ [Sources] >Hmac/CryptHmacMd5Null.c >Hmac/CryptHmacSha1Null.c >Hmac/CryptHmacSha256Null.c > + Kdf/CryptHkdfNull.c >Cipher/CryptAesNull.c >Cipher/CryptTdesNull.c >Cipher/CryptArc4Null.c > - >Pk/CryptRsaBasic.c >Pk/CryptRsaExtNull.c >Pk/CryptPkcs1OaepNull.c > @@ -55,13 +55,11 @@ [Sources] >Pk/CryptPkcs7VerifyCommon.c >Pk/CryptPkcs7VerifyBase.c >Pk/CryptPkcs7VerifyEku.c > - >Pk/CryptDhNull.c >Pk/CryptX509Null.c >Pk/CryptAuthenticodeNull.c >Pk/CryptTsNull.c >Pem/CryptPemNull.c > - >Rand/CryptRandNull.c > >SysCall/CrtWrapper.c > diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > index a59079d99e05..e99c046be29b 100644 > --- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > @@ -42,6 +42,7 @@ [Sources] >Hmac/CryptHmacMd5Null.c >Hmac/CryptHmacSha1Null.c >Hmac/CryptHmacSha256Null.c > + Kdf/CryptHkdfNull.c >Cipher/CryptAesNull.c >Cipher/CryptTdesNull.c >Cipher/CryptArc4Null.c > diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > index 3fd7d65abfca..fc217938825d 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > @@ -42,6 +42,7 @@ [Sources] >Hmac/CryptHmacMd5Null.c >Hmac/CryptHmacSha1Null.c >Hmac/CryptHmacSha256.c > + Kdf/CryptHkdfNull.c >Cipher/CryptAes.c >Cipher/CryptTdesNull.c >Cipher/CryptArc4Null.c > diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h > b/CryptoPkg/Include/Library/BaseCryptLib.h > index 19d1afe3c8c0..da32bb2444fd 100644 > --- a/CryptoPkg/Include/Library/BaseCryptLib.h > +++ b/CryptoPkg/Include/Library/BaseCryptLib.h > @@ -3122,4 +3122,37 @@ RandomBytes ( >IN UINTN Size >); > > +// > = > +//Key Derivation Function Primitive > +// > = > + > +/** > + Derive key data using HMAC-SHA256 based KDF. > + > + @param[in] Key Pointer to the user-supplied key. > + @param[in] KeySize Key size in bytes. > + @param[in] Salt Pointer to the salt(non-secret) value. > + @param[in] SaltSize Salt size in bytes. > + @param[in] Info Pointer to the application specific info. > + @param[in] InfoSize Info size in bytes. > + @param[Out] Out Pointer to buffer to receive hkdf value. > + @param[in] OutSize Size of hkdf bytes to generate. > + > + @retval TRUE Hkdf generated successfully. > + @retval FALSE Hkdf
[edk2-devel] [PATCH] Build Spec:Add Module Arch to BuildRebuild Module Section
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2022 Added arch output to build report so it's easy to tell which arch is being generated. Code change https://bugzilla.tianocore.org/show_bug.cgi?id=2016 will be done.The spec change is also required. Cc: Bob Feng Cc: Liming Gao Signed-off-by: Zhiju.Fan --- 13_build_reports/138_module_section.md | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/13_build_reports/138_module_section.md b/13_build_reports/138_module_section.md index d457c24..6f7edc5 100644 --- a/13_build_reports/138_module_section.md +++ b/13_build_reports/138_module_section.md @@ -38,11 +38,12 @@ sections are listed according to their DSC position. ### 13.8.1 Module Section Summary -This sub-section lists the module basic information: Module name, INF file -path, File GUID, Size, hash value, module build time stamp, module build time -and driver type. +This sub-section lists the module basic information: Module name, Module Arch, +INF file path, File GUID, Size, hash value, module build time stamp, module +build time and driver type. * Module Name : %`BASE_NAME` in INF `[Defines]` section% +* Module Arch : %Architecture of current module% * Module INF Path : %Path of Module INF file% * File GUID : %`FILE_GUID` in INF `[Defines]` section% * Size : %Module EFI image size% @@ -70,6 +71,7 @@ Volume 3 of the PI Specification (Table 3 Defined File Types). >==< Module Summary Module Name:SmbiosDxe +Module Arch:X64 Module INF Path:MdeModule\Universal\SmbiosDxe\SmbiosDxe.inf File GUID: F9D88642-0737-49BC-81B5-6889CD57D9EA Size: 0x7000 (28.00K) @@ -88,6 +90,7 @@ Driver Type:0x7 (DRIVER) >==< Module Summary Module Name:EbcDxe +Module Arch:X64 Module INF Path:MdeModule\Universal\EbcDxe\EbcDxe.inf File GUID: 13AC6DD0-73D0-11D4-B06B-00AA00BD6DE7 Size: 0x9000 (36.00K) -- 2.14.1.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44429): https://edk2.groups.io/g/devel/message/44429 Mute This Topic: https://groups.io/mt/32605502/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=- <>
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
> -Original Message-
> From: Javeed, Ashraf
> Sent: Friday, July 26, 2019 9:47 AM
> To: Laszlo Ersek; devel@edk2.groups.io
> Cc: Kinney, Michael D; Gao, Liming; Ni, Ray; Wu, Hao A
> Subject: RE: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe
> industry standard registers
>
> Hi Laszlo,
> Good catch!
> I shall provide patch V2 with the suggested fix.
>
> Everyone,
> Any other input with this regard?
With Laszlo's comment addressed,
Reviewed-by: Hao A Wu
Best Regards,
Hao Wu
>
> Thanks
> Ashraf
>
>
> > -Original Message-
> > From: Laszlo Ersek
> > Sent: Friday, July 26, 2019 2:51 AM
> > To: devel@edk2.groups.io; Javeed, Ashraf
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Ni, Ray ; Wu, Hao A
> >
> > Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe
> industry
> > standard registers
> >
> > Hi Javeed,
> >
> > On 07/25/19 20:23, Javeed, Ashraf wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > > The following two PCI Capability Structure registers are updated as
> > > per the PCI Base Specification Revision 4:-
> > > (1) The PCI Device capability register
> 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
> > > needs to be upgraded for the PCI features like -
> > > LN system CLS (LnSystemCLS),
> > > 10b Tag completer/requester register fields
> > > (TenBitTagCompleterSupported, TenBitTagRequesterSupported),
> > > Emergency power reduction support and initialization requirement
> > > (EmergencyPowerReductionSupported,
> > > EmergencyPowerReductionInitializationRequired),
> > > and FRS support (FrsSupported ).
> > >
> > > (2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2)
> > needs
> > > to be upgraded for the -
> > > Emergency power reduction request enabling
> > > (EmergencyPowerReductionRequest), and also the 10b Extended Tag
> > > enabling (TenBitTagRequesterEnable).
> > >
> > > The following two are defined as per the PCI Express Base
> > > Specification Revision 2.1:-
> > > (1) Defined macro definitions for all the ranges of Maximum Payload Sizes
> > > and Maximum Read Request Sizes defined
> > >
> > > (2) Defined macro definitions for all the ranges of Completion Timeout
> > > value.
> > >
> > > Signed-off-by: Ashraf Javeed
> > > Cc: Michael D Kinney
> > > Cc: Liming Gao
> > > Cc: Ray Ni
> > > Cc: Hao A Wu
> > > ---
> > > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > > ---
> > > 1 file changed, 36 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > index d4003de74c..e652e77a1e 100644
> > > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > @@ -91,6 +91,24 @@ typedef union {
> > >UINT16 Uint16;
> > > } PCI_REG_PCIE_DEVICE_CONTROL;
> > >
> > > +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > > +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > > +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > > +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define
> > > +PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define
> > PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > > +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define
> > > +PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> > > +
> > > +#define PCIE_MAX_READ_REQ_SIZE_128B0
> > > +#define PCIE_MAX_READ_REQ_SIZE_256B1
> > > +#define PCIE_MAX_READ_REQ_SIZE_512B2
> > > +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > > +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > > +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> > > +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> > > +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> > > +
> > > typedef union {
> > >struct {
> > > UINT16 CorrectableError : 1;
> > > @@ -250,16 +268,30 @@ typedef union {
> > > UINT32 NoRoEnabledPrPrPassing : 1;
> > > UINT32 LtrMechanism : 1;
> > > UINT32 TphCompleter : 2;
> > > -UINT32 Reserved : 4;
> > > +UINT32 LnSystemCLS : 2;
> > > +UINT32 TenBitTagCompleterSupported : 1;
> > > +UINT32 TenBitTagRequesterSupported : 1;
> > > UINT32 Obff : 2;
> > > UINT32 ExtendedFmtField : 1;
> > > UINT32 EndEndTlpPrefix : 1;
> > > UINT32 MaxEndEndTlpPrefixes : 2;
> > > -UINT32 Reserved2 : 8;
> > > +UINT32 EmergencyPowerReductionSupported : 2;
> > > +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> > > +UINT32 Reserved : 4;
> > > +UINT32 FrsSupported : 1;
> >
> > This is risky practice. There could be code "out there" that already uses
> > the
> > Reserved field in place of the named LnSystemCLS,
> > TenBitTagCompleterSupported, TenBitTagRequesterSupported fields.
> >
> > Of course, my point is *not* that we should keep the old Reserved field
> > -- if code uses a field called Reserved, it should be prepared for build
> breakages,
> > when those fields are finally given sensible names.
> >
> > Instead, what is risky is
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Hi Laszlo,
Good catch!
I shall provide patch V2 with the suggested fix.
Everyone,
Any other input with this regard?
Thanks
Ashraf
> -Original Message-
> From: Laszlo Ersek
> Sent: Friday, July 26, 2019 2:51 AM
> To: devel@edk2.groups.io; Javeed, Ashraf
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray ; Wu, Hao A
>
> Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> standard registers
>
> Hi Javeed,
>
> On 07/25/19 20:23, Javeed, Ashraf wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > The following two PCI Capability Structure registers are updated as
> > per the PCI Base Specification Revision 4:-
> > (1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
> > needs to be upgraded for the PCI features like -
> > LN system CLS (LnSystemCLS),
> > 10b Tag completer/requester register fields
> > (TenBitTagCompleterSupported, TenBitTagRequesterSupported),
> > Emergency power reduction support and initialization requirement
> > (EmergencyPowerReductionSupported,
> > EmergencyPowerReductionInitializationRequired),
> > and FRS support (FrsSupported ).
> >
> > (2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2)
> needs
> > to be upgraded for the -
> > Emergency power reduction request enabling
> > (EmergencyPowerReductionRequest), and also the 10b Extended Tag
> > enabling (TenBitTagRequesterEnable).
> >
> > The following two are defined as per the PCI Express Base
> > Specification Revision 2.1:-
> > (1) Defined macro definitions for all the ranges of Maximum Payload Sizes
> > and Maximum Read Request Sizes defined
> >
> > (2) Defined macro definitions for all the ranges of Completion Timeout
> > value.
> >
> > Signed-off-by: Ashraf Javeed
> > Cc: Michael D Kinney
> > Cc: Liming Gao
> > Cc: Ray Ni
> > Cc: Hao A Wu
> > ---
> > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > ---
> > 1 file changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > index d4003de74c..e652e77a1e 100644
> > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > @@ -91,6 +91,24 @@ typedef union {
> >UINT16 Uint16;
> > } PCI_REG_PCIE_DEVICE_CONTROL;
> >
> > +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define
> > +PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define
> PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define
> > +PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> > +
> > +#define PCIE_MAX_READ_REQ_SIZE_128B0
> > +#define PCIE_MAX_READ_REQ_SIZE_256B1
> > +#define PCIE_MAX_READ_REQ_SIZE_512B2
> > +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> > +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> > +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> > +
> > typedef union {
> >struct {
> > UINT16 CorrectableError : 1;
> > @@ -250,16 +268,30 @@ typedef union {
> > UINT32 NoRoEnabledPrPrPassing : 1;
> > UINT32 LtrMechanism : 1;
> > UINT32 TphCompleter : 2;
> > -UINT32 Reserved : 4;
> > +UINT32 LnSystemCLS : 2;
> > +UINT32 TenBitTagCompleterSupported : 1;
> > +UINT32 TenBitTagRequesterSupported : 1;
> > UINT32 Obff : 2;
> > UINT32 ExtendedFmtField : 1;
> > UINT32 EndEndTlpPrefix : 1;
> > UINT32 MaxEndEndTlpPrefixes : 2;
> > -UINT32 Reserved2 : 8;
> > +UINT32 EmergencyPowerReductionSupported : 2;
> > +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> > +UINT32 Reserved : 4;
> > +UINT32 FrsSupported : 1;
>
> This is risky practice. There could be code "out there" that already uses the
> Reserved field in place of the named LnSystemCLS,
> TenBitTagCompleterSupported, TenBitTagRequesterSupported fields.
>
> Of course, my point is *not* that we should keep the old Reserved field
> -- if code uses a field called Reserved, it should be prepared for build
> breakages,
> when those fields are finally given sensible names.
>
> Instead, what is risky is reintroducing the Reserved field with the same name,
> but different meaning. It could silently break code that refers to Reserved.
>
> Thus, in such cases, it's better to locate the highest-numbered Reserved
> field in
> the structure, add one to that number, and introduce Reserved(N+1). This is
> guaranteed to trigger a compilation failure in code that refers to Reserved
> right
> now.
>
> In this particular case (= in structure
> PCI_REG_PCIE_DEVICE_CAPABILITY2), the new field would be "Reserved3".
> The patch should remove Reserved and Reserved2, and add Reserved3.
>
> Thanks
> Laszlo
>
> >} Bits;
> >
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Hi Laszlo, I understand and I have no issues with it. Regards Ashraf > -Original Message- > From: Laszlo Ersek > Sent: Friday, July 26, 2019 3:23 AM > To: devel@edk2.groups.io; Javeed, Ashraf > Cc: Kinney, Michael D ; Gao, Liming > ; Ni, Ray ; Wu, Hao A > > Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > standard registers > > Hello Ashraf, > > On 07/25/19 23:20, Laszlo Ersek wrote: > > Hi Javeed, > > [...] > > Sorry, I didn't mean to address you by surname. > > (I find that the comma notation in names is totally useless. Some people put > surname first, some others given name -- same confusion as without the > comma.) > > I should have looked at your email address -- I know the Intel scheme puts the > given name first. > > Thanks, > Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44427): https://edk2.groups.io/g/devel/message/44427 Mute This Topic: https://groups.io/mt/32555963/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] IntelFsp2Pkg: PeiService pointer not reset to 0 in SecMain
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Chiu, Chasel
> Sent: Thursday, July 25, 2019 11:51 PM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Zeng, Star
>
> Subject: [edk2-devel] [PATCH] IntelFsp2Pkg: PeiService pointer not reset to 0
> in SecMain
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2018
>
> Current FSP SEC_IDT_TABLE structure is not natural aligned:
> typedef struct _SEC_IDT_TABLE {
> EFI_PEI_SERVICES *PeiService;
> UINT64IdtTable[];
> } SEC_IDT_TABLE;
> Compiler will insert DWORD padding between 2 elements and
> GetPeiServicesTablePointer() in early phase then always returns padding
> data from stack, which was not rest to 0 in SecMain.
'rest' -> 'reset'
>
> Solution is to align FSP SEC_IDT_TABLE structure to UefiCpuPkg to have
> UINT64 as PeiService field and rest it to 0.
'rest' to 'reset'
Please correct the typo 'rest' to 'reset' in the commit message.
After that, Reviewed-by: Star Zeng .
Thanks,
Star
>
> Test: Verified on internal platform and booting successfully
> with FSP API mode.
>
> Cc: Nate DeSimone
> Cc: Star Zeng
> Signed-off-by: Chasel Chiu
> ---
> IntelFsp2Pkg/FspSecCore/SecMain.c | 2 +-
> IntelFsp2Pkg/FspSecCore/SecMain.h | 10 --
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.c
> b/IntelFsp2Pkg/FspSecCore/SecMain.c
> index a63d1336e4..7169afc6c7 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecMain.c
> +++ b/IntelFsp2Pkg/FspSecCore/SecMain.c
> @@ -114,7 +114,7 @@ SecStartup (
>// | |
>// | |
>// |---|> TempRamBase
> - IdtTableInStack.PeiService = NULL;
> + IdtTableInStack.PeiService = 0;
>AsmReadIdtr ();
>if (IdtDescriptor.Base == 0) {
> ExceptionHandler = FspGetExceptionHandler(mIdtEntryTemplate);
> diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.h
> b/IntelFsp2Pkg/FspSecCore/SecMain.h
> index 6fb16febab..af7f387960 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecMain.h
> +++ b/IntelFsp2Pkg/FspSecCore/SecMain.h
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2014 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
> @@ -29,7 +29,13 @@ typedef VOID (*PEI_CORE_ENTRY) ( \ );
>
> typedef struct _SEC_IDT_TABLE {
> - EFI_PEI_SERVICES *PeiService;
> + //
> + // Reserved 8 bytes preceding IDT to store EFI_PEI_SERVICES**, since
> + IDT base // address should be 8-byte alignment.
> + // Note: For IA32, only the 4 bytes immediately preceding IDT is used
> + to store // EFI_PEI_SERVICES** //
> + UINT64PeiService;
>UINT64IdtTable[FixedPcdGet8 (PcdFspMaxInterruptSupported)];
> } SEC_IDT_TABLE;
>
> --
> 2.13.3.windows.1
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44426): https://edk2.groups.io/g/devel/message/44426
Mute This Topic: https://groups.io/mt/32599362/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 07/25/2019 6:30pm-7:30pm #cal-reminder
*Reminder:* TianoCore Design Meeting - APAC/NAMO *When:* Thursday, 25 July 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles *Where:* https://zoom.us/j/969264410 View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=460287 ) *Organizer:* Stephano Cetola stephano.cet...@intel.com ( stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO ) *Description:* Topic: *1.* *Edk2 Build Cache Enhancement* (Steven Shi) https://edk2.groups.io/g/devel/files/Designs/2019/0726/Edk2BuildCacheEnhancement-v1.pdf Join Zoom Meeting https://zoom.us/j/969264410 ( https://zoom.us/j/969264410 ) One tap mobile +16465588656,,969264410# US (New York) +17207072699,,969264410# US Dial by your location +1 646 558 8656 US (New York) +1 720 707 2699 US Meeting ID: 969 264 410 Find your local number: https://zoom.us/u/abOtdJckxL -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44425): https://edk2.groups.io/g/devel/message/44425 Mute This Topic: https://groups.io/mt/32604895/21656 Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-non-osi] [PATCH 6/6] Cleanup maintainers, contributions, and licenses
Reviewed-by: Chasel Chiu
> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Friday, July 26, 2019 1:36 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Laszlo Ersek ; Leif
> Lindholm ; Kinney, Michael D
> ; Kubacki, Michael A
> ; Sinha, Ankit ; Chiu,
> Chasel ; Yao, Jiewen ;
> Chaganty, Rangasai V ; Gillispie; Gillispie,
> Thad
> ; Bu; Bu, Daocheng ; Oram;
> Oram, Isaac W ; Sun, Zailiang
> ; Qian, Yi
> Subject: [edk2-non-osi] [PATCH 6/6] Cleanup maintainers, contributions, and
> licenses
>
> - Merged Maintainers.txt from devel-MinPlatform branch with
> Maintainers.txt in master branch and updated to match the maintainers
> in the equivalent edk2-platforms Maintainers.txt
>
> - Removed the old Contributions.txt files
>
> - Updated the Kaby Lake microcode to the new Intel microcode license
> which Intel switched to in 2018
>
> Cc: Andrew Fish
> Cc: Laszlo Ersek
> Cc: Leif Lindholm
> Cc: Michael D Kinney
> Cc: Michael Kubacki
> Cc: Ankit Sinha
> Cc: Chasel Chiu
> Cc: Jiewen Yao
> Cc: Sai Chaganty
> Cc: Gillispie, Thad
> Cc: Bu, Daocheng
> Cc: Oram, Isaac W
> Cc: Zailiang Sun
> Cc: Yi Qian
> Signed-off-by: Nate DeSimone
> ---
> Contributions.txt | 163 -
> Maintainers.txt | 20 ++
> .../KabylakeSiliconBinPkg/Contributions.txt | 218 --
> .../Intel/KabylakeSiliconBinPkg/License.txt | 6 +-
> .../Microcode/IntelMicrocodeLicense.txt | 37 +++
> 5 files changed, 60 insertions(+), 384 deletions(-) delete mode 100644
> Contributions.txt delete mode 100644
> Silicon/Intel/KabylakeSiliconBinPkg/Contributions.txt
> create mode 100644
> Silicon/Intel/KabylakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt
>
> diff --git a/Contributions.txt b/Contributions.txt deleted file mode 100644
> index
> 8cee4e2..000
> --- a/Contributions.txt
> +++ /dev/null
> @@ -1,163 +0,0 @@
> -==
> -= Code Contributions =
> -==
> -
> -To make a contribution to a TianoCore project, follow these steps.
> -1. Create a change description in the format specified below to
> - use in the source control commit log.
> -2. Your commit message must include your "Signed-off-by" signature,
> - and "Contributed-under" message.
> -3. Your "Contributed-under" message explicitly states that the
> - contribution is made under the terms of the specified
> - contribution agreement. Your "Contributed-under" message
> - must include the name of contribution agreement and version.
> - For example: Contributed-under: TianoCore Contribution Agreement 1.0
> - The "TianoCore Contribution Agreement" is included below in
> - this document.
> -4. Submit your code to the TianoCore project using the process
> - that the project documents on its web page. If the process is
> - not documented, then submit the code on development email list
> - for the project.
> -5. Contributions must have an explicit license, and the license must be
> - compatible with the contribution agreement. The license must be
> - available as a License.txt file alongside, or above in the directory
> - tree of, the contributed files.
> -
> -
> -= TianoCore Contribution Agreement 1.1 =
> -
> -
> -INTEL CORPORATION ("INTEL") MAKES AVAILABLE SOFTWARE,
> DOCUMENTATION ("DOCUMENTATION"), -INFORMATION AND/OR OTHER
> MATERIALS FOR USE IN THE TIANOCORE OPEN SOURCE -PROJECT
> (COLLECTIVELY "CONTENT"). USE OF THE CONTENT IS GOVERNED BY THE
> -TERMS AND CONDITIONS OF THIS AGREEMENT BETWEEN YOU AND INTEL
> AND/OR THE -TERMS AND CONDITIONS OF LICENSE AGREEMENTS OR NOTICES
> INDICATED OR -REFERENCED BELOW. BY USING THE CONTENT, YOU AGREE THAT
> YOUR USE OF THE -CONTENT IS GOVERNED BY THIS AGREEMENT AND/OR THE
> TERMS AND CONDITIONS -OF ANY APPLICABLE LICENSE AGREEMENTS OR
> NOTICES INDICATED OR REFERENCED -BELOW. IF YOU DO NOT AGREE TO THE
> TERMS AND CONDITIONS OF THIS -AGREEMENT AND THE TERMS AND
> CONDITIONS OF ANY APPLICABLE LICENSE -AGREEMENTS OR NOTICES
> INDICATED OR REFERENCED BELOW, THEN YOU MAY NOT -USE THE CONTENT.
> -
> -Unless otherwise indicated, all Content (except Documentation) made available
> on the TianoCore -site is provided to you under the terms and conditions of
> the
> BSD -License ("BSD"). A copy of the BSD License is available at
> -http://opensource.org/licenses/bsd-license.php
> -or when applicable, in the associated License.txt file.
> -
> -Unless otherwise indicated, all Documentation made available on the
> -TianoCore site is provided to you under the terms and conditions of the
> -FreeBSD Documentation License ("FreeBSD"). A copy of the BSD License is
> -available at https://www.freebsd.org/copyright/freebsd-doc-license.html or,
> -when applicable, in the associated License.txt file.
> -
> -Certain other content may be made available under other licenses as
> -indicated
> in or
Re: [edk2-devel] [PATCH] IntelFsp2Pkg: PeiService pointer not reset to 0 in SecMain
Reviewed-by: Nate DeSimone
-Original Message-
From: devel@edk2.groups.io On Behalf Of Chiu, Chasel
Sent: Thursday, July 25, 2019 8:51 AM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Zeng, Star
Subject: [edk2-devel] [PATCH] IntelFsp2Pkg: PeiService pointer not reset to 0
in SecMain
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2018
Current FSP SEC_IDT_TABLE structure is not natural aligned:
typedef struct _SEC_IDT_TABLE {
EFI_PEI_SERVICES *PeiService;
UINT64IdtTable[];
} SEC_IDT_TABLE;
Compiler will insert DWORD padding between 2 elements and
GetPeiServicesTablePointer() in early phase then always returns padding data
from stack, which was not rest to 0 in SecMain.
Solution is to align FSP SEC_IDT_TABLE structure to UefiCpuPkg to have UINT64
as PeiService field and rest it to 0.
Test: Verified on internal platform and booting successfully
with FSP API mode.
Cc: Nate DeSimone
Cc: Star Zeng
Signed-off-by: Chasel Chiu
---
IntelFsp2Pkg/FspSecCore/SecMain.c | 2 +- IntelFsp2Pkg/FspSecCore/SecMain.h |
10 --
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.c
b/IntelFsp2Pkg/FspSecCore/SecMain.c
index a63d1336e4..7169afc6c7 100644
--- a/IntelFsp2Pkg/FspSecCore/SecMain.c
+++ b/IntelFsp2Pkg/FspSecCore/SecMain.c
@@ -114,7 +114,7 @@ SecStartup (
// | |
// | |
// |---|> TempRamBase
- IdtTableInStack.PeiService = NULL;
+ IdtTableInStack.PeiService = 0;
AsmReadIdtr ();
if (IdtDescriptor.Base == 0) {
ExceptionHandler = FspGetExceptionHandler(mIdtEntryTemplate);
diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.h
b/IntelFsp2Pkg/FspSecCore/SecMain.h
index 6fb16febab..af7f387960 100644
--- a/IntelFsp2Pkg/FspSecCore/SecMain.h
+++ b/IntelFsp2Pkg/FspSecCore/SecMain.h
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2019, Intel Corporation. All rights
+ reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -29,7 +29,13 @@ typedef VOID (*PEI_CORE_ENTRY) ( \ );
typedef struct _SEC_IDT_TABLE {
- EFI_PEI_SERVICES *PeiService;
+ //
+ // Reserved 8 bytes preceding IDT to store EFI_PEI_SERVICES**, since
+ IDT base // address should be 8-byte alignment.
+ // Note: For IA32, only the 4 bytes immediately preceding IDT is used
+ to store // EFI_PEI_SERVICES** //
+ UINT64PeiService;
UINT64IdtTable[FixedPcdGet8 (PcdFspMaxInterruptSupported)];
} SEC_IDT_TABLE;
--
2.13.3.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44422): https://edk2.groups.io/g/devel/message/44422
Mute This Topic: https://groups.io/mt/32599362/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/2] OvmfPkg/build.sh: use newer '-drive if=pflash' syntax when running qemu
On 07/24/19 03:51, rebe...@bsdio.com wrote: > Specify the firmware to use via the newer '-drive if=pflash' syntax > which allows specifying the raw format and readonly parameters. This > avoids warnings with newer version of QEMU. > > Signed-off-by: Rebecca Cran > --- > OvmfPkg/build.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh > index a2c4eff2a5..e2890ff762 100755 > --- a/OvmfPkg/build.sh > +++ b/OvmfPkg/build.sh > @@ -268,7 +268,7 @@ if [[ "$RUN_QEMU" == "yes" ]]; then >fi >ln -sf $FV_DIR/OVMF.fd $QEMU_FIRMWARE_DIR/bios.bin >if [[ "$ENABLE_FLASH" == "yes" ]]; then > -QEMU_COMMAND="$QEMU_COMMAND -pflash $QEMU_FIRMWARE_DIR/bios.bin" > +QEMU_COMMAND="$QEMU_COMMAND -drive > if=pflash,format=raw,readonly,file=$QEMU_FIRMWARE_DIR/bios.bin" >else > QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR" >fi > I'm late to reviewing the "OvmfPkg/build.sh" patches, but then again, I'm glad that both Jordan and Phil are scrutinizing them :) So I guess, on "OvmfPkg/build.sh" patches, I'll just defer to Jordan and Phil. I appreciate the relief! (ask me about my day... or rather don't...) Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44421): https://edk2.groups.io/g/devel/message/44421 Mute This Topic: https://groups.io/mt/32580104/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Thu, 07/25/2019 5:00pm-5:30pm #cal-reminder
*Reminder:* TianoCore Bug Triage - APAC / NAMO *When:* Thursday, 25 July 2019, 5:00pm to 5:30pm, (GMT-07:00) America/Los Angeles *Where:* https://zoom.us/j/251103409 View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=460284 ) *Organizer:* Stephano Cetola stephano.cet...@intel.com ( stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO ) *Description:* Join Zoom Meeting https://zoom.us/j/251103409 ( https://zoom.us/j/251103409 ) One tap mobile +17207072699,,251103409# US +16465588656,,251103409# US (New York) Dial by your location +1 720 707 2699 US +1 646 558 8656 US (New York) Meeting ID: 251 103 409 Find your local number: https://zoom.us/u/acEIbOAUyA ( https://zoom.us/u/acEIbOAUyA ) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44420): https://edk2.groups.io/g/devel/message/44420 Mute This Topic: https://groups.io/mt/32604367/21656 Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V2 0/6] Support 5-level paging in DXE long mode
Having the vendor name for cpu may cause confusion to customers. AMD customer may found even their code is running in AMD processors Intel/Cpuid.h is still included. It may also be possible that Intel platform code has to include AMD/Cpuid.h. The CPU is different from other hardwares. It is ok that two PCIE cards from different vendors exist in the same platform. But not Ok for CPU. Not sure if I am over concerned. > On Jul 25, 2019, at 11:55 PM, Kinney, Michael D > wrote: > > Ray, > > I prefer to add a Vendor to the path based > on the vendor who published the specification. > Adding the vendor to the path will allow > include files to be added in the future with > clear names. > > The UefiCpuPkg is an example of a poor choice > for the original Cpuid.h file. It should have > been in a vendor specific directory from the > beginning. The AMD one is correct in that > package. > > I would also like to consider moving more of > The ARM and AARCH64 content into MdePkg to help > with package dependencies. > > If we really want only a single directory, > then another option is to add the vendor > name to the include filename. > > Mike > >> -Original Message- >> From: Ni, Ray >> Sent: Wednesday, July 24, 2019 10:40 PM >> To: Kinney, Michael D ; >> devel@edk2.groups.io >> Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- >> level paging in DXE long mode >> >> Mike, >> All the CPUID definitions also applies to AMD >> processors. >> There are two Cpuid.h in UefiCpuPkg today. >> 1. UefiCpuPkg/Include/Register/Cpuid.h >> 2. UefiCpuPkg/Include/Register/Amd/Cpuid.h >> >> The second one contains additional structures needed by >> AMD processor. >> But first one also applies to AMD processor. >> >> Can we just put Cpuid.h under MdePkg/Include/Register/ >> because they are common to both Intel and AMD? >> >> Thanks, >> Ray >> >>> -Original Message- >>> From: Kinney, Michael D >>> Sent: Thursday, July 25, 2019 8:52 AM >>> To: Ni, Ray ; devel@edk2.groups.io; >> Kinney, Michael >>> D >>> Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- >> level paging in DXE >>> long mode >>> >>> Ray, >>> >>> I think the use of Include/Register is good for this >> type of content. >>> But we may need a Vendor directory. >>> >>> The general form would be: >>> >>> Include/Register//.h >>> >>> Since the definitions being discussed here are from >> an Intel public >>> document, perhaps the path should be: >>> >>> Include/Register/Intel/Cpuid.h >>> >>> Thanks, >>> >>> Mike >>> -Original Message- From: Ni, Ray Sent: Wednesday, July 24, 2019 5:46 PM To: Kinney, Michael D ; devel@edk2.groups.io Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- >> level paging in DXE long mode Mike, Are you suggesting that 1. Copy Cpuid.h in MdePkg/Include/IndustryStandard/ >> 2. Change UefiCpuPkg/Include/Register/Cpuid.h to just >> include It looks like a potential issue that there are two >> "Cpuid.h" public header file in different folders. But given the include pattern used: "" VS >> "", the risk people may include wrong file or compilers don't >> know which file to use is zero. Is that what you think? Thanks, Ray > -Original Message- > From: Kinney, Michael D > Sent: Thursday, July 25, 2019 1:23 AM > To: devel@edk2.groups.io; Ni, Ray >> ; Kinney, Michael > D > Subject: RE: [edk2-devel] [PATCH V2 0/6] Support >> 5- level paging in DXE > long mode > > Hi Ray, > > Given that there may be register definitions for other CPUs or devices > added to MdePkg in the future, should an extra directory level be > added? Doing that would break source >> compatibility for existing > components that use #include >> from UefiCpuPkg. We > could keep Cpuid.h in UefiCpuPkg, and it could be >> a #include of the > new Cpuid.h file in the MdePkg in the extended >> path. > > Also, should CpuId.h be included from BaseLib.h inside: > > #if defined (MDE_CPU_IA32) || defined >> (MDE_CPU_X64) > > This would make all CPUID related register definitions available to > components the needs BaseLib to call > AsmCpuId() or AsmCpuIdEx()? > > We could also move the CRx, >> FLAGS/EFLAGS/descriptor structures out of > BaseLib.h into include files that are peers to Cpuid.h and could be > updated based on public spec updates. > > Thanks, > > Mike > >> -Original Message- >> From: devel@edk2.groups.io >> [mailto:devel@edk2.groups.io] On Behalf Of Ni, >> Ray >> Sent: Wednesday, July 24, 2019 3:00 AM >> To: devel@edk2.groups.io >> Subject: [edk2-devel] [PATCH V2 0/6] Support 5- level paging in DXE >> long mode >> >> v2: >> Refined the patch according
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Hello Ashraf, On 07/25/19 23:20, Laszlo Ersek wrote: > Hi Javeed, [...] Sorry, I didn't mean to address you by surname. (I find that the comma notation in names is totally useless. Some people put surname first, some others given name -- same confusion as without the comma.) I should have looked at your email address -- I know the Intel scheme puts the given name first. Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44418): https://edk2.groups.io/g/devel/message/44418 Mute This Topic: https://groups.io/mt/32555963/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Hi Javeed,
On 07/25/19 20:23, Javeed, Ashraf wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> The following two PCI Capability Structure registers are updated as per
> the PCI Base Specification Revision 4:-
> (1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
> needs to be upgraded for the PCI features like -
> LN system CLS (LnSystemCLS),
> 10b Tag completer/requester register fields
> (TenBitTagCompleterSupported, TenBitTagRequesterSupported),
> Emergency power reduction support and initialization requirement
> (EmergencyPowerReductionSupported,
> EmergencyPowerReductionInitializationRequired),
> and FRS support (FrsSupported ).
>
> (2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
> to be upgraded for the -
> Emergency power reduction request enabling
> (EmergencyPowerReductionRequest), and also the 10b Extended Tag
> enabling (TenBitTagRequesterEnable).
>
> The following two are defined as per the PCI Express Base Specification
> Revision 2.1:-
> (1) Defined macro definitions for all the ranges of Maximum Payload Sizes
> and Maximum Read Request Sizes defined
>
> (2) Defined macro definitions for all the ranges of Completion Timeout
> value.
>
> Signed-off-by: Ashraf Javeed
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Hao A Wu
> ---
> MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> ---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index d4003de74c..e652e77a1e 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -91,6 +91,24 @@ typedef union {
>UINT16 Uint16;
> } PCI_REG_PCIE_DEVICE_CONTROL;
>
> +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> +#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> +#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> +
> +#define PCIE_MAX_READ_REQ_SIZE_128B0
> +#define PCIE_MAX_READ_REQ_SIZE_256B1
> +#define PCIE_MAX_READ_REQ_SIZE_512B2
> +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> +
> typedef union {
>struct {
> UINT16 CorrectableError : 1;
> @@ -250,16 +268,30 @@ typedef union {
> UINT32 NoRoEnabledPrPrPassing : 1;
> UINT32 LtrMechanism : 1;
> UINT32 TphCompleter : 2;
> -UINT32 Reserved : 4;
> +UINT32 LnSystemCLS : 2;
> +UINT32 TenBitTagCompleterSupported : 1;
> +UINT32 TenBitTagRequesterSupported : 1;
> UINT32 Obff : 2;
> UINT32 ExtendedFmtField : 1;
> UINT32 EndEndTlpPrefix : 1;
> UINT32 MaxEndEndTlpPrefixes : 2;
> -UINT32 Reserved2 : 8;
> +UINT32 EmergencyPowerReductionSupported : 2;
> +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> +UINT32 Reserved : 4;
> +UINT32 FrsSupported : 1;
This is risky practice. There could be code "out there" that already
uses the Reserved field in place of the named LnSystemCLS,
TenBitTagCompleterSupported, TenBitTagRequesterSupported fields.
Of course, my point is *not* that we should keep the old Reserved field
-- if code uses a field called Reserved, it should be prepared for build
breakages, when those fields are finally given sensible names.
Instead, what is risky is reintroducing the Reserved field with the same
name, but different meaning. It could silently break code that refers to
Reserved.
Thus, in such cases, it's better to locate the highest-numbered Reserved
field in the structure, add one to that number, and introduce
Reserved(N+1). This is guaranteed to trigger a compilation failure in
code that refers to Reserved right now.
In this particular case (= in structure
PCI_REG_PCIE_DEVICE_CAPABILITY2), the new field would be "Reserved3".
The patch should remove Reserved and Reserved2, and add Reserved3.
Thanks
Laszlo
>} Bits;
>UINT32 Uint32;
> } PCI_REG_PCIE_DEVICE_CAPABILITY2;
>
> +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> +
> #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
> #define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
>
Re: [edk2-devel] [edk2-non-osi] [PATCH 6/6] Cleanup maintainers, contributions, and licenses
Hi Nate, On 07/25/19 19:35, Nate DeSimone wrote: > - Merged Maintainers.txt from devel-MinPlatform branch with > Maintainers.txt in master branch and updated to match the maintainers > in the equivalent edk2-platforms Maintainers.txt > > - Removed the old Contributions.txt files > > - Updated the Kaby Lake microcode to the new Intel microcode license > which Intel switched to in 2018 > > Cc: Andrew Fish > Cc: Laszlo Ersek > Cc: Leif Lindholm > Cc: Michael D Kinney > Cc: Michael Kubacki > Cc: Ankit Sinha > Cc: Chasel Chiu > Cc: Jiewen Yao > Cc: Sai Chaganty > Cc: Gillispie, Thad > Cc: Bu, Daocheng > Cc: Oram, Isaac W > Cc: Zailiang Sun > Cc: Yi Qian > Signed-off-by: Nate DeSimone > --- > Contributions.txt | 163 - > Maintainers.txt | 20 ++ > .../KabylakeSiliconBinPkg/Contributions.txt | 218 -- > .../Intel/KabylakeSiliconBinPkg/License.txt | 6 +- > .../Microcode/IntelMicrocodeLicense.txt | 37 +++ > 5 files changed, 60 insertions(+), 384 deletions(-) > delete mode 100644 Contributions.txt > delete mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Contributions.txt > create mode 100644 > Silicon/Intel/KabylakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt I'll defer to the other stewards. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44416): https://edk2.groups.io/g/devel/message/44416 Mute This Topic: https://groups.io/mt/32601187/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 0/4] Arm, ArmPlatform, Crypto, Embedded: list internal headers in [Sources]
On 07/24/19 19:00, Leif Lindholm wrote: > On Wed, Jul 24, 2019 at 03:17:56PM +, Gao, Liming wrote: >>> Would it be feasible to update the --hash functionality to make use of >>> the include dependencies extracted from the source files? (Clearly, we >>> know when the source files change, so we would also know when we would >>> need to re-run the dependency search.) >> >> The design is to save the step to extract the dependencies from the source >> files. >> I can further collect the build performance to be taken on the dependencies >> extraction >> from the source files, and decide whether take this way. Another simple way >> is >> to calculate all source files in module directory and make sure there is no >> file missing for --hash option. >> >>> >>> If not, I think we should make the explicit listing of .h files >>> in .inf mandatory, triggering a build failure when not the case. >>> >>> If it is, then I think we should make it explicitly banned to list .h >>> files in .inf. (If there is no other dependency, such as doxygen, also >>> making use of .inf listings of .h files.) >> >> I know edk2 also has PI Packaging UPT. PI packaging requires all source >> files are listed in module INF file. Otherwise, some source files will be >> missed >> in the packaging, and can't be rollback. > > OK, this means we should update the documentation to be crystal clear > that .h files need to be listed too. > > I am OK to keep the warning enabled for now. But I would also wish > that we start planning for making it an error at some point in the > future. Could you please file a Feature Request for that (i.e. s/warning/error/) in the Bugzilla? Thanks! Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44415): https://edk2.groups.io/g/devel/message/44415 Mute This Topic: https://groups.io/mt/32529014/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Please ignore this!
Sent the patch with wrong commit message details.
Regards
Ashraf
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Javeed,
> Ashraf
> Sent: Thursday, July 25, 2019 11:47 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray ; Wu, Hao A
>
> Subject: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> standard registers
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> The PCIe Device capability register #2 (PCI_REG_PCIE_DEVICE_CAPABILITY2)
> needs to be upgraded for the PCI features like - LN system CLS, 10b Tag
> completer/requester register fields, emergency power reduction support and
> initialization requirement, and FRS support.
>
> The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2) needs
> to be upgraded for the - emergency power reduction request enabling and also
> the 10b Extended Tag enabling.
>
> Needs macro definitions for all the ranges of Maximum Payload Sizes and
> Maximum Read Request Sizes defined
>
> Needs macro definitions for all the ranges of Completion Timeout range needs
> to be defined.
>
> Signed-off-by: Ashraf Javeed
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Hao A Wu
> ---
> MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> ---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index d4003de74c..e652e77a1e 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -91,6 +91,24 @@ typedef union {
>UINT16 Uint16;
> } PCI_REG_PCIE_DEVICE_CONTROL;
>
> +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> +#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> +#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> +
> +#define PCIE_MAX_READ_REQ_SIZE_128B0
> +#define PCIE_MAX_READ_REQ_SIZE_256B1
> +#define PCIE_MAX_READ_REQ_SIZE_512B2
> +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> +
> typedef union {
>struct {
> UINT16 CorrectableError : 1;
> @@ -250,16 +268,30 @@ typedef union {
> UINT32 NoRoEnabledPrPrPassing : 1;
> UINT32 LtrMechanism : 1;
> UINT32 TphCompleter : 2;
> -UINT32 Reserved : 4;
> +UINT32 LnSystemCLS : 2;
> +UINT32 TenBitTagCompleterSupported : 1;
> +UINT32 TenBitTagRequesterSupported : 1;
> UINT32 Obff : 2;
> UINT32 ExtendedFmtField : 1;
> UINT32 EndEndTlpPrefix : 1;
> UINT32 MaxEndEndTlpPrefixes : 2;
> -UINT32 Reserved2 : 8;
> +UINT32 EmergencyPowerReductionSupported : 2;
> +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> +UINT32 Reserved : 4;
> +UINT32 FrsSupported : 1;
>} Bits;
>UINT32 Uint32;
> } PCI_REG_PCIE_DEVICE_CAPABILITY2;
>
> +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> +
> #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
> #define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
>
> @@ -273,7 +305,8 @@ typedef union {
> UINT16 IdoRequest : 1;
> UINT16 IdoCompletion : 1;
> UINT16 LtrMechanism : 2;
> -UINT16 Reserved : 2;
> +UINT16 EmergencyPowerReductionRequest : 1;
> +UINT16 TenBitTagRequesterEnable : 1;
> UINT16 Obff : 2;
> UINT16 EndEndTlpPrefixBlocking : 1;
>} Bits;
> --
> 2.21.0.windows.1
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44413): https://edk2.groups.io/g/devel/message/44413
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
The following two PCI Capability Structure registers are updated as per
the PCI Base Specification Revision 4:-
(1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
needs to be upgraded for the PCI features like -
LN system CLS (LnSystemCLS),
10b Tag completer/requester register fields
(TenBitTagCompleterSupported, TenBitTagRequesterSupported),
Emergency power reduction support and initialization requirement
(EmergencyPowerReductionSupported,
EmergencyPowerReductionInitializationRequired),
and FRS support (FrsSupported ).
(2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
to be upgraded for the -
Emergency power reduction request enabling
(EmergencyPowerReductionRequest), and also the 10b Extended Tag
enabling (TenBitTagRequesterEnable).
The following two are defined as per the PCI Express Base Specification
Revision 2.1:-
(1) Defined macro definitions for all the ranges of Maximum Payload Sizes
and Maximum Read Request Sizes defined
(2) Defined macro definitions for all the ranges of Completion Timeout
value.
Signed-off-by: Ashraf Javeed
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Ray Ni
Cc: Hao A Wu
---
MdePkg/Include/IndustryStandard/PciExpress21.h | 39
---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
b/MdePkg/Include/IndustryStandard/PciExpress21.h
index d4003de74c..e652e77a1e 100644
--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
@@ -91,6 +91,24 @@ typedef union {
UINT16 Uint16;
} PCI_REG_PCIE_DEVICE_CONTROL;
+#define PCIE_MAX_PAYLOAD_SIZE_128B 0
+#define PCIE_MAX_PAYLOAD_SIZE_256B 1
+#define PCIE_MAX_PAYLOAD_SIZE_512B 2
+#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
+#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
+#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
+
+#define PCIE_MAX_READ_REQ_SIZE_128B0
+#define PCIE_MAX_READ_REQ_SIZE_256B1
+#define PCIE_MAX_READ_REQ_SIZE_512B2
+#define PCIE_MAX_READ_REQ_SIZE_1024B 3
+#define PCIE_MAX_READ_REQ_SIZE_2048B 4
+#define PCIE_MAX_READ_REQ_SIZE_4096B 5
+#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
+#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
+
typedef union {
struct {
UINT16 CorrectableError : 1;
@@ -250,16 +268,30 @@ typedef union {
UINT32 NoRoEnabledPrPrPassing : 1;
UINT32 LtrMechanism : 1;
UINT32 TphCompleter : 2;
-UINT32 Reserved : 4;
+UINT32 LnSystemCLS : 2;
+UINT32 TenBitTagCompleterSupported : 1;
+UINT32 TenBitTagRequesterSupported : 1;
UINT32 Obff : 2;
UINT32 ExtendedFmtField : 1;
UINT32 EndEndTlpPrefix : 1;
UINT32 MaxEndEndTlpPrefixes : 2;
-UINT32 Reserved2 : 8;
+UINT32 EmergencyPowerReductionSupported : 2;
+UINT32 EmergencyPowerReductionInitializationRequired : 1;
+UINT32 Reserved : 4;
+UINT32 FrsSupported : 1;
} Bits;
UINT32 Uint32;
} PCI_REG_PCIE_DEVICE_CAPABILITY2;
+#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
+
#define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
#define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
@@ -273,7 +305,8 @@ typedef union {
UINT16 IdoRequest : 1;
UINT16 IdoCompletion : 1;
UINT16 LtrMechanism : 2;
-UINT16 Reserved : 2;
+UINT16 EmergencyPowerReductionRequest : 1;
+UINT16 TenBitTagRequesterEnable : 1;
UINT16 Obff : 2;
UINT16 EndEndTlpPrefixBlocking : 1;
} Bits;
--
2.21.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44414): https://edk2.groups.io/g/devel/message/44414
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
The PCIe Device capability register #2 (PCI_REG_PCIE_DEVICE_CAPABILITY2)
needs to be upgraded for the PCI features like - LN system CLS, 10b Tag
completer/requester register fields, emergency power reduction support
and initialization requirement, and FRS support.
The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2) needs
to be upgraded for the - emergency power reduction request enabling and
also the 10b Extended Tag enabling.
Needs macro definitions for all the ranges of Maximum Payload Sizes and
Maximum Read Request Sizes defined
Needs macro definitions for all the ranges of Completion Timeout range
needs to be defined.
Signed-off-by: Ashraf Javeed
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Ray Ni
Cc: Hao A Wu
---
MdePkg/Include/IndustryStandard/PciExpress21.h | 39
---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
b/MdePkg/Include/IndustryStandard/PciExpress21.h
index d4003de74c..e652e77a1e 100644
--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
@@ -91,6 +91,24 @@ typedef union {
UINT16 Uint16;
} PCI_REG_PCIE_DEVICE_CONTROL;
+#define PCIE_MAX_PAYLOAD_SIZE_128B 0
+#define PCIE_MAX_PAYLOAD_SIZE_256B 1
+#define PCIE_MAX_PAYLOAD_SIZE_512B 2
+#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
+#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
+#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
+
+#define PCIE_MAX_READ_REQ_SIZE_128B0
+#define PCIE_MAX_READ_REQ_SIZE_256B1
+#define PCIE_MAX_READ_REQ_SIZE_512B2
+#define PCIE_MAX_READ_REQ_SIZE_1024B 3
+#define PCIE_MAX_READ_REQ_SIZE_2048B 4
+#define PCIE_MAX_READ_REQ_SIZE_4096B 5
+#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
+#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
+
typedef union {
struct {
UINT16 CorrectableError : 1;
@@ -250,16 +268,30 @@ typedef union {
UINT32 NoRoEnabledPrPrPassing : 1;
UINT32 LtrMechanism : 1;
UINT32 TphCompleter : 2;
-UINT32 Reserved : 4;
+UINT32 LnSystemCLS : 2;
+UINT32 TenBitTagCompleterSupported : 1;
+UINT32 TenBitTagRequesterSupported : 1;
UINT32 Obff : 2;
UINT32 ExtendedFmtField : 1;
UINT32 EndEndTlpPrefix : 1;
UINT32 MaxEndEndTlpPrefixes : 2;
-UINT32 Reserved2 : 8;
+UINT32 EmergencyPowerReductionSupported : 2;
+UINT32 EmergencyPowerReductionInitializationRequired : 1;
+UINT32 Reserved : 4;
+UINT32 FrsSupported : 1;
} Bits;
UINT32 Uint32;
} PCI_REG_PCIE_DEVICE_CAPABILITY2;
+#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
+
#define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
#define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
@@ -273,7 +305,8 @@ typedef union {
UINT16 IdoRequest : 1;
UINT16 IdoCompletion : 1;
UINT16 LtrMechanism : 2;
-UINT16 Reserved : 2;
+UINT16 EmergencyPowerReductionRequest : 1;
+UINT16 TenBitTagRequesterEnable : 1;
UINT16 Obff : 2;
UINT16 EndEndTlpPrefixBlocking : 1;
} Bits;
--
2.21.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44412): https://edk2.groups.io/g/devel/message/44412
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Please ignore this!
I shall amend the commit message, reformat and send the patch again.
Thanks
Ashraf
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Javeed,
> Ashraf
> Sent: Thursday, July 25, 2019 11:28 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray ; Wu, Hao A
>
> Subject: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> standard registers
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> The following two PCI Capability Structure registers are updated as per the
> PCI
> Base Specification Revision 4:-
> (1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
> needs to be upgraded for the PCI features like -
> LN system CLS (LnSystemCLS),
> 10b Tag completer/requester register fields
> (TenBitTagCompleterSupported, TenBitTagRequesterSupported),
> Emergency power reduction support and initialization requirement
> (EmergencyPowerReductionSupported,
> EmergencyPowerReductionInitializationRequired),
> and FRS support (FrsSupported ).
>
> (2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
> to be upgraded for the -
> Emergency power reduction request enabling
> (EmergencyPowerReductionRequest), and also the 10b Extended Tag
> enabling (TenBitTagRequesterEnable).
>
> The following two are defined as per the PCI Express Base Specification
> Revision
> 2.1:-
> (1) Defined macro definitions for all the ranges of Maximum Payload Sizes
> and Maximum Read Request Sizes defined
>
> (2) Defined macro definitions for all the ranges of Completion Timeout
> value.
>
> Signed-off-by: Ashraf Javeed
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Hao A Wu
> ---
> MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> ---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index d4003de74c..e652e77a1e 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -91,6 +91,24 @@ typedef union {
>UINT16 Uint16;
> } PCI_REG_PCIE_DEVICE_CONTROL;
>
> +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> +#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> +#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> +
> +#define PCIE_MAX_READ_REQ_SIZE_128B0
> +#define PCIE_MAX_READ_REQ_SIZE_256B1
> +#define PCIE_MAX_READ_REQ_SIZE_512B2
> +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> +
> typedef union {
>struct {
> UINT16 CorrectableError : 1;
> @@ -250,16 +268,30 @@ typedef union {
> UINT32 NoRoEnabledPrPrPassing : 1;
> UINT32 LtrMechanism : 1;
> UINT32 TphCompleter : 2;
> -UINT32 Reserved : 4;
> +UINT32 LnSystemCLS : 2;
> +UINT32 TenBitTagCompleterSupported : 1;
> +UINT32 TenBitTagRequesterSupported : 1;
> UINT32 Obff : 2;
> UINT32 ExtendedFmtField : 1;
> UINT32 EndEndTlpPrefix : 1;
> UINT32 MaxEndEndTlpPrefixes : 2;
> -UINT32 Reserved2 : 8;
> +UINT32 EmergencyPowerReductionSupported : 2;
> +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> +UINT32 Reserved : 4;
> +UINT32 FrsSupported : 1;
>} Bits;
>UINT32 Uint32;
> } PCI_REG_PCIE_DEVICE_CAPABILITY2;
>
> +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> +
> #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
> #define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
>
> @@ -273,7 +305,8 @@ typedef union {
> UINT16 IdoRequest : 1;
> UINT16 IdoCompletion : 1;
> UINT16 LtrMechanism : 2;
> -UINT16 Reserved : 2;
> +UINT16 EmergencyPowerReductionRequest : 1;
> +UINT16 TenBitTagRequesterEnable : 1;
> UINT16 Obff : 2;
> UINT16 EndEndTlpPrefixBlocking : 1;
>} Bits;
> --
> 2.21.0.windows.1
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44411): https://edk2.groups.io/g/devel/message/44411
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
[edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
The following two PCI Capability Structure registers are updated as per
the PCI Base Specification Revision 4:-
(1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
needs to be upgraded for the PCI features like -
LN system CLS (LnSystemCLS),
10b Tag completer/requester register fields
(TenBitTagCompleterSupported, TenBitTagRequesterSupported),
Emergency power reduction support and initialization requirement
(EmergencyPowerReductionSupported,
EmergencyPowerReductionInitializationRequired),
and FRS support (FrsSupported ).
(2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
to be upgraded for the -
Emergency power reduction request enabling
(EmergencyPowerReductionRequest), and also the 10b Extended Tag
enabling (TenBitTagRequesterEnable).
The following two are defined as per the PCI Express Base Specification
Revision 2.1:-
(1) Defined macro definitions for all the ranges of Maximum Payload Sizes
and Maximum Read Request Sizes defined
(2) Defined macro definitions for all the ranges of Completion Timeout
value.
Signed-off-by: Ashraf Javeed
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Ray Ni
Cc: Hao A Wu
---
MdePkg/Include/IndustryStandard/PciExpress21.h | 39
---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
b/MdePkg/Include/IndustryStandard/PciExpress21.h
index d4003de74c..e652e77a1e 100644
--- a/MdePkg/Include/IndustryStandard/PciExpress21.h
+++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
@@ -91,6 +91,24 @@ typedef union {
UINT16 Uint16;
} PCI_REG_PCIE_DEVICE_CONTROL;
+#define PCIE_MAX_PAYLOAD_SIZE_128B 0
+#define PCIE_MAX_PAYLOAD_SIZE_256B 1
+#define PCIE_MAX_PAYLOAD_SIZE_512B 2
+#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
+#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
+#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
+#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
+
+#define PCIE_MAX_READ_REQ_SIZE_128B0
+#define PCIE_MAX_READ_REQ_SIZE_256B1
+#define PCIE_MAX_READ_REQ_SIZE_512B2
+#define PCIE_MAX_READ_REQ_SIZE_1024B 3
+#define PCIE_MAX_READ_REQ_SIZE_2048B 4
+#define PCIE_MAX_READ_REQ_SIZE_4096B 5
+#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
+#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
+
typedef union {
struct {
UINT16 CorrectableError : 1;
@@ -250,16 +268,30 @@ typedef union {
UINT32 NoRoEnabledPrPrPassing : 1;
UINT32 LtrMechanism : 1;
UINT32 TphCompleter : 2;
-UINT32 Reserved : 4;
+UINT32 LnSystemCLS : 2;
+UINT32 TenBitTagCompleterSupported : 1;
+UINT32 TenBitTagRequesterSupported : 1;
UINT32 Obff : 2;
UINT32 ExtendedFmtField : 1;
UINT32 EndEndTlpPrefix : 1;
UINT32 MaxEndEndTlpPrefixes : 2;
-UINT32 Reserved2 : 8;
+UINT32 EmergencyPowerReductionSupported : 2;
+UINT32 EmergencyPowerReductionInitializationRequired : 1;
+UINT32 Reserved : 4;
+UINT32 FrsSupported : 1;
} Bits;
UINT32 Uint32;
} PCI_REG_PCIE_DEVICE_CAPABILITY2;
+#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
+#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
+#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
+
#define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
#define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
@@ -273,7 +305,8 @@ typedef union {
UINT16 IdoRequest : 1;
UINT16 IdoCompletion : 1;
UINT16 LtrMechanism : 2;
-UINT16 Reserved : 2;
+UINT16 EmergencyPowerReductionRequest : 1;
+UINT16 TenBitTagRequesterEnable : 1;
UINT16 Obff : 2;
UINT16 EndEndTlpPrefixBlocking : 1;
} Bits;
--
2.21.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44410): https://edk2.groups.io/g/devel/message/44410
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-non-osi] [PATCH 2/6] Add new Microcode.
From: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
reviewed-by: Amy Chan
---
.../Microcode/MicrocodeUpdates.inf | 1 +
.../Microcode/mC0806E9_0030.mcb | Bin 0 -> 95232 bytes
2 files changed, 1 insertion(+)
create mode 100644
Silicon/Intel/KabylakeSiliconBinPkg/Microcode/mC0806E9_0030.mcb
diff --git a/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
b/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
index 9e0591e..5673420 100644
--- a/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
+++ b/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
@@ -23,4 +23,5 @@
[Sources]
mC0406E3_00A0.mcb
m80406E8_0026.mcb
+ mC0806E9_0030.mcb
diff --git
a/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/mC0806E9_0030.mcb
b/Silicon/Intel/KabylakeSiliconBinPkg/Microcode/mC0806E9_0030.mcb
new file mode 100644
index
..7398734f4f2439fe35857994ec3e68e125122af5
GIT binary patch
literal 95232
zcmaI6Q;aAK4=p;jZQHhI_Sm*<+qP}nwr$(C^D?ItH@B`fJ_(?0aA00aO4VEB({
z1ejnKU=RRmFqJHT|LOk!IPdhI<@`VO|3|@p5)c6B|H}jZ+=0Kf!8BS1v^pC16=
ze|7#}=>ISHzr6n&7~M9|s3ph($SOiKT{Ng_Kv<>p99drcC_#<`E%kmQ!5R>)f
ztg`El4QBy7i-l|gyvX^$fsJb0%wUbOhVY)W+ZmXwfpl74%x$UWRIS)i1ES;6S^u)xR1B)_6!K=XF
zzi*k~JR@zT+b8MTm@$iUgUZBplxP8-SOm+IPqUl(O~ku}e6esq|A
zgYr13?Hd_y93XVV!)IAHc#WMW!Pbbg{E-{>@(`kNLKAOn_x1k)dC3LMXHKzp`b$89
zJo2RVFff5jXQU9}F{-MyTDJ=$680lw3{t3}-`7Lc-JU+
zNvCf!8Y(L8ngLF@6y!2{U#p|Q4qi$uE`90~X+8RfR^z`6Zjy<2D~JZ!yyvm
[edk2-devel] [edk2-non-osi] [PATCH 6/6] Cleanup maintainers, contributions, and licenses
- Merged Maintainers.txt from devel-MinPlatform branch with
Maintainers.txt in master branch and updated to match the maintainers
in the equivalent edk2-platforms Maintainers.txt
- Removed the old Contributions.txt files
- Updated the Kaby Lake microcode to the new Intel microcode license
which Intel switched to in 2018
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Michael Kubacki
Cc: Ankit Sinha
Cc: Chasel Chiu
Cc: Jiewen Yao
Cc: Sai Chaganty
Cc: Gillispie, Thad
Cc: Bu, Daocheng
Cc: Oram, Isaac W
Cc: Zailiang Sun
Cc: Yi Qian
Signed-off-by: Nate DeSimone
---
Contributions.txt | 163 -
Maintainers.txt | 20 ++
.../KabylakeSiliconBinPkg/Contributions.txt | 218 --
.../Intel/KabylakeSiliconBinPkg/License.txt | 6 +-
.../Microcode/IntelMicrocodeLicense.txt | 37 +++
5 files changed, 60 insertions(+), 384 deletions(-)
delete mode 100644 Contributions.txt
delete mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Contributions.txt
create mode 100644
Silicon/Intel/KabylakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt
diff --git a/Contributions.txt b/Contributions.txt
deleted file mode 100644
index 8cee4e2..000
--- a/Contributions.txt
+++ /dev/null
@@ -1,163 +0,0 @@
-==
-= Code Contributions =
-==
-
-To make a contribution to a TianoCore project, follow these steps.
-1. Create a change description in the format specified below to
- use in the source control commit log.
-2. Your commit message must include your "Signed-off-by" signature,
- and "Contributed-under" message.
-3. Your "Contributed-under" message explicitly states that the
- contribution is made under the terms of the specified
- contribution agreement. Your "Contributed-under" message
- must include the name of contribution agreement and version.
- For example: Contributed-under: TianoCore Contribution Agreement 1.0
- The "TianoCore Contribution Agreement" is included below in
- this document.
-4. Submit your code to the TianoCore project using the process
- that the project documents on its web page. If the process is
- not documented, then submit the code on development email list
- for the project.
-5. Contributions must have an explicit license, and the license must be
- compatible with the contribution agreement. The license must be
- available as a License.txt file alongside, or above in the directory
- tree of, the contributed files.
-
-
-= TianoCore Contribution Agreement 1.1 =
-
-
-INTEL CORPORATION ("INTEL") MAKES AVAILABLE SOFTWARE, DOCUMENTATION
("DOCUMENTATION"),
-INFORMATION AND/OR OTHER MATERIALS FOR USE IN THE TIANOCORE OPEN SOURCE
-PROJECT (COLLECTIVELY "CONTENT"). USE OF THE CONTENT IS GOVERNED BY THE
-TERMS AND CONDITIONS OF THIS AGREEMENT BETWEEN YOU AND INTEL AND/OR THE
-TERMS AND CONDITIONS OF LICENSE AGREEMENTS OR NOTICES INDICATED OR
-REFERENCED BELOW. BY USING THE CONTENT, YOU AGREE THAT YOUR USE OF THE
-CONTENT IS GOVERNED BY THIS AGREEMENT AND/OR THE TERMS AND CONDITIONS
-OF ANY APPLICABLE LICENSE AGREEMENTS OR NOTICES INDICATED OR REFERENCED
-BELOW. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS
-AGREEMENT AND THE TERMS AND CONDITIONS OF ANY APPLICABLE LICENSE
-AGREEMENTS OR NOTICES INDICATED OR REFERENCED BELOW, THEN YOU MAY NOT
-USE THE CONTENT.
-
-Unless otherwise indicated, all Content (except Documentation) made available
on the TianoCore
-site is provided to you under the terms and conditions of the BSD
-License ("BSD"). A copy of the BSD License is available at
-http://opensource.org/licenses/bsd-license.php
-or when applicable, in the associated License.txt file.
-
-Unless otherwise indicated, all Documentation made available on the
-TianoCore site is provided to you under the terms and conditions of the
-FreeBSD Documentation License ("FreeBSD"). A copy of the BSD License is
-available at https://www.freebsd.org/copyright/freebsd-doc-license.html or,
-when applicable, in the associated License.txt file.
-
-Certain other content may be made available under other licenses as
-indicated in or with such Content(for example, in a License.txt file).
-
-You accept and agree to the following terms and conditions for Your
-present and future Contributions submitted to TianoCore site. Except
-for the license granted to Intel hereunder, You reserve all right,
-title, and interest in and to Your Contributions.
-
-== SECTION 1: Definitions ==
-* "You" or "Contributor" shall mean the copyright owner or legal
- entity authorized by the copyright owner that is making a
- Contribution hereunder. All other entities that control, are
- controlled by, or are under common control with that entity are
- considered to be a single Contributor. For the purposes of this
- definition, "control" means (i) the power,
[edk2-devel] [edk2-non-osi] [PATCH 0/6] Merge content from devel-MinPlatform to master
While Minimum Platform development has transferred from devel-MinPlatform branch to master branch on the edk2-platforms repository, this has not yet occurred on the edk2-non-osi repository. This patch series cherry-picks the content from devel-MinPlatform that has not yet been merged to master and updates the maintainers, contributions, and licenses files to account for the new content in master branch. All patches in this series have already been reviewed before, with the exception of PATCH 6. Cc: Andrew Fish Cc: Laszlo Ersek Cc: Leif Lindholm Cc: Michael D Kinney Cc: Michael Kubacki Cc: Ankit Sinha Cc: Chasel Chiu Cc: Jiewen Yao Cc: Sai Chaganty Cc: Gillispie, Thad Cc: Bu, Daocheng Cc: Oram, Isaac W Cc: Zailiang Sun Cc: Yi Qian Jiewen Yao (4): Add KabylakeSiliconBinPkg. Add new Microcode. PurleySiliconBinPkg: Initial version. replace FSP license file. Khalil (1): Added TXT ACMs of release 1.7.1 PW Nate DeSimone (1): Cleanup maintainers, contributions, and licenses Contributions.txt | 163 - Maintainers.txt | 20 + .../Intel/KabylakeSiliconBinPkg/License.txt | 30 + .../Microcode/IntelMicrocodeLicense.txt | 37 + .../Microcode/MicrocodeUpdates.inf| 27 + .../Microcode/m80406E8_0026.mcb | Bin 0 -> 95232 bytes .../Microcode/mC0406E3_00A0.mcb | Bin 0 -> 97280 bytes .../Microcode/mC0806E9_0030.mcb | Bin 0 -> 95232 bytes .../Intel/PurleySiliconBinPkg/FSP_License.pdf | Bin 0 -> 15051 bytes .../FvLateSilicon/DEBUG/FVLATESILICON.Fv | Bin 0 -> 663512 bytes .../FvLateSilicon/DEBUG/FVLATESILICON.Fv.txt | 17 + .../FvLateSilicon/DEBUG/FvLateSilicon.inf | 4021 + .../FvLateSilicon/RELEASE/FVLATESILICON.Fv| Bin 0 -> 429688 bytes .../RELEASE/FVLATESILICON.Fv.txt | 17 + .../FvLateSilicon/RELEASE/FvLateSilicon.inf | 3822 + .../DEBUG/FVPOSTMEMORYSILICON.Fv | Bin 0 -> 196608 bytes .../DEBUG/FVPOSTMEMORYSILICON.Fv.txt |3 + .../DEBUG/FvPostMemorySilicon.inf | 280 + .../RELEASE/FVPOSTMEMORYSILICON.Fv| Bin 0 -> 196608 bytes .../RELEASE/FVPOSTMEMORYSILICON.Fv.txt|3 + .../RELEASE/FvPostMemorySilicon.inf | 268 + .../DEBUG/FVPREMEMORYSILICON.Fv | Bin 0 -> 1245184 bytes .../DEBUG/FVPREMEMORYSILICON.Fv.txt |7 + .../DEBUG/FvPreMemorySilicon.inf | 1099 +++ .../RELEASE/FVPREMEMORYSILICON.Fv | Bin 0 -> 1245184 bytes .../RELEASE/FVPREMEMORYSILICON.Fv.txt |7 + .../RELEASE/FvPreMemorySilicon.inf| 1054 +++ .../DEBUG/FVTEMPMEMORYSILICON.Fv | Bin 0 -> 131072 bytes .../DEBUG/FVTEMPMEMORYSILICON.Fv.txt |4 + .../DEBUG/FvTempMemorySilicon.inf | 267 + .../RELEASE/FVTEMPMEMORYSILICON.Fv| Bin 0 -> 131072 bytes .../RELEASE/FVTEMPMEMORYSILICON.Fv.txt|4 + .../RELEASE/FvTempMemorySilicon.inf | 263 + .../Microcode/Microcode.inf | 25 + .../Microcode/mb750654_0243.inc | 7170 + ..._BIOSACX_v1_7_1_20181204_LBG_PW_signed.bin | Bin 0 -> 262144 bytes ...EY_SINIT_v1_7_2_20190123_LBG_PW_signed.bin | Bin 0 -> 262144 bytes 37 files changed, 18445 insertions(+), 163 deletions(-) delete mode 100644 Contributions.txt create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/License.txt create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Microcode/m80406E8_0026.mcb create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Microcode/mC0406E3_00A0.mcb create mode 100644 Silicon/Intel/KabylakeSiliconBinPkg/Microcode/mC0806E9_0030.mcb create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FSP_License.pdf create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/DEBUG/FVLATESILICON.Fv create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/DEBUG/FVLATESILICON.Fv.txt create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/DEBUG/FvLateSilicon.inf create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/RELEASE/FVLATESILICON.Fv create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/RELEASE/FVLATESILICON.Fv.txt create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvLateSilicon/RELEASE/FvLateSilicon.inf create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvPostMemorySilicon/DEBUG/FVPOSTMEMORYSILICON.Fv create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvPostMemorySilicon/DEBUG/FVPOSTMEMORYSILICON.Fv.txt create mode 100644 Silicon/Intel/PurleySiliconBinPkg/FvPostMemorySilicon/DEBUG/FvPostMemorySilicon.inf create mode 100644
Re: [edk2-devel] [PATCH 2/4] UefiCpuPkg/CpuDxe: Support parsing 5-level page table
On 07/24/19 09:03, Ni, Ray wrote:
>
>
>> -Original Message-
>> From: Laszlo Ersek
>> Sent: Tuesday, July 23, 2019 5:23 PM
>> To: devel@edk2.groups.io; Ni, Ray
>> Cc: Dong, Eric
>> Subject: Re: [edk2-devel] [PATCH 2/4] UefiCpuPkg/CpuDxe: Support parsing
>> 5-level page table
>>
>> On 07/22/19 10:15, Ni, Ray wrote:
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
>>>
>>> Signed-off-by: Ray Ni
>>> Cc: Eric Dong
>>> Cc: Laszlo Ersek
>>> ---
>>> UefiCpuPkg/CpuDxe/CpuPageTable.c | 22 --
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> index c369b44f12..8e959eb2b7 100644
>>> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>>> @@ -1,7 +1,7 @@
>>> /** @file
>>>Page table management support.
>>>
>>> - Copyright (c) 2017, Intel Corporation. All rights reserved.
>>> + Copyright (c) 2017 - 2019, Intel Corporation. All rights
>>> + reserved.
>>>Copyright (c) 2017, AMD Incorporated. All rights reserved.
>>>
>>>SPDX-License-Identifier: BSD-2-Clause-Patent @@ -276,25 +276,43 @@
>>> GetPageTableEntry (
>>>UINTN Index2;
>>>UINTN Index3;
>>>UINTN Index4;
>>> + UINTN Index5;
>>>UINT64*L1PageTable;
>>>UINT64*L2PageTable;
>>>UINT64*L3PageTable;
>>>UINT64*L4PageTable;
>>> + UINT64*L5PageTable;
>>>UINT64AddressEncMask;
>>> + IA32_CR4 Cr4;
>>> + BOOLEAN Enable5LevelPaging;
>>>
>>>ASSERT (PagingContext != NULL);
>>>
>>> + Index5 = ((UINTN)RShiftU64 (Address, 48)) &
>> PAGING_PAE_INDEX_MASK;
>>>Index4 = ((UINTN)RShiftU64 (Address, 39)) &
>> PAGING_PAE_INDEX_MASK;
>>>Index3 = ((UINTN)Address >> 30) & PAGING_PAE_INDEX_MASK;
>>>Index2 = ((UINTN)Address >> 21) & PAGING_PAE_INDEX_MASK;
>>>Index1 = ((UINTN)Address >> 12) & PAGING_PAE_INDEX_MASK;
>>>
>>> + Cr4.UintN = AsmReadCr4 ();
>>> + Enable5LevelPaging = (BOOLEAN) (Cr4.Bits.LA57 == 1);
>>> +
>>>// Make sure AddressEncMask is contained to smallest supported address
>> field.
>>>//
>>>AddressEncMask = PcdGet64 (PcdPteMemoryEncryptionAddressOrMask)
>> &
>>> PAGING_1G_ADDRESS_MASK_64;
>>>
>>>if (PagingContext->MachineType == IMAGE_FILE_MACHINE_X64) {
>>> -L4PageTable = (UINT64 *)(UINTN)PagingContext-
>>> ContextData.X64.PageTableBase;
>>> +if (Enable5LevelPaging) {
>>> + L5PageTable = (UINT64 *)(UINTN)PagingContext-
>>> ContextData.X64.PageTableBase;
>>> + if (L5PageTable[Index5] == 0) {
>>> +*PageAttribute = PageNone;
>>> +return NULL;
>>> + }
>>> +
>>> + L4PageTable = (UINT64 *)(UINTN)(L5PageTable[Index5] &
>> ~AddressEncMask & PAGING_4K_ADDRESS_MASK_64);
>>> +} else {
>>> + L4PageTable = (UINT64 *)(UINTN)PagingContext-
>>> ContextData.X64.PageTableBase;
>>> +}
>>> if (L4PageTable[Index4] == 0) {
>>>*PageAttribute = PageNone;
>>>return NULL;
>>>
>>
>> The patch seems to be a no-op if Enable5LevelPaging is FALSE, so that's good.
>>
>> Questions:
>>
>> (1) Same question as under patch #1: is the CR4 check reliable on AMD
>> processors too?
>
> Replied in 1/4 thread.
>
>>
>> (2) Should we read CR4 (or call CPUID) every time this function is invoked?
>> Can we perform the check at CpuDxe startup, and cache the result?
> It's a good suggestion. Will address it in V2.
>
>
>>
>> (3) Should we consider the PCD (from patch #3) before accessing the
>> hardware (CR4 / CPUID alike)?
> I want to avoid touching PCD in this CPU driver.
> All the information is taken in DxeIpl and pass to CPU driver through
> Cr4.LA57.
Makes sense, thanks.
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44402): https://edk2.groups.io/g/devel/message/44402
Mute This Topic: https://groups.io/mt/32556533/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
New interface added to PCI Platform Protocol / PCI Override Protocol to
retrieve device-specific platform policy for the following PCI standard
features, like Maximum Payload Size (MPS), Maximum Read Request Size
(MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power Management
(ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock
Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO).
New source files added with enhanced definitions are in:
MdePkg/Include/Protocol/PciPlatform2.h,
MdePkg/Include/Protocol/PciOverride2.h
Signed-off-by: Ashraf Javeed
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Ray Ni
---
MdePkg/Include/Protocol/PciOverride2.h | 46
++
MdePkg/Include/Protocol/PciPlatform2.h | 396
MdePkg/MdePkg.dec | 6 ++
3 files changed, 448 insertions(+)
diff --git a/MdePkg/Include/Protocol/PciOverride2.h
b/MdePkg/Include/Protocol/PciOverride2.h
new file mode 100644
index 00..cf452d9f8f
--- /dev/null
+++ b/MdePkg/Include/Protocol/PciOverride2.h
@@ -0,0 +1,46 @@
+/** @file
+ This file declares EFI PCI Override protocol which provides the interface
between
+ the PCI bus driver/PCI Host Bridge Resource Allocation driver and an
implementation's
+ driver to describe the unique features of a platform.
+ This protocol is optional.
+
+ Copyright (c) 2019, 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
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+ @par Revision Reference:
+ This Protocol is defined in UEFI Platform Initialization Specification 1.2
+ Volume 5: Standards
+
+**/
+
+#ifndef _PCI_OVERRIDE2_H_
+#define _PCI_OVERRIDE2_H_
+
+///
+/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with
EFI_PCI_PLATFORM_PROTOCOL
+///
+#include
+
+///
+/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL
+///
+#define EFI_PCI_OVERRIDE2_GUID \
+ { \
+0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, 0x42,
0x47} \
+ }
+
+///
+/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL
+///
+typedef EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2;
+
+
+extern EFI_GUID gEfiPciOverrideProtocol2Guid;
+
+#endif
diff --git a/MdePkg/Include/Protocol/PciPlatform2.h
b/MdePkg/Include/Protocol/PciPlatform2.h
new file mode 100644
index 00..3ff41b7754
--- /dev/null
+++ b/MdePkg/Include/Protocol/PciPlatform2.h
@@ -0,0 +1,396 @@
+/** @file
+ This file declares PCI Platform Protocol that provide the interface between
+ the PCI bus driver/PCI Host Bridge Resource Allocation driver and a
platform-specific
+ driver to describe the unique features of a platform.
+ This protocol is optional.
+
+Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+ @par Revision Reference:
+ This Protocol is defined in UEFI Platform Initialization Specification 1.2
+ Volume 5: Standards
+
+**/
+
+#ifndef _PCI_PLATFORM2_H_
+#define _PCI_PLATFORM2_H_
+
+///
+/// This file must be included because the EFI_PCI_PLATFORM_PROTOCOL2 uses
+/// EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PHASE.
+///
+#include
+
+///
+/// Reuse the existing definition to maintain backward compatibility
+///
+#include
+
+///
+/// Global ID for the EFI_PCI_PLATFORM_PROTOCOL2.
+///
+#define EFI_PCI_PLATFORM_PROTOCOL2_GUID \
+ { \
+0x787b0367, 0xa945, 0x4d60, {0x8d, 0x34, 0xb9, 0xd1, 0x88, 0xd2, 0xd0,
0xb6} \
+ }
+
+///
+/// As per the present definition and specification of this protocol, the major
+/// version is 1, and minor version is 1. Any driver utilizing this protocol
+/// shall use these versions number to maintain the backward compatibility as
+/// per its specification changes in future.
+///
+enum EfiPciPlatformProtocolVersion {
+ EFI_PCI_PLATFORM_PROTOCOL_MAJOR_VERSION = 1,
+
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Yes. I mean highlight those changes bases on PCI Express Base Specification Revision 4.0. Otherwise, I don't know where are they from. Thanks Liming > -Original Message- > From: Javeed, Ashraf > Sent: Friday, July 26, 2019 12:05 AM > To: Gao, Liming ; devel@edk2.groups.io > Cc: Kinney, Michael D ; Ni, Ray > ; Wu, Hao A > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard > registers > > Liming, > The following are the 2 points summarizing the changes as per spec 4, and it > is already part of commit message... > > > > > > The PCIe Device capability register #2 > > > > > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for > > > > > > the PCI features like - LN system CLS, 10b Tag > > > > > > completer/requester register fields, emergency power reduction > > > > > > support and initialization requirement, and > > > > > FRS support. > > > > > > > > > > > > The PCIe Device Control register #2 > > > > > > (PCI_REG_PCIE_DEVICE_CONTROL2) needs to be upgraded for the - > > > > > > emergency power reduction request enabling and also the 10b > > > > > > Extended Tag enabling. > > Thanks > Ashraf > > > -Original Message- > > From: Gao, Liming > > Sent: Thursday, July 25, 2019 9:06 PM > > To: Javeed, Ashraf ; devel@edk2.groups.io > > Cc: Kinney, Michael D ; Ni, Ray > > ; Wu, Hao A > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard > > registers > > > > That make sense. In the commit message, can you update the message to > > describe which change bases on PCI Express Base Specification Revision 4.0? > > > > Thanks > > Liming > > > -Original Message- > > > From: Javeed, Ashraf > > > Sent: Thursday, July 25, 2019 11:30 PM > > > To: Gao, Liming ; devel@edk2.groups.io > > > Cc: Kinney, Michael D ; Ni, Ray > > > ; Wu, Hao A > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > standard registers > > > > > > These new macros definitions define PCI attributes which exist in the > > > PCI Express Base Specification Revision 2.1; hence placing this in the > > PciExpress21.h align with the specification revision. > > > > > > Thanks > > > Ashraf > > > > > > > -Original Message- > > > > From: Gao, Liming > > > > Sent: Thursday, July 25, 2019 8:05 PM > > > > To: Javeed, Ashraf ; devel@edk2.groups.io > > > > Cc: Kinney, Michael D ; Ni, Ray > > > > ; Wu, Hao A > > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > > standard registers > > > > > > > > I agree the structure update in PciExpress21.h. I also see some new > > > > macro definitions. Can they be added to PciExpress40.h, for example: > > > > > > > > #define PCIE_MAX_PAYLOAD_SIZE_128B 0 > > > > #define PCIE_MAX_PAYLOAD_SIZE_256B 1 > > > > #define PCIE_MAX_PAYLOAD_SIZE_512B 2 > > > > #define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define > > > > PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define > > PCIE_MAX_PAYLOAD_SIZE_4096B > > > > 5 #define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define > > > > PCIE_MAX_PAYLOAD_SIZE_RVSD2 7 > > > > > > > > #define PCIE_MAX_READ_REQ_SIZE_128B0 > > > > #define PCIE_MAX_READ_REQ_SIZE_256B1 > > > > #define PCIE_MAX_READ_REQ_SIZE_512B2 > > > > #define PCIE_MAX_READ_REQ_SIZE_1024B 3 > > > > #define PCIE_MAX_READ_REQ_SIZE_2048B 4 > > > > #define PCIE_MAX_READ_REQ_SIZE_4096B 5 > > > > #define PCIE_MAX_READ_REQ_SIZE_RVSD1 6 > > > > #define PCIE_MAX_READ_REQ_SIZE_RVSD2 7 > > > > > > > > Thanks > > > > Liming > > > > > -Original Message- > > > > > From: Javeed, Ashraf > > > > > Sent: Thursday, July 25, 2019 10:24 PM > > > > > To: Gao, Liming ; devel@edk2.groups.io > > > > > Cc: Kinney, Michael D ; Ni, Ray > > > > > ; Wu, Hao A > > > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > > > standard registers > > > > > > > > > > Liming, > > > > > The existing structure are extended in PCI Express Base > > > > > Specification Revision > > > > 4; hence I have made the change in PciExpress21.h. > > > > > > > > > > Thanks > > > > > Ashraf > > > > > > > > > > > -Original Message- > > > > > > From: Gao, Liming > > > > > > Sent: Thursday, July 25, 2019 7:35 PM > > > > > > To: Javeed, Ashraf ; > > > > > > devel@edk2.groups.io > > > > > > Cc: Kinney, Michael D ; Ni, Ray > > > > > > ; Wu, Hao A > > > > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe > > > > > > industry standard registers > > > > > > > > > > > > Ashraf: > > > > > > So, those update base on PCI Express Base Specification > > > > > > Revision 4.0. If new definitions are in version 4.0, they can be > > > > > > added into PciExpress40.h. If the existing structure is > > > > > > extended, they can be kept in > > > > PciExpress21.h. > > > > > > > > > > > > Thanks > > > > > > Liming > > > > > > > -Original Message- > > > > > > > From: Javeed, Ashraf > > > > > > > Sent: Monday, July 22, 2019 2:26 PM > > > > > > > To: devel@edk2.groups.io > > > > > > > Cc: Kinney, Michael D ; Gao,
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Liming, The following are the 2 points summarizing the changes as per spec 4, and it is already part of commit message... > > > > > The PCIe Device capability register #2 > > > > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for > > > > > the PCI features like - LN system CLS, 10b Tag > > > > > completer/requester register fields, emergency power reduction > > > > > support and initialization requirement, and > > > > FRS support. > > > > > > > > > > The PCIe Device Control register #2 > > > > > (PCI_REG_PCIE_DEVICE_CONTROL2) needs to be upgraded for the - > > > > > emergency power reduction request enabling and also the 10b Extended > > > > > Tag enabling. Thanks Ashraf > -Original Message- > From: Gao, Liming > Sent: Thursday, July 25, 2019 9:06 PM > To: Javeed, Ashraf ; devel@edk2.groups.io > Cc: Kinney, Michael D ; Ni, Ray > ; Wu, Hao A > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard > registers > > That make sense. In the commit message, can you update the message to > describe which change bases on PCI Express Base Specification Revision 4.0? > > Thanks > Liming > > -Original Message- > > From: Javeed, Ashraf > > Sent: Thursday, July 25, 2019 11:30 PM > > To: Gao, Liming ; devel@edk2.groups.io > > Cc: Kinney, Michael D ; Ni, Ray > > ; Wu, Hao A > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > standard registers > > > > These new macros definitions define PCI attributes which exist in the > > PCI Express Base Specification Revision 2.1; hence placing this in the > PciExpress21.h align with the specification revision. > > > > Thanks > > Ashraf > > > > > -Original Message- > > > From: Gao, Liming > > > Sent: Thursday, July 25, 2019 8:05 PM > > > To: Javeed, Ashraf ; devel@edk2.groups.io > > > Cc: Kinney, Michael D ; Ni, Ray > > > ; Wu, Hao A > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > standard registers > > > > > > I agree the structure update in PciExpress21.h. I also see some new > > > macro definitions. Can they be added to PciExpress40.h, for example: > > > > > > #define PCIE_MAX_PAYLOAD_SIZE_128B 0 > > > #define PCIE_MAX_PAYLOAD_SIZE_256B 1 > > > #define PCIE_MAX_PAYLOAD_SIZE_512B 2 > > > #define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define > > > PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define > PCIE_MAX_PAYLOAD_SIZE_4096B > > > 5 #define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define > > > PCIE_MAX_PAYLOAD_SIZE_RVSD2 7 > > > > > > #define PCIE_MAX_READ_REQ_SIZE_128B0 > > > #define PCIE_MAX_READ_REQ_SIZE_256B1 > > > #define PCIE_MAX_READ_REQ_SIZE_512B2 > > > #define PCIE_MAX_READ_REQ_SIZE_1024B 3 > > > #define PCIE_MAX_READ_REQ_SIZE_2048B 4 > > > #define PCIE_MAX_READ_REQ_SIZE_4096B 5 > > > #define PCIE_MAX_READ_REQ_SIZE_RVSD1 6 > > > #define PCIE_MAX_READ_REQ_SIZE_RVSD2 7 > > > > > > Thanks > > > Liming > > > > -Original Message- > > > > From: Javeed, Ashraf > > > > Sent: Thursday, July 25, 2019 10:24 PM > > > > To: Gao, Liming ; devel@edk2.groups.io > > > > Cc: Kinney, Michael D ; Ni, Ray > > > > ; Wu, Hao A > > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > > standard registers > > > > > > > > Liming, > > > > The existing structure are extended in PCI Express Base > > > > Specification Revision > > > 4; hence I have made the change in PciExpress21.h. > > > > > > > > Thanks > > > > Ashraf > > > > > > > > > -Original Message- > > > > > From: Gao, Liming > > > > > Sent: Thursday, July 25, 2019 7:35 PM > > > > > To: Javeed, Ashraf ; > > > > > devel@edk2.groups.io > > > > > Cc: Kinney, Michael D ; Ni, Ray > > > > > ; Wu, Hao A > > > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe > > > > > industry standard registers > > > > > > > > > > Ashraf: > > > > > So, those update base on PCI Express Base Specification > > > > > Revision 4.0. If new definitions are in version 4.0, they can be > > > > > added into PciExpress40.h. If the existing structure is > > > > > extended, they can be kept in > > > PciExpress21.h. > > > > > > > > > > Thanks > > > > > Liming > > > > > > -Original Message- > > > > > > From: Javeed, Ashraf > > > > > > Sent: Monday, July 22, 2019 2:26 PM > > > > > > To: devel@edk2.groups.io > > > > > > Cc: Kinney, Michael D ; Gao, > > > > > > Liming ; Ni, Ray ; Wu, > > > > > > Hao A > > > > > > Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry > > > > > > standard registers > > > > > > > > > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007 > > > > > > The PCIe Device capability register #2 > > > > > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for > > > > > > the PCI features like - LN system CLS, 10b Tag > > > > > > completer/requester register fields, emergency power reduction > > > > > > support and initialization requirement, and > > > > > FRS support. > > > > > > > > > > > > The PCIe Device Control register #2 > > > > > >
Re: [edk2-devel] [PATCH V2 0/6] Support 5-level paging in DXE long mode
Ray, I prefer to add a Vendor to the path based on the vendor who published the specification. Adding the vendor to the path will allow include files to be added in the future with clear names. The UefiCpuPkg is an example of a poor choice for the original Cpuid.h file. It should have been in a vendor specific directory from the beginning. The AMD one is correct in that package. I would also like to consider moving more of The ARM and AARCH64 content into MdePkg to help with package dependencies. If we really want only a single directory, then another option is to add the vendor name to the include filename. Mike > -Original Message- > From: Ni, Ray > Sent: Wednesday, July 24, 2019 10:40 PM > To: Kinney, Michael D ; > devel@edk2.groups.io > Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- > level paging in DXE long mode > > Mike, > All the CPUID definitions also applies to AMD > processors. > There are two Cpuid.h in UefiCpuPkg today. > 1. UefiCpuPkg/Include/Register/Cpuid.h > 2. UefiCpuPkg/Include/Register/Amd/Cpuid.h > > The second one contains additional structures needed by > AMD processor. > But first one also applies to AMD processor. > > Can we just put Cpuid.h under MdePkg/Include/Register/ > because they are common to both Intel and AMD? > > Thanks, > Ray > > > -Original Message- > > From: Kinney, Michael D > > Sent: Thursday, July 25, 2019 8:52 AM > > To: Ni, Ray ; devel@edk2.groups.io; > Kinney, Michael > > D > > Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- > level paging in DXE > > long mode > > > > Ray, > > > > I think the use of Include/Register is good for this > type of content. > > But we may need a Vendor directory. > > > > The general form would be: > > > > Include/Register//.h > > > > Since the definitions being discussed here are from > an Intel public > > document, perhaps the path should be: > > > > Include/Register/Intel/Cpuid.h > > > > Thanks, > > > > Mike > > > > > -Original Message- > > > From: Ni, Ray > > > Sent: Wednesday, July 24, 2019 5:46 PM > > > To: Kinney, Michael D ; > > > devel@edk2.groups.io > > > Subject: RE: [edk2-devel] [PATCH V2 0/6] Support 5- > level paging in > > > DXE long mode > > > > > > Mike, > > > Are you suggesting that > > > 1. Copy Cpuid.h in MdePkg/Include/IndustryStandard/ > 2. > > > Change UefiCpuPkg/Include/Register/Cpuid.h to just > include > > > > > > > > > It looks like a potential issue that there are two > "Cpuid.h" public > > > header file in different folders. > > > But given the include pattern used: > > > "" VS > "", the risk > > > people may include wrong file or compilers don't > know which file to > > > use is zero. > > > > > > Is that what you think? > > > > > > Thanks, > > > Ray > > > > > > > -Original Message- > > > > From: Kinney, Michael D > > > > Sent: Thursday, July 25, 2019 1:23 AM > > > > To: devel@edk2.groups.io; Ni, Ray > ; > > > Kinney, Michael > > > > D > > > > Subject: RE: [edk2-devel] [PATCH V2 0/6] Support > 5- > > > level paging in DXE > > > > long mode > > > > > > > > Hi Ray, > > > > > > > > Given that there may be register definitions for > > > other CPUs or devices > > > > added to MdePkg in the future, should an extra > > > directory level be > > > > added? Doing that would break source > compatibility > > > for existing > > > > components that use #include > from > > > UefiCpuPkg. We > > > > could keep Cpuid.h in UefiCpuPkg, and it could be > a > > > #include of the > > > > new Cpuid.h file in the MdePkg in the extended > path. > > > > > > > > Also, should CpuId.h be included from BaseLib.h > > > inside: > > > > > > > > #if defined (MDE_CPU_IA32) || defined > (MDE_CPU_X64) > > > > > > > > This would make all CPUID related register > > > definitions available to > > > > components the needs BaseLib to call > > > > AsmCpuId() or AsmCpuIdEx()? > > > > > > > > We could also move the CRx, > FLAGS/EFLAGS/descriptor > > > structures out of > > > > BaseLib.h into include files that are peers to > > > Cpuid.h and could be > > > > updated based on public spec updates. > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -Original Message- > > > > > From: devel@edk2.groups.io > > > > > [mailto:devel@edk2.groups.io] On Behalf Of Ni, > Ray > > > > > Sent: Wednesday, July 24, 2019 3:00 AM > > > > > To: devel@edk2.groups.io > > > > > Subject: [edk2-devel] [PATCH V2 0/6] Support 5- > > > level paging in DXE > > > > > long mode > > > > > > > > > > v2: > > > > >Refined the patch according to reviewers' > all > > > comments except: > > > > > 0A0h cannot be changed to A0h or build > fails. > > > > >A big change in this patch is Cpuid.h is > moved > > > from UefiCpuPkg to > > > > > MdePkg. > > > > >The move is based on real requirement when > > > certain modules that > > > > > cannot > > > > >depend on UefiCpuPkg but needs to reference > > > structures defined in > > > > > SDM. > > > > > > > > > > Ray Ni (6): > > > > >
[edk2-devel] [PATCH] IntelFsp2Pkg: PeiService pointer not reset to 0 in SecMain
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2018
Current FSP SEC_IDT_TABLE structure is not natural aligned:
typedef struct _SEC_IDT_TABLE {
EFI_PEI_SERVICES *PeiService;
UINT64IdtTable[];
} SEC_IDT_TABLE;
Compiler will insert DWORD padding between 2 elements and
GetPeiServicesTablePointer() in early phase then always
returns padding data from stack, which was not rest to 0
in SecMain.
Solution is to align FSP SEC_IDT_TABLE structure to UefiCpuPkg
to have UINT64 as PeiService field and rest it to 0.
Test: Verified on internal platform and booting successfully
with FSP API mode.
Cc: Nate DeSimone
Cc: Star Zeng
Signed-off-by: Chasel Chiu
---
IntelFsp2Pkg/FspSecCore/SecMain.c | 2 +-
IntelFsp2Pkg/FspSecCore/SecMain.h | 10 --
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.c
b/IntelFsp2Pkg/FspSecCore/SecMain.c
index a63d1336e4..7169afc6c7 100644
--- a/IntelFsp2Pkg/FspSecCore/SecMain.c
+++ b/IntelFsp2Pkg/FspSecCore/SecMain.c
@@ -114,7 +114,7 @@ SecStartup (
// | |
// | |
// |---|> TempRamBase
- IdtTableInStack.PeiService = NULL;
+ IdtTableInStack.PeiService = 0;
AsmReadIdtr ();
if (IdtDescriptor.Base == 0) {
ExceptionHandler = FspGetExceptionHandler(mIdtEntryTemplate);
diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.h
b/IntelFsp2Pkg/FspSecCore/SecMain.h
index 6fb16febab..af7f387960 100644
--- a/IntelFsp2Pkg/FspSecCore/SecMain.h
+++ b/IntelFsp2Pkg/FspSecCore/SecMain.h
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
+ Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
@@ -29,7 +29,13 @@ typedef VOID (*PEI_CORE_ENTRY) ( \
);
typedef struct _SEC_IDT_TABLE {
- EFI_PEI_SERVICES *PeiService;
+ //
+ // Reserved 8 bytes preceding IDT to store EFI_PEI_SERVICES**, since IDT base
+ // address should be 8-byte alignment.
+ // Note: For IA32, only the 4 bytes immediately preceding IDT is used to
store
+ // EFI_PEI_SERVICES**
+ //
+ UINT64PeiService;
UINT64IdtTable[FixedPcdGet8 (PcdFspMaxInterruptSupported)];
} SEC_IDT_TABLE;
--
2.13.3.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44397): https://edk2.groups.io/g/devel/message/44397
Mute This Topic: https://groups.io/mt/32599362/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
V2 is still full patch. It is not the change delta since the first patch. If this patch pass review, it will push. The final push patch should be same to the reviewed patch. Thanks Liming > -Original Message- > From: Javeed, Ashraf > Sent: Thursday, July 25, 2019 11:42 PM > To: Gao, Liming ; devel@edk2.groups.io > Cc: Kinney, Michael D ; Ni, Ray > Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > MdePkg/Protocols: New interface, EFI encodings to PCI Plat > protocol > > Liming, > I meant to create only second patch, I just appended the commit message with > the actual changes details from the previous patch. > > > New interface added to PCI Platform Protocol / PCI Override Protocol > > to retrieve device-specific platform policy for the following PCI > > standard features, like Maximum Payload Size (MPS), Maximum Read > > Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State > > Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, > > Reference Clock Configuration, Extended SYNCH, PTM support, and Completion > > Timeout (CTO). > > New source files added with enhanced definitions are in: > > MdePkg/Include/Protocol/PciPlatform2.h, > > MdePkg/Include/Protocol/PciOverride2.h > > Thanks > Ashraf > > > -Original Message- > > From: Gao, Liming > > Sent: Thursday, July 25, 2019 9:01 PM > > To: devel@edk2.groups.io; Javeed, Ashraf > > Cc: Kinney, Michael D ; Ni, Ray > > > > Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > > > Ashraf: > > V2 is the updated full patch, not patch 2. I think you mean to create > > single > > patch to include all changes instead of create two patches. Right? > > > > Thanks > > Liming > > > -Original Message- > > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > > > Javeed, Ashraf > > > Sent: Thursday, July 25, 2019 10:45 PM > > > To: devel@edk2.groups.io > > > Cc: Kinney, Michael D ; Gao, Liming > > > ; Ni, Ray > > > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > > > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 > > > > > > In V2: Correction made to header sections of source files > > > > > > New interface added to PCI Platform Protocol / PCI Override Protocol > > > to retrieve device-specific platform policy for the following PCI > > > standard features, like Maximum Payload Size (MPS), Maximum Read > > > Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State > > > Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, > > > Reference Clock Configuration, Extended SYNCH, PTM support, and > > Completion Timeout (CTO). > > > New source files added with enhanced definitions are in: > > > MdePkg/Include/Protocol/PciPlatform2.h, > > > MdePkg/Include/Protocol/PciOverride2.h > > > > > > Signed-off-by: Ashraf Javeed > > > Cc: Michael D Kinney > > > Cc: Liming Gao > > > Cc: Ray Ni > > > --- > > > MdePkg/Include/Protocol/PciOverride2.h | 3 --- > > > MdePkg/Include/Protocol/PciPlatform2.h | 5 + > > > 2 files changed, 1 insertion(+), 7 deletions(-) > > > > > > diff --git a/MdePkg/Include/Protocol/PciOverride2.h > > > b/MdePkg/Include/Protocol/PciOverride2.h > > > index cf452d9f8f..a7f541b4c3 100644 > > > --- a/MdePkg/Include/Protocol/PciOverride2.h > > > +++ b/MdePkg/Include/Protocol/PciOverride2.h > > > @@ -13,9 +13,6 @@ > > >THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > > BASIS, > > >WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > > EXPRESS OR IMPLIED. > > > > > > - @par Revision Reference: > > > - This Protocol is defined in UEFI Platform Initialization > > > Specification 1.2 > > > - Volume 5: Standards > > > > > > **/ > > > > > > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h > > > b/MdePkg/Include/Protocol/PciPlatform2.h > > > index 3ff41b7754..717938e68d 100644 > > > --- a/MdePkg/Include/Protocol/PciPlatform2.h > > > +++ b/MdePkg/Include/Protocol/PciPlatform2.h > > > @@ -4,7 +4,7 @@ > > >driver to describe the unique features of a platform. > > >This protocol is optional. > > > > > > -Copyright (c) 2007 - 2019, Intel Corporation. All rights > > > reserved. > > > +Copyright (c) 2019, Intel Corporation. All rights reserved. > > > This program and the accompanying materials are licensed and made > > > available under the terms and conditions of the BSD License that > > > accompanies > > this distribution. > > > The full text of the license may be found at @@ -13,9 +13,6 @@ > > > http://opensource.org/licenses/bsd-license.php. > > > THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > > BASIS, > > > WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > > EXPRESS OR IMPLIED. > > > > > > - @par Revision Reference: > > > - This Protocol is defined in UEFI Platform
Re: [edk2-devel] [PATCH 1/2] OvmfPkg/build.sh: use newer '-drive if=pflash' syntax when running qemu
On 2019-07-24 10:53, Michael D Kinney wrote: > Rebecca, > > If you are interested, I prototyped using a python > script and POSTBUILD statement in the DSC file to > support 'run' targets for OVMF in the following > branch. This potentially allows the same code to > be used for all host OS environments to launch QEMU. > > https://github.com/tianocore/edk2-staging/tree/Bug_1525_FmpDevicePkg_MultipleControllers_V2/OvmfPkg > > https://github.com/tianocore/edk2-staging/blob/Bug_1525_FmpDevicePkg_MultipleControllers_V2/OvmfPkg/PostBuild.py > > https://github.com/tianocore/edk2-staging/blob/Bug_1525_FmpDevicePkg_MultipleControllers_V2/OvmfPkg/Run.py > > Could also be extended to support doing either QEMU or > KVM launch with a -D flag. Thanks. One issue I noticed is that the POSTBUILD line runs "python". Can we use $PYTHON_COMMAND there instead? macOS (and FreeBSD) doesn't install a 'python' symlink, so for macOS you need to run python3 or python3.7 etc., while on FreeBSD we don't have python3 either, so you need to use python3.7. Apart from that, the changes seem to work nicely: the capsules were generated, and when I added 'run' to the build command line, PuTTY opened and QEMU ran. On a related subject, I noticed last week that the build still exits with a return code of 0 if the postbuild step fails: I created https://bugzilla.tianocore.org/show_bug.cgi?id=1977 . - Postbuild Start - TARGET is RELEASE ... Write binary output file /home/bcran/workspace/Build/Vlv2TbltDevicePkg/Capsules//TestCert/MinnowMaxRelease.cap Success cp: MinnowMaxRelease.cap: No such file or directory build.py... : error F008: Postbuild process is not success! - Failed - Build end time: 21:31:38, Jul.12 2019 Build total time: 00:00:02 build returned 0 -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44395): https://edk2.groups.io/g/devel/message/44395 Mute This Topic: https://groups.io/mt/32580104/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
Liming, I meant to create only second patch, I just appended the commit message with the actual changes details from the previous patch. > New interface added to PCI Platform Protocol / PCI Override Protocol > to retrieve device-specific platform policy for the following PCI > standard features, like Maximum Payload Size (MPS), Maximum Read > Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State > Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, > Reference Clock Configuration, Extended SYNCH, PTM support, and Completion > Timeout (CTO). > New source files added with enhanced definitions are in: > MdePkg/Include/Protocol/PciPlatform2.h, > MdePkg/Include/Protocol/PciOverride2.h Thanks Ashraf > -Original Message- > From: Gao, Liming > Sent: Thursday, July 25, 2019 9:01 PM > To: devel@edk2.groups.io; Javeed, Ashraf > Cc: Kinney, Michael D ; Ni, Ray > > Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > Ashraf: > V2 is the updated full patch, not patch 2. I think you mean to create single > patch to include all changes instead of create two patches. Right? > > Thanks > Liming > > -Original Message- > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > > Javeed, Ashraf > > Sent: Thursday, July 25, 2019 10:45 PM > > To: devel@edk2.groups.io > > Cc: Kinney, Michael D ; Gao, Liming > > ; Ni, Ray > > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 > > > > In V2: Correction made to header sections of source files > > > > New interface added to PCI Platform Protocol / PCI Override Protocol > > to retrieve device-specific platform policy for the following PCI > > standard features, like Maximum Payload Size (MPS), Maximum Read > > Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State > > Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, > > Reference Clock Configuration, Extended SYNCH, PTM support, and > Completion Timeout (CTO). > > New source files added with enhanced definitions are in: > > MdePkg/Include/Protocol/PciPlatform2.h, > > MdePkg/Include/Protocol/PciOverride2.h > > > > Signed-off-by: Ashraf Javeed > > Cc: Michael D Kinney > > Cc: Liming Gao > > Cc: Ray Ni > > --- > > MdePkg/Include/Protocol/PciOverride2.h | 3 --- > > MdePkg/Include/Protocol/PciPlatform2.h | 5 + > > 2 files changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/MdePkg/Include/Protocol/PciOverride2.h > > b/MdePkg/Include/Protocol/PciOverride2.h > > index cf452d9f8f..a7f541b4c3 100644 > > --- a/MdePkg/Include/Protocol/PciOverride2.h > > +++ b/MdePkg/Include/Protocol/PciOverride2.h > > @@ -13,9 +13,6 @@ > >THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > >WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > > > > - @par Revision Reference: > > - This Protocol is defined in UEFI Platform Initialization > > Specification 1.2 > > - Volume 5: Standards > > > > **/ > > > > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h > > b/MdePkg/Include/Protocol/PciPlatform2.h > > index 3ff41b7754..717938e68d 100644 > > --- a/MdePkg/Include/Protocol/PciPlatform2.h > > +++ b/MdePkg/Include/Protocol/PciPlatform2.h > > @@ -4,7 +4,7 @@ > >driver to describe the unique features of a platform. > >This protocol is optional. > > > > -Copyright (c) 2007 - 2019, Intel Corporation. All rights > > reserved. > > +Copyright (c) 2019, Intel Corporation. All rights reserved. > > This program and the accompanying materials are licensed and made > > available under the terms and conditions of the BSD License that > > accompanies > this distribution. > > The full text of the license may be found at @@ -13,9 +13,6 @@ > > http://opensource.org/licenses/bsd-license.php. > > THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > > WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > > > > - @par Revision Reference: > > - This Protocol is defined in UEFI Platform Initialization > > Specification 1.2 > > - Volume 5: Standards > > > > **/ > > > > -- > > 2.21.0.windows.1 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44394): https://edk2.groups.io/g/devel/message/44394 Mute This Topic: https://groups.io/mt/32598671/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
That make sense. In the commit message, can you update the message to describe
which change bases on PCI Express Base Specification Revision 4.0?
Thanks
Liming
> -Original Message-
> From: Javeed, Ashraf
> Sent: Thursday, July 25, 2019 11:30 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray
> ; Wu, Hao A
> Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> registers
>
> These new macros definitions define PCI attributes which exist in the PCI
> Express Base Specification Revision 2.1; hence placing this in the
> PciExpress21.h align with the specification revision.
>
> Thanks
> Ashraf
>
> > -Original Message-
> > From: Gao, Liming
> > Sent: Thursday, July 25, 2019 8:05 PM
> > To: Javeed, Ashraf ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Ni, Ray
> > ; Wu, Hao A
> > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> > registers
> >
> > I agree the structure update in PciExpress21.h. I also see some new macro
> > definitions. Can they be added to PciExpress40.h, for example:
> >
> > #define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > #define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > #define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > #define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> > #define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> > #define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > #define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> > #define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> >
> > #define PCIE_MAX_READ_REQ_SIZE_128B0
> > #define PCIE_MAX_READ_REQ_SIZE_256B1
> > #define PCIE_MAX_READ_REQ_SIZE_512B2
> > #define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > #define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > #define PCIE_MAX_READ_REQ_SIZE_4096B 5
> > #define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> > #define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Javeed, Ashraf
> > > Sent: Thursday, July 25, 2019 10:24 PM
> > > To: Gao, Liming ; devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Ni, Ray
> > > ; Wu, Hao A
> > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > > standard registers
> > >
> > > Liming,
> > > The existing structure are extended in PCI Express Base Specification
> > > Revision
> > 4; hence I have made the change in PciExpress21.h.
> > >
> > > Thanks
> > > Ashraf
> > >
> > > > -Original Message-
> > > > From: Gao, Liming
> > > > Sent: Thursday, July 25, 2019 7:35 PM
> > > > To: Javeed, Ashraf ; devel@edk2.groups.io
> > > > Cc: Kinney, Michael D ; Ni, Ray
> > > > ; Wu, Hao A
> > > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > > > standard registers
> > > >
> > > > Ashraf:
> > > > So, those update base on PCI Express Base Specification Revision
> > > > 4.0. If new definitions are in version 4.0, they can be added into
> > > > PciExpress40.h. If the existing structure is extended, they can be kept
> > > > in
> > PciExpress21.h.
> > > >
> > > > Thanks
> > > > Liming
> > > > > -Original Message-
> > > > > From: Javeed, Ashraf
> > > > > Sent: Monday, July 22, 2019 2:26 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Kinney, Michael D ; Gao, Liming
> > > > > ; Ni, Ray ; Wu, Hao A
> > > > >
> > > > > Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > > > > standard registers
> > > > >
> > > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > > > > The PCIe Device capability register #2
> > > > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for the
> > > > > PCI features like - LN system CLS, 10b Tag completer/requester
> > > > > register fields, emergency power reduction support and
> > > > > initialization requirement, and
> > > > FRS support.
> > > > >
> > > > > The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2)
> > > > > needs to be upgraded for the - emergency power reduction request
> > > > > enabling and also the 10b Extended Tag enabling.
> > > > >
> > > > > Needs macro definitions for all the ranges of Maximum Payload
> > > > > Sizes and Maximum Read Request Sizes defined
> > > > >
> > > > > Needs macro definitions for all the ranges of Completion Timeout
> > > > > range needs to be defined.
> > > > >
> > > > > Signed-off-by: Ashraf Javeed
> > > > > Cc: Michael D Kinney
> > > > > Cc: Liming Gao
> > > > > Cc: Ray Ni
> > > > > Cc: Hao A Wu
> > > > > ---
> > > > > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > > > > ---
> > > > > 1 file changed, 36 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > > index d4003de74c..e652e77a1e 100644
> > > > > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > > @@ -91,6 +91,24 @@ typedef union {
> > > > >UINT16 Uint16;
> > > > > } PCI_REG_PCIE_DEVICE_CONTROL;
> > > > >
> >
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
Ashraf: V2 is the updated full patch, not patch 2. I think you mean to create single patch to include all changes instead of create two patches. Right? Thanks Liming > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Javeed, > Ashraf > Sent: Thursday, July 25, 2019 10:45 PM > To: devel@edk2.groups.io > Cc: Kinney, Michael D ; Gao, Liming > ; Ni, Ray > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 > > In V2: Correction made to header sections of source files > > New interface added to PCI Platform Protocol / PCI Override Protocol to > retrieve device-specific platform policy for the following PCI standard > features, like Maximum Payload Size (MPS), Maximum Read Request Size > (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power Management > (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock > Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO). > New source files added with enhanced definitions are in: > MdePkg/Include/Protocol/PciPlatform2.h, > MdePkg/Include/Protocol/PciOverride2.h > > Signed-off-by: Ashraf Javeed > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ray Ni > --- > MdePkg/Include/Protocol/PciOverride2.h | 3 --- > MdePkg/Include/Protocol/PciPlatform2.h | 5 + > 2 files changed, 1 insertion(+), 7 deletions(-) > > diff --git a/MdePkg/Include/Protocol/PciOverride2.h > b/MdePkg/Include/Protocol/PciOverride2.h > index cf452d9f8f..a7f541b4c3 100644 > --- a/MdePkg/Include/Protocol/PciOverride2.h > +++ b/MdePkg/Include/Protocol/PciOverride2.h > @@ -13,9 +13,6 @@ >THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, >WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR > IMPLIED. > > - @par Revision Reference: > - This Protocol is defined in UEFI Platform Initialization Specification 1.2 > - Volume 5: Standards > > **/ > > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h > b/MdePkg/Include/Protocol/PciPlatform2.h > index 3ff41b7754..717938e68d 100644 > --- a/MdePkg/Include/Protocol/PciPlatform2.h > +++ b/MdePkg/Include/Protocol/PciPlatform2.h > @@ -4,7 +4,7 @@ >driver to describe the unique features of a platform. >This protocol is optional. > > -Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > +Copyright (c) 2019, Intel Corporation. All rights reserved. > This program and the accompanying materials are licensed and made available > under > the terms and conditions of the BSD License that accompanies this > distribution. > The full text of the license may be found at > @@ -13,9 +13,6 @@ http://opensource.org/licenses/bsd-license.php. > THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. > > - @par Revision Reference: > - This Protocol is defined in UEFI Platform Initialization Specification 1.2 > - Volume 5: Standards > > **/ > > -- > 2.21.0.windows.1 > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44392): https://edk2.groups.io/g/devel/message/44392 Mute This Topic: https://groups.io/mt/32598671/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
These new macros definitions define PCI attributes which exist in the PCI
Express Base Specification Revision 2.1; hence placing this in the
PciExpress21.h align with the specification revision.
Thanks
Ashraf
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 25, 2019 8:05 PM
> To: Javeed, Ashraf ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray
> ; Wu, Hao A
> Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> registers
>
> I agree the structure update in PciExpress21.h. I also see some new macro
> definitions. Can they be added to PciExpress40.h, for example:
>
> #define PCIE_MAX_PAYLOAD_SIZE_128B 0
> #define PCIE_MAX_PAYLOAD_SIZE_256B 1
> #define PCIE_MAX_PAYLOAD_SIZE_512B 2
> #define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> #define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> #define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> #define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> #define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
>
> #define PCIE_MAX_READ_REQ_SIZE_128B0
> #define PCIE_MAX_READ_REQ_SIZE_256B1
> #define PCIE_MAX_READ_REQ_SIZE_512B2
> #define PCIE_MAX_READ_REQ_SIZE_1024B 3
> #define PCIE_MAX_READ_REQ_SIZE_2048B 4
> #define PCIE_MAX_READ_REQ_SIZE_4096B 5
> #define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> #define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
>
> Thanks
> Liming
> > -Original Message-
> > From: Javeed, Ashraf
> > Sent: Thursday, July 25, 2019 10:24 PM
> > To: Gao, Liming ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Ni, Ray
> > ; Wu, Hao A
> > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > standard registers
> >
> > Liming,
> > The existing structure are extended in PCI Express Base Specification
> > Revision
> 4; hence I have made the change in PciExpress21.h.
> >
> > Thanks
> > Ashraf
> >
> > > -Original Message-
> > > From: Gao, Liming
> > > Sent: Thursday, July 25, 2019 7:35 PM
> > > To: Javeed, Ashraf ; devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Ni, Ray
> > > ; Wu, Hao A
> > > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > > standard registers
> > >
> > > Ashraf:
> > > So, those update base on PCI Express Base Specification Revision
> > > 4.0. If new definitions are in version 4.0, they can be added into
> > > PciExpress40.h. If the existing structure is extended, they can be kept in
> PciExpress21.h.
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: Javeed, Ashraf
> > > > Sent: Monday, July 22, 2019 2:26 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Kinney, Michael D ; Gao, Liming
> > > > ; Ni, Ray ; Wu, Hao A
> > > >
> > > > Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry
> > > > standard registers
> > > >
> > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > > > The PCIe Device capability register #2
> > > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for the
> > > > PCI features like - LN system CLS, 10b Tag completer/requester
> > > > register fields, emergency power reduction support and
> > > > initialization requirement, and
> > > FRS support.
> > > >
> > > > The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2)
> > > > needs to be upgraded for the - emergency power reduction request
> > > > enabling and also the 10b Extended Tag enabling.
> > > >
> > > > Needs macro definitions for all the ranges of Maximum Payload
> > > > Sizes and Maximum Read Request Sizes defined
> > > >
> > > > Needs macro definitions for all the ranges of Completion Timeout
> > > > range needs to be defined.
> > > >
> > > > Signed-off-by: Ashraf Javeed
> > > > Cc: Michael D Kinney
> > > > Cc: Liming Gao
> > > > Cc: Ray Ni
> > > > Cc: Hao A Wu
> > > > ---
> > > > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > > > ---
> > > > 1 file changed, 36 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > index d4003de74c..e652e77a1e 100644
> > > > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > > @@ -91,6 +91,24 @@ typedef union {
> > > >UINT16 Uint16;
> > > > } PCI_REG_PCIE_DEVICE_CONTROL;
> > > >
> > > > +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > > > +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > > > +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > > > +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define
> > > > +PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define
> > > PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > > > +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define
> > > > +PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> > > > +
> > > > +#define PCIE_MAX_READ_REQ_SIZE_128B0
> > > > +#define PCIE_MAX_READ_REQ_SIZE_256B1
> > > > +#define PCIE_MAX_READ_REQ_SIZE_512B2
> > > > +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > > > +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > > > +#define PCIE_MAX_READ_REQ_SIZE_4096B
[edk2-devel] [edk2-platforms: PATCH v2 0/1] Platform/RPi3: Add Debian 10 installation in Systems.md
Sending a v2 that fixes a few typos: "In that is the case" -> "If that is the case" "that you can safely ignore it by selecting" -> "that you can safely ignore by selecting" "prevents the same partition to be remounted" -> "prevents the same partition from being remounted" Pete Batard (1): Platform/RPi3: Add Debian 10 installation in Systems.md Platform/RaspberryPi/RPi3/RPi3.fdf | 2 +- Platform/RaspberryPi/RPi3/Readme.md | 4 +- Platform/RaspberryPi/RPi3/Systems.md | 124 +++- 3 files changed, 123 insertions(+), 7 deletions(-) -- 2.21.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44389): https://edk2.groups.io/g/devel/message/44389 Mute This Topic: https://groups.io/mt/32599163/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms: PATCH v2 1/1] Platform/RPi3: Add Debian 10 installation in Systems.md
This documents the installation of vanilla Debian 10.0 ARM64 (netinst),
which we validated for both Model B and Model B+.
Also fix an erroneous reference in an RPi3.fdf comment.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/RPi3.fdf | 2 +-
Platform/RaspberryPi/RPi3/Readme.md | 4 +-
Platform/RaspberryPi/RPi3/Systems.md | 124 +++-
3 files changed, 123 insertions(+), 7 deletions(-)
diff --git a/Platform/RaspberryPi/RPi3/RPi3.fdf
b/Platform/RaspberryPi/RPi3/RPi3.fdf
index c7c3f7a2ab8c..c62d649834c7 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.fdf
+++ b/Platform/RaspberryPi/RPi3/RPi3.fdf
@@ -300,7 +300,7 @@ [FV.FvMain]
INF Platform/RaspberryPi/$(PLATFORM_NAME)/Drivers/LogoDxe/LogoDxe.inf
#
- # FDT (GUID matches mRaspberryPiFfsFileGuid in RaspberryPiPlatformDxe)
+ # FDT (GUID matches gRaspberryPiFdtFileGuid in FdtDxe)
#
FILE FREEFORM = DF5DA223-1D27-47C3-8D1B-9A41B55A18BC {
SECTION RAW =
Platform/RaspberryPi/$(PLATFORM_NAME)/DeviceTree/bcm2710-rpi-3-b.dtb
diff --git a/Platform/RaspberryPi/RPi3/Readme.md
b/Platform/RaspberryPi/RPi3/Readme.md
index 624f3a8d287a..797da1bab4a9 100644
--- a/Platform/RaspberryPi/RPi3/Readme.md
+++ b/Platform/RaspberryPi/RPi3/Readme.md
@@ -18,8 +18,8 @@ Raspberry Pi is a trademark of the [Raspberry Pi
Foundation](http://www.raspberr
This firmware, that has been validated to compile against the current
[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
-should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as
Windows 10 ARM64
-(full GUI version).
+should be able to boot Linux (Debian, Ubuntu, SUSE), NetBSD, FreeBSD as well
as Windows
+10 ARM64 (full GUI version).
It also provides support for ATF ([Arm Trusted
Platform](https://github.com/ARM-software/arm-trusted-firmware)).
diff --git a/Platform/RaspberryPi/RPi3/Systems.md
b/Platform/RaspberryPi/RPi3/Systems.md
index f6410eb25f0d..4a0c6f3e4de3 100644
--- a/Platform/RaspberryPi/RPi3/Systems.md
+++ b/Platform/RaspberryPi/RPi3/Systems.md
@@ -1,5 +1,125 @@
# Tested Operating Systems
+## Debian
+
+[Debian 10](https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/)
netinst has been
+tested and confirmed to work, both on the Model B and Model B+, including
installation in
+either wired or wireless mode.
+
+Below are steps you can follow to install Debian 10 onto an SD card:
+* Partition the media as MBR and create a ~300 MB partition on it with MBR
type `0x0e`.
+ __Note:__ Make sure that the partition scheme is MBR (not GPT) and the type
`0x0e` (not
+ `0xef` for instance), as the ondie Broadcom bootloader supports neither the
GPT scheme nor
+ the ESP MBR type.
+* Set the partition as active/bootable. This is needed as the Debian partition
manager can
+ not detect it as ESP otherwise, which we need for GRUB installation. If
using `fdisk` on
+ Linux, you can use the `a` command to set a partition as active. On Windows,
you can use
+ `DISKPART` and then type `active` after selecting the relevant disk and
partition.
+* Format the partition as FAT. Here again you should make sure that you use
FAT rather than
+ FAT32 else the Debian partition manager will not detect the partition as
ESP. If you
+ are using Windows `DISKPART` then `format fs=fat quick` should do it. On
Linux, `mkfs.vfat`
+ with the default options should do the same as long as the partition isn't
too large.
+* Copy the UEFI firmware files (`RPI_EFI.fd`, `bootcode.bin`, `fixup.dat` and
`start.elf`)
+ as well as an appropriate `config.txt` onto the FAT partition. If needed you
can download
+ the non UEFI binary files from
https://github.com/raspberrypi/firmware/tree/master/boot.
+* (Optional) If you plan to install through WiFi, you will need to download
relevant non-free
+ WLAN firmware binaries from your WLAN interface (`brcmfmac43430-sdio.txt`
and
+ `brcmfmac43430-sdio.bin` for a Raspberry Pi 3 Model B,
`brcmfmac43455-sdio.txt` and
+ `brcmfmac43455-sdio.bin` for a Raspberry Pi 3 Model B+). You may also want
to obtain the
+ relevant `.clm_blob` (`brcmfmac43430-sdio.clm_blob` or
`brcmfmac43455-sdio.clm_blob`),
+ though wireless networking should work even if you do not provide these
files. Copy these
+ files either at the root of your FAT partition or into a `firmware/`
directory there.
+* Download the latest `debian-##.#.#-arm64-netinst.iso` from
+ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
+* Extract the full content of the ISO onto the FAT partition you created.
+* Insert the media and power up the Raspberry Pi device.
+* On the GRUB menu select `Install` and let the Debian Installer process start.
+ __Note:__ In case anything goes wrong during the install process, you can use
+ Alt-F4 to check the installation log.
+* Select your Language, Country and Keyboard and let the installer proceed
until it reports
+ that `No Common CD-ROM drive was detected.`
+* On `Load
[edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V2] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 In V2: Correction made to header sections of source files New interface added to PCI Platform Protocol / PCI Override Protocol to retrieve device-specific platform policy for the following PCI standard features, like Maximum Payload Size (MPS), Maximum Read Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO). New source files added with enhanced definitions are in: MdePkg/Include/Protocol/PciPlatform2.h, MdePkg/Include/Protocol/PciOverride2.h Signed-off-by: Ashraf Javeed Cc: Michael D Kinney Cc: Liming Gao Cc: Ray Ni --- MdePkg/Include/Protocol/PciOverride2.h | 3 --- MdePkg/Include/Protocol/PciPlatform2.h | 5 + 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/MdePkg/Include/Protocol/PciOverride2.h b/MdePkg/Include/Protocol/PciOverride2.h index cf452d9f8f..a7f541b4c3 100644 --- a/MdePkg/Include/Protocol/PciOverride2.h +++ b/MdePkg/Include/Protocol/PciOverride2.h @@ -13,9 +13,6 @@ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. - @par Revision Reference: - This Protocol is defined in UEFI Platform Initialization Specification 1.2 - Volume 5: Standards **/ diff --git a/MdePkg/Include/Protocol/PciPlatform2.h b/MdePkg/Include/Protocol/PciPlatform2.h index 3ff41b7754..717938e68d 100644 --- a/MdePkg/Include/Protocol/PciPlatform2.h +++ b/MdePkg/Include/Protocol/PciPlatform2.h @@ -4,7 +4,7 @@ driver to describe the unique features of a platform. This protocol is optional. -Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. +Copyright (c) 2019, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License that accompanies this distribution. The full text of the license may be found at @@ -13,9 +13,6 @@ http://opensource.org/licenses/bsd-license.php. THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. - @par Revision Reference: - This Protocol is defined in UEFI Platform Initialization Specification 1.2 - Volume 5: Standards **/ -- 2.21.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44388): https://edk2.groups.io/g/devel/message/44388 Mute This Topic: https://groups.io/mt/32598671/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
I agree the structure update in PciExpress21.h. I also see some new macro
definitions. Can they be added to PciExpress40.h, for example:
#define PCIE_MAX_PAYLOAD_SIZE_128B 0
#define PCIE_MAX_PAYLOAD_SIZE_256B 1
#define PCIE_MAX_PAYLOAD_SIZE_512B 2
#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
#define PCIE_MAX_READ_REQ_SIZE_128B0
#define PCIE_MAX_READ_REQ_SIZE_256B1
#define PCIE_MAX_READ_REQ_SIZE_512B2
#define PCIE_MAX_READ_REQ_SIZE_1024B 3
#define PCIE_MAX_READ_REQ_SIZE_2048B 4
#define PCIE_MAX_READ_REQ_SIZE_4096B 5
#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
Thanks
Liming
> -Original Message-
> From: Javeed, Ashraf
> Sent: Thursday, July 25, 2019 10:24 PM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray
> ; Wu, Hao A
> Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> registers
>
> Liming,
> The existing structure are extended in PCI Express Base Specification
> Revision 4; hence I have made the change in PciExpress21.h.
>
> Thanks
> Ashraf
>
> > -Original Message-
> > From: Gao, Liming
> > Sent: Thursday, July 25, 2019 7:35 PM
> > To: Javeed, Ashraf ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Ni, Ray
> > ; Wu, Hao A
> > Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> > registers
> >
> > Ashraf:
> > So, those update base on PCI Express Base Specification Revision 4.0. If
> > new
> > definitions are in version 4.0, they can be added into PciExpress40.h. If
> > the
> > existing structure is extended, they can be kept in PciExpress21.h.
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Javeed, Ashraf
> > > Sent: Monday, July 22, 2019 2:26 PM
> > > To: devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Gao, Liming
> > > ; Ni, Ray ; Wu, Hao A
> > >
> > > Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> > > registers
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > > The PCIe Device capability register #2
> > > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for the PCI
> > > features like - LN system CLS, 10b Tag completer/requester register
> > > fields, emergency power reduction support and initialization
> > > requirement, and
> > FRS support.
> > >
> > > The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2)
> > > needs to be upgraded for the - emergency power reduction request
> > > enabling and also the 10b Extended Tag enabling.
> > >
> > > Needs macro definitions for all the ranges of Maximum Payload Sizes
> > > and Maximum Read Request Sizes defined
> > >
> > > Needs macro definitions for all the ranges of Completion Timeout range
> > > needs to be defined.
> > >
> > > Signed-off-by: Ashraf Javeed
> > > Cc: Michael D Kinney
> > > Cc: Liming Gao
> > > Cc: Ray Ni
> > > Cc: Hao A Wu
> > > ---
> > > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > > ---
> > > 1 file changed, 36 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > index d4003de74c..e652e77a1e 100644
> > > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > > @@ -91,6 +91,24 @@ typedef union {
> > >UINT16 Uint16;
> > > } PCI_REG_PCIE_DEVICE_CONTROL;
> > >
> > > +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > > +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > > +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > > +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define
> > > +PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define
> > PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > > +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define
> > > +PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> > > +
> > > +#define PCIE_MAX_READ_REQ_SIZE_128B0
> > > +#define PCIE_MAX_READ_REQ_SIZE_256B1
> > > +#define PCIE_MAX_READ_REQ_SIZE_512B2
> > > +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > > +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > > +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> > > +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> > > +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> > > +
> > > typedef union {
> > >struct {
> > > UINT16 CorrectableError : 1;
> > > @@ -250,16 +268,30 @@ typedef union {
> > > UINT32 NoRoEnabledPrPrPassing : 1;
> > > UINT32 LtrMechanism : 1;
> > > UINT32 TphCompleter : 2;
> > > -UINT32 Reserved : 4;
> > > +UINT32 LnSystemCLS : 2;
> > > +UINT32 TenBitTagCompleterSupported : 1;
> > > +UINT32 TenBitTagRequesterSupported : 1;
> > > UINT32 Obff : 2;
> > > UINT32 ExtendedFmtField : 1;
> > > UINT32 EndEndTlpPrefix : 1;
> > > UINT32 MaxEndEndTlpPrefixes : 2;
> > > -UINT32 Reserved2 : 8;
> >
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Liming,
The existing structure are extended in PCI Express Base Specification Revision
4; hence I have made the change in PciExpress21.h.
Thanks
Ashraf
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 25, 2019 7:35 PM
> To: Javeed, Ashraf ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray
> ; Wu, Hao A
> Subject: RE: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> registers
>
> Ashraf:
> So, those update base on PCI Express Base Specification Revision 4.0. If new
> definitions are in version 4.0, they can be added into PciExpress40.h. If the
> existing structure is extended, they can be kept in PciExpress21.h.
>
> Thanks
> Liming
> > -Original Message-
> > From: Javeed, Ashraf
> > Sent: Monday, July 22, 2019 2:26 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Ni, Ray ; Wu, Hao A
> >
> > Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> > registers
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> > The PCIe Device capability register #2
> > (PCI_REG_PCIE_DEVICE_CAPABILITY2) needs to be upgraded for the PCI
> > features like - LN system CLS, 10b Tag completer/requester register
> > fields, emergency power reduction support and initialization requirement,
> > and
> FRS support.
> >
> > The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2)
> > needs to be upgraded for the - emergency power reduction request
> > enabling and also the 10b Extended Tag enabling.
> >
> > Needs macro definitions for all the ranges of Maximum Payload Sizes
> > and Maximum Read Request Sizes defined
> >
> > Needs macro definitions for all the ranges of Completion Timeout range
> > needs to be defined.
> >
> > Signed-off-by: Ashraf Javeed
> > Cc: Michael D Kinney
> > Cc: Liming Gao
> > Cc: Ray Ni
> > Cc: Hao A Wu
> > ---
> > MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> > ---
> > 1 file changed, 36 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > index d4003de74c..e652e77a1e 100644
> > --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> > +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> > @@ -91,6 +91,24 @@ typedef union {
> >UINT16 Uint16;
> > } PCI_REG_PCIE_DEVICE_CONTROL;
> >
> > +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> > +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> > +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> > +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3 #define
> > +PCIE_MAX_PAYLOAD_SIZE_2048B 4 #define
> PCIE_MAX_PAYLOAD_SIZE_4096B 5
> > +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6 #define
> > +PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> > +
> > +#define PCIE_MAX_READ_REQ_SIZE_128B0
> > +#define PCIE_MAX_READ_REQ_SIZE_256B1
> > +#define PCIE_MAX_READ_REQ_SIZE_512B2
> > +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> > +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> > +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> > +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> > +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> > +
> > typedef union {
> >struct {
> > UINT16 CorrectableError : 1;
> > @@ -250,16 +268,30 @@ typedef union {
> > UINT32 NoRoEnabledPrPrPassing : 1;
> > UINT32 LtrMechanism : 1;
> > UINT32 TphCompleter : 2;
> > -UINT32 Reserved : 4;
> > +UINT32 LnSystemCLS : 2;
> > +UINT32 TenBitTagCompleterSupported : 1;
> > +UINT32 TenBitTagRequesterSupported : 1;
> > UINT32 Obff : 2;
> > UINT32 ExtendedFmtField : 1;
> > UINT32 EndEndTlpPrefix : 1;
> > UINT32 MaxEndEndTlpPrefixes : 2;
> > -UINT32 Reserved2 : 8;
> > +UINT32 EmergencyPowerReductionSupported : 2;
> > +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> > +UINT32 Reserved : 4;
> > +UINT32 FrsSupported : 1;
> >} Bits;
> >UINT32 Uint32;
> > } PCI_REG_PCIE_DEVICE_CAPABILITY2;
> >
> > +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
> > +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> > +
> > #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
> > #define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
> >
> > @@ -273,7 +305,8 @@ typedef union {
> > UINT16 IdoRequest : 1;
> > UINT16 IdoCompletion : 1;
> > UINT16 LtrMechanism : 2;
> > -UINT16 Reserved : 2;
> > +UINT16 EmergencyPowerReductionRequest : 1;
> > +UINT16 TenBitTagRequesterEnable : 1;
> > UINT16 Obff : 2;
> > UINT16 EndEndTlpPrefixBlocking : 1;
> >} Bits;
> > --
> > 2.21.0.windows.1
Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Ashraf:
So, those update base on PCI Express Base Specification Revision 4.0. If new
definitions are in version 4.0, they can be added into PciExpress40.h. If the
existing structure is extended, they can be kept in PciExpress21.h.
Thanks
Liming
> -Original Message-
> From: Javeed, Ashraf
> Sent: Monday, July 22, 2019 2:26 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray ; Wu, Hao A
>
> Subject: [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard
> registers
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> The PCIe Device capability register #2 (PCI_REG_PCIE_DEVICE_CAPABILITY2)
> needs to be upgraded for the PCI features like - LN system CLS, 10b Tag
> completer/requester register fields, emergency power reduction support
> and initialization requirement, and FRS support.
>
> The PCIe Device Control register #2 (PCI_REG_PCIE_DEVICE_CONTROL2) needs
> to be upgraded for the - emergency power reduction request enabling and
> also the 10b Extended Tag enabling.
>
> Needs macro definitions for all the ranges of Maximum Payload Sizes and
> Maximum Read Request Sizes defined
>
> Needs macro definitions for all the ranges of Completion Timeout range
> needs to be defined.
>
> Signed-off-by: Ashraf Javeed
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Hao A Wu
> ---
> MdePkg/Include/IndustryStandard/PciExpress21.h | 39
> ---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h
> b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index d4003de74c..e652e77a1e 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -91,6 +91,24 @@ typedef union {
>UINT16 Uint16;
> } PCI_REG_PCIE_DEVICE_CONTROL;
>
> +#define PCIE_MAX_PAYLOAD_SIZE_128B 0
> +#define PCIE_MAX_PAYLOAD_SIZE_256B 1
> +#define PCIE_MAX_PAYLOAD_SIZE_512B 2
> +#define PCIE_MAX_PAYLOAD_SIZE_1024B 3
> +#define PCIE_MAX_PAYLOAD_SIZE_2048B 4
> +#define PCIE_MAX_PAYLOAD_SIZE_4096B 5
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1 6
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD2 7
> +
> +#define PCIE_MAX_READ_REQ_SIZE_128B0
> +#define PCIE_MAX_READ_REQ_SIZE_256B1
> +#define PCIE_MAX_READ_REQ_SIZE_512B2
> +#define PCIE_MAX_READ_REQ_SIZE_1024B 3
> +#define PCIE_MAX_READ_REQ_SIZE_2048B 4
> +#define PCIE_MAX_READ_REQ_SIZE_4096B 5
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD1 6
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD2 7
> +
> typedef union {
>struct {
> UINT16 CorrectableError : 1;
> @@ -250,16 +268,30 @@ typedef union {
> UINT32 NoRoEnabledPrPrPassing : 1;
> UINT32 LtrMechanism : 1;
> UINT32 TphCompleter : 2;
> -UINT32 Reserved : 4;
> +UINT32 LnSystemCLS : 2;
> +UINT32 TenBitTagCompleterSupported : 1;
> +UINT32 TenBitTagRequesterSupported : 1;
> UINT32 Obff : 2;
> UINT32 ExtendedFmtField : 1;
> UINT32 EndEndTlpPrefix : 1;
> UINT32 MaxEndEndTlpPrefixes : 2;
> -UINT32 Reserved2 : 8;
> +UINT32 EmergencyPowerReductionSupported : 2;
> +UINT32 EmergencyPowerReductionInitializationRequired : 1;
> +UINT32 Reserved : 4;
> +UINT32 FrsSupported : 1;
>} Bits;
>UINT32 Uint32;
> } PCI_REG_PCIE_DEVICE_CAPABILITY2;
>
> +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED 0
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED 1
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED 2
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED 3
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED 6
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED 7
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED 14
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> +
> #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
> #define PCIE_DEVICE_CAPABILITY_OBFF_WAKEBIT1
>
> @@ -273,7 +305,8 @@ typedef union {
> UINT16 IdoRequest : 1;
> UINT16 IdoCompletion : 1;
> UINT16 LtrMechanism : 2;
> -UINT16 Reserved : 2;
> +UINT16 EmergencyPowerReductionRequest : 1;
> +UINT16 TenBitTagRequesterEnable : 1;
> UINT16 Obff : 2;
> UINT16 EndEndTlpPrefixBlocking : 1;
>} Bits;
> --
> 2.21.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44385): https://edk2.groups.io/g/devel/message/44385
Mute This Topic: https://groups.io/mt/32555963/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
Sure Liming!
Thanks
Ashraf
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 25, 2019 7:15 PM
> To: devel@edk2.groups.io; Javeed, Ashraf
> Cc: Kinney, Michael D ; Ni, Ray
>
> Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH]
> MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
>
> Ashraf:
> These two protocols are new added. They are not defined in current PI spec.
> Can you update file header to remove below comments?
>
> > + This Protocol is defined in UEFI Platform Initialization
> > + Specification 1.2 Volume 5: Standards
>
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Javeed, Ashraf
> > Sent: Friday, July 19, 2019 11:00 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Ni, Ray
> > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH]
> > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> > New interface added to PCI Platform Protocol / PCI Override Protocol
> > to retrieve device-specific platform policy for the following PCI
> > standard features, like Maximum Payload Size (MPS), Maximum Read
> > Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State
> > Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp,
> > Reference Clock Configuration, Extended SYNCH, PTM support, and
> Completion Timeout (CTO).
> > New source files added with enhanced definitions are in:
> > MdePkg/Include/Protocol/PciPlatform2.h,
> > MdePkg/Include/Protocol/PciOverride2.h
> >
> > Repository:
> > https://github.com/ashrafj/edk2-staging/tree/UEFI_PCI_ENHANCE-2
> >
> > Signed-off-by: Ashraf Javeed
> > Cc: Michael D Kinney
> > Cc: Liming Gao
> > Cc: Ray Ni
> > ---
> > MdePkg/Include/Protocol/PciOverride2.h | 46
> > ++
> > MdePkg/Include/Protocol/PciPlatform2.h | 396
> >
> +
> +
> >
> +
> +
> >
> +
> +
> > ++
> > MdePkg/MdePkg.dec | 6 ++
> > 3 files changed, 448 insertions(+)
> >
> > diff --git a/MdePkg/Include/Protocol/PciOverride2.h
> > b/MdePkg/Include/Protocol/PciOverride2.h
> > new file mode 100644
> > index 00..cf452d9f8f
> > --- /dev/null
> > +++ b/MdePkg/Include/Protocol/PciOverride2.h
> > @@ -0,0 +1,46 @@
> > +/** @file
> > + This file declares EFI PCI Override protocol which provides the
> > +interface between
> > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and
> > +an implementation's
> > + driver to describe the unique features of a platform.
> > + This protocol is optional.
> > +
> > + Copyright (c) 2019, 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 http://opensource.org/licenses/bsd-license.php
> > +
> > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > + BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +
> > + @par Revision Reference:
> > + This Protocol is defined in UEFI Platform Initialization
> > + Specification 1.2 Volume 5: Standards
> > +
> > +**/
> > +
> > +#ifndef _PCI_OVERRIDE2_H_
> > +#define _PCI_OVERRIDE2_H_
> > +
> > +///
> > +/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with
> > +EFI_PCI_PLATFORM_PROTOCOL /// #include
> > +
> > +///
> > +/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL /// #define
> > +EFI_PCI_OVERRIDE2_GUID \
> > + { \
> > +0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9,
> > +0x42, 0x47} \
> > + }
> > +
> > +///
> > +/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL /// typedef
> > +EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2;
> > +
> > +
> > +extern EFI_GUID gEfiPciOverrideProtocol2Guid;
> > +
> > +#endif
> > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h
> > b/MdePkg/Include/Protocol/PciPlatform2.h
> > new file mode 100644
> > index 00..3ff41b7754
> > --- /dev/null
> > +++ b/MdePkg/Include/Protocol/PciPlatform2.h
> > @@ -0,0 +1,396 @@
> > +/** @file
> > + This file declares PCI Platform Protocol that provide the interface
> > +between
> > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and a
> > +platform-specific
> > + driver to describe the unique features of a platform.
> > + This protocol is optional.
> > +
> > +Copyright (c) 2007 -
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
Ashraf:
These two protocols are new added. They are not defined in current PI spec.
Can you update file header to remove below comments?
> + This Protocol is defined in UEFI Platform Initialization Specification 1.2
> + Volume 5: Standards
Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Javeed,
> Ashraf
> Sent: Friday, July 19, 2019 11:00 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray
> Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH]
> MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> New interface added to PCI Platform Protocol / PCI Override Protocol to
> retrieve device-specific platform policy for the following PCI standard
> features, like Maximum Payload Size (MPS), Maximum Read Request Size
> (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power Management
> (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock
> Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO).
> New source files added with enhanced definitions are in:
> MdePkg/Include/Protocol/PciPlatform2.h,
> MdePkg/Include/Protocol/PciOverride2.h
>
> Repository: https://github.com/ashrafj/edk2-staging/tree/UEFI_PCI_ENHANCE-2
>
> Signed-off-by: Ashraf Javeed
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> ---
> MdePkg/Include/Protocol/PciOverride2.h | 46
> ++
> MdePkg/Include/Protocol/PciPlatform2.h | 396
> ++
> ++
> ++
> ++
> MdePkg/MdePkg.dec | 6 ++
> 3 files changed, 448 insertions(+)
>
> diff --git a/MdePkg/Include/Protocol/PciOverride2.h
> b/MdePkg/Include/Protocol/PciOverride2.h
> new file mode 100644
> index 00..cf452d9f8f
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/PciOverride2.h
> @@ -0,0 +1,46 @@
> +/** @file
> + This file declares EFI PCI Override protocol which provides the interface
> between
> + the PCI bus driver/PCI Host Bridge Resource Allocation driver and an
> implementation's
> + driver to describe the unique features of a platform.
> + This protocol is optional.
> +
> + Copyright (c) 2019, 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
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +
> + @par Revision Reference:
> + This Protocol is defined in UEFI Platform Initialization Specification 1.2
> + Volume 5: Standards
> +
> +**/
> +
> +#ifndef _PCI_OVERRIDE2_H_
> +#define _PCI_OVERRIDE2_H_
> +
> +///
> +/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with
> EFI_PCI_PLATFORM_PROTOCOL
> +///
> +#include
> +
> +///
> +/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL
> +///
> +#define EFI_PCI_OVERRIDE2_GUID \
> + { \
> +0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, 0x42,
> 0x47} \
> + }
> +
> +///
> +/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL
> +///
> +typedef EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2;
> +
> +
> +extern EFI_GUID gEfiPciOverrideProtocol2Guid;
> +
> +#endif
> diff --git a/MdePkg/Include/Protocol/PciPlatform2.h
> b/MdePkg/Include/Protocol/PciPlatform2.h
> new file mode 100644
> index 00..3ff41b7754
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/PciPlatform2.h
> @@ -0,0 +1,396 @@
> +/** @file
> + This file declares PCI Platform Protocol that provide the interface between
> + the PCI bus driver/PCI Host Bridge Resource Allocation driver and a
> platform-specific
> + driver to describe the unique features of a platform.
> + This protocol is optional.
> +
> +Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
> +This program and the accompanying materials are licensed and made available
> under
> +the terms and conditions of the BSD License that accompanies this
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> + @par Revision Reference:
> + This Protocol is defined in UEFI Platform
Re: [edk2-devel] [PATCH v2 1/3] OvmfPkg/build.sh: use POSIX 'command -v' instead of 'which'.
On 7/25/19 2:45 PM, rebe...@bsdio.com wrote: > On 2019-07-25 05:07, Philippe Mathieu-Daudé wrote: >> It would be quicker to reply to your series if you use a cover letter. >> (I'd have replied "series: Reviewed-by" instead of going thru each patch). > > Thanks, I'll try and remember that in future. I'm still learning how > best to send patches using "git send-email". Then I recommend you to look at the git-publish tool :) I haven't used 'git send-email' since I started to use it: https://github.com/stefanha/git-publish -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44382): https://edk2.groups.io/g/devel/message/44382 Mute This Topic: https://groups.io/mt/32591947/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms: PATCHv2 1/1] Platform/RPi3: Provide "ethernet[0]" aliases in device tree
On Wed, Jul 24, 2019 at 10:43:42PM +0100, Leif Lindholm wrote: > On Wed, Jul 24, 2019 at 09:53:00PM +0100, Michael Brown wrote: > > On 24/07/2019 19:53, Leif Lindholm wrote: > > > > SanitizePSCI (); > > > > CleanMemoryNodes (); > > > > CleanSimpleFramebuffer (); > > > > + FixEthernetAliases (); > > > > > > ...would it be worth having a return value here and Print()ing a > > > message visible regardless of build profile if this function fails? > > > > Yes, I think that would be very sensible, but it would also be inconsistent > > with the rest of the code: all of the other device-tree-modifying functions > > in FdtDxe.c are declared as VOID and use only DEBUG to report errors. > > > > Changing this pattern throughout FdtDxe.c should, I think, be a completely > > separate patch. Would it be possible to merge the current patch, and I can > > then follow up with a second patch to improve the error visibility in > > non-debug builds? > > Yeah, that works for me. > I'll push it tomorrow when I'm more awake, but for now: > Reviewed-by: Leif Lindholm Pushed as 9181684081bf. Thanks! / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44381): https://edk2.groups.io/g/devel/message/44381 Mute This Topic: https://groups.io/mt/32585981/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/3] OvmfPkg/build.sh: use POSIX 'command -v' instead of 'which'.
On 2019-07-25 05:07, Philippe Mathieu-Daudé wrote: > It would be quicker to reply to your series if you use a cover letter. > (I'd have replied "series: Reviewed-by" instead of going thru each patch). Thanks, I'll try and remember that in future. I'm still learning how best to send patches using "git send-email". -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44380): https://edk2.groups.io/g/devel/message/44380 Mute This Topic: https://groups.io/mt/32591947/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V2] BaseTools: replace the chinese quotation mark with unicode "
On 7/25/19 5:00 AM, Fan, ZhijuX wrote: > From: Sean Brogan > > BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2013 > > chinese quotation mark are used in the file > This patch is going to fix that issue. > > Cc: Bob Feng > Cc: Liming Gao > Signed-off-by: Zhiju.Fan > --- > BaseTools/Source/Python/Pkcs7Sign/Readme.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/BaseTools/Source/Python/Pkcs7Sign/Readme.md > b/BaseTools/Source/Python/Pkcs7Sign/Readme.md > index 5315b7fca4..a7b9caf52c 100644 > --- a/BaseTools/Source/Python/Pkcs7Sign/Readme.md > +++ b/BaseTools/Source/Python/Pkcs7Sign/Readme.md > @@ -10,7 +10,7 @@ NOTE: Below steps are required for Windows. Linux may > already have the OPENSSL e > set OPENSSL_HOME=c:\home\openssl\openssl-[version] > set OPENSSL_CONF=%OPENSSL_HOME%\apps\openssl.cnf > > -When a user uses OpenSSL (req or ca command) to generate the certificates, > OpenSSL will use the openssl.cnf file as the configuration data (can use > “-config path/to/openssl.cnf” to describe the specific config file). > +When a user uses OpenSSL (req or ca command) to generate the certificates, > OpenSSL will use the openssl.cnf file as the configuration data (can use > "-config path/to/openssl.cnf" to describe the specific config file). > > The user need check the openssl.cnf file, to find your CA path setting, e.g. > check if the path exists in [ CA_default ] section. > I wonder, we could add a BaseTool script as pre-commit hook to check this kind of easy typos... Reviewed-by: Philippe Mathieu-Daude -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44379): https://edk2.groups.io/g/devel/message/44379 Mute This Topic: https://groups.io/mt/32594579/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 3/3] OvmfPkg/build.sh: remove $ADD_QEMU_HDA
On 7/24/19 11:44 PM, rebe...@bsdio.com wrote: > $ADD_QEMU_HDA was added because QEMU used to refuse to run without a > disk. Since newer versions run without any disks, remove it. Finally :) Should we also update the wiki documentation? Reviewed-by: Philippe Mathieu-Daude > > Signed-off-by: Rebecca Cran > --- > OvmfPkg/build.sh | 14 -- > 1 file changed, 14 deletions(-) > > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh > index 0219791aa8..960382f633 100755 > --- a/OvmfPkg/build.sh > +++ b/OvmfPkg/build.sh > @@ -213,17 +213,6 @@ if [[ "$RUN_QEMU" == "yes" ]]; then >ENABLE_FLASH=yes >;; >esac > - > - ADD_QEMU_HDA=yes > - for arg in "$@" > - do > -case $arg in > - -hd[a-d]|-fd[ab]|-cdrom) > -ADD_QEMU_HDA=no > -break > -;; > -esac > - done > fi > > # > @@ -267,9 +256,6 @@ if [[ "$RUN_QEMU" == "yes" ]]; then >else > QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR" >fi > - if [[ "$ADD_QEMU_HDA" == "yes" ]]; then > -QEMU_COMMAND="$QEMU_COMMAND -hda fat:$BUILD_ROOT_ARCH" > - fi >echo Running: $QEMU_COMMAND "$@" >$QEMU_COMMAND "$@" >exit $? > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44378): https://edk2.groups.io/g/devel/message/44378 Mute This Topic: https://groups.io/mt/32591949/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 2/3] OvmfPkg/build.sh: use newer '-drive if=pflash' syntax when running qemu
On 7/24/19 11:44 PM, rebe...@bsdio.com wrote: > Specify the firmware to use via the newer '-drive if=pflash' syntax > which allows specifying the raw format parameter. This > avoids warnings with newer version of QEMU. > > Signed-off-by: Rebecca Cran > --- > OvmfPkg/build.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh > index 1c28e65404..0219791aa8 100755 > --- a/OvmfPkg/build.sh > +++ b/OvmfPkg/build.sh > @@ -263,7 +263,7 @@ if [[ "$RUN_QEMU" == "yes" ]]; then >fi >ln -sf $FV_DIR/OVMF.fd $QEMU_FIRMWARE_DIR/bios.bin >if [[ "$ENABLE_FLASH" == "yes" ]]; then > -QEMU_COMMAND="$QEMU_COMMAND -pflash $QEMU_FIRMWARE_DIR/bios.bin" > +QEMU_COMMAND="$QEMU_COMMAND -drive > if=pflash,format=raw,file=$QEMU_FIRMWARE_DIR/bios.bin" >else > QEMU_COMMAND="$QEMU_COMMAND -L $QEMU_FIRMWARE_DIR" >fi > Reviewed-by: Philippe Mathieu-Daude -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44377): https://edk2.groups.io/g/devel/message/44377 Mute This Topic: https://groups.io/mt/32591948/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/3] OvmfPkg/build.sh: use POSIX 'command -v' instead of 'which'.
Hi Rebecca, It would be quicker to reply to your series if you use a cover letter. (I'd have replied "series: Reviewed-by" instead of going thru each patch). On 7/24/19 11:44 PM, rebe...@bsdio.com wrote: > Signed-off-by: Rebecca Cran > --- > OvmfPkg/build.sh | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh > index e94aa2a37e..1c28e65404 100755 > --- a/OvmfPkg/build.sh > +++ b/OvmfPkg/build.sh > @@ -174,11 +174,11 @@ case $PROCESSOR in ># The user set the QEMU_COMMAND variable. We'll use it to run QEMU. ># >: > -elif [ -x `which qemu-system-i386` ]; then > +elif command -v qemu-system-i386; then >QEMU_COMMAND=qemu-system-i386 > -elif [ -x `which qemu-system-x86_64` ]; then > +elif command -v qemu-system-x86_64; then >QEMU_COMMAND=qemu-system-x86_64 > -elif [ -x `which qemu` ]; then > +elif command -v qemu; then >QEMU_COMMAND=qemu > else >echo Unable to find QEMU for IA32 architecture! > @@ -242,12 +242,12 @@ FV_DIR=$BUILD_ROOT/FV > BUILD_ROOT_ARCH=$BUILD_ROOT/$BUILD_ROOT_ARCH > QEMU_FIRMWARE_DIR=$BUILD_ROOT/QEMU > > -if [[ ! -f `which build` || ! -f `which GenFv` ]]; > +if ! command -v build || ! command -v GenFv; > then ># build the tools if they don't yet exist. Bin scheme >echo Building tools as they are not in the path >make -C $WORKSPACE/BaseTools > -elif [[ ( -f `which build` || -f `which GenFv` ) && ! -d > $EDK_TOOLS_PATH/Source/C/bin ]]; > +elif [[ ( $(command -v build) || $(command -v GenFv) ) && ! -d > $EDK_TOOLS_PATH/Source/C/bin ]]; > then ># build the tools if they don't yet exist. BinWrapper scheme >echo Building tools no $EDK_TOOLS_PATH/Source/C/bin directory > Reviewed-by: Philippe Mathieu-Daude -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44376): https://edk2.groups.io/g/devel/message/44376 Mute This Topic: https://groups.io/mt/32591947/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms: PATCH 1/1] Platform/RPi3: Add Debian 10 installation in Systems.md
This documents the installation of vanilla Debian 10.0 ARM64 (netinst),
which we validated for both Model B and Model B+.
Also fix an erroneous reference in an RPi3.fdf comment.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/RPi3.fdf | 2 +-
Platform/RaspberryPi/RPi3/Readme.md | 4 +-
Platform/RaspberryPi/RPi3/Systems.md | 124 +++-
3 files changed, 123 insertions(+), 7 deletions(-)
diff --git a/Platform/RaspberryPi/RPi3/RPi3.fdf
b/Platform/RaspberryPi/RPi3/RPi3.fdf
index c7c3f7a2ab8c..c62d649834c7 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.fdf
+++ b/Platform/RaspberryPi/RPi3/RPi3.fdf
@@ -300,7 +300,7 @@ [FV.FvMain]
INF Platform/RaspberryPi/$(PLATFORM_NAME)/Drivers/LogoDxe/LogoDxe.inf
#
- # FDT (GUID matches mRaspberryPiFfsFileGuid in RaspberryPiPlatformDxe)
+ # FDT (GUID matches gRaspberryPiFdtFileGuid in FdtDxe)
#
FILE FREEFORM = DF5DA223-1D27-47C3-8D1B-9A41B55A18BC {
SECTION RAW =
Platform/RaspberryPi/$(PLATFORM_NAME)/DeviceTree/bcm2710-rpi-3-b.dtb
diff --git a/Platform/RaspberryPi/RPi3/Readme.md
b/Platform/RaspberryPi/RPi3/Readme.md
index 624f3a8d287a..797da1bab4a9 100644
--- a/Platform/RaspberryPi/RPi3/Readme.md
+++ b/Platform/RaspberryPi/RPi3/Readme.md
@@ -18,8 +18,8 @@ Raspberry Pi is a trademark of the [Raspberry Pi
Foundation](http://www.raspberr
This firmware, that has been validated to compile against the current
[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
-should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as
Windows 10 ARM64
-(full GUI version).
+should be able to boot Linux (Debian, Ubuntu, SUSE), NetBSD, FreeBSD as well
as Windows
+10 ARM64 (full GUI version).
It also provides support for ATF ([Arm Trusted
Platform](https://github.com/ARM-software/arm-trusted-firmware)).
diff --git a/Platform/RaspberryPi/RPi3/Systems.md
b/Platform/RaspberryPi/RPi3/Systems.md
index f6410eb25f0d..edce1aaabb29 100644
--- a/Platform/RaspberryPi/RPi3/Systems.md
+++ b/Platform/RaspberryPi/RPi3/Systems.md
@@ -1,5 +1,125 @@
# Tested Operating Systems
+## Debian
+
+[Debian 10](https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/)
netinst has been
+tested and confirmed to work, both on the Model B and Model B+, including
installation in
+either wired or wireless mode.
+
+Below are steps you can follow to install Debian 10 onto an SD card:
+* Partition the media as MBR and create a ~300 MB partition on it with MBR
type `0x0e`.
+ __Note:__ Make sure that the partition scheme is MBR (not GPT) and the type
`0x0e` (not
+ `0xef` for instance), as the ondie Broadcom bootloader supports neither the
GPT scheme nor
+ the ESP MBR type.
+* Set the partition as active/bootable. This is needed as the Debian partition
manager can
+ not detect it as ESP otherwise, which we need for GRUB installation. If
using `fdisk` on
+ Linux, you can use the `a` command to set a partition as active. On
Windows, you can use
+ `DISKPART` and then type `active` after selecting the relevant disk and
partition.
+* Format the partition as FAT. Here again you should make sure that you use
FAT rather than
+ FAT32 else the Debian partition manager will not detect the partition as
ESP. If you
+ are using Windows `DISKPART` then `format fs=fat quick` should do it. On
Linux, `mkfs.vfat`
+ with the default options should do the same as long as the partition isn't
too large.
+* Copy the UEFI firmware files (`RPI_EFI.fd`, `bootcode.bin`, `fixup.dat` and
`start.elf`)
+ as well as an appropriate `config.txt` onto the FAT partition. If needed you
can download
+ the non UEFI binary files from
https://github.com/raspberrypi/firmware/tree/master/boot.
+* (Optional) If you plan to install through WiFi, you will need to download
relevant non-free
+ WLAN firmware binaries from your WLAN interface (`brcmfmac43430-sdio.txt`
and
+ `brcmfmac43430-sdio.bin` for a Raspberry Pi 3 Model B,
`brcmfmac43455-sdio.txt` and
+ `brcmfmac43455-sdio.bin` for a Raspberry Pi 3 Model B+). You may also want
to obtain the
+ relevant `.clm_blob` (`brcmfmac43430-sdio.clm_blob` or
`brcmfmac43455-sdio.clm_blob`),
+ though wireless networking should work even if you do not provide these
files. Copy these
+ files either at the root of your FAT partition or into a `firmware/`
directory there.
+* Download the latest `debian-##.#.#-arm64-netinst.iso` from
+ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/
+* Extract the full content of the ISO onto the FAT partition you created.
+* Insert the media and power up the Raspberry Pi device.
+* On the GRUB menu select `Install` and let the Debian Installer process start.
+ __Note:__ In case anything goes wrong during the install process, you can use
+ Alt-F4 to check the installation log.
+* Select your Language, Country and Keyboard and let the installer proceed
until it reports
+ that `No Common CD-ROM drive was detected.`
+* On `Load
Re: [edk2-devel] [PATCH V2] BaseTools:Add extra debugging message
Nit in subject, "BaseTools:Add extra debugging message"
On 7/25/19 5:02 AM, Fan, ZhijuX wrote:
> From: Max Knutsen
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2014
>
> Add extra debugging to improve error identification.
> Error while processing file if the file is read incorrectly
>
> This patch is going to fix that issue.
>
> Cc: Bob Feng
> Cc: Liming Gao
> Signed-off-by: Zhiju.Fan
> ---
> BaseTools/Source/Python/AutoGen/StrGather.py | 16 ++--
> BaseTools/Source/Python/Trim/Trim.py | 4 +++-
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/BaseTools/Source/Python/AutoGen/StrGather.py
> b/BaseTools/Source/Python/AutoGen/StrGather.py
> index 2e4671a433..eed30388be 100644
> --- a/BaseTools/Source/Python/AutoGen/StrGather.py
> +++ b/BaseTools/Source/Python/AutoGen/StrGather.py
> @@ -526,12 +526,16 @@ def SearchString(UniObjectClass, FileList,
> IsCompatibleMode):
> return UniObjectClass
>
> for File in FileList:
> -if os.path.isfile(File):
> -Lines = open(File, 'r')
> -for Line in Lines:
> -for StrName in STRING_TOKEN.findall(Line):
> -EdkLogger.debug(EdkLogger.DEBUG_5, "Found string
> identifier: " + StrName)
> -UniObjectClass.SetStringReferenced(StrName)
> +try:
> +if os.path.isfile(File):
> +Lines = open(File, 'r')
> +for Line in Lines:
> +for StrName in STRING_TOKEN.findall(Line):
> +EdkLogger.debug(EdkLogger.DEBUG_5, "Found string
> identifier: " + StrName)
> +UniObjectClass.SetStringReferenced(StrName)
> +except:
> +EdkLogger.error("UnicodeStringGather", AUTOGEN_ERROR,
> "SearchString: Error while processing file", File=File, RaiseError=False)
> +raise
>
> UniObjectClass.ReToken()
>
> diff --git a/BaseTools/Source/Python/Trim/Trim.py
> b/BaseTools/Source/Python/Trim/Trim.py
> index 43119bd7ff..8767b67f7e 100644
> --- a/BaseTools/Source/Python/Trim/Trim.py
> +++ b/BaseTools/Source/Python/Trim/Trim.py
> @@ -73,8 +73,10 @@ def TrimPreprocessedFile(Source, Target, ConvertHex,
> TrimLong):
> try:
> with open(Source, "r") as File:
> Lines = File.readlines()
> -except:
> +except IOError:
> EdkLogger.error("Trim", FILE_OPEN_FAILURE, ExtraData=Source)
> +expect:
> +EdkLogger.error("Trim", AUTOGEN_ERROR, "TrimPreprocessedFile: Error
> while processing file", File=Source)
>
> PreprocessedFile = ""
> InjectedFile = ""
>
Reviewed-by: Philippe Mathieu-Daude
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44374): https://edk2.groups.io/g/devel/message/44374
Mute This Topic: https://groups.io/mt/32594584/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection
On Thu, Jul 25, 2019 at 11:05:34AM +0100, Anthony PERARD wrote:
> On Thu, Jul 25, 2019 at 11:08:29AM +0200, Roger Pau Monné wrote:
> > On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> > > On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > > > On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > > > > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > > > > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > > > > > + // error message: CpuDxe: IntersectMemoryDescriptor:
> > > > > > > + //desc [FC00, 1) type 1 cap
> > > > > > > 87026001
> > > > > > > + //conflicts with aperture [FEE0, FEE01000) cap
> > > > > > > 1
> > > > > > >//
> > > > > > > - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> > > > > > > -continue;
> > > > > > > + if (!XenHvmloaderDetected ()) {
> > > > > > > +AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
> > > > > >
> > > > > > This special casing for PVH looks weird, ideally we would like to
> > > > > > use
> > > > > > the same code path, or else it should be explicitly mentioned why
> > > > > > PVH
> > > > > > has diverging behaviour.
> > > > >
> > > > > I think hvmloader is the issue rather than PVH. Here is part of the
> > > > > "memory map" as found in hvmloader/config.h:
> > > > >
> > > > > /* Special BIOS mappings, etc. are allocated from here upwards... */
> > > > > #define RESERVED_MEMBASE 0xFC00
> > > > > /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in
> > > > > acpi/dsdt.asl! */
> > > > > #define ACPI_INFO_PHYSICAL_ADDRESS0xFC00
> > > > > #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> > > > > #define RESERVED_MEMORY_DYNAMIC_END 0xFE00
> > > > >
> > > > > and hvmloader simply creates a single e820 reserved entry, from
> > > > > RESERVED_MEMBASE to the top of 4GB. It's probably too much.
> > > >
> > > > But isn't this kind of dangerous? How can you assure future versions
> > > > of hvmloader won't use this space?
> > > >
> > > > > If hvmloader only reserved
> > > > > ACPI_INFO_PHYSICAL_ADDRESS-RESERVED_MEMORY_DYNAMIC_END, I might not
> > > > > have
> > > > > to special case hvmloader.
> > > >
> > > > Could we look into getting this fixed in hvmloader then?
> > > >
> > > > I think it's dangerous for OVMF to play such tricks with the memory
> > > > map.
> > > >
> > > > > As far as I know 0xfee0 isn't a special
> > > > > bios mapping, but something the hardware provides.
> > > >
> > > > Yes, that's used by the lapic, so it's not specific to hvmloader.
> > >
> > > Right, I've got a closer look at that CpuDxe module, it wants the local
> > > APIC memory mapped space to be "mapped IO", and that different than
> > > "reserved".
> > >
> > > So while parsing the e820 from hvmloader, instead of ignoring all
> > > reserved region, I'm going to avoid adding the local apic memory mapped
> > > space.
> > >
> > > something like:
> > > if (hvmloaderDetected())
> >
> > I don't think you need to gate this on hvmloader being used, while
> > it's true that PVH memory map doesn't contain such reserved memory
> > region ATM I don't see any harm in doing this for PVH also.
>
> Ok.
>
> > > Base = $(start of the e820 entry);
> > > End = $(start of the e820 entry + size);
> > > LocalApic = 0xfee0;
> > > if (Base < LocalApic && LocalApic < End) {
> > > AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
> > > if (End > (LocalApic + SIZE_4KB)) {
> >
> > The range is actually from 0xfee0 to 0xfeef (2MB), so you
> > likely want to make sure non of this is added as reserved?
>
> You mean 1MB, right ? :-).
D'oh, yes :).
> I've try to find out in the Intel manual why
> it would be 1MB and couldn't find that, but on the other hand the
> initialisation code for OVMF running on QEMU does also reserve 1MB for
> the local apic. So I'll change to 1MB.
It's the Interrupt Address Range, which contains the mmio lapic
registers and the mmio region where devices write in order to signal
interrupts to the apic (used as the address field for MSI(-X)).
Thanks, Roger.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44373): https://edk2.groups.io/g/devel/message/44373
Mute This Topic: https://groups.io/mt/32308708/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH V2] BaseTools:Added arch output to build report
Hi Fan, On 7/25/19 5:04 AM, Fan, ZhijuX wrote: > From: Matthew Carlson > > BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2016 > > Added arch output to build report so it's easy to tell > which arch is being generated. Useful when multiple versions > of a single module is being emitted for multiple archs. > > This patch is going to Added arch output Your patch seems fine, but I don't understand what you mean in the previous sentence, can you clarify please? > > Cc: Bob Feng > Cc: Liming Gao > Signed-off-by: Zhiju.Fan > --- > BaseTools/Source/Python/build/BuildReport.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/BaseTools/Source/Python/build/BuildReport.py > b/BaseTools/Source/Python/build/BuildReport.py > index a3eb3b2383..b4189240e1 100644 > --- a/BaseTools/Source/Python/build/BuildReport.py > +++ b/BaseTools/Source/Python/build/BuildReport.py > @@ -558,6 +558,7 @@ class ModuleReport(object): > def __init__(self, M, ReportType): > self.ModuleName = M.Module.BaseName > self.ModuleInfPath = M.MetaFile.File > +self.ModuleArch = M.Arch > self.FileGuid = M.Guid > self.Size = 0 > self.BuildTimeStamp = None > @@ -668,6 +669,7 @@ class ModuleReport(object): > > FileWrite(File, "Module Summary") > FileWrite(File, "Module Name: %s" % self.ModuleName) > +FileWrite(File, "Module Arch: %s" % self.ModuleArch) > FileWrite(File, "Module INF Path: %s" % self.ModuleInfPath) > FileWrite(File, "File GUID:%s" % self.FileGuid) > if self.Size: > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44372): https://edk2.groups.io/g/devel/message/44372 Mute This Topic: https://groups.io/mt/32594597/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms: PATCH 1/1] Platform/RPi3: Report device tree modification errors using Print()
Most functions in FdtDxe currently return VOID and report errors using
only DEBUG. Update functions to return EFI_STATUS and report errors
using Print() so that errors are at least visible in non-debug builds.
Signed-off-by: Michael Brown
---
.../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102 --
1 file changed, 70 insertions(+), 32 deletions(-)
diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
index 57e4bee8da..17d3bbd82d 100644
--- a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -24,7 +25,7 @@ STATIC VOID *mFdtImage;
STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
STATIC
-VOID
+EFI_STATUS
FixEthernetAliases (
VOID
)
@@ -36,6 +37,7 @@ FixEthernetAliases (
UINTN CopySize;
CHAR8 *Copy;
INTN Retval;
+ EFI_STATUSStatus;
//
// Look up the 'ethernet[0]' aliases
@@ -43,14 +45,14 @@ FixEthernetAliases (
Aliases = fdt_path_offset (mFdtImage, "/aliases");
if (Aliases < 0) {
DEBUG ((DEBUG_ERROR, "%a: failed to locate '/aliases'\n", __FUNCTION__));
-return;
+return EFI_NOT_FOUND;
}
Ethernet = fdt_getprop (mFdtImage, Aliases, "ethernet", NULL);
Ethernet0 = fdt_getprop (mFdtImage, Aliases, "ethernet0", NULL);
Alias = Ethernet ? Ethernet : Ethernet0;
if (!Alias) {
DEBUG ((DEBUG_ERROR, "%a: failed to locate 'ethernet[0]' alias\n",
__FUNCTION__));
-return;
+return EFI_NOT_FOUND;
}
//
@@ -60,15 +62,17 @@ FixEthernetAliases (
Copy = AllocateCopyPool (CopySize, Alias);
if (!Copy) {
DEBUG ((DEBUG_ERROR, "%a: failed to copy '%a'\n", __FUNCTION__, Alias));
-return;
+return EFI_OUT_OF_RESOURCES;
}
//
// Create missing aliases
//
+ Status = EFI_SUCCESS;
if (!Ethernet) {
Retval = fdt_setprop (mFdtImage, Aliases, "ethernet", Copy, CopySize);
if (Retval != 0) {
+ Status = EFI_DEVICE_ERROR;
DEBUG ((DEBUG_ERROR, "%a: failed to create 'ethernet' alias (%d)\n",
__FUNCTION__, Retval));
}
@@ -77,6 +81,7 @@ FixEthernetAliases (
if (!Ethernet0) {
Retval = fdt_setprop (mFdtImage, Aliases, "ethernet0", Copy, CopySize);
if (Retval != 0) {
+ Status = EFI_DEVICE_ERROR;
DEBUG ((DEBUG_ERROR, "%a: failed to create 'ethernet0' alias (%d)\n",
__FUNCTION__, Retval));
}
@@ -84,10 +89,11 @@ FixEthernetAliases (
}
FreePool (Copy);
+ return Status;
}
STATIC
-VOID
+EFI_STATUS
UpdateMacAddress (
VOID
)
@@ -103,7 +109,7 @@ UpdateMacAddress (
Node = fdt_path_offset (mFdtImage, "ethernet");
if (Node < 0) {
DEBUG ((DEBUG_ERROR, "%a: failed to locate 'ethernet' alias\n",
__FUNCTION__));
-return;
+return EFI_NOT_FOUND;
}
//
@@ -112,7 +118,7 @@ UpdateMacAddress (
Status = mFwProtocol->GetMacAddress (MacAddress);
if (EFI_ERROR (Status)) {
DEBUG ((DEBUG_ERROR, "%a: failed to retrieve MAC address\n",
__FUNCTION__));
-return;
+return Status;
}
Retval = fdt_setprop (mFdtImage, Node, "mac-address", MacAddress,
@@ -120,16 +126,17 @@ UpdateMacAddress (
if (Retval != 0) {
DEBUG ((DEBUG_ERROR, "%a: failed to create 'mac-address' property (%d)\n",
__FUNCTION__, Retval));
-return;
+return EFI_DEVICE_ERROR;
}
DEBUG ((DEBUG_INFO, "%a: setting MAC address to
%02x:%02x:%02x:%02x:%02x:%02x\n",
__FUNCTION__, MacAddress[0], MacAddress[1], MacAddress[2], MacAddress[3],
MacAddress[4], MacAddress[5]));
+ return EFI_SUCCESS;
}
STATIC
-VOID
+EFI_STATUS
CleanMemoryNodes (
VOID
)
@@ -139,7 +146,7 @@ CleanMemoryNodes (
Node = fdt_path_offset (mFdtImage, "/memory");
if (Node < 0) {
-return;
+return EFI_SUCCESS;
}
/*
@@ -150,11 +157,14 @@ CleanMemoryNodes (
Retval = fdt_del_node (mFdtImage, Node);
if (Retval != 0) {
DEBUG ((DEBUG_ERROR, "Failed to remove /memory\n"));
+return EFI_DEVICE_ERROR;
}
+
+ return EFI_SUCCESS;
}
STATIC
-VOID
+EFI_STATUS
SanitizePSCI (
VOID
)
@@ -166,7 +176,7 @@ SanitizePSCI (
Root = fdt_path_offset (mFdtImage, "/");
ASSERT (Root >= 0);
if (Root < 0) {
-return;
+return EFI_NOT_FOUND;
}
Node = fdt_path_offset (mFdtImage, "/psci");
@@ -177,41 +187,42 @@ SanitizePSCI (
ASSERT (Node >= 0);
if (Node < 0) {
DEBUG ((DEBUG_ERROR, "Couldn't find/create /psci\n"));
-return;
+return EFI_DEVICE_ERROR;
}
Retval = fdt_setprop_string (mFdtImage, Node, "compatible", "arm,psci-1.0");
if (Retval != 0) {
DEBUG ((DEBUG_ERROR, "Couldn't set /psci compatible property\n"));
-return;
+return EFI_DEVICE_ERROR;
}
Retval = fdt_setprop_string (mFdtImage, Node, "method", "smc");
if (Retval != 0) {
DEBUG ((DEBUG_ERROR, "Couldn't set /psci method
[edk2-devel] [edk2-platforms: PATCH 0/1] Report device tree modification errors using Print()
>>> ...would it be worth having a return value here and Print()ing a >>> message visible regardless of build profile if this function fails? >> >> Yes, I think that would be very sensible, but it would also be inconsistent >> with the rest of the code: all of the other device-tree-modifying functions >> in FdtDxe.c are declared as VOID and use only DEBUG to report errors. >> >> Changing this pattern throughout FdtDxe.c should, I think, be a completely >> separate patch. Would it be possible to merge the current patch, and I can >> then follow up with a second patch to improve the error visibility in >> non-debug builds? > > Yeah, that works for me. As promised, here is the subsequent patch to improve error visibility throughout FdtDxe. Michael Brown (1): Platform/RPi3: Report device tree modification errors using Print() .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102 -- 1 file changed, 70 insertions(+), 32 deletions(-) -- 2.21.0 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44370): https://edk2.groups.io/g/devel/message/44370 Mute This Topic: https://groups.io/mt/32596680/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection
On Thu, Jul 25, 2019 at 11:08:29AM +0200, Roger Pau Monné wrote:
> On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> > On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > > On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > > > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > > > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > > > > + // error message: CpuDxe: IntersectMemoryDescriptor:
> > > > > > + //desc [FC00, 1) type 1 cap
> > > > > > 87026001
> > > > > > + //conflicts with aperture [FEE0, FEE01000) cap 1
> > > > > >//
> > > > > > - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> > > > > > -continue;
> > > > > > + if (!XenHvmloaderDetected ()) {
> > > > > > +AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
> > > > >
> > > > > This special casing for PVH looks weird, ideally we would like to use
> > > > > the same code path, or else it should be explicitly mentioned why PVH
> > > > > has diverging behaviour.
> > > >
> > > > I think hvmloader is the issue rather than PVH. Here is part of the
> > > > "memory map" as found in hvmloader/config.h:
> > > >
> > > > /* Special BIOS mappings, etc. are allocated from here upwards... */
> > > > #define RESERVED_MEMBASE 0xFC00
> > > > /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in
> > > > acpi/dsdt.asl! */
> > > > #define ACPI_INFO_PHYSICAL_ADDRESS0xFC00
> > > > #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> > > > #define RESERVED_MEMORY_DYNAMIC_END 0xFE00
> > > >
> > > > and hvmloader simply creates a single e820 reserved entry, from
> > > > RESERVED_MEMBASE to the top of 4GB. It's probably too much.
> > >
> > > But isn't this kind of dangerous? How can you assure future versions
> > > of hvmloader won't use this space?
> > >
> > > > If hvmloader only reserved
> > > > ACPI_INFO_PHYSICAL_ADDRESS-RESERVED_MEMORY_DYNAMIC_END, I might not have
> > > > to special case hvmloader.
> > >
> > > Could we look into getting this fixed in hvmloader then?
> > >
> > > I think it's dangerous for OVMF to play such tricks with the memory
> > > map.
> > >
> > > > As far as I know 0xfee0 isn't a special
> > > > bios mapping, but something the hardware provides.
> > >
> > > Yes, that's used by the lapic, so it's not specific to hvmloader.
> >
> > Right, I've got a closer look at that CpuDxe module, it wants the local
> > APIC memory mapped space to be "mapped IO", and that different than
> > "reserved".
> >
> > So while parsing the e820 from hvmloader, instead of ignoring all
> > reserved region, I'm going to avoid adding the local apic memory mapped
> > space.
> >
> > something like:
> > if (hvmloaderDetected())
>
> I don't think you need to gate this on hvmloader being used, while
> it's true that PVH memory map doesn't contain such reserved memory
> region ATM I don't see any harm in doing this for PVH also.
Ok.
> > Base = $(start of the e820 entry);
> > End = $(start of the e820 entry + size);
> > LocalApic = 0xfee0;
> > if (Base < LocalApic && LocalApic < End) {
> > AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
> > if (End > (LocalApic + SIZE_4KB)) {
>
> The range is actually from 0xfee0 to 0xfeef (2MB), so you
> likely want to make sure non of this is added as reserved?
You mean 1MB, right ? :-). I've try to find out in the Intel manual why
it would be 1MB and couldn't find that, but on the other hand the
initialisation code for OVMF running on QEMU does also reserve 1MB for
the local apic. So I'll change to 1MB.
Thanks,
--
Anthony PERARD
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44369): https://edk2.groups.io/g/devel/message/44369
Mute This Topic: https://groups.io/mt/32308708/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 24/35] OvmfPkg/XenPlatformPei: Rework memory detection
On Wed, Jul 24, 2019 at 05:17:59PM +0100, Anthony PERARD wrote:
> On Tue, Jul 23, 2019 at 11:42:07AM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 22, 2019 at 03:53:19PM +0100, Anthony PERARD wrote:
> > > On Mon, Jul 15, 2019 at 04:15:21PM +0200, Roger Pau Monné wrote:
> > > > On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> > > > > + // error message: CpuDxe: IntersectMemoryDescriptor:
> > > > > + //desc [FC00, 1) type 1 cap
> > > > > 87026001
> > > > > + //conflicts with aperture [FEE0, FEE01000) cap 1
> > > > >//
> > > > > - if (Entry->Type != EfiAcpiAddressRangeMemory) {
> > > > > -continue;
> > > > > + if (!XenHvmloaderDetected ()) {
> > > > > +AddReservedMemoryBaseSizeHob (Base, End - Base, FALSE);
> > > >
> > > > This special casing for PVH looks weird, ideally we would like to use
> > > > the same code path, or else it should be explicitly mentioned why PVH
> > > > has diverging behaviour.
> > >
> > > I think hvmloader is the issue rather than PVH. Here is part of the
> > > "memory map" as found in hvmloader/config.h:
> > >
> > > /* Special BIOS mappings, etc. are allocated from here upwards... */
> > > #define RESERVED_MEMBASE 0xFC00
> > > /* NB. ACPI_INFO_PHYSICAL_ADDRESS *MUST* match definition in
> > > acpi/dsdt.asl! */
> > > #define ACPI_INFO_PHYSICAL_ADDRESS0xFC00
> > > #define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
> > > #define RESERVED_MEMORY_DYNAMIC_END 0xFE00
> > >
> > > and hvmloader simply creates a single e820 reserved entry, from
> > > RESERVED_MEMBASE to the top of 4GB. It's probably too much.
> >
> > But isn't this kind of dangerous? How can you assure future versions
> > of hvmloader won't use this space?
> >
> > > If hvmloader only reserved
> > > ACPI_INFO_PHYSICAL_ADDRESS-RESERVED_MEMORY_DYNAMIC_END, I might not have
> > > to special case hvmloader.
> >
> > Could we look into getting this fixed in hvmloader then?
> >
> > I think it's dangerous for OVMF to play such tricks with the memory
> > map.
> >
> > > As far as I know 0xfee0 isn't a special
> > > bios mapping, but something the hardware provides.
> >
> > Yes, that's used by the lapic, so it's not specific to hvmloader.
>
> Right, I've got a closer look at that CpuDxe module, it wants the local
> APIC memory mapped space to be "mapped IO", and that different than
> "reserved".
>
> So while parsing the e820 from hvmloader, instead of ignoring all
> reserved region, I'm going to avoid adding the local apic memory mapped
> space.
>
> something like:
> if (hvmloaderDetected())
I don't think you need to gate this on hvmloader being used, while
it's true that PVH memory map doesn't contain such reserved memory
region ATM I don't see any harm in doing this for PVH also.
> Base = $(start of the e820 entry);
> End = $(start of the e820 entry + size);
> LocalApic = 0xfee0;
> if (Base < LocalApic && LocalApic < End) {
> AddReservedMemoryRangeHob (Base, LocalApic, FALSE);
> if (End > (LocalApic + SIZE_4KB)) {
The range is actually from 0xfee0 to 0xfeef (2MB), so you
likely want to make sure non of this is added as reserved?
Thanks, Roger.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44368): https://edk2.groups.io/g/devel/message/44368
Mute This Topic: https://groups.io/mt/32308708/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch v3 6/6] UefiCpuPkg/RegisterCpuFeaturesLib: Start all processors simultaneously.
Reviewed-by: Ray Ni
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, July 24, 2019 3:07 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Kumar,
> Chandana C ; Zeng, Star
>
> Subject: [Patch v3 6/6] UefiCpuPkg/RegisterCpuFeaturesLib: Start all
> processors simultaneously.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973
>
> For semaphore type register, it required all processors to do the task at the
> same time.
> Current logic begins BSP's task after all APs have finished their tasks.
> This will caused set semaphore task hang if semaphore has package level
> type.
> This patch use new EDKII_PEI_MP_SERVICES2_PPI to start all processors at
> the same time to fix the potential hang issue.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Chandana Kumar
> Cc: Star Zeng
> Signed-off-by: Eric Dong
> ---
> .../CpuFeaturesInitialize.c | 2 +-
> .../DxeRegisterCpuFeaturesLib.c | 6 +-
> .../PeiRegisterCpuFeaturesLib.c | 66 ++-
> .../PeiRegisterCpuFeaturesLib.inf | 1 +
> .../RegisterCpuFeatures.h | 2 +-
> 5 files changed, 54 insertions(+), 23 deletions(-)
>
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index 33752c1a9f..4e97e863c7 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -1074,7 +1074,7 @@ CpuFeaturesDetect (
> //
> // Wakeup all APs for data collection.
> //
> -StartupAPsWorker (CollectProcessorData, NULL);
> +StartupAllAPsWorker (CollectProcessorData, NULL);
>}
>
>//
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c
> index f87b2892aa..e2e06e88e0 100644
> ---
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c
> +++
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLi
> +++ b.c
> @@ -1,7 +1,7 @@
> /** @file
>CPU Register Table Library functions.
>
> - Copyright (c) 2017, Intel Corporation. All rights reserved.
> + Copyright (c) 2017 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
> @@ -116,7 +116,7 @@ GetProcessorInformation (
>to check whether procedure has done.
> **/
> VOID
> -StartupAPsWorker (
> +StartupAllAPsWorker (
>IN EFI_AP_PROCEDURE Procedure,
>IN EFI_EVENTMpEvent
>)
> @@ -248,7 +248,7 @@ CpuFeaturesInitialize (
> //
> // Wakeup all APs for programming.
> //
> -StartupAPsWorker (SetProcessorRegister, MpEvent);
> +StartupAllAPsWorker (SetProcessorRegister, MpEvent);
>}
>
>//
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c
> index 8ad5a40e5a..52b849ce13 100644
> ---
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c
> +++
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLi
> +++ b.c
> @@ -1,7 +1,7 @@
> /** @file
>CPU Register Table Library functions.
>
> - Copyright (c) 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +
> #include "RegisterCpuFeatures.h"
>
> #define REGISTER_CPU_FEATURES_GUID \
> @@ -154,7 +156,7 @@ GetProcessorInformation (
>
> **/
> VOID
> -StartupAPsWorker (
> +StartupAllAPsWorker (
>IN EFI_AP_PROCEDURE Procedure,
>IN EFI_EVENTMpEvent
>)
> @@ -180,6 +182,48 @@ StartupAPsWorker (
>ASSERT_EFI_ERROR (Status);
> }
>
> +/**
> + Worker function to execute a caller provided function on all enabled APs.
> +
> + @param[in] Procedure A pointer to the function to be run on
> + enabled APs of the system.
> + @param[in] MpEvent The Event used to sync the result.
> +
> +**/
> +VOID
> +StartupAllCPUsWorker (
> + IN EFI_AP_PROCEDURE Procedure
> + )
> +{
> + EFI_STATUS Status;
> + EDKII_PEI_MP_SERVICES2_PPI *CpuMp2Ppi;
> + CPU_FEATURES_DATA*CpuFeaturesData;
> +
> + CpuFeaturesData = GetCpuFeaturesData ();
> +
> + //
> + // Get MP Services2 Ppi
> + //
> + Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> + ASSERT_EFI_ERROR (Status);
> +
> + //
> + // Wakeup all APs for data collection.
> +
Re: [edk2-devel] [Patch v3 5/6] UefiCpuPkg/CpuMpPei: Produce EDKII_PEI_MP_SERVICES2_PPI.
With file name changing from Mp2Pei.c to CpuMp2Pei.c, Reviewed-by: Ray Ni
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, July 24, 2019 3:07 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Kumar,
> Chandana C ; Zeng, Star
>
> Subject: [Patch v3 5/6] UefiCpuPkg/CpuMpPei: Produce
> EDKII_PEI_MP_SERVICES2_PPI.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973
>
> Produce new EDKII_PEI_MP_SERVICES2_PPI service.
>
> It includes all APIs existed in EFI_PEI_MP_SERVICES_PPI and add new API
> EDKII_PEI_MP_SERVICES_STARTUP_ALL_CPUS.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Chandana Kumar
> Cc: Star Zeng
> Signed-off-by: Eric Dong
> ---
> UefiCpuPkg/CpuMpPei/CpuMpPei.c | 21 +-
> UefiCpuPkg/CpuMpPei/CpuMpPei.h | 3 +-
> UefiCpuPkg/CpuMpPei/CpuMpPei.inf | 2 +
> UefiCpuPkg/CpuMpPei/Mp2Pei.c | 417
> +++
> 4 files changed, 436 insertions(+), 7 deletions(-) create mode 100644
> UefiCpuPkg/CpuMpPei/Mp2Pei.c
>
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 926541c937..07ccbe7c6a 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -1,13 +1,15 @@
> /** @file
>CPU PEI Module installs CPU Multiple Processor PPI.
>
> - Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2015 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
>
> #include "CpuMpPei.h"
>
> +extern EDKII_PEI_MP_SERVICES2_PPImMpServices2Ppi;
> +
> //
> // CPU MP PPI to be installed
> //
> @@ -21,10 +23,17 @@ EFI_PEI_MP_SERVICES_PPImMpServicesPpi =
> {
>PeiWhoAmI,
> };
>
> -EFI_PEI_PPI_DESCRIPTOR mPeiCpuMpPpiDesc = {
> - (EFI_PEI_PPI_DESCRIPTOR_PPI |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> - ,
> -
> +EFI_PEI_PPI_DESCRIPTOR mPeiCpuMpPpiList[] = {
> + {
> +EFI_PEI_PPI_DESCRIPTOR_PPI,
> +,
> +
> + },
> + {
> +(EFI_PEI_PPI_DESCRIPTOR_PPI |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> +,
> +
> + }
> };
>
> /**
> @@ -667,7 +676,7 @@ InitializeCpuMpWorker (
>//
>// Install CPU MP PPI
>//
> - Status = PeiServicesInstallPpi();
> + Status = PeiServicesInstallPpi(mPeiCpuMpPpiList);
>ASSERT_EFI_ERROR (Status);
>
>return Status;
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.h index a5d8a755b2..7d5c527d60
> 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.h
> @@ -1,7 +1,7 @@
> /** @file
>Definitions to install Multiple Processor PPI.
>
> - Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2015 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
> @@ -15,6 +15,7 @@
> #include #include
> #include
> +#include
>
> #include
> #include
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> index 4fc4ea77ba..fb2db650e5 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.inf
> @@ -26,6 +26,7 @@
>CpuMpPei.c
>CpuBist.c
>CpuPaging.c
> + Mp2Pei.c
>
> [Packages]
>MdePkg/MdePkg.dec
> @@ -54,6 +55,7 @@
>gEfiSecPlatformInformation2PpiGuid
>gEfiVectorHandoffInfoPpiGuid ## SOMETIMES_CONSUMES
>gEfiPeiMemoryDiscoveredPpiGuid## CONSUMES
> + gEdkiiPeiMpServices2PpiGuid ## PRODUCES
>
> [Pcd]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrM
> ask## CONSUMES
> diff --git a/UefiCpuPkg/CpuMpPei/Mp2Pei.c
> b/UefiCpuPkg/CpuMpPei/Mp2Pei.c new file mode 100644 index
> 00..c1116a5b77
> --- /dev/null
> +++ b/UefiCpuPkg/CpuMpPei/Mp2Pei.c
> @@ -0,0 +1,417 @@
> +/** @file
> + EDKII_PEI_MP_SERVICES2_PPI Implementation code.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> + SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include "CpuMpPei.h"
> +
> +/**
> + This service retrieves the number of logical processor in the
> +platform
> + and the number of those logical processors that are enabled on this boot.
> + This service may only be called from the BSP.
> +
> + This function is used to retrieve the following information:
> +- The number of logical processors that are present in the system.
> +- The number of enabled logical processors in the system at the instant
> + this call is made.
> +
> + Because MP Service Ppi provides services to enable and disable
> + processors dynamically, the number of enabled logical processors may
> + vary during the course of a boot session.
> +
> + If this service is called from an AP, then EFI_DEVICE_ERROR is returned.
> + If NumberOfProcessors or NumberOfEnabledProcessors is NULL, then
> + EFI_INVALID_PARAMETER is returned. Otherwise, the total number of
> + processors
Re: [edk2-devel] [Patch v3 4/6] UefiCpuPkg: Add new EDKII_PEI_MP_SERVICES2_PPI
> -Original Message- > From: Dong, Eric > Sent: Wednesday, July 24, 2019 3:07 PM > To: devel@edk2.groups.io > Cc: Ni, Ray ; Laszlo Ersek ; Kumar, > Chandana C ; Zeng, Star > > Subject: [Patch v3 4/6] UefiCpuPkg: Add new EDKII_PEI_MP_SERVICES2_PPI > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973 > > Add definition for new EDKII_PEI_MP_SERVICES2_PPI. > > It includes all APIs existed in EFI_PEI_MP_SERVICES_PPI and add new API > EDKII_PEI_MP_SERVICES_STARTUP_ALL_CPUS. > > Cc: Ray Ni > Cc: Laszlo Ersek > Cc: Chandana Kumar > Cc: Star Zeng > Signed-off-by: Eric Dong > --- > UefiCpuPkg/Include/Ppi/MpServices2.h | 279 > +++ > UefiCpuPkg/UefiCpuPkg.dec| 3 + > 2 files changed, 282 insertions(+) > create mode 100644 UefiCpuPkg/Include/Ppi/MpServices2.h > > diff --git a/UefiCpuPkg/Include/Ppi/MpServices2.h > b/UefiCpuPkg/Include/Ppi/MpServices2.h > new file mode 100644 > index 00..83a56588a5 > --- /dev/null > +++ b/UefiCpuPkg/Include/Ppi/MpServices2.h > @@ -0,0 +1,279 @@ > +/** @file > + This file declares edkii Multi-processor service PPI. With edkii changed to EDKII, Reviewed-by: Ray Ni -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44365): https://edk2.groups.io/g/devel/message/44365 Mute This Topic: https://groups.io/mt/32581677/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch v3 3/6] UefiCpuPkg/MpInitLibUp: Add MpInitLibStartupAllCPUs API.
Reviewed-by: Ray Ni
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Dong,
> Eric
> Sent: Wednesday, July 24, 2019 3:07 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Kumar,
> Chandana C ; Zeng, Star
>
> Subject: [edk2-devel] [Patch v3 3/6] UefiCpuPkg/MpInitLibUp: Add
> MpInitLibStartupAllCPUs API.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1973
>
> Add new MpInitLibStartupAllCPUs API uses to start all processors at the same
> time.
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Chandana Kumar
> Cc: Star Zeng
> Signed-off-by: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c | 35
>
> 1 file changed, 35 insertions(+)
>
> diff --git a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> index 36c2bb5326..b4024ee1ae 100644
> --- a/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> +++ b/UefiCpuPkg/Library/MpInitLibUp/MpInitLibUp.c
> @@ -405,3 +405,38 @@ MpInitLibWhoAmI (
>*ProcessorNumber = 0;
>return EFI_SUCCESS;
> }
> +
> +/**
> + This service executes a caller provided function on all enabled CPUs.
> +
> + @param[in] Procedure A pointer to the function to be run on
> + enabled APs of the system. See type
> + EFI_AP_PROCEDURE.
> + @param[in] TimeoutInMicroseconds Indicates the time limit in
> microseconds for
> + APs to return from Procedure, either
> for
> + blocking or non-blocking mode. Zero
> means
> + infinity. TimeoutInMicroseconds is
> ignored
> + for BSP.
> + @param[in] ProcedureArgument The parameter passed into
> Procedure for
> + all APs.
> +
> + @retval EFI_SUCCESS CPU have finished the procedure.
> + @retval EFI_INVALID_PARAMETER Procedure is NULL.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MpInitLibStartupAllCPUs (
> + IN EFI_AP_PROCEDURE Procedure,
> + IN UINTN TimeoutInMicroseconds,
> + IN VOID *ProcedureArgument OPTIONAL
> + )
> +{
> + if (Procedure == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + Procedure (ProcedureArgument);
> +
> + return EFI_SUCCESS;
> +}
> --
> 2.21.0.windows.1
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#44364): https://edk2.groups.io/g/devel/message/44364
Mute This Topic: https://groups.io/mt/32581674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 0/3] add DwMmcHcDxe driver
On Wed, Jul 24, 2019 at 05:26:03PM +0800, tien.hock@intel.com wrote: > From: "Tien Hock, Loh" > > Changelog: > v3: > * Fix an issue in NonDiscoverableDeviceDxe driver where it did not > invalidate > cache before copying the memory. > v2: > *Split DwMmcHcDxe driver into two patches. One is for PlatformDwMmc > protocol, >and the other is for DwMmcHcDxe driver. > v1: > *Add NonDiscoverableDeviceDxe for embedded platform. Make DwMmcHcDxe driver >to support both eMMC and SD controller. > > Haojian Zhuang (3): > EmbeddedPkg: add NonDiscoverableDeviceDxe driver > EmbeddedPkg: add PlatformDwMmc protocol > EmbeddedPkg/Drivers: add DwMmcHcDxe driver > > .../Drivers/DwMmcHcDxe/ComponentName.c| 214 ++ > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.c | 1295 + > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.dec | 40 + > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.h | 815 ++ > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.inf | 69 + > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.c | 2366 + > EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.h | 983 +++ > EmbeddedPkg/Drivers/DwMmcHcDxe/EmmcDevice.c | 1042 > EmbeddedPkg/Drivers/DwMmcHcDxe/SdDevice.c | 1104 > EmbeddedPkg/EmbeddedPkg.dec |1 + > EmbeddedPkg/Include/Protocol/PlatformDwMmc.h | 79 + > .../NonDiscoverableDeviceDxe/ComponentName.c | 124 + > .../NonDiscoverableDeviceDxe.c| 243 ++ > .../NonDiscoverableDeviceDxe.inf | 52 + > .../NonDiscoverableDeviceIo.c | 976 +++ > .../NonDiscoverableDeviceIo.h | 92 + > 16 files changed, 9495 insertions(+) > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/ComponentName.c > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.c > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.dec > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.h > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHcDxe.inf > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.c > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/DwMmcHci.h > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/EmmcDevice.c > create mode 100644 EmbeddedPkg/Drivers/DwMmcHcDxe/SdDevice.c > create mode 100644 EmbeddedPkg/Include/Protocol/PlatformDwMmc.h > create mode 100644 > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/ComponentName.c > create mode 100644 > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDeviceDxe.c > create mode 100644 > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDeviceDxe.inf > create mode 100644 > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDeviceIo.c > create mode 100644 > EmbeddedPkg/Universal/NonDiscoverableDeviceDxe/NonDiscoverableDeviceIo.h > > -- > 2.19.0 > Tested on HiKey platform. Best Regards Haojian -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44363): https://edk2.groups.io/g/devel/message/44363 Mute This Topic: https://groups.io/mt/32582252/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
