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 su
> -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] [edk2-staging/RISC
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
//
PciFeatureRo
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 [mailto:devel@edk2.group
> -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 a
> -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
>
> Subje
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: https://edk
Ashraf,
At the end of PciFeatureGetDevicePolicy, value from the PCI features
configuration table is the minimum one.
I prefer to defer the finalize of PciDevice->SetupMPS in the
OverrideMaxPayloadSize().
Through this, the 4 phases can be reduced to 3 phases.
Thanks,
Ray
> -Original Message-
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 On
> >
> > 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
> be
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.
No impact.
Current code does not use Nonce.
I just find the issue when I review the final 1.0 spec.
Thank you
Yao Jiewen
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, December 18, 2019 10:32 PM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Kinney, Michael D
> Subject: RE:
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
---
SecurityPkg/Library/HashApiInstanceSm3/HashApiInst
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
---
SecurityPkg/Library/HashApiInstanceSha256/Hash
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
---
SecurityPkg/Library/HashApiInstanceSha1/HashApiInsta
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 achieve
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
hashing
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
---
SecurityPkg/Library/HashApiInstanceSha1/HashApiInsta
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 achieve
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
hashing
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
---
SecurityPkg/Library/HashApiInstanceSha384/Hash
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
---
SecurityPkg/Library/HashApiInstanceSha256/Hash
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
---
Secu
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
---
Secu
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
---
SecurityPkg/Library/HashApiInstanceSha384/Hash
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
---
SecurityPkg/Library/HashApiInstanceSm3/HashApiInst
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
E
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 ++
MdeModulePkg/Library/UefiBoot
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 ru
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.
Si
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 u
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
---
Platform/RaspberryPi
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), an
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
---
Platform/RaspberryPi/RPi4/Acpi
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 m
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 descr
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 - IGK
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:
PCI_REG_PCIE_DEVIC
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
abou
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
Mu
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: https:
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 is
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: [P
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
Im
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 deletion(-)
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.
>
> Signed-off
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 +---
Platform/RaspberryPi/RPi4/Acp
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 th
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 requirements
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 a/Platform
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
---
Platform/RaspberryPi/Library/PlatformLib/PlatformLib.i
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 or
* 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 always.
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, Limi
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 O
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: Wang
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 Boot
> > + UINT8 SetupMPS;
1. Can it be "MaxPayloadSize"?
> > +
> > + if (PciConfigPhase == PciFeatureGetDevicePolicy) {
> > +if (SetupMpsAsPerDeviceCapability (PciDevice->SetupMPS)) {
2. Can you replace " SetupMpsAsPerDeviceCapability (PciDevice->SetupMPS" wit
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 Ga
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 DevicePathPro
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 important
68 matches
Mail list logo
