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

-----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

-----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

-----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