Adds a dynamic PCD that specifies whether the feature is active.
This is useful because the feature might be enabled via FeatureFlag
PCD PcdAcpiDebugFeatureEnable meaning it is built and included in
the flash image but the board might need to control whether the
feature is active based on input
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Friday, November 22, 2019 12:49 AM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
>
> Cc: Chen, Gilbert
> Subject: Re: [edk2-devel]
After I reviewed the patch of enabling MaxPayloadSize, MaxReadReqSize and more
PCIE features,
I can now understand the phases more than earlier.
Your patch proposed five phases:
//
// initial phase in configuring the other PCI features to record the primary
// root ports
//
Sorry for missing do the script check. The patch #1 's title length is too
long. We should make sure the title length is less than 72 (not include 72).
Can you change that and resend the patch set?
Thanks,
Zhichao
> -Original Message-
> From: devel@edk2.groups.io
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, December 19, 2019 7:04 AM
> To: Javeed, Ashraf ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Wu, Hao A
> Subject: RE: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 03/12]
> PciBusDxe: Separation of the PCI device registration
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Friday, November 22, 2019 12:24 AM
> To: Chang, Abner (HPS SW/FW Technologist)
> Cc: devel@edk2.groups.io; Chen, Gilbert ; Palmer
> Dabbelt ; Kinney, Michael D
>
>
Reviewed-by: Ray Ni
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#52395): https://edk2.groups.io/g/devel/message/52395
Mute This Topic: https://groups.io/mt/68796766/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
All,
The new EDKII Platform Boot Manager protocol provides a platform hook to solve
below problem.
Can you please review and think about:
1. Is it a proper solution to the problem?
2. Is the new protocol/function name proper?
3. Are the parameters in the function proper?
**Problem:
In my opinion, ASSERT in this mandatory lib is fine. We have the depex of the
protocol, that means the three protocols should have been installed during
boot. Then the ASSERT would be a critical bug because of the failure of running
Boot Services.
Thanks,
Zhichao
From: devel@edk2.groups.io
> >
> > 2 minor comments:
> > 1. StartPciRootPortsOnBridge()
> > Can it be renamed to EnablePciDevicesOnBridge()?
> > Because it basically calls PciIo.Attribute() to enable the devices.
> > And I am
> not
> > sure the enable only applies to PCI root ports. There could be PCI devices
>
That's good. Thanks!
>-Original Message-
>From: Yao, Jiewen
>Sent: Thursday, December 19, 2019 6:32 AM
>To: Gao, Liming ; devel@edk2.groups.io
>Cc: Kinney, Michael D
>Subject: RE: [PATCH] MdePkg/Spdm: fix Nonce structure error.
>
>No impact.
>Current code does not use Nonce.
>I just find
I reuse the BZ 2161 and add my requirement there as below.
https://bugzilla.tianocore.org/show_bug.cgi?id=2161
1. If without platform build log or DSC info, the tool only need to output
module fanout build dependency info which includes what APIs
(PPI/Protocol/Guid/PCD/Lib) a module depends on.
A gEfiCallerIdGuid needs to be introduced in the BaseHashLibPei method to save
the hash mask of registered API instances of hashing algorithms.
gEfiCallerIdGuid saves the last registered hash mask as a HOB that can be
modified or updated with the subsequent registration of API instances of
This is the HashApiInstance implementation for SHA1 which registers the SHA1
hash library in CryptoPkg with BaseHashLib based on whether a platform supports
SHA1 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
Currently the UEFI drivers using the SHA/SM3 hashing algorithms use hard-coded
API to calculate the hash, such as, sha_256(…), etc. Since SHA384 and/or SM3
are being increasingly adopted, it becomes cumbersome to modify the driver with
SHA384 or SM3 calls for each application.
To better
A gEfiCallerIdGuid needs to be introduced in the BaseHashLibPei method to save
the hash mask of registered API instances of hashing algorithms.
gEfiCallerIdGuid saves the last registered hash mask as a HOB that can be
modified or updated with the subsequent registration of API instances of
This is the HashApiInstance implementation for SHA384 which registers the
SHA384 hash library in CryptoPkg with BaseHashLib based on whether a platform
supports SHA384 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SHA256 which registers the
SHA256 hash library in CryptoPkg with BaseHashLib based on whether a platform
supports SHA256 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SM3 which registers the SM3
hash library in CryptoPkg with BaseHashLib based on whether a platform supports
SM3 hash algorithm.
Signed-off-by: Subash Lakkimsetti
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SHA256 which registers the
SHA256 hash library in CryptoPkg with BaseHashLib based on whether a platform
supports SHA256 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SHA1 which registers the SHA1
hash library in CryptoPkg with BaseHashLib based on whether a platform supports
SHA1 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
Currently the UEFI drivers using the SHA/SM3 hashing algorithms use hard-coded
API to calculate the hash, such as, sha_256(…), etc. Since SHA384 and/or SM3
are being increasingly adopted, it becomes cumbersome to modify the driver with
SHA384 or SM3 calls for each application.
To better
This implementation eliminates the need to use hard-coded API to calculate hash
by PEI and DXE drivers by introducing a common and unified API for hash
calculation.
The common API will execute the hash algorithm specified by the PCD,
PcdSystemHashPolicy.
Signed-off-by: Sukerkar, Amol N
---
This implementation eliminates the need to use hard-coded API to calculate hash
by PEI and DXE drivers by introducing a common and unified API for hash
calculation.
The common API will execute the hash algorithm specified by the PCD,
PcdSystemHashPolicy.
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SHA384 which registers the
SHA384 hash library in CryptoPkg with BaseHashLib based on whether a platform
supports SHA384 hash algorithm (provided by PcdTpm2HashMask).
Signed-off-by: Sukerkar, Amol N
---
This is the HashApiInstance implementation for SM3 which registers the SM3
hash library in CryptoPkg with BaseHashLib based on whether a platform supports
SM3 hash algorithm.
Signed-off-by: Subash Lakkimsetti
Signed-off-by: Sukerkar, Amol N
---
I have submitted a patch version 4.
Thanks
Ashish
-Original Message-
From: Ni, Ray
Sent: Wednesday, December 18, 2019 1:43 AM
To: Ashish Singhal ; devel@edk2.groups.io; Wang, Jian
J ; Wu, Hao A ; Gao, Zhichao
Subject: RE: [PATCH v3] MdeModulePkg: Add Platform Boot Options Protocol
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.
Signed-off-by: Ashish Singhal
---
.../Include/Protocol/PlatformBootManager.h | 82 ++
Hi Nate,
On 12/18/19 4:01 AM, Nate DeSimone wrote:
Any chance I could get a code review on this?
Thanks,
Nate
-Original Message-
From: devel@edk2.groups.io On Behalf Of Nate DeSimone
Sent: Friday, December 6, 2019 10:15 AM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; Leif
On Wed, 30 Oct 2019 at 15:50, PierreGondois wrote:
>
> From: Pierre Gondois
>
> The '-tc' option of the Intel iASL compiler facilitates
> generation of AML code in a C array. This AML code is
> output to a .hex file. The .hex file can be included
> from a C source file, thereby allowing one to
On 2019.12.18 17:00, Philippe Mathieu-Daudé wrote:
On 12/18/19 5:36 PM, Pete Batard wrote:
Hi Philippe,
On 2019.12.18 15:57, Philippe Mathieu-Daudé wrote:
On 12/18/19 12:41 PM, Pete Batard wrote:
Use code derived from JunoPkg to generate our serial tables and
also use PCDs where possible.
On 12/18/19 5:59 PM, Pete Batard wrote:
On 2019.12.18 16:05, Philippe Mathieu-Daudé wrote:
On 12/18/19 12:41 PM, Pete Batard wrote:
The PL011 can be a better choice for the serial console on the RPi4,
given that its baud clock is not derived from the CPU clock (which
may change under our feet
On 12/18/19 5:36 PM, Pete Batard wrote:
Hi Philippe,
On 2019.12.18 15:57, Philippe Mathieu-Daudé wrote:
On 12/18/19 12:41 PM, Pete Batard wrote:
Use code derived from JunoPkg to generate our serial tables and
also use PCDs where possible.
Signed-off-by: Pete Batard
---
On 2019.12.18 16:05, Philippe Mathieu-Daudé wrote:
On 12/18/19 12:41 PM, Pete Batard wrote:
The PL011 can be a better choice for the serial console on the RPi4,
given that its baud clock is not derived from the CPU clock (which
may change under our feet unless we keep it fixed at a low rate),
Hi Philippe,
On 2019.12.18 15:57, Philippe Mathieu-Daudé wrote:
On 12/18/19 12:41 PM, Pete Batard wrote:
Use code derived from JunoPkg to generate our serial tables and
also use PCDs where possible.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf | 4 +-
Reviewed-by: Maurice Ma
Thanks,
-Maurice
> -Original Message-
> From: Dong, Guo
> Sent: Tuesday, December 17, 2019 16:12
> To: devel@edk2.groups.io
> Cc: Ma, Maurice ; You, Benjamin
> ; Dong, Guo ;
> u14...@gmail.com
> Subject: [edk2-devel] [PATCH V2] UefiPayloadPkg/BootManager: Add PS2
Hi Ard,
On 2019.12.18 14:46, Ard Biesheuvel wrote:
Hi Pete,
On Wed, 18 Dec 2019 at 13:42, Pete Batard wrote:
Use a proper aslc source to build the table.
Note that we use ACPI 5.1 for this table to match the MADT
constraints.
Signed-off-by: Pete Batard
---
On 2019.12.18 14:55, Ard Biesheuvel wrote:
On Wed, 18 Dec 2019 at 13:42, Pete Batard wrote:
From: Andrei Warkentin
Since the RPi4 PCIe host bridge is not ECAM compliant, we cannot
expose it as a host bridge to the OS via ACPI, so we add a dummy
MCFG table.
I don't think the MCFG table is
On 12/18/19 12:41 PM, Pete Batard wrote:
The PL011 can be a better choice for the serial console on the RPi4,
given that its baud clock is not derived from the CPU clock (which
may change under our feet unless we keep it fixed at a low rate), and
given the fact that the SBSA/SBBR specs that
I attached a patch witch change that is needed in EDK2 code as it is described.
PCI_REG_PCIE_DEVICE_CONTROL2 struct is UINT16 but has 17 bits !!
Issue is UINT16 LtrMechanism
There is 2 instead of 1.
-UINT16 LtrMechanism : 2;
+UINT16 LtrMechanism : 1;
Daniel Banaszek
BIOS Engineer -
On 12/18/19 12:41 PM, Pete Batard wrote:
Use code derived from JunoPkg to generate our serial tables and
also use PCDs where possible.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf | 4 +-
Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc | 100
Yes. We keep the same name to avoid the incompatible issue.
Thanks
Liming
From: devel@edk2.groups.io On Behalf Of Javeed, Ashraf
Sent: Wednesday, December 18, 2019 10:55 PM
To: Javeed; Javeed, Ashraf ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [Patch] MdePkg PciExpress21:
On Wed, 18 Dec 2019 at 13:42, Pete Batard wrote:
>
> From: Andrei Warkentin
>
> Since the RPi4 PCIe host bridge is not ECAM compliant, we cannot
> expose it as a host bridge to the OS via ACPI, so we add a dummy
> MCFG table.
I don't think the MCFG table is mandatory, so if the OS complains
I want to withdraw my request as by renaming it would cause build failures in
the code that is already using this register definition.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#52356): https://edk2.groups.io/g/devel/message/52356
Good catch!
Please rename the LtrMechanism to LtrMechanismEnable to match with the PCI Base
Specification.
Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#52355): https://edk2.groups.io/g/devel/message/52355
Mute This Topic:
Hi Pete,
On Wed, 18 Dec 2019 at 13:42, Pete Batard wrote:
>
> Use a proper aslc source to build the table.
>
> Note that we use ACPI 5.1 for this table to match the MADT
> constraints.
>
> Signed-off-by: Pete Batard
> ---
> Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc | 104
Ray,
As discussed, the ProcessMaxPayloadSize() gets the minimum payload size for all
devices under a certain root port, at the end of PciFeatureSetupPhase.
The value from the PCI features configuration table is aligned to each of
PciDevice->SetupMPS, under a root port.
The PciDevice->SetupMPS
Jiewen:
The change is good. Have you found any impact in the existing code?
Reviewed-by: Liming Gao
Thanks
Liming
> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, December 18, 2019 11:00 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject:
I just send the patch mail to the mail list
https://edk2.groups.io/g/devel/message/52350. Please review this one.
Thanks
Liming
From: Banaszek, Daniel Pawel
Sent: Wednesday, December 18, 2019 4:37 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Ni, Ray
Subject: RE: ASAP Issue in PciExpress21.h
From: Daniel Pawel Banaszek
Device Control 2 Structure have an issue.
LtrMechanism - there is 2 bits instead of 1.
Signed-off-by: Daniel Pawel Banaszek
Reviewed-by: Liming Gao
Cc: Ray Ni
---
MdePkg/Include/IndustryStandard/PciExpress21.h | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, Dec 18, 2019 at 11:41:56 +, Pete Batard wrote:
> From: Ard Biesheuvel
>
> Add an ACPI_BASIC_MODE_ENABLE flag to produces builds intended to run in
> ACPI mode without any additional requirements (memory limits, acpi=force,
> etc).
>
> This flag is disabled by default.
>
>
From: Ard Biesheuvel
Add an ACPI_BASIC_MODE_ENABLE flag to produces builds intended to run in
ACPI mode without any additional requirements (memory limits, acpi=force,
etc).
This flag is disabled by default.
Signed-off-by: Pete Batard
---
Use code derived from JunoPkg to generate our serial tables and
also use PCDs where possible.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf | 4 +-
Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc | 100 +---
From: Andrei Warkentin
Since the RPi4 PCIe host bridge is not ECAM compliant, we cannot
expose it as a host bridge to the OS via ACPI, so we add a dummy
MCFG table. However, given the hardwired nature of this platform,
we can expose the xHCI controller that is guaranteed to live at
the base of
The PL011 can be a better choice for the serial console on the RPi4,
given that its baud clock is not derived from the CPU clock (which
may change under our feet unless we keep it fixed at a low rate), and
given the fact that the SBSA/SBBR specs that describe ARM specific
architectural
Use a proper aslc source to build the table.
Note that we use ACPI 5.1 for this table to match the MADT
constraints.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc | 104 ++--
1 file changed, 76 insertions(+), 28 deletions(-)
diff --git
This series aims at bringing the Raspberry Pi 4 platform to a state
where its firmware can actually be used with Linux OSes
For instance, we have tested installation of vanilla Debian 10.2 on
a USB 3.0 flash drive with a UEFI firmware built with these patches
and, notwhistanding the lack of NIC
* Use ACPI 5.1 everywhere, since we are constrained to use v5.x for
MADT compatibility.
* Clean up whitespaces and reorganize header declaration.
* Prefix all RPi related constant with RPI_ to make them clearer to
differentiate from regular EDK2 ones.
* Reference IndustryStandard/Acpi.h
Hello Bob,
Please find my answers inline.
I created a Bugzilla ticket here:
https://bugzilla.tianocore.org/show_bug.cgi?id=2425
I have started to look at the implementation,
Regards,
Pierre
From: Feng, Bob C
Sent: 17 December 2019 11:42
To: Pierre Gondois ; devel@edk2.groups.io
Cc: Gao,
Ashraf,
Can ProcessMaxPayloadSize() get the minimum payload size for all devices under
a certain root port?
I can understand that the payload size stored in the PCI features configuration
table is the minimum value.
But the value stored in each PciDevice->SetupMPS is not the minimum value.
So
Sunny,
Thanks for your comments.
Thanks,
Ray
> -Original Message-
> From: Wang, Sunny (HPS SW)
> Sent: Wednesday, December 18, 2019 11:54 AM
> To: disc...@edk2.groups.io; ashishsin...@nvidia.com; Jeff Brasen
> ; Ni, Ray ;
> devel@edk2.groups.io; Laszlo Ersek ; af...@apple.com
> Cc:
I am ok with adding EDKII_PLATFORM_BOOT_MANAGER_PROTOCOL.
> -Original Message-
> From: Ashish Singhal
> Sent: Wednesday, December 18, 2019 12:22 PM
> To: Ni, Ray ; devel@edk2.groups.io; Wang, Jian J
> ; Wu, Hao A
> ; Gao, Zhichao
> Subject: RE: [PATCH v3] MdeModulePkg: Add Platform
> > + UINT8 SetupMPS;
1. Can it be "MaxPayloadSize"?
> > +
> > + if (PciConfigPhase == PciFeatureGetDevicePolicy) {
> > +if (SetupMpsAsPerDeviceCapability (PciDevice->SetupMPS)) {
2. Can you replace " SetupMpsAsPerDeviceCapability (PciDevice->SetupMPS"
Reviewed-by: Vitaly Cheptsov
On Wed, Dec 18, 2019 at 05:10, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
>
> Add the new instance lib for build.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Vitaly Cheptsov
> Reviewed-by: Liming Gao
> Tested-by: Zhichao
Reviewed-by: Vitaly Cheptsov
On Wed, Dec 18, 2019 at 05:10, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
>
> UefiDevicePathLibOptionalDevicePathProtocol's implementation isn't
> fit its description. It should be implement as blow:
> Try to find the
This makes very good sense to me, thank you for taking your time to fix it.
I am slightly unsure whether if checks with subsequent assertions are really
needed in mandatory version, as asserting in the constructor will trigger
missing protocol very early anyway, but I do not think it is
66 matches
Mail list logo
