Date   

Re: [edk2-platforms][PATCH v1 2/3] TigerLakeOpenBoardPkg: Remove unnecessary debug macro argument

Chaganty, Rangasai V
 

Reviewed-by: Sai Chaganty <rangasai.v.chaganty@...>

-----Original Message-----
From: mikuback@... <mikuback@...>
Sent: Tuesday, October 04, 2022 8:36 PM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Luo, Heng <heng.luo@...>; Oram, Isaac W <isaac.w.oram@...>
Subject: [edk2-platforms][PATCH v1 2/3] TigerLakeOpenBoardPkg: Remove unnecessary debug macro argument

From: Michael Kubacki <michael.kubacki@...>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4094

Removes an argument passed to a debug macro without a print specifier. The argument appears to be useless.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Heng Luo <heng.luo@...>
Cc: Isaac Oram <isaac.w.oram@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMemDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMemDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c b/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMemDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
index f0eb3f3f141f..f31cec231e8c 100644
--- a/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMemDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
+++ b/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMe
+++ mDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
@@ -32,7 +32,7 @@ PeiSiPreMemDefaultPolicyInitLibConstructor (
if (PeiPreMemSiDefaultPolicyInitPpi == NULL) {
return Status;
}
- DEBUG ((DEBUG_INFO, "PeiPreMemSiDefaultPolicyInitPpi->PeiPreMemPolicyInit ()\n", Status));
+ DEBUG ((DEBUG_INFO,
+ "PeiPreMemSiDefaultPolicyInitPpi->PeiPreMemPolicyInit ()\n"));
Status = PeiPreMemSiDefaultPolicyInitPpi->PeiPreMemPolicyInit ();
ASSERT_EFI_ERROR (Status);

--
2.28.0.windows.1


[PATCH] UefiPayloadPkg: Make UniversalPayloadBuild.sh executable

Sean Rhodes
 

Make the wrapper executable so that it can be built without modification
on Linux.

Cc: Guo Dong <guo.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: James Lu <james.lu@...>
Cc: Gua Guo <gua.guo@...>
Signed-off-by: Sean Rhodes <sean@...>
---
UefiPayloadPkg/UniversalPayloadBuild.sh | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 UefiPayloadPkg/UniversalPayloadBuild.sh

diff --git a/UefiPayloadPkg/UniversalPayloadBuild.sh b/UefiPayloadPkg/UniversalPayloadBuild.sh
old mode 100644
new mode 100755
--
2.34.1


[edk2-platforms PATCH v2] Platform/RaspberryPi: fix pci DT node address in SyncPcie()

Adrien Thierry
 

To make sure the XHCI controller does not get reset by Linux in DT mode,
we remove its pci parent node from the device tree. However, the pci
node address has been updated in the Raspberry Pi 4 device tree [1] and
no longer matches the one we are trying to remove in SyncPcie(). This
results in the XHCI controller actually being reset by Linux, which
leads to errors during USB initialization:

[ 3.563963] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 3.569538] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 3.577452] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000040000000890
[ 3.587725] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 3.593115] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 3.600693] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
[ 3.608106] hub 1-0:1.0: USB hub found
[ 3.612026] hub 1-0:1.0: 1 port detected
[ 3.616819] hub 2-0:1.0: USB hub found
[ 3.620726] hub 2-0:1.0: 4 ports detected
[ 3.875902] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 4.008123] usb 1-1: device descriptor read/64, error -71
[ 4.256088] usb 1-1: device descriptor read/64, error -71
[ 4.495882] usb 1-1: new high-speed USB device number 3 using xhci_hcd
[ 4.628111] usb 1-1: device descriptor read/64, error -71
[ 4.872083] usb 1-1: device descriptor read/64, error -71
[ 5.407888] usb 1-1: new high-speed USB device number 4 using xhci_hcd
[ 6.023964] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[ 6.239977] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.

This patch allows matching any address for the pci node, thus working
with both legacy and new device trees.

[1] https://lore.kernel.org/all/20210831125843.1233488-1-nsaenzju@redhat.com/

Fixes: efff29cdcdb7 ("Platform/RaspberryPi: Always use non translating DMA in DT mode")
Signed-off-by: Adrien Thierry <athierry@...>
---

v1->v2: Match both pci@1,0 and pci@0,0

I chose to remove the address altogether, since there is only one pci
node for the Raspberry Pi 4 and thus no ambiguity. Let me know if you
prefer explicitly matching pci@1,0 and pci@0,0.

Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index e72d132b18..cbbc2ad30d 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -388,14 +388,14 @@ SyncPcie (
* triggering the mailbox by removing the node.
*/

- Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d500000/pci@1,0");
+ Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d500000/pci");
if (Node < 0) {
// This can happen on CM4/etc which doesn't have an onboard XHCI
- DEBUG ((DEBUG_INFO, "%a: failed to locate /scb/pcie@7d500000/pci@1/usb@1\n", __FUNCTION__));
+ DEBUG ((DEBUG_INFO, "%a: failed to locate /scb/pcie@7d500000/pci\n", __FUNCTION__));
} else {
Retval = fdt_del_node (mFdtImage, Node);
if (Retval != 0) {
- DEBUG ((DEBUG_ERROR, "Failed to remove /scb/pcie@7d500000/pci@1/usb@1\n"));
+ DEBUG ((DEBUG_ERROR, "Failed to remove /scb/pcie@7d500000/pci\n"));
return EFI_NOT_FOUND;
}
}

base-commit: ae75c51f27e21036b6ee021a2d5b9f365f951413
--
2.37.3


Re: [PATCH v2] MdeModulePkg/UefiBootManagerLib: Add Disk Info support for Ufs

Ard Biesheuvel
 

Merged #3447 into master.

On Thu, 6 Oct 2022 at 16:44, Jeff Brasen <jbrasen@...> wrote:

Add support for getting disk info from UFS devices.

Signed-off-by: Jeff Brasen <jbrasen@...>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c | 4 +++-
.../Library/UefiBootManagerLib/UefiBootManagerLib.inf | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
index fac33b9ee9..030b2ee3ec 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
@@ -195,7 +195,9 @@ BmGetDescriptionFromDiskInfo (

BmEliminateExtraSpaces (Description);
}
- } else if (CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoScsiInterfaceGuid)) {
+ } else if (CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoScsiInterfaceGuid) ||
+ CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoUfsInterfaceGuid))
+ {
BufferSize = sizeof (EFI_SCSI_INQUIRY_DATA);
Status = DiskInfo->Inquiry (
DiskInfo,
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
index fe05d5f1cc..2fc0a80a4e 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+++ b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -85,6 +85,7 @@
gEfiDiskInfoIdeInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
gEfiDiskInfoScsiInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
gEfiDiskInfoSdMmcInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
+ gEfiDiskInfoUfsInterfaceGuid ## SOMETIMES_CONSUMES ## GUID

[Protocols]
gEfiPciRootBridgeIoProtocolGuid ## CONSUMES
--
2.25.1


Re: Intel NUC platform firmware -- no serial I/O support?

Laszlo Ersek
 

On 04/07/22 12:49, Laszlo Ersek wrote:

On the NUC, this whole child controller chain, and protocol stack,
breaks down because there is no SerialIo protocol interface in the
protocol db. The following command returns nothing, even after "connect
-r":

Shell> dh -d -v -p SerialIo
(On OVMF, the command returns handle BE, see above.)
It's hard to understand the "secret decisions" about physical platform
firmware. I'm working with a new NUC now, and this one does provide a
functional SerialIo protocol implementation out of the box (with the
"AMI Serial I/O Driver" actually doing its job, unlike in the previous
NUC). However, TerminalDxe is *still* not included in the platform
firmware. Unfathomable. (Well, "TerminalSrc", aka "AMI Terminal Driver"
is included, but like on the earlier NUC, it seems to be doing nothing;
it doesn't bind SerialIo.)

Laszlo


[PATCH v2] MdeModulePkg/UefiBootManagerLib: Add Disk Info support for Ufs

Jeff Brasen
 

Add support for getting disk info from UFS devices.

Signed-off-by: Jeff Brasen <jbrasen@...>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c | 4 +++-
.../Library/UefiBootManagerLib/UefiBootManagerLib.inf | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
index fac33b9ee9..030b2ee3ec 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
@@ -195,7 +195,9 @@ BmGetDescriptionFromDiskInfo (

BmEliminateExtraSpaces (Description);
}
- } else if (CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoScsiInterfaceGuid)) {
+ } else if (CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoScsiInterfaceGuid) ||
+ CompareGuid (&DiskInfo->Interface, &gEfiDiskInfoUfsInterfaceGuid))
+ {
BufferSize = sizeof (EFI_SCSI_INQUIRY_DATA);
Status = DiskInfo->Inquiry (
DiskInfo,
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
index fe05d5f1cc..2fc0a80a4e 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+++ b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -85,6 +85,7 @@
gEfiDiskInfoIdeInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
gEfiDiskInfoScsiInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
gEfiDiskInfoSdMmcInterfaceGuid ## SOMETIMES_CONSUMES ## GUID
+ gEfiDiskInfoUfsInterfaceGuid ## SOMETIMES_CONSUMES ## GUID

[Protocols]
gEfiPciRootBridgeIoProtocolGuid ## CONSUMES
--
2.25.1


Re: [PATCH] MdeModulePkg/UefiBootManagerLib: Add Disk Info support for Ufs

Ard Biesheuvel
 

On Thu, 6 Oct 2022 at 16:23, Jeff Brasen via groups.io
<jbrasen@...> wrote:

Any additional thoughts on this patch?
If you resend it using a mail client that doesn't corrupt all the
whitespace, I can merge it for you (with Zhichao's ack).


-----Original Message-----
From: Jeff Brasen
Sent: Tuesday, July 19, 2022 9:14 AM
To: gaoliming <gaoliming@...>; devel@edk2.groups.io
Cc: jian.j.wang@...; zhichao.gao@...; ray.ni@...
Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib:
Add Disk Info support for Ufs

Yes, Universal Flash Storage is based on the SCSI architectural model and
installs gEfiExtScsiPassThruProtocolGuid to function.

Thanks,
Jeff

-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Monday, July 18, 2022 7:44 PM
To: devel@edk2.groups.io; Jeff Brasen <jbrasen@...>
Cc: jian.j.wang@...; zhichao.gao@...; ray.ni@...
Subject: 回复: [edk2-devel] [PATCH]
MdeModulePkg/UefiBootManagerLib:
Add Disk Info support for Ufs

External email: Use caution opening links or attachments


Jeff:
I want to confirm why UFS apply the same rule to SCSI. Does UFS
follows SCSI spec?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Jeff
Brasen
via
groups.io
发送时间: 2022年6月15日 1:54
收件人: devel@edk2.groups.io
抄送: jian.j.wang@...; gaoliming@...;
zhichao.gao@...; ray.ni@...; Jeff Brasen
<jbrasen@...>
主题: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Add
Disk
Info support for Ufs

Add support for getting disk info from UFS devices.

Signed-off-by: Jeff Brasen <jbrasen@...>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c | 3
++-
MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf |
1
+
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git
a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
index fac33b9ee9..87b82f299f 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
+++
b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
@@ -195,7 +195,8 @@ BmGetDescriptionFromDiskInfo (


BmEliminateExtraSpaces (Description);

}

- } else if (CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoScsiInterfaceGuid)) {

+ } else if (CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoScsiInterfaceGuid) ||

+ CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoUfsInterfaceGuid)) {

BufferSize = sizeof (EFI_SCSI_INQUIRY_DATA);

Status = DiskInfo->Inquiry (

DiskInfo,

diff --git
a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
index fe05d5f1cc..2fc0a80a4e 100644
---
a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+++
b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -85,6 +85,7 @@
gEfiDiskInfoIdeInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

gEfiDiskInfoScsiInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

gEfiDiskInfoSdMmcInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

+ gEfiDiskInfoUfsInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID



[Protocols]

gEfiPciRootBridgeIoProtocolGuid ## CONSUMES

--
2.25.1










Re: [PATCH v1 1/1] MiscBootServices: Stall_Func: Reduces the stall interval for Stall_Func

G Edhaya Chandran
 

On Fri, Sep 30, 2022 at 05:28 AM, Robert Wood wrote:
MiscBootServicesBBTestFunction.c
Hi Robert,

   Can you please also raise a Bugzilla ticket for this issue here: Bug List (tianocore.org)
Please do attach the failure logs in the ticket.

This issue was discussed in the forum. May we know how the value of 4000000 was arrived for the new Stall value?

With Warm Regards,
Edhay


Re: [PATCH] MdeModulePkg/UefiBootManagerLib: Add Disk Info support for Ufs

Jeff Brasen
 

Any additional thoughts on this patch?

-----Original Message-----
From: Jeff Brasen
Sent: Tuesday, July 19, 2022 9:14 AM
To: gaoliming <gaoliming@...>; devel@edk2.groups.io
Cc: jian.j.wang@...; zhichao.gao@...; ray.ni@...
Subject: RE: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib:
Add Disk Info support for Ufs

Yes, Universal Flash Storage is based on the SCSI architectural model and
installs gEfiExtScsiPassThruProtocolGuid to function.

Thanks,
Jeff

-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: Monday, July 18, 2022 7:44 PM
To: devel@edk2.groups.io; Jeff Brasen <jbrasen@...>
Cc: jian.j.wang@...; zhichao.gao@...; ray.ni@...
Subject: 回复: [edk2-devel] [PATCH]
MdeModulePkg/UefiBootManagerLib:
Add Disk Info support for Ufs

External email: Use caution opening links or attachments


Jeff:
I want to confirm why UFS apply the same rule to SCSI. Does UFS
follows SCSI spec?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Jeff
Brasen
via
groups.io
发送时间: 2022年6月15日 1:54
收件人: devel@edk2.groups.io
抄送: jian.j.wang@...; gaoliming@...;
zhichao.gao@...; ray.ni@...; Jeff Brasen
<jbrasen@...>
主题: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Add
Disk
Info support for Ufs

Add support for getting disk info from UFS devices.

Signed-off-by: Jeff Brasen <jbrasen@...>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c | 3
++-
MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf |
1
+
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git
a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
index fac33b9ee9..87b82f299f 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
+++
b/MdeModulePkg/Library/UefiBootManagerLib/BmBootDescription.c
@@ -195,7 +195,8 @@ BmGetDescriptionFromDiskInfo (


BmEliminateExtraSpaces (Description);

}

- } else if (CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoScsiInterfaceGuid)) {

+ } else if (CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoScsiInterfaceGuid) ||

+ CompareGuid (&DiskInfo->Interface,
&gEfiDiskInfoUfsInterfaceGuid)) {

BufferSize = sizeof (EFI_SCSI_INQUIRY_DATA);

Status = DiskInfo->Inquiry (

DiskInfo,

diff --git
a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
index fe05d5f1cc..2fc0a80a4e 100644
---
a/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+++
b/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -85,6 +85,7 @@
gEfiDiskInfoIdeInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

gEfiDiskInfoScsiInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

gEfiDiskInfoSdMmcInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID

+ gEfiDiskInfoUfsInterfaceGuid ##
SOMETIMES_CONSUMES ## GUID



[Protocols]

gEfiPciRootBridgeIoProtocolGuid ## CONSUMES

--
2.25.1






Now: TianoCore edk2-test Bug Triage Meeting - 10/06/2022 #cal-notice

Group Notification <noreply@...>
 

TianoCore edk2-test Bug Triage Meeting

When:
10/06/2022
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

Where:
https://armltd.zoom.us/j/93809865843?pwd=dU1hSzk4NHM2RGhaRDRyWWZxUzY5dz09&from=addon

Organizer: Edhaya Chandran Edhaya.Chandran@...

View Event

Description:


Event: TianoCore edk2-test Bug Triage Meeting - 10/06/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: TianoCore edk2-test Bug Triage Meeting

When:
10/06/2022
10:00pm to 11:00pm
(UTC+08:00) Asia/Shanghai

Where:
https://armltd.zoom.us/j/93809865843?pwd=dU1hSzk4NHM2RGhaRDRyWWZxUzY5dz09&from=addon

Organizer: Edhaya Chandran Edhaya.Chandran@...

View Event

Description:


Re: [PATCH v7 3/7] MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices

Ard Biesheuvel
 

(cc Liming & Mike)

On Wed, 5 Oct 2022 at 22:33, Dionna Glaze <dionnaglaze@...> wrote:

Location of notification is has been specified in UEFI v2.9.

Cc: Gerd Hoffmann <kraxel@...>
Cc: James Bottomley <jejb@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Tom Lendacky <thomas.lendacky@...>
Cc: Ard Biesheuvel <ardb@...>
Cc: "Min M. Xu" <min.m.xu@...>
Cc: Andrew Fish <afish@...>
Cc: "Michael D. Kinney" <michael.d.kinney@...>
Cc: Ray Ni <ray.ni@...>

Signed-off-by: Dionna Glaze <dionnaglaze@...>
Reviewed-by: Ard Biesheuvel <ardb@...>

---
MdeModulePkg/Core/Dxe/DxeMain.inf | 1 +
MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 ++++++
2 files changed, 7 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e4bca89577..35d5bf0dee 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -100,6 +100,7 @@
gEfiEventVirtualAddressChangeGuid ## CONSUMES ## Event
## CONSUMES ## Event
## PRODUCES ## Event
+ gEfiEventBeforeExitBootServicesGuid
gEfiEventExitBootServicesGuid
gEfiHobMemoryAllocModuleGuid ## SOMETIMES_CONSUMES ## HOB
gEfiFirmwareFileSystem2Guid ## CONSUMES ## GUID # Used to compare with FV's file system guid and get the FV's file system format
diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
index 5733f0c8ec..4683016ed7 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
+++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
@@ -763,6 +763,12 @@ CoreExitBootServices (
{
EFI_STATUS Status;

+ //
+ // Notify other drivers of their last chance to use boot services
+ // before the memory map is terminated.
+ //
+ CoreNotifySignalList (&gEfiEventBeforeExitBootServicesGuid);
+
//
// Disable Timer
//
--
2.38.0.rc1.362.ged0d419d3c-goog


Re: [PATCH v7 2/7] MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID

Ard Biesheuvel
 

(cc Liming & Mike)

On Wed, 5 Oct 2022 at 22:33, Dionna Glaze <dionnaglaze@...> wrote:

Event group as defined in UEFI standard v2.9.

Cc: Ard Biescheuvel <ardb@...>
Cc: "Min M. Xu" <min.m.xu@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: James Bottomley <jejb@...>
Cc: Tom Lendacky <Thomas.Lendacky@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Erdem Aktas <erdemaktas@...>

Signed-off-by: Dionna Glaze <dionnaglaze@...>
Reviewed-by: Ard Biesheuvel <ardb@...>

---
MdePkg/Include/Guid/EventGroup.h | 5 +++++
MdePkg/MdePkg.dec | 5 ++++-
2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/Guid/EventGroup.h b/MdePkg/Include/Guid/EventGroup.h
index 063d1f7157..64bfd4bab9 100644
--- a/MdePkg/Include/Guid/EventGroup.h
+++ b/MdePkg/Include/Guid/EventGroup.h
@@ -14,6 +14,11 @@ SPDX-License-Identifier: BSD-2-Clause-Patent

extern EFI_GUID gEfiEventExitBootServicesGuid;

+#define EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES \
+ { 0x8be0e274, 0x3970, 0x4b44, { 0x80, 0xc5, 0x1a, 0xb9, 0x50, 0x2f, 0x3b, 0xfc } }
+
+extern EFI_GUID gEfiEventBeforeExitBootServicesGuid;
+
#define EFI_EVENT_GROUP_VIRTUAL_ADDRESS_CHANGE \
{ 0x13fa7698, 0xc831, 0x49c7, { 0x87, 0xea, 0x8f, 0x43, 0xfc, 0xc2, 0x51, 0x96 } }

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index de3c56758b..32c3501e66 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -408,7 +408,10 @@
gEfiEventMemoryMapChangeGuid = { 0x78BEE926, 0x692F, 0x48FD, { 0x9E, 0xDB, 0x01, 0x42, 0x2E, 0xF0, 0xD7, 0xAB }}

## Include/Guid/EventGroup.h
- gEfiEventVirtualAddressChangeGuid = { 0x13FA7698, 0xC831, 0x49C7, { 0x87, 0xEA, 0x8F, 0x43, 0xFC, 0xC2, 0x51, 0x96 }}
+ gEfiEventVirtualAddressChangeGuid = { 0x13FA7698, 0xC831, 0x49C7, { 0x87, 0xEA, 0x8F, 0x43, 0xFC, 0xC2, 0x51, 0x96 }}
+
+ ## Include/Guid/EventGroup.h
+ gEfiEventBeforeExitBootServicesGuid = { 0x8BE0E274, 0x3970, 0x4B44, { 0x80, 0xC5, 0x1A, 0xB9, 0x50, 0x2F, 0x3B, 0xFC }}

## Include/Guid/EventGroup.h
gEfiEventExitBootServicesGuid = { 0x27ABF055, 0xB1B8, 0x4C26, { 0x80, 0x48, 0x74, 0x8F, 0x37, 0xBA, 0xA2, 0xDF }}
--
2.38.0.rc1.362.ged0d419d3c-goog


Re: [edk2-platforms][PATCH v1 2/3] TigerLakeOpenBoardPkg: Remove unnecessary debug macro argument

Heng Luo
 

Reviewed-by: Heng Luo <heng.luo@...>

-----Original Message-----
From: mikuback@... <mikuback@...>
Sent: Wednesday, October 5, 2022 11:36 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Desimone,
Nathaniel L <nathaniel.l.desimone@...>; Luo, Heng
<heng.luo@...>; Oram, Isaac W <isaac.w.oram@...>
Subject: [edk2-platforms][PATCH v1 2/3] TigerLakeOpenBoardPkg: Remove
unnecessary debug macro argument

From: Michael Kubacki <michael.kubacki@...>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4094

Removes an argument passed to a debug macro without a print specifier.
The argument appears to be useless.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Heng Luo <heng.luo@...>
Cc: Isaac Oram <isaac.w.oram@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---

Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMemDe
faultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMem
DefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
b/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMem
DefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
index f0eb3f3f141f..f31cec231e8c 100644
---
a/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMem
DefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
+++
b/Platform/Intel/TigerlakeOpenBoardPkg/FspWrapper/Library/PeiSiPreMe
+++ mDefaultPolicyInitLib/PeiSiPreMemDefaultPolicyInitLib.c
@@ -32,7 +32,7 @@ PeiSiPreMemDefaultPolicyInitLibConstructor (
if (PeiPreMemSiDefaultPolicyInitPpi == NULL) {
return Status;
}
- DEBUG ((DEBUG_INFO, "PeiPreMemSiDefaultPolicyInitPpi-
PeiPreMemPolicyInit ()\n", Status));
+ DEBUG ((DEBUG_INFO,
+ "PeiPreMemSiDefaultPolicyInitPpi->PeiPreMemPolicyInit ()\n"));
Status = PeiPreMemSiDefaultPolicyInitPpi->PeiPreMemPolicyInit ();
ASSERT_EFI_ERROR (Status);

--
2.28.0.windows.1


[PATCH 2/2] Revert "OvmfPkg/Microvm: no secure boot"

Gerd Hoffmann
 

This reverts commit 60d55c4156523e5dfb316b7c0c445b96c8f8be81.

Now that we have stateless secure boot support (which doesn't
need SMM) in OVMF we can enable the build option for MicroVM.

Bring it back by reverting the commit removing it.
Also add the new PlatformPKProtectionLib.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/Microvm/MicrovmX64.dsc | 22 +++++++++++++++++++++-
OvmfPkg/Microvm/MicrovmX64.fdf | 4 ++++
2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index e60d3a2071ab..7eff8e2a88d9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -214,7 +214,15 @@ [LibraryClasses]
!endif
RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf

+!if $(SECURE_BOOT_ENABLE) == TRUE
+ PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
+ AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+ SecureBootVariableLib|SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.inf
+ PlatformPKProtectionLib|SecurityPkg/Library/PlatformPKProtectionLibVarPolicy/PlatformPKProtectionLibVarPolicy.inf
+ SecureBootVariableProvisionLib|SecurityPkg/Library/SecureBootVariableProvisionLib/SecureBootVariableProvisionLib.inf
+!else
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+!endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
@@ -691,7 +699,14 @@ [Components]

MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf

- MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
+ MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
+ <LibraryClasses>
+!if $(SECURE_BOOT_ENABLE) == TRUE
+ NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
+!include OvmfPkg/OvmfTpmSecurityStub.dsc.inc
+!endif
+ }
+
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
OvmfPkg/LocalApicTimerDxe/LocalApicTimerDxe.inf
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
@@ -853,6 +868,11 @@ [Components]
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}

+!if $(SECURE_BOOT_ENABLE) == TRUE
+ SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+ OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
+!endif
+
OvmfPkg/PlatformDxe/Platform.inf
OvmfPkg/IoMmuDxe/IoMmuDxe.inf

diff --git a/OvmfPkg/Microvm/MicrovmX64.fdf b/OvmfPkg/Microvm/MicrovmX64.fdf
index ff0aab2bcb9e..380ba3a36883 100644
--- a/OvmfPkg/Microvm/MicrovmX64.fdf
+++ b/OvmfPkg/Microvm/MicrovmX64.fdf
@@ -206,6 +206,10 @@ [FV.DXEFV]
INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
INF OvmfPkg/VirtioRngDxe/VirtioRng.inf

+!if $(SECURE_BOOT_ENABLE) == TRUE
+ INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+!endif
+
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
--
2.37.3


[PATCH 1/2] OvmfPkg/Microvm: add SECURE_BOOT_FEATURE_ENABLED

Gerd Hoffmann
 

Compiler flag is needed to make (stateless) secure boot be actually
secure, i.e. restore EFI variables from ROM on reset.

Signed-off-by: Gerd Hoffmann <kraxel@...>
---
OvmfPkg/Microvm/MicrovmX64.dsc | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 33d68a5493de..e60d3a2071ab 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -91,6 +91,15 @@ [BuildOptions]
INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES

+ #
+ # SECURE_BOOT_FEATURE_ENABLED
+ #
+!if $(SECURE_BOOT_ENABLE) == TRUE
+ MSFT:*_*_*_CC_FLAGS = /D SECURE_BOOT_FEATURE_ENABLED
+ INTEL:*_*_*_CC_FLAGS = /D SECURE_BOOT_FEATURE_ENABLED
+ GCC:*_*_*_CC_FLAGS = -D SECURE_BOOT_FEATURE_ENABLED
+!endif
+
!include NetworkPkg/NetworkBuildOptions.dsc.inc

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
--
2.37.3


[PATCH 0/2] OvmfPkg/Microvm: support stateless secure boot

Gerd Hoffmann
 

Gerd Hoffmann (2):
OvmfPkg/Microvm: add SECURE_BOOT_FEATURE_ENABLED
Revert "OvmfPkg/Microvm: no secure boot"

OvmfPkg/Microvm/MicrovmX64.dsc | 31 ++++++++++++++++++++++++++++++-
OvmfPkg/Microvm/MicrovmX64.fdf | 4 ++++
2 files changed, 34 insertions(+), 1 deletion(-)

--
2.37.3


Re: [PATCH v2 4/4] OvmfPkg/PciHotPlugInitDxe: reserve more mmio space

Laszlo Ersek
 

On 10/05/22 07:01, Gerd Hoffmann wrote:
On Tue, Oct 04, 2022 at 05:57:46PM +0200, Laszlo Ersek wrote:
On 10/04/22 15:47, Gerd Hoffmann wrote:
In case the 64-bit pci mmio window is larger than the default size
of 32G be generous and hand out larger chunks of address space for
prefetchable mmio bridge windows.
+ SetMmioPadding (
+ --FirstResource,
+ TRUE,
+ FALSE,
+ (UINTN)HighBitSetRoundUp64 (RShiftU64 (Pci64Size, 8))
+ );
Looks good to me, thanks; I'm just missing the rationale on the
RShiftU64() call. Please elaborate.
Cover letter explains this a bit. The idea is to scale things up with
the available address space. Patch #3 does that for the 64-bit pci mmio
window. This patch does the same for the bridge windows, leveraging the
patch #3 calculations by looking at PcdPciMmio64Size. The shift by 8
assigns 1/256 of the total mmio window size to each bridge.

The '8' is just pulled out of thin air. Looks reasonable to me, in case
it turns out it is not we can adjust that in the future.
OK, starting with a 64GB aperture size, 256MB will be reserved per port
/ bridge.

For this patch:

Reviewed-by: Laszlo Ersek <lersek@...>

Laszlo


Re: The principles of EDK2 module reconstruction for archs

Chang, Abner
 

[AMD Official Use Only - General]

Here is the update of the Wiki page for the consistency with edk2 C Coding Standard Spec.
https://github.com/changab/tianocore.github.io/wiki/The-Guidelines-of-Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'-Implementation

Thanks
Abner

-----Original Message-----
From: Chang, Abner
Sent: Wednesday, October 5, 2022 1:39 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
(Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
archs

[AMD Official Use Only - General]

PR updated
https://github.com/tianocore-docs/edk2-
CCodingStandardsSpecification/pull/2/commits. Please check it.

Thanks
Abner

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 4, 2022 10:18 PM
To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
for archs

Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.


I would not add link to Wiki from EDK II C Coding Standard Specification.

We want documents published from tianocore-docs to support standalone
formats such as PDF and if there is a link in one of those documents,
we want to know that it is a permanent link. I am concerned we may
reorganize Wiki pages and links in PDF would become stale.

Links from Wiki to specs makes sense.

Mike

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Tuesday, October 4, 2022 7:05 AM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 4, 2022 12:54 AM
To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

Caution: This message originated from an External Source. Use
proper caution when opening attachments, clicking links, or responding.


Hi Abner,

responses below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Chang, Abner via groups.io
Sent: Sunday, October 2, 2022 10:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Mike,
Agree. This can be mentioned on the Wiki page. Also, this would
require the discussion between maintainer and contributor. I
would say
maintainer has the responsibility to make sure an arch folder is
only created when necessary.

Agreed
Ok, I will update Directory and file names section.


Do you agree with the arch concatenate solution for arch folder?
That
means IA32_X64 instead of X86 (I am fine with this)?

Yes

However, there is one scenario. Assume there were two arch
folders
IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64, we
may
rename IA32_X64 to IA32_X64_ARM.
Although the directory naming is not real a problem to the
build, a separate ARM folder seems easier? Or we can just allow
this kind of folder
naming structure, however we let maintainer to make the decision?

I would let the maintainer make the decision. For your example,
another approach may be to move the IA32_X64 content up a level so
it is common and is used by IA32, X64, ARM. And leave RISCV64
folder for an arch that has special requirements. I think having
some flexibility in the guidelines is very beneficial. The main
goal is for consistency when a specific guideline is followed.
I think we can have the naming rules in the edk2 C coding standard
spec and
put these guidelines on the Wiki page.
Is that ok to have a link to Wiki page in the edk2 C coding standard spec?

Abner



Abner


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Monday, October 3, 2022 1:18 PM
To: Chang, Abner <Abner.Chang@...>;
devel@edk2.groups.io;
quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil
V L <sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>;
Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

Caution: This message originated from an External Source. Use
proper caution when opening attachments, clicking links, or
responding.


Abner,

I think another guideline is to minimize the number of
subdirectories.

Only create them if it helps with the organization and long
term maintenance of the component.

Mike


-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Sunday, October 2, 2022 8:13 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

[AMD Official Use Only - General]

Hi Mike and Leif,
First of all, we don't use arch folder if the module is
mainly for a specific arch in obviously. So we will have
both common and arch-specific
files constructed under module/library root.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
ed
k
2
.groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7CA
bner.Chan
g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
e608e11a
82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
sb3d8eyJWI
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7
C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
M%3D&amp;r
eserved=0
SmmCpuFeatureLib\Ia32
SmmCpuFeatureLib\X64
SmmCpuFeatureLib\SmmCpuFeatureLib.c
SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib


Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
Looks like below?

CpuDxe\IA32_X64\IA32\abc.nasm
CpuDxe\IA32_X64\X64\abc.nasm
CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c
CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c
CpuDxe\ARM\CpuDxe.c CpuDxe\
CpuDxeCommon.c // If required.
CpuDxe.inf // Use INF section arch modifier for X86,
RISC-V
and ARM.
CpuDxeAmd.inf // Separate INF for AMD.

Seems ok, but is AARCH64_RISCV64 a real case? Or it means
we can create a folder "AARCH64_RISCV64" when there are some
common
files
shared by AARCH64 and RISCV64?

For the 32/64 bit support, it can still stay under module
root and don't need to assign a folder for them unless the
arch has the different
implementation.
Regards,
Abner



-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Saturday, October 1, 2022 2:52 AM
To: devel@edk2.groups.io; quic_llindhol@...;
Chang, Abner <Abner.Chang@...>; Ni, Ray
<ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module
reconstruction for archs

Caution: This message originated from an External Source.
Use proper caution when opening attachments, clicking
links, or
responding.


Hi Leif,

Concatenation is a good idea. Makes it more obvious and
can be easily adopted for new CPU archs.

There is an additional case where an implementation does
not have differences based on CPU Arch or Vendor, but it
does have differences based on the bit- width of the CPU.
Take BaseSafeIntLib as
an example.
It has source files for 32-bit CPUs, 64-bit CPUs, and CPU
arch specific file for Ebc because Ebc adapts to 32-bit or
64-bit depending on the CPU type the EBC Interpreter is running.

MdePkg/Library/BaseSafeIntLib/
BaseSafeIntLib.inf
SafeIntLib.c
SafeIntLib32.c
SafeIntLib64.c
SafeIntLibEbc.c

Should we add "32" and "64" as supported suffices in file names?

If we wanted to put type content into a subdirectory, what
would be the suggested directory name for "32" and "64".
Or do we want to require this type of difference to always
be files in top level directory of
the modules/library?

Best regards,

Mike


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On
Behalf Of Leif Lindholm
Sent: Friday, September 30, 2022 9:09 AM
To: devel@edk2.groups.io; Kinney, Michael D
<michael.d.kinney@...>; Chang, Abner
<Abner.Chang@...>;
Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He, Jiangang <Jiangang.He@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module
reconstruction for archs

I agree similar things will certainly happen for
ARM/AARCH64, which will probably be noticeable when I
start eradicating ArmPkg and putting the arch-standard
bits into
(mostly) MdePkg.

But I like the ability to see already at the filesystem
level which files belong to the architecture I'm
currently working on and
which don't.

Could we concatenate architectures?
I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?

/
Leif

On 2022-09-30 08:28, Michael D Kinney wrote:
Hi Abner,

One comment is on adding a new CPU type dir name of 'X86'
for content that is common for IA32/X64.

I can imagine a similar case for ARM/AARCH64 and for
the RISCV (32, 64, 128) cases.

I think I would prefer to drop X86 and if there are
files that are common to multiple CPU architectures
then they are considered common and are in top
directory of module and the file header and INF file
can clearly document which CPU archs the file
applies.

Mike

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: Friday, September 30, 2022 12:11 AM
To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef
(Abdul
Lateef) <AbdulLateef.Attar@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io;
Kinney, Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif
Lindholm <quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2
module reconstruction for archs

[AMD Official Use Only - General]

Thanks Ray, here are my responses.
https://nam11.safelinks.protection.outlook.com/?url=h
tt
ps%3
A%2F
%2Fg
ithub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification
%2Fp
ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
f4
86f
920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
3800
1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
JQ
IjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=
HAq
ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0

@Kinney, Michael D we may also need your
clarification on the
comments.


-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Thursday, September 29, 2022 3:42 PM
To: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>; Chang, Abner
<Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>;
Leif Lindholm <quic_llindhol@...>; Andrew
Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2
module reconstruction for archs

Caution: This message originated from an External Source.
Use proper caution when opening attachments,
clicking links, or
responding.


Abner,
Comments in
https://nam11.safelinks.protection.outlook.com/?url=
ht
tps%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
CCodingStandardsSpecification%2Fpull%2F2%23pullreque
st
revi
ew-
1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
8jo8%3D&amp;reserved=0

We can discuss more in tomorrow's meeting.


-----Original Message-----
From: Attar, AbdulLateef (Abdul Lateef)
<AbdulLateef.Attar@...>
Sent: Thursday, September 29, 2022 3:11 PM
To: Chang, Abner <Abner.Chang@...>; Sunil V L
<sunilvl@...>; devel@edk2.groups.io;
Ni, Ray <ray.ni@...>
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2
module reconstruction for archs

Hi Abner,
Looks good to me.
Reviewed-by: Abdul Lateef Attar <abdattar@...>

Thanks
AbduL

-----Original Message-----
From: Chang, Abner <Abner.Chang@...>
Sent: 28 September 2022 20:31
To: Sunil V L <sunilvl@...>;
devel@edk2.groups.io; ray.ni@...
Cc: Kinney, Michael D <michael.d.kinney@...>;
lichao <lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>;
He,
Jiangang <Jiangang.He@...>; Attar, AbdulLateef
(Abdul
Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: RE: [edk2-devel] The principles of EDK2
module reconstruction for archs

[AMD Official Use Only - General]

I just had created PR to update edkII C coding
standard spec for the file and directory naming. We
can review and confirm this update first and then
go back to the principles of EDK2 module
reconstruction for archs.
Here is the PR:
https://nam11.safelinks.protection.outlook.com/?url=
ht
tps%
3A%2
F%2F
gith
ub.com%2Ftianocore-docs%2Fedk2-
&amp;data=05%7C01%7CAbner.Chang%40amd.c
om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
d994e18
3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
7C%7C&a
mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
mp;reserv
ed=0
CCodingStandardsSpecification/pull/2

The naming rule is mainly for the new module or new file
IMO.
Some existing module may not meet the guidelines
mentioned in this
spec.
Thus we need the principles of EDK2 module
reconstruction on the existing module to support
other processor archs and not impacting the
existing platforms (e.g.
rename the INF file or directory to meet the guidelines).

Sunil, seems RISC-V CpuDxe meet the guideline.
Please check
it.
Just feel that having CpuDxe.c to Riscv64 folder
is not quite a best solution. I think at least we
can abstract the protocol structure and protocol
installation under CpuDxe\ and have the arch
implementation under arch folder. We can discuss
this later after we confirming the
guideline and principles.

Thanks
Abner

-----Original Message-----
From: Sunil V L <sunilvl@...>
Sent: Wednesday, September 28, 2022 3:34 PM
To: devel@edk2.groups.io; ray.ni@...
Cc: Chang, Abner <Abner.Chang@...>; Kinney,
Michael
D <michael.d.kinney@...>; lichao
<lichao@...>; Kirkendall, Garrett
<Garrett.Kirkendall@...>; Grimes, Paul
<Paul.Grimes@...>; He, Jiangang
<Jiangang.He@...>; Attar, AbdulLateef (Abdul
Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
<quic_llindhol@...>; Andrew Fish
<afish@...>
Subject: Re: [edk2-devel] The principles of EDK2
module reconstruction for archs

Caution: This message originated from an External
Source.
Use proper caution when opening attachments,
clicking links, or
responding.


On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
wrote:
Hi Ray,

1. When a new arch's implementation is
introduced to the existing
module which was developed for the specific arch:

1. The folder reconstruction:

* Create arch folder for the existing arch
implementation
[Ray] Do you move existing arch implementation to
that arch
folder?
It will
break existing platforms a lot.

* Create the arch folder for the new introduced
arch
[Ray] I agree. But if we don't create arch folder
for existing arch
implementation, the pkg layout will be a mess.

[Ray] Hard for me to understand all the principles here.
Maybe we review
existing code including to-be-upstreamed code and
decide how
to go.
Could you please take a look below changes which
is trying to add RISC-V support for CpuDxe?
https://nam11.safelinks.protection.outlook.com/?url=
ht
tps%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=
ht
tps%
3A%2
F%2F
gith
ub.com%2Ftianocore%2Fedk2-
staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
=xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
ed=0

What do you suggest with above example?

1) Common INF for all architectures - but modify
INF alone, no
X86 folder creation.

This is what I have done in the commit above. May
be of least impact to existing code since it is only INF
change.
But like you mentioned this is bit weird that X86
files will remain in root folder directly along
with some common
files.

2) Common INF (CpuDxe.inf) + create arch folders
X86, X64, IA32,
RiscV64 etc

IMO, this is probably the best approach. What
would be the challenges with this?

3) Separate INF for arch like CpuDxe.inf for x86,
CpuDxeRiscV64.inf for
RISC-V.

This again probably is not a good idea.

4) If the module/library is specific to one arch (ex:
SMM(X86), SBI(RISC-V)), then create separate INF.

Thanks!
Sunil









Re: 回复: [edk2-devel] [PATCH] [PATCH]MdeModulePkg/Ufs: Coverity scan flags multiple issues in edk2-stable202205 Signed-off-by: sivaparvathic@ami.com

 

On Tue, Sep 13, 2022 at 10:44 AM, gaoliming wrote:
gaoliming
Hi GaoLiming,

Could you please review the changes?

Thanks,
Sivaparvathi