Re: [edk2-devel] [PATCH v5 2/2] OvmfPkg/RiscVVirt: Override for RV CPU Features

[Dhaval Sharma]

Hi Laszlo,
Thanks a lot for your feedback. I have modified my next patchset addressing
most of the comments. Summary below. But *before I submit the final
version* I wanted to seek clarification on a few things mentioned below
with [Dhaval]. Current PR I am planning to submit:
https://github.com/tianocore/edk2/pull/4928

I am summarizing all comments for better readability:
(1) Split into four separate patches, in v6.   *Done*.-
with some comments below
1a. Fix previous error from earlier patch that had declaration outside
baselib.h
1b. Renaming RiscVInvalidateDataCacheAsm() to
RiscVInvalidateDataCacheAsmFence() etc.
1c. Adding the new cache maintenance operations to BaseLib, including
the
  new assembly instruction encodings.
1d. Updating BaseCacheMaintenanceLib (utilizing the new BaseLib
primitives).
1e. I have added another one for RiscvVirt platform kind of an override
as 5th patch.
(2)  This belongs to v6 patch#4, because only BaseCacheMaintenanceLib needs
the PCD.*Done*
(3)  "CMO" should be expanded as "cache management operations".   *Done*
(4)  The whole PCD is insufficiently documented.  *Done*
(5)  Accordingly, the default value of the PCD should be
0x.  *Done*
(6)  The "MdePkg/MdePkg.uni" file should be kept in sync with dec.
*Done*.  [Dhaval] Is this used beyond setup options? For some PCDs I do not
find an entry in uni.
(7)  Belongs to v6 patch#4. *Done*
(8)  Please consider appending the "## CONSUMES" hint. *Done*
(9)  Belongs to v6 patch#3. *Done*
(10) Belongs to v6 patch#3. *Done*
(11) I agree that we should use symbolic names rather than magic constants,
but raw encodings of machine instructions don't belong into a
 C header file. [Dhaval] This bytecode was introduced thinking what if
all compilers do not support it. but given the default compiler in edk2 GCC
12 supports it
 we can eliminate this byte encoding completely to make it easy and
simple to consume for others.
(12) Also, filing a feature request (about these instructions). As per (11)
it is already available.
(13) As stated above, these two interfaces don't belong here. *Done*
(14) As stated above, these function declarations don't belong here. *Done*
(15) I believe this un-indented comment will not pass ECC Check /
 uncrustify. [Dhaval] I attach my stuart_build logs. I do not see
specific errors.https://github.com/tianocore/edk2/pull/4928 Pull request
all passed. Am I missing something?
(16-17-18) The name of the function suggests the return type should be
BOOLEAN. *Done*
(19) Should be STATIC, and should *not* be EFIAPI. (Not a public
interface.) *Done*
(20) This will definitely not pass uncrustify. If you are talking about bad
indent seen on Ops and Length- it is fixed. *Done*
(21) Logging this error for every cache line of the requested range does
not seem useful. I suggest checking Op before the loop. *Done*
(22) As stated above, the API renames -- together with the updated leading
comments -- belong in v6 patch#2. *Done*
(23) As stated above, the API renames -- together with the updated leading
comments -- belong in v6 patch#2. *Done*
(24) The DEBUG message seems bogus; invalidating the whole I-Cache *is*
what is being requested here. *Done*
(25-26) The *API* renames belong to v6 patch#2. & The new APIs, plus the
*file* rename, belong to v6 patch#3. *Done*
(27) Please use the assembler macros from point (11). Please see (11)
(28-29-30-31) Please do not abbreviate RISC-V as "RV". It's incredibly
confusing.  Inconsistent spelling in the patch subject: "RISCV CMO". ditto;
should be RISC-V.ditto, should be PcdRiscVFeatureOverride *Done*
(32-33) Total inconsistency, RV64_ versus RV_.  Should be RiscVIsCMOEnabled
(upper case V). *Done*

On Tue, Oct 17, 2023 at 8:09 PM Laszlo Ersek  wrote:

> On 10/17/23 14:17, Dhaval Sharma wrote:
> > This PCD provides a way for platform to override any
> > HW features that are default enabled by previous stages
> > of FW (like OpenSBI). For the case where previous/prev
> > stage has disabled the feature, this override is not
> > useful and its usage should be avoided.
> >
> > Ard Biesheuvel 
> > Jiewen Yao 
> > Jordan Justen 
> > Gerd Hoffmann 
> > Sunil V L 
> > Andrei Warkentin 
>
> (4) You forgot to prepend "Cc:".
>
> (5) The cover letter (0/2 email here) should contain all the Cc: tags
> from the patches' commit messages, so that whoever gets at least one
> patch CC'd from the series also get the cover letter for the series.
>
> Thanks
> Laszlo
>
> >
> > Signed-off-by: Dhaval Sharma 
> > ---
> >  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> > index fe320525153f..8b5e010316ba 100644
> > --- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> > +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> > @@ -203,6 +203,8 @@ [PcdsFeatureFlag]
> >gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtPr

Re: [edk2-devel] [PATCH] OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. file

[Gerd Hoffmann]

On Wed, Oct 18, 2023 at 07:24:34PM +0200, Laszlo Ersek wrote:
> Referring to a file relative to a regular file makes no sense (or at least
> it cannot be implemented consistently with how a file is referred to
> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> strictly since the beginning, and a few months ago I reported USWG Mantis
> ticket #2367 [1] too, for clearing up the related confusion in the UEFI
> spec.
> 
> Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
> believe the shim bug is ever going to be fixed. We can however relax the
> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> opened relative to a regular file is absolute, then the base file is going
> to be ignored anyway, so we can let the caller's bug slide. This happens
> to make shim work.
> 
> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
> want to build upstream shim/grub binaries, but boot the same ISO
> otherwise. The fastest way for overriding the ESP for this purpose is to
> copy its original contents to a virtio filesystem, then overwrite the shim
> and grub binaries from the host side. Note that this is different from
> direct-booting a kernel (via fw_cfg); the point is to check whether the
> just-built shim and grub are able to boot the rest of the ISO.
> 
> [1] https://mantis.uefi.org/mantis/view.php?id=2367
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
> [3] https://github.com/rhboot/shim/issues/382
> 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Gerd Hoffmann 
Tested-by: Gerd Hoffmann 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109795): https://edk2.groups.io/g/devel/message/109795
Mute This Topic: https://groups.io/mt/102044004/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] Maintainers.txt: Update maintainers list

[Nickle Wang via groups.io]

Acked-by: Nickle Wang 

Regards,
Nickle

> -Original Message-
> From: abner.ch...@amd.com 
> Sent: Thursday, October 19, 2023 1:43 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Leif Lindholm ;
> Michael D Kinney ; Abdul Lateef Attar
> ; Nickle Wang ; Jian J
> Wang ; Liming Gao ;
> Zhiguang Liu ; Eric Dong ; Ray Ni
> ; Rahul Kumar ; Gerd Hoffmann
> 
> Subject: [PATCH 1/1] Maintainers.txt: Update maintainers list
>
> External email: Use caution opening links or attachments
>
>
> From: Abner Chang 
>
> - Add two entries of MdePkg and MdeModulePkg for
>   manageability modules and files.
> - Add one entry of UefiCpuPkg AMD related files.
>
> Signed-off-by: Abner Chang 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Abdul Lateef Attar 
> Cc: Nickle Wang 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> ---
>  Maintainers.txt | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/Maintainers.txt b/Maintainers.txt index 1a7525b1b4c..4bec19832f4
> 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -443,6 +443,13 @@ F:
> MdeModulePkg/Include/Protocol/UsbEthernetProtocol.h
>  M: Richard Ho  [richardho]
>  R: Rebecca Cran  [bcran]
>
> +MdeModulePkg: Manageability modules
> +F: MdeModulePkg/Include/*Ipmi*.*
> +F: MdeModulePkg/Library/*Ipmi*.*
> +M: Abner Chang  [changab]
> +R: Abdul Lateef Attar  [abdattar]
> +R: Nickle Wang  [nicklela]
> +
>  MdePkg
>  F: MdePkg/
>  W:
> https://github.co/
> m%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FMdePkg&data=05%7C01%7Cn
> icklew%40nvidia.com%7C19ae524dd28b4d2af5a108dbd0666ef6%7C43083d157
> 27340c1b7db39efd9ccc17a%7C0%7C0%7C638332910617920407%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ucUKG4eTnf%2BoX7c5gqIKEwaa
> sXxqGNpzexoUDfmajLQ%3D&reserved=0
> @@ -468,6 +475,14 @@ R: Gua Guo  [gguo11837463]
>  R: Chasel Chiu  [ChaselChiu]
>  R: James Lu  [jameslu8]
>
> +MdePkg: Manageability industryStandard standard C header files
> +F: MdePkg/Include/IndustryStandard/*Ipmi*.h
> +F: MdePkg/Include/IndustryStandard/*Mctp*.h
> +F: MdePkg/Include/IndustryStandard/*Pldm*.h
> +M: Abner Chang  [changab]
> +R: Abdul Lateef Attar  [abdattar]
> +R: Nickle Wang  [nicklela]
> +
>  NetworkPkg
>  F: NetworkPkg/
>  W:
> https://github.co/
> m%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FNetworkPkg&data=05%7C01
> %7Cnicklew%40nvidia.com%7C19ae524dd28b4d2af5a108dbd0666ef6%7C43083
> d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638332910617920407%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UbJX%2FCKOqxJx7BxejmzV
> oGEvj0jxi8snAYL%2F6FSgJR4%3D&reserved=0
> @@ -657,6 +672,12 @@ F: UefiCpuPkg/ResetVector/
>  R: Debkumar De  [dde01]
>  R: Catharine West  [catharine-intl]
>
> +UefiCpuPkg: AMD related files
> +F: UefiCpuPkg/Library/MmSaveStateLib/*Amd*.*
> +F: UefiCpuPkg/Library/SmmCpuFeaturesLib/*Amd*.*
> +M: Abdul Lateef Attar  [abdattar]
> +R: Abner Chang  [changab]
> +
>  UefiPayloadPkg
>  F: UefiPayloadPkg/
>  W:
> https://github.co/
> m%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FUefiPayloadPkg&data=05%7C
> 01%7Cnicklew%40nvidia.com%7C19ae524dd28b4d2af5a108dbd0666ef6%7C430
> 83d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638332910617920407%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jzgjQra0EsPmGv0wp1Tfpj
> LmtMW2ZuNi8MmDchI%2BIK0%3D&reserved=0
> --
> 2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109794): https://edk2.groups.io/g/devel/message/109794
Mute This Topic: https://groups.io/mt/102055114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V1 2/2] OvmfPkg/AcpiPlatformDxe: Check the status to ensure no error

[sunceping]

From: Ceping Sun 

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

The status of "AcpiProtocol->InstallAcpiTable" is overwritten
before it can be used, it is better to check it before overwriting.

Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Min Xu 
Signed-off-by: Ceping Sun 
---
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index 24c22bb646ca..7e2adcaa82d3 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -53,6 +53,11 @@ InstallCloudHvTablesTdx (
CurrentTable->Length,
&TableHandle
);
+  if (EFI_ERROR (Status)) {
+ASSERT_EFI_ERROR (Status);
+return Status;
+  }
+
   for (UINTN i = 0; i < CurrentTable->Length; i++) {
 DEBUG ((DEBUG_INFO, " %x", *((UINT8 *)CurrentTable + i)));
   }
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109793): https://edk2.groups.io/g/devel/message/109793
Mute This Topic: https://groups.io/mt/102055425/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V1 1/2] OvmfPkg/AcpiPlatformDxe: Avoid possible NULL pointer dereference

[sunceping]

From: Ceping Sun 

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

The function InstallCloudHvTablesTdx had an Assert when "DsdtTable == NULL",
but this comes into play only in DEBUG mode. In Release mode , there is
no handling if the pointer is NULL. To avoid the possible null pointer
dereference, it is better to handle it when the pointer is null.

Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Min Xu 
Signed-off-by: Ceping Sun 
---
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c 
b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index d3e73c155e8f..24c22bb646ca 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -71,6 +71,7 @@ InstallCloudHvTablesTdx (
   if (DsdtTable == NULL) {
 DEBUG ((DEBUG_INFO, "%a: no DSDT found\n", __func__));
 ASSERT (FALSE);
+CpuDeadLoop ();
   }
 
   Status = AcpiProtocol->InstallAcpiTable (
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109792): https://edk2.groups.io/g/devel/message/109792
Mute This Topic: https://groups.io/mt/102055424/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V1 0/2] OvmfPkg/AcpiPlatformDxe: Fix the coverity errors

[sunceping]

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

Coverity report 2 issues in OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c.

In the function InstallCloudHvTablesTdx, the pointer is already checked. 
  if (DsdtTable == NULL) {
DEBUG ((DEBUG_INFO, "%a: no DSDT found\n", __func__));
ASSERT (FALSE);
  }
But this comes into play only in DEBUG mode, in Release mode, that would be an 
error 
with dereferencing null pointer. Fix this by adding CpuDeadLoop() after assert. 

In addition, the status of "AcpiProtocol->InstallAcpiTable" is overwritten 
before
it can be used in the function, it is better to check it before overwriting.

code: https://github.com/sunceping/edk2/tree/fixcoverityerrors.v1

Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Min Xu 
Signed-off-by: Ceping Sun 

Ceping Sun (2):
  OvmfPkg/AcpiPlatformDxe: Avoid possible NULL pointer dereference
  OvmfPkg/AcpiPlatformDxe: Check the status to ensure no error

 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109791): https://edk2.groups.io/g/devel/message/109791
Mute This Topic: https://groups.io/mt/102055422/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] Maintainers.txt: Update maintainers list

[Chang, Abner via groups.io]

From: Abner Chang 

- Add two entries of MdePkg and MdeModulePkg for
  manageability modules and files.
- Add one entry of UefiCpuPkg AMD related files.

Signed-off-by: Abner Chang 
Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
---
 Maintainers.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1a7525b1b4c..4bec19832f4 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -443,6 +443,13 @@ F: MdeModulePkg/Include/Protocol/UsbEthernetProtocol.h
 M: Richard Ho  [richardho]
 R: Rebecca Cran  [bcran]
 
+MdeModulePkg: Manageability modules
+F: MdeModulePkg/Include/*Ipmi*.*
+F: MdeModulePkg/Library/*Ipmi*.*
+M: Abner Chang  [changab]
+R: Abdul Lateef Attar  [abdattar]
+R: Nickle Wang  [nicklela]
+
 MdePkg
 F: MdePkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
@@ -468,6 +475,14 @@ R: Gua Guo  [gguo11837463]
 R: Chasel Chiu  [ChaselChiu]
 R: James Lu  [jameslu8]
 
+MdePkg: Manageability industryStandard standard C header files
+F: MdePkg/Include/IndustryStandard/*Ipmi*.h
+F: MdePkg/Include/IndustryStandard/*Mctp*.h
+F: MdePkg/Include/IndustryStandard/*Pldm*.h
+M: Abner Chang  [changab]
+R: Abdul Lateef Attar  [abdattar]
+R: Nickle Wang  [nicklela]
+
 NetworkPkg
 F: NetworkPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg
@@ -657,6 +672,12 @@ F: UefiCpuPkg/ResetVector/
 R: Debkumar De  [dde01]
 R: Catharine West  [catharine-intl]
 
+UefiCpuPkg: AMD related files
+F: UefiCpuPkg/Library/MmSaveStateLib/*Amd*.*
+F: UefiCpuPkg/Library/SmmCpuFeaturesLib/*Amd*.*
+M: Abdul Lateef Attar  [abdattar]
+R: Abner Chang  [changab]
+
 UefiPayloadPkg
 F: UefiPayloadPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
-- 
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109790): https://edk2.groups.io/g/devel/message/109790
Mute This Topic: https://groups.io/mt/102055114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/1] Add new entries in Maintainers.txt

[Chang, Abner via groups.io]

From: Abner Chang 

- Add entry of MdePkg for manageability industry
  standard C header files.
- Add entry of MdeModulePkg for manageability modules
  and files.
- Add entry of UefiCpuPkg for AMD implementation.

This change will be merged with at least one steward and
at lease one maintainer or reviewer from each of below
package.
- MdePkg
- MdeModulePkg
- UefiCpuPkg.

Signed-off-by: Abner Chang 
Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Abdul Lateef Attar 
Cc: Nickle Wang 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 

Abner Chang (1):
  Maintainers.txt: Update maintainers list

 Maintainers.txt | 21 +
 1 file changed, 21 insertions(+)

-- 
2.37.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109789): https://edk2.groups.io/g/devel/message/109789
Mute This Topic: https://groups.io/mt/102055113/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] IntelFsp2Pkg\Tools\ConfigEditor: Added new USF config workstream support - Config Edit utility addition/changes.

[Arun Sura]

This patch is to enable config editor to have a new feature that can load and 
view the configuration data of compiled VFR or HFR in form of YAML.
This can help users to understand and track the configuration data when 
modifications are made.

Running Configuration Editor:
python ConfigEditor.py

Cc: Chasel Chiu 
Cc: Duggapu Chinni B 
Cc: Nate DeSimone 
Cc: Ray Han Lim Ng 
Cc: Star Zeng 
Cc: Ted Kuo 
Cc: Ashraf Ali S 
Cc: Susovan Mohapatra 
Signed-off-by: Arun Sura 
---
 IntelFsp2Pkg/Tools/ConfigEditor/ConfigEditor.py | 226 
+++---
 IntelFsp2Pkg/Tools/ConfigEditor/GenYamlCfg.py   | 197 
+
 2 files changed, 368 insertions(+), 55 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/ConfigEditor/ConfigEditor.py 
b/IntelFsp2Pkg/Tools/ConfigEditor/ConfigEditor.py
index 5271504282..35c418a9a9 100644
--- a/IntelFsp2Pkg/Tools/ConfigEditor/ConfigEditor.py
+++ b/IntelFsp2Pkg/Tools/ConfigEditor/ConfigEditor.py
@@ -1015,6 +1015,10 @@ class application(tkinter.Frame):
  "Unsupported file '%s' !" % path)
 return
 
+# VFR Format Page modification
+def page_construct(self):
+self.left.bind("<>", self.on_config_page_select_change)
+
 def search_bar(self):
 # get data from text box
 self.search_text = self.edit.get()
@@ -1165,7 +1169,8 @@ class application(tkinter.Frame):
 page_id = next(iter(page))
 # Put CFG items into related page list
 self.page_list[page_id] = self.cfg_data_obj.get_cfg_list(page_id)
-self.page_list[page_id].sort(key=lambda x: x['order'])
+if self.mode == 'fsp':
+self.page_list[page_id].sort(key=lambda x: x['order'])
 page_name = self.cfg_data_obj.get_page_title(page_id)
 child = self.left.insert(
 parent, 'end',
@@ -1199,17 +1204,23 @@ class application(tkinter.Frame):
 for item in self.get_current_config_data():
 disp_list.append(item)
 row = 0
-disp_list.sort(key=lambda x: x['order'])
-for item in disp_list:
-self.add_config_item(item, row)
-row += 2
-if self.invalid_values:
-string = 'The following contails invalid options/values \n\n'
-for i in self.invalid_values:
-string += i + ": " + str(self.invalid_values[i]) + "\n"
-reply = messagebox.showwarning('Warning!', string)
-if reply == 'ok':
-self.invalid_values.clear()
+if self.mode == 'fsp':
+disp_list.sort(key=lambda x: x['order'])
+for item in disp_list:
+self.add_config_item(item, row)
+row += 2
+if self.invalid_values:
+string = 'The following contails invalid options/values \n\n'
+for i in self.invalid_values:
+string += i + ": " + str(self.invalid_values[i]) + "\n"
+reply = messagebox.showwarning('Warning!', string)
+if reply == 'ok':
+self.invalid_values.clear()
+elif self.mode == 'vfr':
+for item in disp_list:
+self.add_vfr_config_item(item, row)
+row += 2
+
 
 fsp_version = ''
 
@@ -1219,16 +1230,19 @@ class application(tkinter.Frame):
 with open(file_name, "rb") as pkl_file:
 gen_cfg_data.__dict__ = marshal.load(pkl_file)
 gen_cfg_data.prepare_marshal(False)
-elif file_name.endswith('.yaml'):
+elif file_name.endswith('.yaml') or file_name.endswith('.yml'):
 if gen_cfg_data.load_yaml(file_name) != 0:
 raise Exception(gen_cfg_data.get_last_error())
 else:
 raise Exception('Unsupported file "%s" !' % file_name)
+
+self.mode = gen_cfg_data.yaml_type
 # checking fsp version
-if gen_cfg_data.detect_fsp():
-self.fsp_version = '2.X'
-else:
-self.fsp_version = '1.X'
+if gen_cfg_data.yaml_type == 'fsp':
+if gen_cfg_data.detect_fsp():
+self.fsp_version = '2.X'
+else:
+self.fsp_version = '1.X'
 
 return gen_cfg_data
 
@@ -1252,7 +1266,7 @@ class application(tkinter.Frame):
 elif ftype == 'bin':
 question = 'All configuration will be reloaded from BIN file, \
 continue ?'
-elif ftype == 'yaml':
+elif ftype == 'yaml' or ftype == 'yml':
 questi

[edk2-devel] [PATCH] Remove memory cache setting for memory under 1MB

[Yuanhao Xie]

With the fact that CSM is not supported,
the request is to remove the cache setting for memory under 1MB.
This can be treated as the missing part of legacy CSM deprecation.

This patch only set the 0 to 9 and C to F as Write Back.
A-B range is still uncacheable for VGA.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Isaac Oram 
Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Yuanhao Xie 
---
 Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c 
b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
index 05728275a5..38a8db6b3f 100644
--- a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
+++ b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
@@ -245,7 +245,7 @@ SetCacheMtrrAfterEndOfPei (
  &MtrrSetting,
  0xC,
  0x4,
- CacheWriteProtected
+ CacheWriteBack
  );
   ASSERT_EFI_ERROR ( Status);
 
-- 
2.36.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109787): https://edk2.groups.io/g/devel/message/109787
Mute This Topic: https://groups.io/mt/102037244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 0/1] Enable EDK2 on StarFive VisionFive 2 board

[John Chew]

Boot flow in VF2 using EDK2 as bootloader:
BootROM -> U-Boot SPL -> OpenSBI -> EDK2 -> Linux -> OS

Currently, we rely on U-Boot SPL to initialize DDR and load OpenSBI and
EDK2 into DDR from multiple boot sources, including SD Card, eMMC, or QSPI 
Flash.
Furthermore, our EDK2 code is capable of loading Linux from various sources as
well, such as SD Card, eMMC, NVME, or USB.

edk2 and edk2-platform code links:
edk2: https://github.com/johnchewyy/edkii/tree/vf2_jh7110_devel_upstream
edk2-platform: 
https://github.com/johnchewyy/edkii-platforms/tree/vf2_jh7110_devel_upstream

Cc: Sunil V L 
Cc: Li Yong 

mindachen1987 (1):
  StarFive/VisionFive2: Add VisionFive 2 platform

 Platform/StarFive/VisionFive2/DeviceTree/Gpio.h|   42 +
 Platform/StarFive/VisionFive2/DeviceTree/Irq.h |   20 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkGen.h|  398 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkIsp.h|   57 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkVout.h   |   68 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110PinCtrl.h   | 1573 
+
 Platform/StarFive/VisionFive2/DeviceTree/JH7110Power.h |   22 +
 Platform/StarFive/VisionFive2/DeviceTree/JH7110Rst.h   |  228 +++
 Platform/StarFive/VisionFive2/DeviceTree/Led.h |   90 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveClk.dtsi  |  130 ++
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveHdmi.dtsi |   28 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveJH7110.dtsi   | 1812 

 Platform/StarFive/VisionFive2/DeviceTree/StarFivePwmDac.dtsi   |   26 +
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dts   |  211 +++
 Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dtsi  |  838 
+
 Platform/StarFive/VisionFive2/DeviceTree/Thermal.h |   16 +
 Platform/StarFive/VisionFive2/DeviceTree/VisionFive2DeviceTree.inf |   36 +
 Platform/StarFive/VisionFive2/VarStore.fdf.inc |   77 +
 Platform/StarFive/VisionFive2/VisionFive2.dsc  |  590 
+++
 Platform/StarFive/VisionFive2/VisionFive2.fdf  |  286 +++
 Platform/StarFive/VisionFive2/VisionFive2.fdf.inc  |   48 +
 21 files changed, 6596 insertions(+)
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/Gpio.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/Irq.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkGen.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkIsp.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkVout.h
 create mode 100755 Platform/StarFive/VisionFive2/DeviceTree/JH7110PinCtrl.h
 create mode 100755 Platform/StarFive/VisionFive2/DeviceTree/JH7110Power.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/JH7110Rst.h
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/Led.h
 create mode 100755 Platform/StarFive/VisionFive2/DeviceTree/StarFiveClk.dtsi
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/StarFiveHdmi.dtsi
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/StarFiveJH7110.dtsi
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/StarFivePwmDac.dtsi
 create mode 100644 
Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dts
 create mode 100755 
Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dtsi
 create mode 100644 Platform/StarFive/VisionFive2/DeviceTree/Thermal.h
 create mode 100644 
Platform/StarFive/VisionFive2/DeviceTree/VisionFive2DeviceTree.inf
 create mode 100644 Platform/StarFive/VisionFive2/VarStore.fdf.inc
 create mode 100644 Platform/StarFive/VisionFive2/VisionFive2.dsc
 create mode 100644 Platform/StarFive/VisionFive2/VisionFive2.fdf
 create mode 100644 Platform/StarFive/VisionFive2/VisionFive2.fdf.inc

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109785): https://edk2.groups.io/g/devel/message/109785
Mute This Topic: https://groups.io/mt/102053747/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 6/6] StarFive/JH7110Pkg: Add JH7110 Silicon Package

[John Chew]

From: mindachen1987 

Cc: Sunil V L 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h | 24 +++
 Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec | 45 

 2 files changed, 69 insertions(+)

diff --git a/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h 
b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
new file mode 100644
index ..b6875f6aa82b
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
@@ -0,0 +1,24 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#ifndef JH7110_H__
+#define JH7110_H__
+
+// #define JH7110_SOC_REGISTERS   (FixedPcdGet64 
(PcdJH7110RegistersAddress))
+// #define JH7110_SOC_REGISTER_LENGTH 0x0200
+
+/* Generic PCI addresses */
+#define PCIE_TOP_OF_MEM_WIN   (FixedPcdGet64 (PcdJH7110PciBusMmioAdr))
+#define PCIE_CPU_MMIO_WINDOW  (FixedPcdGet64 (PcdJH7110PciCpuMmioAdr))
+#define PCIE_BRIDGE_MMIO_LEN  (FixedPcdGet32 (PcdJH7110PciBusMmioLen))
+
+/* PCI root bridge control registers location */
+#define PCIE_REG_BASE (FixedPcdGet64 (PcdJH7110PciRegBase))
+#define PCIE_CONFIG_BASE  (FixedPcdGet64 (PcdJH7110PciConfigRegBase))
+
+#endif /* JH7110_H__ */
diff --git a/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec 
b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
new file mode 100644
index ..438557a15500
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
@@ -0,0 +1,45 @@
+## @file
+#
+#  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = JH7110Pkg
+  PACKAGE_GUID   = D4B585C5-EBCA-4779-B974-05A3CF2F10C4
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
+
+[Guids]
+  gJH7110TokenSpaceGuid = {0x44045e56, 0x7056, 0x4be6, {0x88, 0xc0, 0x49, 
0x0c, 0x67, 0x90, 0x2f, 0xba}}
+
+[PcdsFixedAtBuild.common]
+# Memory map
+  gJH7110TokenSpaceGuid.PcdJH7110FlashVarOffset|0x0|UINT32|0x0001
+
+# PCIe
+  gJH7110TokenSpaceGuid.PcdJH7110RegistersAddress|0|UINT32|0x0002
+  gJH7110TokenSpaceGuid.PcdJH7110PciRegBase|0x2b00|UINT64|0x0003
+  gJH7110TokenSpaceGuid.PcdJH7110PciBusMmioAdr|0x0|UINT64|0x0004
+  gJH7110TokenSpaceGuid.PcdJH7110PciBusMmioLen|0x0|UINT32|0x0005
+  gJH7110TokenSpaceGuid.PcdJH7110PciCpuMmioAdr|0x0|UINT64|0x0006
+  gJH7110TokenSpaceGuid.PcdJH7110PciConfigRegBase|0x94000|UINT64|0x0007
+
+# SPI
+  gJH7110TokenSpaceGuid.PcdSpiFlashRegBase|0|UINT32|0x1008
+  gJH7110TokenSpaceGuid.PcdSpiFlashAhbBase|0|UINT64|0x1009
+  gJH7110TokenSpaceGuid.PcdSpiFlashFifoWidth|0|UINT8|0x1010
+  gJH7110TokenSpaceGuid.PcdSpiFlashRefClkHz|0|UINT32|0x1011
+  gJH7110TokenSpaceGuid.PcdSpiFlashTshslNs|0|UINT32|0x1012
+  gJH7110TokenSpaceGuid.PcdSpiFlashTsd2dNs|0|UINT32|0x113
+  gJH7110TokenSpaceGuid.PcdSpiFlashTchshNs|0|UINT32|0x114
+  gJH7110TokenSpaceGuid.PcdSpiFlashTslchNs|0|UINT32|0x115
+
+[Protocols]
+  gJH7110SpiMasterProtocolGuid = { 0xA33C46E0, 0x4FB6, 0x4AA3, { 0x8E, 0x66, 
0x00, 0x06, 0x9F, 0x3A, 0x11, 0x81 }}
+  gJH7110SpiFlashProtocolGuid  = { 0x5ECECDF6, 0x81DA, 0x4E10, { 0x9D, 0x4B, 
0x26, 0x65, 0x8C, 0x03, 0xAB, 0xBC }}
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109784): https://edk2.groups.io/g/devel/message/109784
Mute This Topic: https://groups.io/mt/102053687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 5/6] StarFive/JH7110Pkg: Implement boot services memory allocation driver

[John Chew]

Some DXE drivers such as MMC's DMA can only work with 32-bit addressing.
So, EfiBootServicesData need to set within 32-bit range only.

This is achieved by setting all EfiConventionalMemory to
EfiBootServicesData before any memory allocations in the early stage of
DXE.

Cc: Sunil V L 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c   | 108 

 Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf |  34 
++
 2 files changed, 142 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c 
b/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c
new file mode 100644
index ..a26a77661d4e
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c
@@ -0,0 +1,108 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+BootServicesInitialize (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS Status;
+  UINTN  MemoryMapSize;
+  EFI_MEMORY_DESCRIPTOR  *MemoryMap, *Desc;
+  UINTN  MapKey;
+  UINTN  DescriptorSize;
+  UINT32 DescriptorVersion;
+  EFI_PHYSICAL_ADDRESS   Addr;
+  UINTN  Idx;
+  UINTN  Pages;
+
+  MemoryMap = NULL;
+  MemoryMapSize = 0;
+  Pages = 0;
+
+  Status = gBS->GetMemoryMap (
+  &MemoryMapSize,
+  MemoryMap,
+  &MapKey,
+  &DescriptorSize,
+  &DescriptorVersion
+  );
+
+  if (Status == EFI_BUFFER_TOO_SMALL) {
+Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1;
+MemoryMap = AllocatePages (Pages);
+
+//
+// Get System MemoryMap
+//
+Status = gBS->GetMemoryMap (
+&MemoryMapSize,
+MemoryMap,
+&MapKey,
+&DescriptorSize,
+&DescriptorVersion
+);
+  }
+
+  if (EFI_ERROR (Status) || (MemoryMap == NULL)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to get memory map\n", __func__));
+if (MemoryMap) {
+  FreePages ((VOID *)MemoryMap, Pages);
+}
+
+return EFI_SUCCESS;
+  }
+
+  Desc = MemoryMap;
+
+  //
+  // Change 64-bit EfiConventionalMemory with EfiBootServicesData
+  // So that DXE driver only allocate EfiBootServicesData in 32-bit addresses
+  //
+  for (Idx = 0; Idx < (MemoryMapSize / DescriptorSize); Idx++) {
+if ((Desc->Type == EfiConventionalMemory) &&
+((Desc->PhysicalStart > MAX_UINT32) || ((Desc->PhysicalStart + 
Desc->NumberOfPages * EFI_PAGE_SIZE) > MAX_UINT32)))
+{
+  if (Desc->PhysicalStart > MAX_UINT32) {
+Addr   = Desc->PhysicalStart;
+Status = gBS->AllocatePages (
+ AllocateAddress,
+ EfiBootServicesData,
+ Desc->NumberOfPages,
+ &Addr
+ );
+  } else {
+Addr   = 0x1ULL;
+Status = gBS->AllocatePages (
+ AllocateAddress,
+ EfiBootServicesData,
+ Desc->NumberOfPages - EFI_SIZE_TO_PAGES 
(0x1 - Desc->PhysicalStart),
+ &Addr
+ );
+  }
+
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to allocate boot service data at 
%llX\n", __func__, Addr));
+  }
+}
+
+Desc = (EFI_MEMORY_DESCRIPTOR *)((UINT64)Desc + DescriptorSize);
+  }
+
+  FreePages ((VOID *)MemoryMap, Pages);
+
+  return EFI_SUCCESS;
+}
diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf 
b/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf
new file mode 100644
index ..33a777ae5a24
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf
@@ -0,0 +1,34 @@
+## @file
+# DXE Boot Service driver for StarFive JH7110 SoC
+#
+# Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010019
+  BASE_NAME  = BootServicesDxe
+  FILE_GUID  = E7B2A7CF-4A9B-4F63-9B9E-12B34C5D6E78
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= BootServicesInitial

[edk2-devel] [PATCH v1 4/6] StarFive/JH7110Pkg: Add PlatformBootManagerLib library

[John Chew]

From: JohnChew 

For JH7110 with graphic console

Cc: Sunil V L 
Co-authored-by: Yong Li 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c 
  | 1014 
 Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.h 
  |   46 +
 
Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 |   71 ++
 3 files changed, 1131 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c
new file mode 100755
index ..b58d2c7cbcd5
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -0,0 +1,1014 @@
+/** @file
+*  Implementation for PlatformBootManagerLib library class interfaces.
+*
+*  Copyright (C) 2015-2016, Red Hat, Inc.
+*  Copyright (c) 2014, ARM Ltd. All rights reserved.
+*  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+*  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "PlatformBm.h"
+
+#define DP_NODE_LEN(Type)  { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 8) 
}
+
+#define VERSION_STRING_PREFIX  L"RISC-V EDK2 firmware version "
+
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATHSerialDxe;
+  UART_DEVICE_PATH  Uart;
+  VENDOR_DEFINED_DEVICE_PATHTermType;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} PLATFORM_SERIAL_CONSOLE;
+#pragma pack ()
+
+STATIC PLATFORM_SERIAL_CONSOLE  mSerialConsole = {
+  //
+  // VENDOR_DEVICE_PATH SerialDxe
+  //
+  {
+{ HARDWARE_DEVICE_PATH,  HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) },
+EDKII_SERIAL_PORT_LIB_VENDOR_GUID
+  },
+
+  //
+  // UART_DEVICE_PATH Uart
+  //
+  {
+{ MESSAGING_DEVICE_PATH, MSG_UART_DP,  DP_NODE_LEN (UART_DEVICE_PATH)   },
+0,  // Reserved
+FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate
+FixedPcdGet8 (PcdUartDefaultDataBits),  // DataBits
+FixedPcdGet8 (PcdUartDefaultParity),// Parity
+FixedPcdGet8 (PcdUartDefaultStopBits)   // StopBits
+  },
+
+  //
+  // VENDOR_DEFINED_DEVICE_PATH TermType
+  //
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_VENDOR_DP,
+  DP_NODE_LEN (VENDOR_DEFINED_DEVICE_PATH)
+}
+//
+// Guid to be filled in dynamically
+//
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+#pragma pack (1)
+typedef struct {
+  USB_CLASS_DEVICE_PATH   Keyboard;
+  EFI_DEVICE_PATH_PROTOCOLEnd;
+} PLATFORM_USB_KEYBOARD;
+#pragma pack ()
+
+STATIC PLATFORM_USB_KEYBOARD  mUsbKeyboard = {
+  //
+  // USB_CLASS_DEVICE_PATH Keyboard
+  //
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_USB_CLASS_DP,
+  DP_NODE_LEN (USB_CLASS_DEVICE_PATH)
+},
+0x, // VendorId: any
+0x, // ProductId: any
+3,  // DeviceClass: HID
+1,  // DeviceSubClass: boot
+1   // DeviceProtocol: keyboard
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+/**
+  Check if the handle satisfies a particular condition.
+
+  @param[in] Handle  The handle to check.
+  @param[in] ReportText  A caller-allocated string passed in for reporting
+ purposes. It must never be NULL.
+
+  @retval TRUE   The condition is satisfied.
+  @retval FALSE  Otherwise. This includes the case when the condition could not
+ be fully evaluated due to an error.
+**/
+typedef
+BOOLEAN
+(EFIAPI *FILTER_FUNCTION)(
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  );
+
+/**
+  Process a handle.
+
+  @param[in] Handle  The handle to process.
+  @param[in] ReportText  A caller-allocated string passed in for reporting
+ purposes. It must never be NULL.
+**/
+typedef
+VOID
+(EFIAPI *CALLBACK_FUNCTION)(
+  IN EFI_HANDLE   Handle,
+  IN CONST CHAR16 *ReportText
+  );
+
+/**
+  Locate all handles that carry the specified protocol, filter them with a
+  callback function, and pass each handle that passes the filter to another
+  callback.
+
+  @param[in] ProtocolGuid  The protocol to look for.
+
+  @param[in] FilterThe filter function to pass each handle to. If this
+   parameter is NULL, then all handles are processed.
+
+  @param[in] Process   The callback function to pass each handle to that
+   clears the filter.
+**/
+STATIC
+

[edk2-devel] [PATCH v1 3/6] StarFive/JH7110Pkg: Add firmware volume block protocol

[John Chew]

Support for efi variable to store in QSPI flash

Cc: Sunil V L 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c   | 909 

 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h   | 138 +++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf |  70 ++
 3 files changed, 1117 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c 
b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
new file mode 100644
index ..c30e82ed0871
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
@@ -0,0 +1,909 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include "FvbDxe.h"
+
+STATIC FVB_DEVICE  *mFvbDevice;
+
+STATIC CONST FVB_DEVICE  mFvbFlashInstanceTemplate = {
+  {
+0,/* AddrSize ... NEED TO BE FILLED */
+NULL, /* Read from NOR FLASH ... NEED TO BE FILLED */
+0,/* RegBase ... NEED TO BE FILLED */
+0,/* AbhBase ... NEED TO BE FILLED */
+0,/* FifoWidth ... NEED TO BE FILLED */
+0,/* WriteDelay ... NEED TO BE FILLED */
+  }, /* SPI_DEVICE_PARAMS */
+
+  NULL, /* SpiFlashProtocol ... NEED TO BE FILLED */
+  NULL, /* SpiMasterProtocol ... NEED TO BE FILLED */
+  NULL, /* Handle ... NEED TO BE FILLED */
+
+  FVB_FLASH_SIGNATURE, /* Signature ... NEED TO BE FILLED */
+
+  0, /* ShadowBufBaseAddr ... NEED TO BE FILLED */
+  0, /* ShadowBufSize ... NEED TO BE FILLED */
+  0, /* FvbFlashVarOffset ... NEED TO BE FILLED */
+  0, /* FvbFlashVarSize ... NEED TO BE FILLED */
+  0, /* BlockSize ... NEED TO BE FILLED */
+  0, /* LastBlock ... NEED TO BE FILLED */
+  0, /* StartLba */
+
+  {
+FvbGetAttributes,   /* GetAttributes */
+FvbSetAttributes,   /* SetAttributes */
+FvbGetPhysicalAddress,  /* GetPhysicalAddress */
+FvbGetBlockSize,/* GetBlockSize */
+FvbRead,/* Read */
+FvbWrite,   /* Write */
+FvbEraseBlocks, /* EraseBlocks */
+NULL,   /* ParentHandle */
+  }, /* EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL */
+
+  {
+{
+  {
+HARDWARE_DEVICE_PATH,
+HW_VENDOR_DP,
+{
+  (UINT8)sizeof (VENDOR_DEVICE_PATH),
+  (UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+}
+  },
+  { 0xfc0cb972, 0x21df, 0x44d2, { 0x92, 0xa5, 0x78, 0x98, 0x99, 0xcb, 
0xf6, 0x61 }
+  }
+},
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 }
+}
+  } /* FVB_DEVICE_PATH */
+};
+
+STATIC
+EFI_STATUS
+FvbInitFvAndVariableStoreHeaders (
+  IN FVB_DEVICE  *FlashInstance
+  )
+{
+  EFI_FIRMWARE_VOLUME_HEADER  *FirmwareVolumeHeader;
+  VARIABLE_STORE_HEADER   *VariableStoreHeader;
+  EFI_STATUS  Status;
+  VOID*Headers;
+  UINTN   HeadersLength;
+  UINTN   BlockSize;
+
+  HeadersLength = sizeof (EFI_FIRMWARE_VOLUME_HEADER) +
+  sizeof (EFI_FV_BLOCK_MAP_ENTRY) +
+  sizeof (VARIABLE_STORE_HEADER);
+  Headers = AllocateZeroPool (HeadersLength);
+
+  BlockSize = FlashInstance->BlockSize;
+
+  /* VariableBase -> FtwWOrkingBase -> FtwSpareBase are declared
+   * consecutively in contiguous memory
+   */
+  ASSERT (
+  PcdGet64 (PcdFlashNvStorageVariableBase64) +
+  PcdGet32 (PcdFlashNvStorageVariableSize) ==
+  PcdGet64 (PcdFlashNvStorageFtwWorkingBase64)
+  );
+  ASSERT (
+  PcdGet64 (PcdFlashNvStorageFtwWorkingBase64) +
+  PcdGet32 (PcdFlashNvStorageFtwWorkingSize) ==
+  PcdGet64 (PcdFlashNvStorageFtwSpareBase64)
+  );
+
+  /* Ensure the size of the variable area is at least one block size */
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageVariableSize) > 0) &&
+  (PcdGet32 (PcdFlashNvStorageVariableSize) / BlockSize > 0)
+  );
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageFtwWorkingSize) > 0) &&
+  (PcdGet32 (PcdFlashNvStorageFtwWorkingSize) / BlockSize > 0)
+  );
+  ASSERT (
+  (PcdGet32 (PcdFlashNvStorageFtwSpareSize) > 0) &&
+  (PcdGet32 (PcdFlashNvStorageFtwSpareSize) / BlockSize > 0)
+  );
+
+  /* Ensure the Variable areas are aligned on block size boundaries */
+  ASSERT ((PcdGet64 (PcdFlashNvStorageVariableBase64) % BlockSize) == 0);
+  ASSERT ((PcdGet64 (PcdFlashNvStorageFtwWorkingBase64) % BlockSize) == 0);
+  ASSERT ((PcdGet64 (PcdFlashNvStorageFtwSpareBase64) % BlockSize) == 0);
+
+  /* -
+   * | Firmware Volume Header |  |
+   * --   Non-Volatile   |
+   * | Variable Store Header  | Storage Variable |
+   * -

[edk2-devel] [PATCH v1 2/6] StarFive/JH7110Pkg: Add SPI protocol and driver support

[John Chew]

Cc: Sunil V L 
Signed-off-by: John Chew 
---
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
 | 893 
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.h
 | 188 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.inf  
 |  52 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.c  
 | 571 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.h  
 |  35 +
 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.inf 
|  44 +
 Silicon/StarFive/JH7110Pkg/Include/Protocol/Spi.h  
 | 163 
 Silicon/StarFive/JH7110Pkg/Include/Protocol/SpiFlash.h 
 |  88 ++
 8 files changed, 2034 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c 
b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
new file mode 100755
index ..c345556f8abf
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
@@ -0,0 +1,893 @@
+/** @file
+ *
+ *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include "SpiDxe.h"
+
+SPI_MASTER  *mSpiMasterInstance;
+
+STATIC
+VOID
+SpiControllerEnable (
+  IN UINT32  RegBase
+  )
+{
+  UINT32  Reg;
+
+  Reg  = MmioRead32 (RegBase + SPI_REG_CONFIG);
+  Reg |= SPI_REG_CONFIG_ENABLE;
+  MmioWrite32 (RegBase + SPI_REG_CONFIG, Reg);
+}
+
+STATIC
+VOID
+SpiControllerDisable (
+  IN UINT32  RegBase
+  )
+{
+  UINT32  Reg;
+
+  Reg  = MmioRead32 (RegBase + SPI_REG_CONFIG);
+  Reg &= ~SPI_REG_CONFIG_ENABLE;
+  MmioWrite32 (RegBase + SPI_REG_CONFIG, Reg);
+}
+
+STATIC
+VOID
+SpiWriteSpeed (
+  IN SPI_DEVICE_PARAMS  *Slave,
+  IN UINT32 SclkHz,
+  IN SPI_TIMING_PARAMS  *Timing
+  )
+{
+  UINT32  Reg, Div, RefClkNs, SclkNs;
+  UINT32  Tshsl, Tchsh, Tslch, Tsd2d;
+
+  SpiControllerDisable (Slave->RegBase);
+
+  /* Configure baudrate */
+  Reg  = MmioRead32 (Slave->RegBase + SPI_REG_CONFIG);
+  Reg &= ~(SPI_REG_CONFIG_BAUD_MASK << SPI_REG_CONFIG_BAUD_LSB);
+
+  Div = DIV_ROUND_UP (Timing->RefClkHz, SclkHz * 2) - 1;
+
+  if (Div > SPI_REG_CONFIG_BAUD_MASK) {
+Div = SPI_REG_CONFIG_BAUD_MASK;
+  }
+
+  DEBUG (
+ (DEBUG_INFO, "%a(): RefClk %dHz sclk %dHz Div 0x%x, actual %dHz\n", 
__func__,
+  Timing->RefClkHz, SclkHz, Div, Timing->RefClkHz / (2 * (Div + 1)))
+ );
+
+  Reg |= (Div << SPI_REG_CONFIG_BAUD_LSB);
+  MmioWrite32 (Slave->RegBase + SPI_REG_CONFIG, Reg);
+
+  /* Configure delay timing */
+  RefClkNs = DIV_ROUND_UP (10, Timing->RefClkHz);
+  SclkNs = DIV_ROUND_UP (10, SclkHz);
+
+  if (Timing->TshslNs >= SclkNs + RefClkNs) {
+Timing->TshslNs -= SclkNs + RefClkNs;
+  }
+
+  if (Timing->TchshNs >= SclkNs + 3 * RefClkNs) {
+Timing->TchshNs -= SclkNs + 3 * RefClkNs;
+  }
+
+  Tshsl = DIV_ROUND_UP (Timing->TshslNs, RefClkNs);
+  Tchsh = DIV_ROUND_UP (Timing->TchshNs, RefClkNs);
+  Tslch = DIV_ROUND_UP (Timing->TslchNs, RefClkNs);
+  Tsd2d = DIV_ROUND_UP (Timing->Tsd2dNs, RefClkNs);
+
+  Reg = ((Tshsl & SPI_REG_DELAY_TSHSL_MASK)
+ << SPI_REG_DELAY_TSHSL_LSB);
+  Reg |= ((Tchsh & SPI_REG_DELAY_TCHSH_MASK)
+  << SPI_REG_DELAY_TCHSH_LSB);
+  Reg |= ((Tslch & SPI_REG_DELAY_TSLCH_MASK)
+  << SPI_REG_DELAY_TSLCH_LSB);
+  Reg |= ((Tsd2d & SPI_REG_DELAY_TSD2D_MASK)
+  << SPI_REG_DELAY_TSD2D_LSB);
+  MmioWrite32 (Slave->RegBase + SPI_REG_DELAY, Reg);
+
+  SpiControllerEnable (Slave->RegBase);
+}
+
+STATIC
+EFI_STATUS
+SpiWaitIdle (
+  IN UINT32  RegBase
+  )
+{
+  BOOLEAN IsIdle;
+  UINT32  Count = 0;
+  UINT32  TimeoutMs = 500;
+
+  do {
+IsIdle = (BOOLEAN)((MmioRead32(RegBase + SPI_REG_CONFIG) >>
+SPI_REG_CONFIG_IDLE_LSB) & 0x1);
+Count = (IsIdle) ? (Count+1) : 0;
+
+/*
+ * Make sure the QSPI controller is in really idle
+ * for n period of time before proceed
+ */
+if (Count >= SPI_POLL_IDLE_RETRY) {
+  return EFI_SUCCESS;
+}
+
+gBS->Stall (1);
+  } while (TimeoutMs);
+
+  return EFI_TIMEOUT;
+}
+
+STATIC
+EFI_STATUS
+SpiExecFlashCmd (
+  IN UINT32  RegBase,
+  IN UINT32  Reg
+  )
+{
+  EFI_STATUS  Status;
+  UINT32  Retry = SPI_REG_RETRY;
+
+  /* Write the CMDCTRL without start execution */
+  MmioWrite32 (RegBase + SPI_REG_CMDCTRL, Reg);
+  /* Start execute */
+  Reg |= SPI_REG_CMDCTRL_EXECUTE;
+  MmioWrite32 (RegBase + SPI_REG_CMDCTRL, Reg);
+
+  while (Retry--) {
+Reg = MmioRead32 (RegBase + SPI_REG_CMDCTRL);
+if ((Reg & SPI_REG_CMDCTRL_INPROGRESS) == 0) {
+  break;
+}
+gBS->Stall (1);
+  }
+
+  if (!Retry) {
+DEBUG ((DEBUG_ERROR, "%a(): flash command execution Timeout\n", __func__));
+return EFI_TIMEOUT;
+  }
+
+  /* Polling QSPI idle status */
+  Status = SpiWaitIdle (RegBase);
+  if (EFI_ERR

[edk2-devel] [PATCH v1 1/6] StarFive/JH7110Pkg: Add Pci controller driver

[John Chew]

From: mindachen1987 

Cc: Sunil V L 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
   |  249 
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf   
   |   48 +
 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLibConstructor.c
 |  405 ++
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.c   
   | 1460 
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.inf 
   |   33 +
 5 files changed, 2195 insertions(+)

diff --git 
a/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
new file mode 100644
index ..7d73cb5b4b5c
--- /dev/null
+++ b/Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -0,0 +1,249 @@
+/** @file
+ *
+ * PCI Host Bridge Library instance for StarFive JH7110 SOC
+ *
+ * Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack(1)
+
+typedef PACKED struct {
+  ACPI_HID_DEVICE_PATHAcpiDevicePath;
+  EFI_DEVICE_PATH_PROTOCOLEndDevicePath;
+} EFI_PCI_ROOT_BRIDGE_DEVICE_PATH;
+
+#pragma pack ()
+
+STATIC CONST EFI_PCI_ROOT_BRIDGE_DEVICE_PATH  mEfiPciRootBridgeDevicePath[] = {
+  {
+{
+  {
+ACPI_DEVICE_PATH,
+ACPI_DP,
+{
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
+}
+  },
+  EISA_PNP_ID (0x0A08), // PCI Express
+  0
+},
+
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  {
+END_DEVICE_PATH_LENGTH,
+0
+  }
+}
+  },
+
+  {
+{
+  {
+ACPI_DEVICE_PATH,
+ACPI_DP,
+{
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH)),
+  (UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
+}
+  },
+  EISA_PNP_ID (0x0A08), // PCI Express
+  1
+},
+
+{
+  END_DEVICE_PATH_TYPE,
+  END_ENTIRE_DEVICE_PATH_SUBTYPE,
+  {
+END_DEVICE_PATH_LENGTH,
+0
+  }
+}
+  },
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+CHAR16  *mPciHostBridgeLibAcpiAddressSpaceTypeStr[] = {
+  L"Mem", L"I/O", L"Bus"
+};
+
+// These should come from the PCD...
+#define JH7110_PCI_BUSNUM_MIN 0x00
+#define JH7110_PCI_BUSNUM_MAX 0xFF
+#define JH7110_PCI_PORTIO_MIN 0x01
+#define JH7110_PCI_PORTIO_MAX 0x00 // MIN>MAX disables PIO
+#define JH7110_PCI_PORTIO_OFFSET  0x00
+// The bridge thinks its MMIO is here (which means it can't access this area 
in phy ram)
+
+#define JH7110_PCI_SEG0_MMIO32_MIN  (0x3000)
+#define JH7110_PCI_SEG0_MMIO32_MAX  (JH7110_PCI_SEG0_MMIO32_MIN + 0x7FF)
+// The CPU views it via a window here..
+// We might be able to size another region?
+#define JH7110_PCI_SEG0_MMIO64_MIN  (0x9)
+#define JH7110_PCI_SEG0_MMIO64_MAX  (0x94000)
+
+#define JH7110_PCI_SEG1_MMIO32_MIN  (0x3800)
+#define JH7110_PCI_SEG1_MMIO32_MAX  (JH7110_PCI_SEG1_MMIO32_MIN + 0x7FF)
+// The CPU views it via a window here..
+// We might be able to size another region?
+#define JH7110_PCI_SEG1_MMIO64_MIN  (0x98000)
+#define JH7110_PCI_SEG1_MMIO64_MAX  (0x9c000)
+
+//
+// See description in MdeModulePkg/Include/Library/PciHostBridgeLib.h
+//
+PCI_ROOT_BRIDGE  mPciRootBridges[] = {
+  {
+0,  // Segment
+0,  // Supports
+0,  // Attributes
+FALSE,  // DmaAbove4G
+FALSE,  // NoExtendedConfigSpace (true=256 
byte config, false=4k)
+FALSE,  // ResourceAssigned
+EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM |
+EFI_PCI_HOST_BRIDGE_MEM64_DECODE,   // AllocationAttributes
+{ JH7110_PCI_BUSNUM_MIN,
+  JH7110_PCI_BUSNUM_MAX },// Bus
+{ JH7110_PCI_PORTIO_MIN,
+  JH7110_PCI_PORTIO_MAX,
+  MAX_UINT64 - JH7110_PCI_PORTIO_OFFSET + 1 },   // Io
+{ JH7110_PCI_SEG0_MMIO32_MIN, JH7110_PCI_SEG0_MMIO32_MAX, 0 },  // Mem
+{ JH7110_PCI_SEG0_MMIO64_MIN,JH7110_PCI_SEG0_MMIO64_MAX,  0 },  // 
MemAbove4G
+{ MAX_UINT32,0x0 }, // 
Pefetchable Mem
+{ MAX_UINT64,0x0 }, // 
Pefetchable MemAbove4G
+(EFI_DEVICE_PATH_PROTOCOL *)&mEfiPciRootBridgeDevicePath[0]
+  },
+  {
+1,  // Segment
+0,  // Supports
+0,  // Attributes
+FALSE,  // DmaAbove4G
+FALSE,

[edk2-devel] [PATCH v1 0/6] Patches for JH7110 SoC platform

[John Chew]

In this patches it include all the platform specific drivers/protocol
that is being use for JH7110 SoC platform. All the drivers includes:
1. PCIE driver for NVME and USB (GT710 graphic in progress)
2. QSPI Flash driver for efi variable
3. FVB driver for efi variable
4. Boot service memory allocation driver
5. Platform boot manager for graphical console display

Reference branch: 
https://github.com/johnchewyy/edkii-platforms/tree/vf2_jh7110_devel_upstream

Cc: Sunil V L 
Cc: Li Yong 

John Chew (4):
  StarFive/JH7110Pkg: Add SPI protocol and driver support
  StarFive/JH7110Pkg: Add firmware volume block protocol
  StarFive/JH7110Pkg: Implement boot services memory allocation driver
  StarFive/JH7110Pkg: Add PlatformBootManagerLib library

mindachen1987 (2):
  StarFive/JH7110Pkg: Add Pci controller driver
  StarFive/JH7110Pkg: Add JH7110 Silicon Package

 Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c
  |  108 ++
 Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf  
  |   34 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
  |  909 
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h
  |  138 ++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf  
  |   70 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
  |  893 
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.h
  |  188 +++
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.inf  
  |   52 +
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.c  
  |  571 
 Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.h  
  |   35 +
 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.inf 
 |   44 +
 Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h   
  |   24 +
 Silicon/StarFive/JH7110Pkg/Include/Protocol/Spi.h  
  |  163 +++
 Silicon/StarFive/JH7110Pkg/Include/Protocol/SpiFlash.h 
  |   88 ++
 Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec   
  |   45 +
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c 
  |  249 
 Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf   
  |   48 +
 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLibConstructor.c
|  405 ++
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.c   
  | 1460 
 Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.inf 
  |   33 +
 Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c 
  | 1014 ++
 Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.h 
  |   46 +
 
Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 |   71 +
 23 files changed, 6688 insertions(+)
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/BootServicesDxe/BootServicesDxe.inf
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.h
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/FvbDxe/FvbDxe.inf
 create mode 100755 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.h
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiDxe/SpiDxe.inf
 create mode 100755 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.c
 create mode 100755 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.h
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Driver/SpiFvbServicesDxe/SpiFlashDxe/SpiFlashDxe.inf
 create mode 100644 Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
 create mode 100644 Silicon/StarFive/JH7110Pkg/Include/Protocol/Spi.h
 create mode 100644 Silicon/StarFive/JH7110Pkg/Include/Protocol/SpiFlash.h
 create mode 100644 Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Library/PciHostBridgeLib/PciHostBridgeLibConstructor.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.c
 create mode 100644 
Silicon/StarFive/JH7110Pkg/Library/PciSegmentLib/PciSegmentLib.inf
 create mode 100755 
Silicon/StarFive/JH

[edk2-devel] [PATCH v1 4/4] DesignWare/DwEmmcDxe: Add handling for SDMMC

[John Chew]

From: mindachen1987 

Add base address PCD for eMMC and SDMMC
Add application command for SDMMC
Add PCD for Ultra High Speed (UHS) option

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sunil V L 
Cc: Li Yong 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/Synopsys/DesignWare/DesignWare.dec 
 |   2 +
 Silicon/Synopsys/DesignWare/DesignWare.dsc 
 |   1 +
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h 
 |  64 +++
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c  
 | 183 +---
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
 |   1 +
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/{DwEmmcDxe.inf => 
DwSdmmcDxe.inf} |   9 +-
 6 files changed, 158 insertions(+), 102 deletions(-)

diff --git a/Silicon/Synopsys/DesignWare/DesignWare.dec 
b/Silicon/Synopsys/DesignWare/DesignWare.dec
index 751370a8b1af..91aca7568b08 100755
--- a/Silicon/Synopsys/DesignWare/DesignWare.dec
+++ b/Silicon/Synopsys/DesignWare/DesignWare.dec
@@ -31,4 +31,6 @@ [PcdsFixedAtBuild.common]
   
gDesignWareTokenSpaceGuid.PcdDwEmmcDxeClockFrequencyInHz|0x0|UINT32|0x0003
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeMaxClockFreqInHz|0x0|UINT32|0x0004
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeFifoDepth|0x0|UINT32|0x0005
+  gDesignWareTokenSpaceGuid.PcdDwSdDxeBaseAddress|0x0|UINT32|0x0006
+  gDesignWareTokenSpaceGuid.PcdDwEmmcDxeUHSEn|TRUE|BOOLEAN|0x0007
   
gDesignWareTokenSpaceGuid.PcdDwEmmcDxeCPULittleEndian|FALSE|BOOLEAN|0x0008
diff --git a/Silicon/Synopsys/DesignWare/DesignWare.dsc 
b/Silicon/Synopsys/DesignWare/DesignWare.dsc
index b5a7b38e142e..7ebec358851e 100755
--- a/Silicon/Synopsys/DesignWare/DesignWare.dsc
+++ b/Silicon/Synopsys/DesignWare/DesignWare.dsc
@@ -43,3 +43,4 @@ [LibraryClasses]
 [Components]
   Silicon/Synopsys/DesignWare/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf
   Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
+  Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwSdmmcDxe.inf
diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
index 3347418006c7..5d2e6d4055a4 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
@@ -18,38 +18,38 @@
 #include 
 
 // DW MMC Registers
-#define DWEMMC_CTRL ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x000)
-#define DWEMMC_PWREN((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x004)
-#define DWEMMC_CLKDIV   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x008)
-#define DWEMMC_CLKSRC   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x00c)
-#define DWEMMC_CLKENA   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x010)
-#define DWEMMC_TMOUT((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x014)
-#define DWEMMC_CTYPE((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x018)
-#define DWEMMC_BLKSIZ   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x01c)
-#define DWEMMC_BYTCNT   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x020)
-#define DWEMMC_INTMASK  ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x024)
-#define DWEMMC_CMDARG   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x028)
-#define DWEMMC_CMD  ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x02c)
-#define DWEMMC_RESP0((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x030)
-#define DWEMMC_RESP1((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x034)
-#define DWEMMC_RESP2((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x038)
-#define DWEMMC_RESP3((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x03c)
-#define DWEMMC_RINTSTS  ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x044)
-#define DWEMMC_STATUS   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x048)
-#define DWEMMC_FIFOTH   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x04c)
-#define DWEMMC_TCBCNT   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x05c)
-#define DWEMMC_TBBCNT   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x060)
-#define DWEMMC_DEBNCE   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x064)
-#define DWEMMC_HCON ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x070)
-#define DWEMMC_UHSREG   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x074)
-#define DWEMMC_BMOD ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x080)
-#define DWEMMC_DBADDR   ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x088)
-#define DWEMMC_IDSTS((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x08c)
-#define DWEMMC_IDINTEN  ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x090)
-#define DWEMMC_DSCADDR  ((UINT32)PcdGet32 (PcdDwEmmcDxeBaseAddress) + 
0x094)
-#define DWEMM

Re: [edk2-devel] [PATCH v1] MdeModulePkg: Ignore TAB in string input

[Dandan Bi]

Reviewed-by: Dandan Bi 


Thanks,
Dandan
-Original Message-
From: Li, Oscar  
Sent: Monday, September 18, 2023 3:26 PM
To: devel@edk2.groups.io
Cc: Li, Oscar ; Chiang, Dakota ; 
Bi, Dandan ; Dong, Eric 
Subject: [PATCH v1] MdeModulePkg: Ignore TAB in string input

From: Oscar Li 

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

Ignore TAB when handling input characters for string input to be consistent 
with the usual behavior.

Signed-off-by: Oscar Li 
Cc: Dakota Chiang 
Cc: Dandan Bi 
Cc: Eric Dong 
---
 MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
index f70feeb55f..44e774ce24 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
@@ -226,6 +226,9 @@ ReadString (
   return EFI_DEVICE_ERROR;

 }

 

+  case CHAR_TAB:

+break;

+

   case CHAR_BACKSPACE:

 if ((StringPtr[0] != CHAR_NULL) && (CurrentCursor != 0)) {

   for (Index = 0; Index < CurrentCursor - 1; Index++) {

-- 
2.41.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109777): https://edk2.groups.io/g/devel/message/109777
Mute This Topic: https://groups.io/mt/101435625/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 2/4] DesignWare/DwEmmcDxe: Add CPU little endian option

[John Chew]

From: mindachen1987 

Add PCD for little endian CPU. During RX, the endianess of data receive
via DMA will be swap.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sunil V L 
Cc: Li Yong 
Co-authored-by: mindachen1987 
Signed-off-by: John Chew 
---
 Silicon/Synopsys/DesignWare/DesignWare.dec  | 1 +
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c   | 5 +
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf | 1 +
 3 files changed, 7 insertions(+)

diff --git a/Silicon/Synopsys/DesignWare/DesignWare.dec 
b/Silicon/Synopsys/DesignWare/DesignWare.dec
index f7ec7927543c..751370a8b1af 100755
--- a/Silicon/Synopsys/DesignWare/DesignWare.dec
+++ b/Silicon/Synopsys/DesignWare/DesignWare.dec
@@ -31,3 +31,4 @@ [PcdsFixedAtBuild.common]
   
gDesignWareTokenSpaceGuid.PcdDwEmmcDxeClockFrequencyInHz|0x0|UINT32|0x0003
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeMaxClockFreqInHz|0x0|UINT32|0x0004
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeFifoDepth|0x0|UINT32|0x0005
+  
gDesignWareTokenSpaceGuid.PcdDwEmmcDxeCPULittleEndian|FALSE|BOOLEAN|0x0008
diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
index 7ac286c5f361..edda28a45d7c 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -588,6 +588,11 @@ DwEmmcReadBlockData (
   }
   Status = DwEmmcWaitDmaComplete(This, 1);
 
+  if (DWMCI_SD_READ_MASK(mDwEmmcArgument) && (FixedPcdGetBool 
(PcdDwEmmcDxeCPULittleEndian))) {
+Buffer[3] = SwapBytes32(Buffer[3]);
+Buffer[4] = SwapBytes32(Buffer[4]);
+  }
+
 out:
   // Restore Tpl
   gBS->RestoreTPL (Tpl);
diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
index 7f70fe1e2a38..18c84a4172f9 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
@@ -51,6 +51,7 @@ [Pcd]
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeMaxClockFreqInHz
   gDesignWareTokenSpaceGuid.PcdDwEmmcDxeFifoDepth
   gDesignWareTokenSpaceGuid.PcdDwPermitObsoleteDrivers
+  gDesignWareTokenSpaceGuid.PcdDwEmmcDxeCPULittleEndian
 
 [Depex]
   TRUE
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109775): https://edk2.groups.io/g/devel/message/109775
Mute This Topic: https://groups.io/mt/102053209/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 3/4] DesignWare/DwEmmcDxe: Remove ARM dependency library

[John Chew]

From: mindachen1987 

This driver do not have dependency on ArmLib. It will cause compilation
error when compile with risv architecture.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sunil V L 
Cc: Li Yong 
Signed-off-by: mindachen1987 
---
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
index 18c84a4172f9..0bd78d5a05ad 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
@@ -30,7 +30,6 @@ [Packages]
   Silicon/Synopsys/DesignWare/DesignWare.dec
 
 [LibraryClasses]
-  ArmLib
   BaseLib
   BaseMemoryLib
   CacheMaintenanceLib
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109774): https://edk2.groups.io/g/devel/message/109774
Mute This Topic: https://groups.io/mt/102053207/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/4] DesignWare/DwEmmcDxe: Enabled Internal IDMAC interrupt RX/TX register

[John Chew]

From: mindachen1987 

Remove DMA enable in CTRL register
Added DMA polling handling for RX/TX

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sunil V L 
Cc: Li Yong 
Co-authored-by: John Chew 
Signed-off-by: mindachen1987 
---
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h|  6 +++
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c | 52 
++--
 2 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
index 09ad9b8428c4..3347418006c7 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h
@@ -129,4 +129,10 @@
 
 #define DWEMMC_GET_HDATA_WIDTH(x)   (((x) >> 7) & 0x7)
 
+/* Internal IDMAC interrupt defines */
+#define DWMCI_IDINTEN_RI(1 << 1)
+#define DWMCI_IDINTEN_TI(1 << 0)
+
+#define DWMCI_IDINTEN_MASK  (DWMCI_IDINTEN_RI | 
DWMCI_IDINTEN_TI)
+
 #endif  // __DWEMMC_H__
diff --git a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c 
b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
index 39b1ea4346dc..7ac286c5f361 100644
--- a/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
+++ b/Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c
@@ -215,6 +215,7 @@ DwEmmcNotifyState (
 do {
   Data = MmioRead32 (DWEMMC_BMOD);
 } while (Data & DWEMMC_IDMAC_SWRESET);
+MmioWrite32 (DWEMMC_IDINTEN, 0x3);
 break;
   case MmcIdleState:
 break;
@@ -463,6 +464,14 @@ PrepareDmaData (
   )
 {
   UINTN  Cnt, Blks, Idx, LastIdx;
+  UINT32 Data; /* flag, cnt */
+
+  MmioWrite32 (DWEMMC_CTRL, DWEMMC_CTRL_FIFO_RESET);
+  do {
+/* Wait until reset operation finished */
+Data = MmioRead32 (DWEMMC_CTRL);
+  } while (Data & DWEMMC_CTRL_RESET_ALL);
+  MmioWrite32 (DWEMMC_IDSTS, 0x);
 
   Cnt = (Length + DWEMMC_DMA_BUF_SIZE - 1) / DWEMMC_DMA_BUF_SIZE;
   Blks = (Length + DWEMMC_BLOCK_SIZE - 1) / DWEMMC_BLOCK_SIZE;
@@ -487,9 +496,7 @@ PrepareDmaData (
   (IdmacDesc + LastIdx)->Des1 = DWEMMC_IDMAC_DES1_BS1(Length -
   (LastIdx * 
DWEMMC_DMA_BUF_SIZE));
   /* Set the Next field of Last Descriptor */
-  (IdmacDesc + LastIdx)->Des3 = 0;
   MmioWrite32 (DWEMMC_DBADDR, (UINT32)((UINTN)IdmacDesc));
-
   return EFI_SUCCESS;
 }
 
@@ -501,7 +508,7 @@ StartDma (
   UINT32 Data;
 
   Data = MmioRead32 (DWEMMC_CTRL);
-  Data |= DWEMMC_CTRL_INT_EN | DWEMMC_CTRL_DMA_EN | DWEMMC_CTRL_IDMAC_EN;
+  Data |= DWEMMC_CTRL_DMA_EN | DWEMMC_CTRL_IDMAC_EN;
   MmioWrite32 (DWEMMC_CTRL, Data);
   Data = MmioRead32 (DWEMMC_BMOD);
   Data |= DWEMMC_IDMAC_ENABLE | DWEMMC_IDMAC_FB;
@@ -511,6 +518,41 @@ StartDma (
   MmioWrite32 (DWEMMC_BYTCNT, Length);
 }
 
+STATIC
+EFI_STATUS
+DwEmmcWaitDmaComplete (
+  IN EFI_MMC_HOST_PROTOCOL *This,
+  IN UINT32 Read
+  )
+{
+  UINT32 Mask, Ctrl, Timeout = 100;
+  EFI_STATUS Status = EFI_SUCCESS;
+
+  Mask = (Read) ? DWMCI_IDINTEN_RI : DWMCI_IDINTEN_TI;
+
+  do {
+Ctrl = MmioRead32 (DWEMMC_IDSTS);
+if (Ctrl & Mask) {
+  break;
+}
+Timeout--;
+gBS->Stall(1);
+  } while (Timeout);
+
+  if (!Timeout) {
+DEBUG ((DEBUG_INFO, "%a, DMA waiting timeout...\n", __func__));
+Status = EFI_DEVICE_ERROR;
+  }
+  MmioWrite32 (DWEMMC_IDSTS, DWMCI_IDINTEN_MASK);
+  Ctrl = MmioRead32(DWEMMC_CTRL);
+  Ctrl &= ~(DWEMMC_CTRL_DMA_EN);
+  Ctrl = MmioWrite32(DWEMMC_CTRL, Ctrl);
+
+  gBS->Stall(100);
+
+  return Status;
+}
+
 EFI_STATUS
 DwEmmcReadBlockData (
   IN EFI_MMC_HOST_PROTOCOL *This,
@@ -544,6 +586,8 @@ DwEmmcReadBlockData (
 DEBUG ((DEBUG_ERROR, "Failed to read data, mDwEmmcCommand:%x, 
mDwEmmcArgument:%x, Status:%r\n", mDwEmmcCommand, mDwEmmcArgument, Status));
 goto out;
   }
+  Status = DwEmmcWaitDmaComplete(This, 1);
+
 out:
   // Restore Tpl
   gBS->RestoreTPL (Tpl);
@@ -583,6 +627,8 @@ DwEmmcWriteBlockData (
 DEBUG ((DEBUG_ERROR, "Failed to write data, mDwEmmcCommand:%x, 
mDwEmmcArgument:%x, Status:%r\n", mDwEmmcCommand, mDwEmmcArgument, Status));
 goto out;
   }
+  Status = DwEmmcWaitDmaComplete(This, 0);
+
 out:
   // Restore Tpl
   gBS->RestoreTPL (Tpl);
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109773): https://edk2.groups.io/g/devel/message/109773
Mute This Topic: https://groups.io/mt/102053201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Event: TianoCore Community Meeting - APAC/NAMO - Thursday, October 19, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Community Meeting - APAC/NAMO*

*When:*
Thursday, October 19, 2023
7:30pm to 8:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

*Organizer:* Michael Kinney

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2043510 )

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

Meeting ID: 283 318 374 436
Passcode: 633zLo

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 119 493 012 8

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1194930128&ivr=teams&d=conf.intel.com&test=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_Y2M1NDE3ODYtN2M3Yy00MDMxLTk3OWYtMTlkNjhlNWFlMjA2@thread.v2&messageId=0&language=en-US
 )




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109772): https://edk2.groups.io/g/devel/message/109772
Mute This Topic: https://groups.io/mt/102053192/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 0/4] Designware MMCDXE changes and enhancement

[John Chew]

This patch series involves the following changes:
1. Remove DMA enable in CTRL register
2. Added DMA polling handling for RX/TX 
3. Integrate SD MMC handling into the driver

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sunil V L 
Cc: Li Yong 

mindachen1987 (4):
  DesignWare/DwEmmcDxe: Enabled Internal IDMAC interrupt RX/TX register
  DesignWare/DwEmmcDxe: Add CPU little endian option
  DesignWare/DwEmmcDxe: Remove ARM dependency library
  DesignWare/DwEmmcDxe: Add handling for SDMMC

 Silicon/Synopsys/DesignWare/DesignWare.dec 
 |   3 +
 Silicon/Synopsys/DesignWare/DesignWare.dsc 
 |   1 +
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmc.h 
 |  70 +++---
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.c  
 | 240 ++--
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/DwEmmcDxe.inf
 |   3 +-
 Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/{DwEmmcDxe.inf => 
DwSdmmcDxe.inf} |  11 +-
 6 files changed, 221 insertions(+), 107 deletions(-)
 copy Silicon/Synopsys/DesignWare/Drivers/DwEmmcDxe/{DwEmmcDxe.inf => 
DwSdmmcDxe.inf} (74%)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109771): https://edk2.groups.io/g/devel/message/109771
Mute This Topic: https://groups.io/mt/102053167/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Question about OvmfPackage cxl emulation support

[Yoshinoya]

Hi,
I findd qemu supports cxl emulation, but it uses seabios as virtual machine 
firmware.


Does UEFI OvmfPackage have a plan to support CXL device enumeration and 
declaration?


Thanks

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109770): https://edk2.groups.io/g/devel/message/109770
Mute This Topic: https://groups.io/mt/102052612/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 2/2] StandaloneMmPkg: Arm: Update to use the new StandaloneMmCpu driver

[Tuan Phan]

Hi Sami,
Not sure if you can merge this series or let me know who can do it.

Thanks,

From: Sami Mujawar 
Date: Thursday, October 5, 2023 at 4:12 AM
To: Tuan Phan , devel@edk2.groups.io 

Cc: ardb+tianoc...@kernel.org , ray...@intel.com 
, huangm...@linux.alibaba.com , 
suni...@ventanamicro.com , yong...@intel.com 
, yeoreum@arm.com , n...@arm.com 

Subject: Re: [PATCH v3 2/2] StandaloneMmPkg: Arm: Update to use the new 
StandaloneMmCpu driver

Hi Tuan,

Thank you for this patch.

These changes look good to me.

Reviewed-by: Sami Mujawar 

Regards,

Sami Mujawar

On 28/09/2023 10:14 pm, Tuan Phan wrote:
> Update entry point library for Arm to use the new architecture independent
> StandaloneMmCpu driver.
>
> Signed-off-by: Tuan Phan 
> Reviewed-by: levi.yun 
> ---
>   .../Library/Arm/StandaloneMmCoreEntryPoint.h  | 17 +
>   .../Arm/CreateHobList.c   | 43 ++--
>   .../Arm/StandaloneMmCoreEntryPoint.c  | 69 +++
>   .../StandaloneMmCoreEntryPoint.inf|  2 +-
>   4 files changed, 67 insertions(+), 64 deletions(-)
>
> diff --git a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h 
> b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
> index 41bf0f132b4f..dbb81610ff8e 100644
> --- a/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
> +++ b/StandaloneMmPkg/Include/Library/Arm/StandaloneMmCoreEntryPoint.h
> @@ -10,6 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>   #ifndef __STANDALONEMMCORE_ENTRY_POINT_H__
>
>   #define __STANDALONEMMCORE_ENTRY_POINT_H__
>
>
>
> +#include 
>
>   #include 
>
>   #include 
>
>
>
> @@ -47,18 +48,6 @@ typedef struct {
> EFI_SECURE_PARTITION_CPU_INFO*CpuInfo;
>
>   } EFI_SECURE_PARTITION_BOOT_INFO;
>
>
>
> -typedef
>
> -EFI_STATUS
>
> -(*PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT) (
>
> -  IN UINTN  EventId,
>
> -  IN UINTN  CpuNumber,
>
> -  IN UINTN  NsCommBufferAddr
>
> -  );
>
> -
>
> -typedef struct {
>
> -  PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT*ArmTfCpuDriverEpPtr;
>
> -} ARM_TF_CPU_DRIVER_EP_DESCRIPTOR;
>
> -
>
>   typedef RETURN_STATUS (*REGION_PERMISSION_UPDATE_FUNC) (
>
> IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
>
> IN  UINT64Length
>
> @@ -145,8 +134,8 @@ LocateStandaloneMmCorePeCoffData (
>   VOID *
>
>   EFIAPI
>
>   CreateHobListFromBootInfo (
>
> -  IN  OUT  PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT  *CpuDriverEntryPoint,
>
> -  IN   EFI_SECURE_PARTITION_BOOT_INFO  *PayloadBootInfo
>
> +  IN  OUT  PI_MM_CPU_DRIVER_ENTRYPOINT *CpuDriverEntryPoint,
>
> +  IN   EFI_SECURE_PARTITION_BOOT_INFO  *PayloadBootInfo
>
> );
>
>
>
>   /**
>
> diff --git 
> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c 
> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
> index 2ac2d354f06a..80ed532352af 100644
> --- a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
> +++ b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c
> @@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>   #include 
>
>   #include 
>
>
>
> +#include 
>
>   #include 
>
>   #include 
>
>   #include 
>
> @@ -39,7 +40,7 @@ extern EFI_GUID  gEfiStandaloneMmNonSecureBufferGuid;
>   // GUID to identify HOB where the entry point of the CPU driver will be
>
>   // populated to allow this entry point driver to invoke it upon receipt of 
> an
>
>   // event
>
> -extern EFI_GUID  gEfiArmTfCpuDriverEpDescriptorGuid;
>
> +extern EFI_GUID  gEfiMmCpuDriverEpDescriptorGuid;
>
>
>
>   /**
>
> Use the boot information passed by privileged firmware to populate a HOB 
> list
>
> @@ -52,22 +53,22 @@ extern EFI_GUID  gEfiArmTfCpuDriverEpDescriptorGuid;
>   **/
>
>   VOID *
>
>   CreateHobListFromBootInfo (
>
> -  IN  OUT  PI_MM_ARM_TF_CPU_DRIVER_ENTRYPOINT  *CpuDriverEntryPoint,
>
> -  IN   EFI_SECURE_PARTITION_BOOT_INFO  *PayloadBootInfo
>
> +  IN  OUT  PI_MM_CPU_DRIVER_ENTRYPOINT *CpuDriverEntryPoint,
>
> +  IN   EFI_SECURE_PARTITION_BOOT_INFO  *PayloadBootInfo
>
> )
>
>   {
>
> -  EFI_HOB_HANDOFF_INFO_TABLE   *HobStart;
>
> -  EFI_RESOURCE_ATTRIBUTE_TYPE  Attributes;
>
> -  UINT32   Index;
>
> -  UINT32   BufferSize;
>
> -  UINT32   Flags;
>
> -  EFI_MMRAM_HOB_DESCRIPTOR_BLOCK   *MmramRangesHob;
>
> -  EFI_MMRAM_DESCRIPTOR *MmramRanges;
>
> -  EFI_MMRAM_DESCRIPTOR *NsCommBufMmramRange;
>
> -  MP_INFORMATION_HOB_DATA  *MpInformationHobData;
>
> -  EFI_PROCESSOR_INFORMATION*ProcInfoBuffer;
>
> -  EFI_SECURE_PARTITION_CPU_INFO*CpuInfo;
>
> -  ARM_TF_CPU_DRIVER_EP_DESCRIPTOR  *CpuDriverEntryPointDesc;
>
> +  EFI_HOB_HANDOFF_INFO_TABLE  *HobStart;
>
> +  EFI_RESOURCE_ATTRIBUTE_TYPE Attributes;
>
> +  UINT32  Index;
>
> +  UINT32  BufferSize;
>
> +  UINT32  Flags;

[edk2-devel] [PATCH] OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. file

[Laszlo Ersek]

Referring to a file relative to a regular file makes no sense (or at least
it cannot be implemented consistently with how a file is referred to
relative to a directory). VirtioFsSimpleFileOpen() has enforced this
strictly since the beginning, and a few months ago I reported USWG Mantis
ticket #2367 [1] too, for clearing up the related confusion in the UEFI
spec.

Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
believe the shim bug is ever going to be fixed. We can however relax the
check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
opened relative to a regular file is absolute, then the base file is going
to be ignored anyway, so we can let the caller's bug slide. This happens
to make shim work.

Why this matters: UEFI-bootable Linux installer ISOs tend to come with
shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
want to build upstream shim/grub binaries, but boot the same ISO
otherwise. The fastest way for overriding the ESP for this purpose is to
copy its original contents to a virtio filesystem, then overwrite the shim
and grub binaries from the host side. Note that this is different from
direct-booting a kernel (via fw_cfg); the point is to check whether the
just-built shim and grub are able to boot the rest of the ISO.

[1] https://mantis.uefi.org/mantis/view.php?id=2367
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
[3] https://github.com/rhboot/shim/issues/382

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Signed-off-by: Laszlo Ersek 
---

Notes:
context:-U4

 OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
index a13d4f6a1e2d..2ecf3d6c2325 100644
--- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
+++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
@@ -394,22 +394,33 @@ VirtioFsSimpleFileOpen (
 
   //
   // Referring to a file relative to a regular file makes no sense (or at least
   // it cannot be implemented consistently with how a file is referred to
-  // relative to a directory).
+  // relative to a directory). See USWG Mantis ticket #2367.
   //
   if (!VirtioFsFile->IsDirectory) {
+BOOLEAN  BugCompat;
+
+//
+// Tolerate this bug in the caller if FileName is absolute. If FileName is
+// absolute, then VirtioFsAppendPath() below will disregard
+// VirtioFsFile->CanonicalPathname.
+//
+BugCompat = (FileName[0] == L'\\');
+
 DEBUG ((
-  DEBUG_ERROR,
+  BugCompat ? DEBUG_WARN : DEBUG_ERROR,
   ("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
"nonsensical request to open a file or directory relative to a regular "
"file\n"),
   __func__,
   VirtioFs->Label,
   VirtioFsFile->CanonicalPathname,
   FileName
   ));
-return EFI_INVALID_PARAMETER;
+if (!BugCompat) {
+  return EFI_INVALID_PARAMETER;
+}
   }
 
   //
   // Allocate the new VIRTIO_FS_FILE object.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109768): https://edk2.groups.io/g/devel/message/109768
Mute This Topic: https://groups.io/mt/102044004/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] BaseTools: trim warning to error

[Rebecca Cran]

Reviewed-by: Rebecca Cran 


On 9/22/23 00:47, Yuwei Chen wrote:

As the error is changed to warning, Trim.py will skip the build
error when the source code have exactly issue.
This patch change warning to error to opens the checking.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Yuwei Chen 
---
  BaseTools/Source/Python/Trim/Trim.py | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Trim/Trim.py 
b/BaseTools/Source/Python/Trim/Trim.py
index c479f7d2b2e7..416935df5e90 100644
--- a/BaseTools/Source/Python/Trim/Trim.py
+++ b/BaseTools/Source/Python/Trim/Trim.py
@@ -281,10 +281,10 @@ def DoInclude(Source, Indent='', IncludePathList=[], 
LocalSearchPath=None, Inclu
  F = File.readlines()
  break
  else:
-EdkLogger.warn("Trim", "Failed to find include file %s" % Source)
+EdkLogger.error("Trim", "Failed to find include file %s" % Source)
  return []
  except:
-EdkLogger.warn("Trim", FILE_OPEN_FAILURE, ExtraData=Source)
+EdkLogger.error("Trim", FILE_OPEN_FAILURE, ExtraData=Source)
  return []
  
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109767): https://edk2.groups.io/g/devel/message/109767
Mute This Topic: https://groups.io/mt/101516516/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS

[Konstantin Aladyshev]

Thanks!

I've found some issues with the current PLDM code, I hope I will get
back with complete feedback on how to make everything work by Friday.

I was also thinking about the response buffer interface in the
MctpProtocol/PldmProtocols.
Currently the caller should provide the response buffer big enough to
accommodate the actual response. Otherwise the code will return with
error.
I'm thinking, wouldn't it be better to just dynamically allocate the
response buffer inside the protocols and leave the responsibility of
calling FreePool(...) to the caller?
What do you think?

Best regards,
Konstantin Aladyshev

On Wed, Oct 18, 2023 at 6:45 AM Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
> Code update is on 
> https://github.com/changab/edk2-platforms/tree/MCTP_OVER_KCS_UPDATE, the last 
> commit.
>
> Abner
>
> > -Original Message-
> > From: Chang, Abner
> > Sent: Wednesday, October 18, 2023 10:49 AM
> > To: Konstantin Aladyshev 
> > Subject: RE: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
> >
> > Sure, this works for me. I will update the code.
> >
> > Thanks
> > Abner
> >
> > > -Original Message-
> > > From: Konstantin Aladyshev 
> > > Sent: Tuesday, October 17, 2023 11:58 PM
> > > To: Chang, Abner 
> > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS
> > >
> > > Caution: This message originated from an External Source. Use proper
> > caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > Oops, sorry, never mind the last letter. I think I've got confused
> > > between the different PldmSubmit functions.
> > > We don't need to change the protocol interface.
> > >
> > > But still I think we can get rid of special values like
> > > PLDM_TERMINUS_ID_UNASSIGNED and PLDM_TERMINUS_ID_SPECIAL
> > with
> > > something like this:
> > >
> > > https://github.com/changab/edk2-
> > >
> > platforms/blob/56087215747be4a6a73e17e8478d5a8c6e35c801/Features/
> > > ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.c#L16
> > > - UINT8mSourcePldmTerminusId  =
> > > PLDM_TERMINUS_ID_UNASSIGNED;
> > > - UINT8mDestinationPldmTerminusId =
> > > PLDM_TERMINUS_ID_UNASSIGNED;
> > > + UINT8mSourcePldmTerminusId  =
> > > PcdGet8(PcdPldmSourceTerminusId);
> > > + UINT8mDestinationPldmTerminusId =
> > > PcdGet8(PcdPldmDestinationTerminusId);
> > >
> > > https://github.com/changab/edk2-
> > >
> > platforms/blob/56087215747be4a6a73e17e8478d5a8c6e35c801/Features/
> > >
> > ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.c#L105
> > > ```
> > >   Status = mEdkiiPldmProtocol->Functions.Version1_0-
> > >PldmSubmitCommand
> > > (
> > >mEdkiiPldmProtocol,
> > >PldmType,
> > >Command,
> > > -
> > > (mSourcePldmTerminusId == PLDM_TERMINUS_ID_SPECIAL)? (UINT8
> > > *)NULL:
> > > &mSourcePldmTerminusId,
> > > -
> > > (mDestinationPldmTerminusId == PLDM_TERMINUS_ID_SPECIAL)? (UINT8
> > > *)NULL: &mDestinationPldmTerminusId,
> > > + 
> > > &mSourcePldmTerminusId,
> > > +
> > > &mDestinationPldmTerminusId,
> > >RequestData,
> > >RequestDataSize,
> > >ResponseData,
> > >ResponseDataSize
> > >);
> > > ```
> > >
> > > I'll try to test everything on the hardware tomorrow.
> > >
> > > Best regards,
> > > Konstantin Aladyshev
> > >
> > > On Tue, Oct 17, 2023 at 4:12 PM Konstantin Aladyshev
> > >  wrote:
> > > >
> > > > One more thought.
> > > >
> > > > Shouldn't we also put the "PldmSetTerminus" to the
> > > EDKII_PLDM_PROTOCOL?
> > > > https://github.com/changab/edk2-
> > >
> > platforms/blob/56087215747be4a6a73e17e8478d5a8c6e35c801/Features/
> > > ManageabilityPkg/Include/Protocol/PldmProtocol.h#L71
> > > >
> > > > As you remember in my test application I've manually constructed the
> > > > MCTP buffer for the "GetPLDMTypes (0x04)" PLDM command and sent it
> > via
> > > > the EDKII_MCTP_PROTOCOL:
> > > > https://github.com/changab/edk2-
> > >
> > platforms/blob/56087215747be4a6a73e17e8478d5a8c6e35c801/Features/
> > > ManageabilityPkg/Include/Protocol/PldmProtocol.h#L71
> > > >
> > > > The next test should be to send the same command, but via the
> > > > EDKII_PLDM_PROTOCOL.
> > > > And to route the MCTP packet correctly, we somehow need to call the
> > > > "PldmSetTerminus" function, before calling "PldmSubmit".
> > > > So I think we need to add PldmSetTerminus to the
> > EDKII_PLDM_PROTOCOL
> > > interface:
> > > > https://github.com/changab/edk2-
> > >
> > pla

Re: [edk2-devel] [PATCH 0/5] EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib class

[Laszlo Ersek]

On 10/18/23 15:44, Ard Biesheuvel wrote:
> On Wed, 18 Oct 2023 at 15:43, Laszlo Ersek  wrote:
>>
>> On 10/12/23 11:10, Laszlo Ersek wrote:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=4564
>>>
>>> The RealTimeClockLib class header in edk2's EmbeddedPkg mistakenly
>>> declares a function called LibRtcVirtualNotifyEvent(). No component ever
>>> calls this function across module boundaries; all RealTimeClockLib
>>> instances in edk2 and edk2-platforms are supposed to register -- and do
>>> register -- their SetVirtualAddressMap() notification functions.
>>>
>>> After the edk2-platforms and edk2-non-osi changes, we can repeat the
>>> procedure form the edk2-platforms series in edk2. In those
>>> RealTimeClockLib instances that define LibRtcVirtualNotifyEvent(),
>>> demonstrate that either (a) the usage is module-internal, or (b) there
>>> is no usage. In case (a), rename LibRtcVirtualNotifyEvent() to
>>> VirtualNotifyEvent(), and make it static. In case (b), remove the
>>> function definition.
>>>
>>> There is a superficial name match in
>>> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe. Note that that module is a
>>> *driver*, not a library instance; what's more,
>>> PcatRealTimeClockRuntimeDxe does not depend on "EmbeddedPkg.dec" at all.
>>> Treat that module too as case (a), right at the front of the series.
>>>
>>> Finally, drop the LibRtcVirtualNotifyEvent() API declaration.
>>>
>>> Cc: Abner Chang 
>>> Cc: Ard Biesheuvel 
>>> Cc: Daniel Schaefer 
>>> Cc: Leif Lindholm 
>>> Cc: Ray Ni 
>>
>> Can I get an ACK for the last three (EmbeddedPkg) patches?
>>
> 
> For the series,
> 
> Reviewed-by: Ard Biesheuvel 

Merged via ; commit range
747a08eae26b..7fe49887c4d2.

Thank you!
Laszlo

> 
>>>
>>> Laszlo Ersek (5):
>>>   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename
>>> LibRtcVirtualNotifyEvent
>>>   ArmPlatformPkg/PL031RealTimeClockLib: hide LibRtcVirtualNotifyEvent
>>>   EmbeddedPkg/TemplateRealTimeClockLib: drop LibRtcVirtualNotifyEvent
>>>   EmbeddedPkg/VirtualRealTimeClockLib: drop LibRtcVirtualNotifyEvent
>>>   EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib
>>> class
>>>
>>>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c  |  5 
>>> ++--
>>>  EmbeddedPkg/Include/Library/RealTimeClockLib.h| 15 
>>> 
>>>  EmbeddedPkg/Library/TemplateRealTimeClockLib/RealTimeClockLib.c   | 24 
>>> 
>>>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 18 
>>> ---
>>>  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c   |  5 
>>> ++--
>>>  5 files changed, 6 insertions(+), 61 deletions(-)
>>>
>>>
>>> base-commit: 95c9f470ca6eab23bfd016bd438f932d7263d395
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109765): https://edk2.groups.io/g/devel/message/109765
Mute This Topic: https://groups.io/mt/101914677/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/5] PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename LibRtcVirtualNotifyEvent

[Laszlo Ersek]

On 10/18/23 17:15, Sami Mujawar wrote:
> Hi Laszlo,
> 
> Please see my response inline marked [SAMI].
> 
> Regards,
> 
> Sami Mujawar
> 
> On 18/10/2023, 14:42, "Laszlo Ersek"  > wrote:
> 
> 
> Hi Sami,
> 
> 
> On 10/12/23 14:33, Sami Mujawar wrote:
>> Hi Laszlo,
>>
>> Thank you for this patch. 
>> These changes look good to me.
>>
>> Reviewed-by: Sami Mujawar > >
>>
>> Tested by booting a Linux guest using Kvmtool guest firmware 
>> (ArmVirtPkg/ArmVirtKvmTool.dsc) for AArch64.
>> Tested-by: Sami Mujawar mailto:sami.muja...@arm.com>>
> 
> 
> your response is under a PcAtChipsetPkg patch -- that's not used in
> "ArmVirtPkg/ArmVirtKvmTool.dsc".
> 
> 
> Which patches did you mean your Tested-by for?
> [SAMI] Sorry for not being clear. PcatRealTimeClockRuntimeDxe is used by the 
> Kvmtool guest firmware, 
> please see 
> https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtKvmTool.dsc#L285-L288
> I have applied this patch and tested that it works for the Kvmtool guest 
> firmware.
> [/SAMI]

And right you are! Wow... that's unexpected of ArmVirtPkg content!

Thanks!
Laszlo

> 
> Thanks!
> Laszlo
> 
> 
>>
>> Regards,
>>
>> Sami Mujawar
>>
>> On 12/10/2023, 10:25, "devel@edk2.groups.io  
>> > on behalf of 
>> Laszlo Ersek via groups.io" >  > > on behalf of lersek=redhat@groups.io 
>>  > >> wrote:
>>
>>
>> PcatRealTimeClockRuntimeDxe seems to have copied the interface name
>> LibRtcVirtualNotifyEvent() from EmbeddedPkg's RealTimeClockLib class.
>> That's not right, for two reasons:
>>
>>
>> - PcatRealTimeClockRuntimeDxe doesn't consume "EmbeddedPkg.dec" in the
>> first place,
>>
>>
>> - in EmbeddedPkg, the RealTimeClockLib class API
>> LibRtcVirtualNotifyEvent() is about to be eliminated (it's a bogus API).
>>
>>
>> Rename the LibRtcVirtualNotifyEvent() function to VirtualNotifyEvent(),
>> and make it static.
>>
>>
>> Tested with booting OVMF.
>>
>>
>> Cc: Ray Ni mailto:ray...@intel.com> 
>> >>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 
>>  
>>  
>> ;>
>> Signed-off-by: Laszlo Ersek mailto:ler...@redhat.com> 
>> >>
>> ---
>> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c 
>> b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>> index b600df487952..ca0cad9b0198 100644
>> --- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>> +++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>> @@ -122,9 +122,10 @@ PcRtcEfiSetWakeupTime (
>> @param[in] Event The Event that is being processed
>> @param[in] Context Event Context
>> **/
>> +STATIC
>> VOID
>> EFIAPI
>> -LibRtcVirtualNotifyEvent (
>> +VirtualNotifyEvent (
>> IN EFI_EVENT Event,
>> IN VOID *Context
>> )
>> @@ -220,7 +221,7 @@ InitializePcRtc (
>> Status = gBS->CreateEventEx (
>> EVT_NOTIFY_SIGNAL,
>> TPL_NOTIFY,
>> - LibRtcVirtualNotifyEvent,
>> + VirtualNotifyEvent,
>> NULL,
>> &gEfiEventVirtualAddressChangeGuid,
>> &mVirtualAddrChangeEvent
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109764): https://edk2.groups.io/g/devel/message/109764
Mute This Topic: https://groups.io/mt/101914676/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/5] PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename LibRtcVirtualNotifyEvent

[Sami Mujawar]

Hi Laszlo,

Please see my response inline marked [SAMI].

Regards,

Sami Mujawar

On 18/10/2023, 14:42, "Laszlo Ersek" mailto:ler...@redhat.com>> wrote:


Hi Sami,


On 10/12/23 14:33, Sami Mujawar wrote:
> Hi Laszlo,
> 
> Thank you for this patch. 
> These changes look good to me.
> 
> Reviewed-by: Sami Mujawar mailto:sami.muja...@arm.com>>
> 
> Tested by booting a Linux guest using Kvmtool guest firmware 
> (ArmVirtPkg/ArmVirtKvmTool.dsc) for AArch64.
> Tested-by: Sami Mujawar mailto:sami.muja...@arm.com>>


your response is under a PcAtChipsetPkg patch -- that's not used in
"ArmVirtPkg/ArmVirtKvmTool.dsc".


Which patches did you mean your Tested-by for?
[SAMI] Sorry for not being clear. PcatRealTimeClockRuntimeDxe is used by the 
Kvmtool guest firmware, 
please see 
https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtKvmTool.dsc#L285-L288
I have applied this patch and tested that it works for the Kvmtool guest 
firmware.
[/SAMI]

Thanks!
Laszlo


> 
> Regards,
> 
> Sami Mujawar
> 
> On 12/10/2023, 10:25, "devel@edk2.groups.io  
> > on behalf of 
> Laszlo Ersek via groups.io"    > on behalf of lersek=redhat@groups.io 
>   >> wrote:
> 
> 
> PcatRealTimeClockRuntimeDxe seems to have copied the interface name
> LibRtcVirtualNotifyEvent() from EmbeddedPkg's RealTimeClockLib class.
> That's not right, for two reasons:
> 
> 
> - PcatRealTimeClockRuntimeDxe doesn't consume "EmbeddedPkg.dec" in the
> first place,
> 
> 
> - in EmbeddedPkg, the RealTimeClockLib class API
> LibRtcVirtualNotifyEvent() is about to be eliminated (it's a bogus API).
> 
> 
> Rename the LibRtcVirtualNotifyEvent() function to VirtualNotifyEvent(),
> and make it static.
> 
> 
> Tested with booting OVMF.
> 
> 
> Cc: Ray Ni mailto:ray...@intel.com> 
> >>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 
>  
>  
> ;>
> Signed-off-by: Laszlo Ersek mailto:ler...@redhat.com> 
> >>
> ---
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c 
> b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> index b600df487952..ca0cad9b0198 100644
> --- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> +++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> @@ -122,9 +122,10 @@ PcRtcEfiSetWakeupTime (
> @param[in] Event The Event that is being processed
> @param[in] Context Event Context
> **/
> +STATIC
> VOID
> EFIAPI
> -LibRtcVirtualNotifyEvent (
> +VirtualNotifyEvent (
> IN EFI_EVENT Event,
> IN VOID *Context
> )
> @@ -220,7 +221,7 @@ InitializePcRtc (
> Status = gBS->CreateEventEx (
> EVT_NOTIFY_SIGNAL,
> TPL_NOTIFY,
> - LibRtcVirtualNotifyEvent,
> + VirtualNotifyEvent,
> NULL,
> &gEfiEventVirtualAddressChangeGuid,
> &mVirtualAddrChangeEvent
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109763): https://edk2.groups.io/g/devel/message/109763
Mute This Topic: https://groups.io/mt/101914676/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Laszlo Ersek]

On 10/18/23 15:13, Gerd Hoffmann wrote:
>   Hi,
> 
>>> -  if (!VirtioFsFile->IsDirectory) {
>>> +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
> 
>> It's nice to see this topic pop up on edk2-devel; apparently you started
>> testing shim on top of virtio-fs. :)
> 
> Indeed.  For starters just passed the host /boot/efi into the guest to
> see how far it goes.
> 
> Amazingly ranking virtiofs first in bootorder JustWorks[tm].

Well, there's no magic :)

On one side, in OVMF's QemuBootOrderLib, the TranslatePciOfwNodes()
function contains a "Generic OpenFirmware device path for PCI devices"
branch (a catch-all branch, if none of the more specific branches match).

On the other side, I had changed QEMU to produce a "bootorder" fw_cfg
entry for virtio-fs, in commit 6da32fe5efdd ("vhost-user-fs: add the
"bootindex" property", 2021-01-13) -- specifically for this purpose.

(The QEMU commit message shows an example OFW device path:

  /pci@i0cf8/pci-bridge@1,6/pci1af4,105a@0/filesystem@0

And, if I remember correctly, the "pci1af4,105a" part was so ugly that I
decided not to add a specific branch for it in QemuBootOrderLib!)

> 
> Next was shim trapping into this when trying to read BOOTX64.CSV (i.e.
> probably it actually was fallback.efi) and a boot loop.
> 
>>> strictly since the beginning, and a few months ago I reported USWG 
>>> Mantis
>>> ticket #2367 [1] too, for clearing up the related confusion in the UEFI
>>> spec.
> 
> I have to admit I didn't check the what the spec says yet.  Looking ...
> 
> Hmm,  EFI_FILE_PROTOCOL.Open() description says "This would typically be
> an open handle to a directory".  I don't read that as "MUST be a
> directory".
> 
> With an absolute path the only thing we need from the Handle passed in
> is the reference to the Filesystem root, the actual file/directory is
> not needed, so accepting anything and not only directories makes sense
> to me.  And most existing implementations apparently agree, otherwise we
> would see much more fallout from this.
> 
> Updating the spec to clearly document expected behavior in that corner
> case would be good.

The spec is inconsistent, in multiple ways.

* Open() is inconsistent with OpenEx(), as the latter does require
"This" to be a directory -- the Summary on OpenEx() says, "Opens a new
file relative to the source directory’s location."

* The "location of base file handle" is inconsistently defined
(ill-defined) by the spec, between the base file being a directory (-->
implying a "child" relationship), versus the base file being a regular
file (--> implying a "sibling" relationship at best). This definition is
more fundamental IMO than the pathname being absolute or relative.

>> (2) With this modification in place, shim is happy, but grub isn't. When
>> I realized that, I looked relatively deeply into making grub work on top
>> of virtio-fs as well -- and my findings were horrendous.
>>
>> I wrote up my findings in a private email to some colleagues; you were
>> among the recipients.
> 
> Yes, I remember.
> 
> Didn't try anything in grub yet.  It boots to the grub shell prompt, but
> there is no kernel on the host ESP anyway.  And no real grub.cfg either,
> only a stub pointing to the real grub.cfg on a different filesystem.
> 
> But, yes, that is probably a dead end.  IIRC grub completely ignores the
> efi filesystem drivers and uses its own exclusively (using its own
> interfaces, not registering them in efi).

That's how I remember it too; grub uses BlockIo / DiskIo protocols as
the basis for its own filesystem drivers, and does not consume EFI
SimpleFs at all.

> 
> Trying to fix that opens the can of worms where you can have both grub
> and efi filesystem drivers being active and stomping on each others
> feet.

Right; in a nutshell, that's the core issue.

> 
>> If you have a use case where you rely on shim but *not* on Grub
>> (UKIs?), then I'm OK relaxing the strictness of VirtioFsDxe.
> 
> No concrete plans yet.  There are ideas/plans to allow booting container
> images as VM.  In that case the root fileystem would be virtiofs, and
> given that OVMF has a driver it IMHO makes sense to use that to boot the
> system.

I'd love that; it was one idea behind
. (Unfortunately
that BZ is private; I don't know why -- probably because it was cloned
from a kernel ticket.)

> And, yes, using UKIs for that makes sense, although the exact
> workflow is far from being clear.
> 
> I think one possible option would be to simply have an /EFI subdirectory
> on the root filesystem, place the files you would have on the ESP there,
> so the rootfs becomes EFI-bootable.  No need to have a boot filesystem
> or directory, given that EFI can read the complete filesystem anyway you
> can slurp the UKIs directly from /lib/modules/$kernel/vmlinuz-virt.efi.
> 
>> In that case, I'd prefer upstreaming my above patch, from April,
>> rather than taking yours.  What do you think abou

[edk2-devel] Event: TianoCore Community Meeting EMEA/NAMO - Thursday, October 19, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Community Meeting EMEA/NAMO*

*When:*
Thursday, October 19, 2023
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

*Where:*
Microsoft Teams meeting Join on your computer or mobile app Click here to join 
the meeting Meeting ID: 226 323 011 029 Passcode: hMRCj6 Download Teams | Join 
on the web Join with a video conferencing device te...@conf.intel.com Video 
Conference ID: 112 716 814 3 Alternate VTC instructions Learn More | Meeting 
options

*Organizer:* Michael Kinney

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=2043512 )

*Description:*



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

Meeting ID: 226 323 011 029
Passcode: hMRCj6

Download Teams ( https://www.microsoft.com/en-us/microsoft-teams/download-app ) 
| Join on the web ( https://www.microsoft.com/microsoft-teams/join-a-meeting )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 112 716 814 3

Alternate VTC instructions ( 
https://conf.intel.com/teams/?conf=1127168143&ivr=teams&d=conf.intel.com&test=test_call
 )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=6e4ce4c4-1242-431b-9a51-92cd01a5df3c&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_MTAyZGJhNjMtYzQ4Mi00MTUxLWFlMWMtOGU0MWNlZDk4NjY5@thread.v2&messageId=0&language=en-US
 )




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109761): https://edk2.groups.io/g/devel/message/109761
Mute This Topic: https://groups.io/mt/102040653/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

[John Chew]

Dear Maintainers,

Just a friendly reminder to ask if you could take a look at my patch. I'd 
really appreciate your feedback and help.

Thank you! =)

-Original Message-
From: YuinYee Chew 
Sent: Friday, September 29, 2023 9:35 PM
To: 'Heinrich Schuchardt' 
Cc: Sunil V L ; Li Yong ; Leif 
Lindholm ; Ard Biesheuvel 
; Abner Chang ; Daniel Schaefer 
; devel@edk2.groups.io
Subject: RE: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

Hi Heinrich,

Both gd25lq128d and gd25lq128e share the same ID "{ 0xc8, 0x60, 0x18}"
gd25lq128d : 
https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128d.html
gd25lq128e : 
https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128e
So, I'm thinking to put it as "gd25lq128" to represent both "d" and "e". 
If sync with Linux, gd25lq128d will be better.

Do you have any suggestion on this? 
Or anyone have any opinion?

Thanks again for the feedback! =)

-Original Message-
From: Heinrich Schuchardt 
Sent: Friday, September 29, 2023 4:55 PM
To: YuinYee Chew 
Cc: Sunil V L ; Li Yong ; Leif 
Lindholm ; Ard Biesheuvel 
; Abner Chang ; Daniel Schaefer 
; devel@edk2.groups.io
Subject: Re: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

On 9/29/23 04:02, John Chew wrote:
> Update Gigadevice norflash list:
> gd25q16, gd25q32, gd25q64, gd25lq64c, gd25q128, gd25lq128, gd25q256
> 
> Add Silicon Kaiser norflash list:
> sk25lp128
> 
> Cc: Sunil V L 
> Cc: Li Yong 
> Cc: Heinrich Schuchardt 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Abner Chang 
> Cc: Daniel Schaefer 
> Signed-off-by: John Chew 
> ---
>   EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 11 ++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> index e16c1c6a14..422fdac851 100644
> --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> @@ -1,6 +1,7 @@
>   /** @file
>   *
>   *  Copyright (c) 2017 Marvell International Ltd.
> +*  Copyright (c) 2023 StarFive, Technology Co., Ltd. All rights 
> +reserved.
>   *
>   *  SPDX-License-Identifier: BSD-2-Clause-Patent
>   *
> @@ -33,12 +34,20 @@ STATIC CONST NOR_FLASH_INFO  NorFlashIds[] = {
> { L"en25q128b",  { 0x1c, 0x30, 0x18 }, 3, 256, 64 * 1024,  256,  0
> },
> { L"en25s64",{ 0x1c, 0x38, 0x17 }, 3, 256, 64 * 1024,  128,  0
> },
> /* GIGADEVICE */
> -  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> NOR_FLASH_ERASE_4K   },
> +  { L"gd25q16",{ 0xc8, 0x40, 0x15 }, 3, 256, 64 * 1024,  32,   
> NOR_FLASH_ERASE_4K   },
> +  { L"gd25q32",{ 0xc8, 0x40, 0x16 }, 3, 256, 64 * 1024,  64,   
> NOR_FLASH_ERASE_4K   },
> { L"gd25lq32",   { 0xc8, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   
> NOR_FLASH_ERASE_4K   },
> +  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> NOR_FLASH_ERASE_4K   },

Linux calls this gd25q64 but probably we don't want to change the displayed 
name.

> +  { L"gd25lq64c",  { 0xc8, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  
> NOR_FLASH_ERASE_4K   },
> +  { L"gd25q128",   { 0xc8, 0x40, 0x18 }, 3, 256, 64 * 1024,  256,  
> NOR_FLASH_ERASE_4K   },
> +  { L"gd25lq128",  { 0xc8, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  
> NOR_FLASH_ERASE_4K   },

Linux calls this gd25lq128d.

> +  { L"gd25q256",   { 0xc8, 0x40, 0x19 }, 3, 256, 64 * 1024,  512,  
> NOR_FLASH_ERASE_4K   },

Except for the two labels the changes match drivers/mtd/spi-nor/gigadevice.c in 
Linux.

> /* ISSI */
> { L"is25lp032",  { 0x9d, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   0
> },
> { L"is25lp064",  { 0x9d, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  0
> },
> { L"is25lp128",  { 0x9d, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  0
> },
> +  /* XINKAI / SILICON KAISER */
> +  { L"sk25lp128",  { 0x27, 0x70, 0x18 }, 3, 256, 64 * 1024,  256,  
> NOR_FLASH_ERASE_4K   },

This matches
https://lore.kernel.org/all/20230726214401.929533-1-jo...@kwiboo.se/

Acked-by: Heinrich Schuchardt 


> /* MACRONIX */
> { L"mx25l2006e", { 0xc2, 0x20, 0x12 }, 3, 256, 64 * 1024,  4,0
> },
> { L"mx25l4005",  { 0xc2, 0x20, 0x13 }, 3, 256, 64 * 1024,  8,0
> },



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109758): https://edk2.groups.io/g

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[蔡雨晴]

Hi Laszlo,


Thank you for your comments. I will commit a new patch to add the maintainers 
to the "Maintainers.txt" file in the root directory of the edk2-platforms 
project.


Please let us know if you have more suggestions.


Thanks,
Yuqing Cai









At 2023-10-18 17:47:04, "Laszlo Ersek"  wrote:
>On 10/13/23 05:03, caiyuqing...@163.com wrote:
>> diff --git a/Platform/Sophgo/Maintainers.md b/Platform/Sophgo/Maintainers.md
>> new file mode 100644
>> index ..4cb32c359a31
>> --- /dev/null
>> +++ b/Platform/Sophgo/Maintainers.md
>> @@ -0,0 +1,105 @@
>> +##Project Name: EDK2 Sophgo SG2042
>> +
>> +##Maintainers:
>> +1. dahogn - dah...@hotmail.com
>> +2. caiyuqing379 - 
>> +3. meng-cz - mengcz1...@gmail.com
>> +4. USER0FISH - 
>> +
>
>This "Platform/Sophgo/Maintainers.md" file / format is useless with
>edk2's "BaseTools/Scripts/GetMaintainer.py" utility. For that utility to
>work, you need to add the maintainers to the "Maintainers.txt" file in
>the edk2-platforms project root dir (... as well).
>
>Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109760): https://edk2.groups.io/g/devel/message/109760
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/1] MdePkg ACPI65: Add 0x0B/Platform Runtime Mechanism (PRM) in Address Space ID of Generic Address Structure (GAS)

[Jinlong Xu]

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

ACPI_Spec_6_5_Aug29 Table 5.1, add 0x0B/Platform Runtime Mechanism (PRM) in 
Address Space ID of Generic Address Structure (GAS)

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Jinlong Xu 
---
 MdePkg/Include/IndustryStandard/Acpi65.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index 6caadf240498..86754a0e123a 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -43,6 +43,7 @@ typedef struct {
 #define EFI_ACPI_6_5_GENERAL_PURPOSE_IO  0x08
 #define EFI_ACPI_6_5_GENERIC_SERIAL_BUS  0x09
 #define EFI_ACPI_6_5_PLATFORM_COMMUNICATION_CHANNEL  0x0A
+#define EFI_ACPI_6_5_PLATFORM_RUNTIME_MECHANISM  0x0B
 #define EFI_ACPI_6_5_FUNCTIONAL_FIXED_HARDWARE   0x7F
 
 //
-- 
2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109759): https://edk2.groups.io/g/devel/message/109759
Mute This Topic: https://groups.io/mt/102040410/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] RedfishPkg/RedfishDiscoverDxe: introduce PcdRedfishSendReceiveTimeout

[Igor Kulchytskyy via groups.io]

Reviewed-by: Igor Kulchytskyy 

-Original Message-
From: Nickle Wang 
Sent: Wednesday, October 18, 2023 9:08 AM
To: devel@edk2.groups.io
Cc: Abner Chang ; Igor Kulchytskyy 
Subject: [EXTERNAL] [PATCH] RedfishPkg/RedfishDiscoverDxe: introduce 
PcdRedfishSendReceiveTimeout


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

Introduce PCD PcdRedfishSendReceiveTimeout to RedfishDiscoverDxe
driver. The SendReceiveTimeout is hard-code value in Redfish discover
driver. With this PCD, platform owner can configure timeout value
easily.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishPkg/RedfishPkg.dec| 5 +
 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf | 2 +-
 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index cdb1528cedc9..0f18865cea0b 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -142,3 +142,8 @@
   # This PCD indicates that if BMC bootstrap credential service will be 
disabled by BIOS or not.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDisableBootstrapCredentialService|FALSE|BOOLEAN|0x1007
+  #
+  # The EFI_REST_EX_HTTP_CONFIG_DATA.SendReceiveTimeout value that 
RedfishDiscoverDxe driver
+  # set to EFI_REST_EX_PROTOCOL.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout|5000|UINT32|0x1008
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
index 950098bf6a0d..c982056fd700 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
@@ -54,4 +54,4 @@

 [Pcd]
   gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand ## CONSUMES
-
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout   ## CONSUEMS
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 17c88ad82db4..2f9e604f6cd6 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
@@ -877,7 +877,7 @@ AddAndSignalNewRedfishService (
 goto EXIT_FREE_CONFIG_DATA;
   }

-  RestExHttpConfigData->SendReceiveTimeout= 5000;
+  RestExHttpConfigData->SendReceiveTimeout= PcdGet32 
(PcdRedfishSendReceiveTimeout);
   RestExHttpConfigData->HttpConfigData.HttpVersion= HttpVersion11;
   RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6 = 
CheckIsIpVersion6 (NetworkInterface);
   if (RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6) {
--
2.17.1

-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109757): https://edk2.groups.io/g/devel/message/109757
Mute This Topic: https://groups.io/mt/102038456/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

[Jake Garver via groups.io]

Thanks for the review, Liming Gao.

Any further comments on this change?

Thanks,
Jake

From: gaoliming 
Sent: Saturday, October 7, 2023 1:05 AM
To: Jake Garver ; devel@edk2.groups.io 
Cc: michael.d.kin...@intel.com ; 
zhiguang@intel.com 
Subject: 回复: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message

External email: Use caution opening links or attachments


Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: Jake Garver 
> 发送时间: 2023年10月6日 0:19
> 收件人: devel@edk2.groups.io
> 抄送: michael.d.kin...@intel.com; gaolim...@byosoft.com.cn;
> zhiguang@intel.com; Jake Garver 
> 主题: [PATCH v2] BaseStackCheckLib: Fix STACK FAULT message
>
> __builtin_return_address returns a pointer, not a string.  Fix the STACK
> FAULT message in BaseStackCheckLib appropriately.
>
> Signed-off-by: Jake Garver 
> ---
>  MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> index 0d2918668e..ea168841b6 100644
> --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckGcc.c
> @@ -6,6 +6,7 @@
>   to exiting the function. If the "canary" is overwritten
__stack_chk_fail()
>   is called. This is GCC specific code.
>
> + Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights
reserved.
>   Copyright (c) 2012, Apple Inc. All rights reserved.
>   SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -34,7 +35,7 @@ __stack_chk_fail (
>  {
>UINT8  DebugPropertyMask;
>
> -  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow in
> function %a.\n", __builtin_return_address (0)));
> +  DEBUG ((DEBUG_ERROR, "STACK FAULT: Buffer Overflow at 0x%p.\n",
> RETURN_ADDRESS (0)));
>
>//
>// Generate a Breakpoint, DeadLoop, or NOP based on PCD settings even
> if
> --
> 2.34.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109756): https://edk2.groups.io/g/devel/message/109756
Mute This Topic: https://groups.io/mt/102040342/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

W dniu 18.10.2023 o 15:36, Laszlo Ersek pisze:

EDK2 expects some random version of uncrustify.

It is not part of BaseTools so I use upstream version. And it looks like
they format in different way using the same config file.

Project URL (to clone and build):

   https://projec...@dev.azure.com/projectmu/Uncrustify/_git/Uncrustify

Command line options to pass to the binary:

   -c ${EDK2_ROOT}/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg \
   --replace \
   --no-backup \
   --if-changed \

You can specify the pathnames to reformat as operands, or you can
additionally pass the "-F -" option, and then the pathnames will be read
from stdin.

Make sure you have committed or at least staged your changes, before
running this command, because these options will update the files in-place.

The only really important option is of course the "-c" one.


Thanks!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109755): https://edk2.groups.io/g/devel/message/109755
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Laszlo Ersek]

On 10/18/23 15:08, Pedro Falcato wrote:
> On Wed, Oct 18, 2023 at 1:20 PM Laszlo Ersek  wrote:
>>
>> On 10/18/23 13:33, Pedro Falcato wrote:
>>> On Wed, Oct 18, 2023 at 12:20 PM Laszlo Ersek  wrote:

 On 10/18/23 12:33, Gerd Hoffmann wrote:
> VirtiofsDxe throws an error in case the caller tries to open a file or
> directory using an handle with is not a directory, claiming that opening
> something relative to a file does not make sense.
>
> The claim is correct, but the code throws errors for both relative and
> absolute paths.  Add a check to fix that.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> index a13d4f6a1e2d..1729ea2f5cf2 100644
> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> @@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
>// it cannot be implemented consistently with how a file is referred to
>// relative to a directory).
>//
> -  if (!VirtioFsFile->IsDirectory) {
> +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
>  DEBUG ((
>DEBUG_ERROR,
>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "

 It's nice to see this topic pop up on edk2-devel; apparently you started
 testing shim on top of virtio-fs. :)

 I have had the following patch in my local repo, on a separate branch,
 since April this year:

> commit cb4a6d1664ea6cabd14d2af0e5d9abb114973870
> Author: Laszlo Ersek 
> Date:   Sat Apr 8 22:50:50 2023 +0200
>
> OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. 
> file
>
> Referring to a file relative to a regular file makes no sense (or at 
> least
> it cannot be implemented consistently with how a file is referred to
> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> strictly since the beginning, and a few months ago I reported USWG 
> Mantis
> ticket #2367 [1] too, for clearing up the related confusion in the 
> UEFI
> spec.
>
> Unfortunately, the shim boot loader contains such a bug [2] [3]. I 
> don't
> believe the shim bug is ever going to be fixed. We can however relax 
> the
> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> opened relative to a regular file is absolute, then the base file is 
> going
> to be ignored anyway, so we can let the caller's bug slide. This 
> happens
> to make shim work.
>
> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes 
> you
> want to build upstream shim/grub binaries, but boot the same ISO
> otherwise. The fastest way for overriding the ESP for this purpose is 
> to
> copy its original contents to a virtio filesystem, then overwrite the 
> shim
> and grub binaries from the host side. Note that this is different from
> direct-booting a kernel (via fw_cfg); the point is to check whether 
> the
> just-built shim and grub are able to boot the rest of the ISO.
>
> [1] https://mantis.uefi.org/mantis/view.php?id=2367
>>>
>>> What does the mantis ticket say/conclude? Yay for private bug trackers
>>> that need corporate buy-in...
>>
>> I posted patches for the UEFI spec. (In two formats -- as a pull request
>> to the locked-down repository on github.com, and as attachments.)
>>
>> Kevin W Shaw started reviewing my patches, but he seemed to
>> misunderstand the git patch format in general; so I commented on that,
>> but then the thread petered out. So it's stuck at the moment.
>>
>> I guess I could try to join USWG meetings / calls and champion the issue
>> there, but I had not had time for that for a decade, and I don't have it
>> now. I'd hope we could communicate asynchronously, via bug trackers...
>>
> 
> Ok so I took some time to re-read the context and the spec. I think
> you're going about things the wrong way.
> The act of tolerating bad base "directories" in open calls is nothing
> new. For instance, in POSIX:
> 
> int openat(int fd, const char *path, int oflag, ...);
> 
> [...]
> The openat() function shall fail if:
> [...]
> [ENOTDIR] The path argument is not an absolute path and fd is a file
> descriptor associated with a non-directory file.
> 
> so there's some track record in POSIX (in fact, openat is extra
> tolerant and can also take bad file descriptors if the path is
> absolute).
> 
> Given that there may be software out there that does rely on this, it
> sure sounds like a better idea to be looser here, both in-driver and
> in-spec.

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[Laszlo Ersek]

On 10/18/23 14:21, Sunil V L wrote:
> On Wed, Oct 18, 2023 at 02:11:17PM +0200, Laszlo Ersek wrote:
>> On 10/18/23 13:21, 蔡雨晴 wrote:
>>> Hi Laszlo,
>>>
>>> Thank you for your comments. I will commit a new patch to add the
>>> maintainers to the "Maintainers.txt" file in the root directory of the
>>> edk2-platforms project.
>>>
>>> Please let us know if you have more suggestions.
>>
>> I do have one, but it's not specifically for this patch set, but for all
>> future edk2(-platforms) patches you may post -- please add "--stat=1000
>> --stat-graph-width=20" to your git-format-patch command line.
>> Edk2(-platforms) use(s) long pathnames, and so the cumulative diffstat
>> tends to be truncated, and on the left side at that. That fact makes it
>> hard to see the extent of a patchset. If you add these options, then the
>> cumulative diffstat is going to be just as wide as it needs to be -- no
>> truncation, and no needless padding.
>>
>> The "BaseTools/Scripts/SetupGit.py" utility creates a git-format-patch
>> alias called "fp" that includes these options.
>>
>> BTW I could help Ard out by pushing this patch set (well, v4, with the
>> Maintainers.txt fix), I'm just not clear when a patch set counts as
>> "sufficiently reviewed" for edk2-platforms.
>>
>> Laszlo
>>
> Hi Laszlo,
> 
> I have pushed the v5 series since they looked decent.

Sure, thanks -- it's useful if the person merging the series confirms
that fact on-list at once (when the merge request is successfully closed).

> Leif had given
> some feedback which are taken care and they looked decent. Maintainer
> entry needs to be added as separate patch. I know there are further
> improvements planned.
> 
> BTW, I have recommended many people to read your guide [1] which I also
> refer every time. Though few things like Setup.py can be added, I found
> your document is really good for any one working on EDK2 patches.
> Thanks!
> 
> [1] -
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers

Glad to hear that!

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109753): https://edk2.groups.io/g/devel/message/109753
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/5] EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib class

[Ard Biesheuvel]

On Wed, 18 Oct 2023 at 15:43, Laszlo Ersek  wrote:
>
> On 10/12/23 11:10, Laszlo Ersek wrote:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=4564
> >
> > The RealTimeClockLib class header in edk2's EmbeddedPkg mistakenly
> > declares a function called LibRtcVirtualNotifyEvent(). No component ever
> > calls this function across module boundaries; all RealTimeClockLib
> > instances in edk2 and edk2-platforms are supposed to register -- and do
> > register -- their SetVirtualAddressMap() notification functions.
> >
> > After the edk2-platforms and edk2-non-osi changes, we can repeat the
> > procedure form the edk2-platforms series in edk2. In those
> > RealTimeClockLib instances that define LibRtcVirtualNotifyEvent(),
> > demonstrate that either (a) the usage is module-internal, or (b) there
> > is no usage. In case (a), rename LibRtcVirtualNotifyEvent() to
> > VirtualNotifyEvent(), and make it static. In case (b), remove the
> > function definition.
> >
> > There is a superficial name match in
> > PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe. Note that that module is a
> > *driver*, not a library instance; what's more,
> > PcatRealTimeClockRuntimeDxe does not depend on "EmbeddedPkg.dec" at all.
> > Treat that module too as case (a), right at the front of the series.
> >
> > Finally, drop the LibRtcVirtualNotifyEvent() API declaration.
> >
> > Cc: Abner Chang 
> > Cc: Ard Biesheuvel 
> > Cc: Daniel Schaefer 
> > Cc: Leif Lindholm 
> > Cc: Ray Ni 
>
> Can I get an ACK for the last three (EmbeddedPkg) patches?
>

For the series,

Reviewed-by: Ard Biesheuvel 

> >
> > Laszlo Ersek (5):
> >   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename
> > LibRtcVirtualNotifyEvent
> >   ArmPlatformPkg/PL031RealTimeClockLib: hide LibRtcVirtualNotifyEvent
> >   EmbeddedPkg/TemplateRealTimeClockLib: drop LibRtcVirtualNotifyEvent
> >   EmbeddedPkg/VirtualRealTimeClockLib: drop LibRtcVirtualNotifyEvent
> >   EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib
> > class
> >
> >  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c  |  5 
> > ++--
> >  EmbeddedPkg/Include/Library/RealTimeClockLib.h| 15 
> > 
> >  EmbeddedPkg/Library/TemplateRealTimeClockLib/RealTimeClockLib.c   | 24 
> > 
> >  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 18 
> > ---
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c   |  5 
> > ++--
> >  5 files changed, 6 insertions(+), 61 deletions(-)
> >
> >
> > base-commit: 95c9f470ca6eab23bfd016bd438f932d7263d395
> >
> >
> >
> >
> >
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109752): https://edk2.groups.io/g/devel/message/109752
Mute This Topic: https://groups.io/mt/101914677/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/5] EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib class

[Laszlo Ersek]

On 10/12/23 11:10, Laszlo Ersek wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=4564
> 
> The RealTimeClockLib class header in edk2's EmbeddedPkg mistakenly
> declares a function called LibRtcVirtualNotifyEvent(). No component ever
> calls this function across module boundaries; all RealTimeClockLib
> instances in edk2 and edk2-platforms are supposed to register -- and do
> register -- their SetVirtualAddressMap() notification functions.
> 
> After the edk2-platforms and edk2-non-osi changes, we can repeat the
> procedure form the edk2-platforms series in edk2. In those
> RealTimeClockLib instances that define LibRtcVirtualNotifyEvent(),
> demonstrate that either (a) the usage is module-internal, or (b) there
> is no usage. In case (a), rename LibRtcVirtualNotifyEvent() to
> VirtualNotifyEvent(), and make it static. In case (b), remove the
> function definition.
> 
> There is a superficial name match in
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe. Note that that module is a
> *driver*, not a library instance; what's more,
> PcatRealTimeClockRuntimeDxe does not depend on "EmbeddedPkg.dec" at all.
> Treat that module too as case (a), right at the front of the series.
> 
> Finally, drop the LibRtcVirtualNotifyEvent() API declaration.
> 
> Cc: Abner Chang 
> Cc: Ard Biesheuvel 
> Cc: Daniel Schaefer 
> Cc: Leif Lindholm 
> Cc: Ray Ni 

Can I get an ACK for the last three (EmbeddedPkg) patches?

Thanks
Laszlo

> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename
> LibRtcVirtualNotifyEvent
>   ArmPlatformPkg/PL031RealTimeClockLib: hide LibRtcVirtualNotifyEvent
>   EmbeddedPkg/TemplateRealTimeClockLib: drop LibRtcVirtualNotifyEvent
>   EmbeddedPkg/VirtualRealTimeClockLib: drop LibRtcVirtualNotifyEvent
>   EmbeddedPkg/RealTimeClockLib: drop LibRtcVirtualNotifyEvent from lib
> class
> 
>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c  |  5 
> ++--
>  EmbeddedPkg/Include/Library/RealTimeClockLib.h| 15 
> 
>  EmbeddedPkg/Library/TemplateRealTimeClockLib/RealTimeClockLib.c   | 24 
> 
>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 18 
> ---
>  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c   |  5 
> ++--
>  5 files changed, 6 insertions(+), 61 deletions(-)
> 
> 
> base-commit: 95c9f470ca6eab23bfd016bd438f932d7263d395
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109751): https://edk2.groups.io/g/devel/message/109751
Mute This Topic: https://groups.io/mt/101914677/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/5] PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe: rename LibRtcVirtualNotifyEvent

[Laszlo Ersek]

Hi Sami,

On 10/12/23 14:33, Sami Mujawar wrote:
> Hi Laszlo,
> 
> Thank you for this patch. 
> These changes look good to me.
> 
> Reviewed-by: Sami Mujawar 
> 
> Tested by booting a Linux guest using Kvmtool guest firmware 
> (ArmVirtPkg/ArmVirtKvmTool.dsc) for AArch64.
> Tested-by: Sami Mujawar 

your response is under a PcAtChipsetPkg patch -- that's not used in
"ArmVirtPkg/ArmVirtKvmTool.dsc".

Which patches did you mean your Tested-by for?

Thanks!
Laszlo

> 
> Regards,
> 
> Sami Mujawar
> 
> On 12/10/2023, 10:25, "devel@edk2.groups.io  on 
> behalf of Laszlo Ersek via groups.io"   on behalf of lersek=redhat@groups.io 
> > wrote:
> 
> 
> PcatRealTimeClockRuntimeDxe seems to have copied the interface name
> LibRtcVirtualNotifyEvent() from EmbeddedPkg's RealTimeClockLib class.
> That's not right, for two reasons:
> 
> 
> - PcatRealTimeClockRuntimeDxe doesn't consume "EmbeddedPkg.dec" in the
> first place,
> 
> 
> - in EmbeddedPkg, the RealTimeClockLib class API
> LibRtcVirtualNotifyEvent() is about to be eliminated (it's a bogus API).
> 
> 
> Rename the LibRtcVirtualNotifyEvent() function to VirtualNotifyEvent(),
> and make it static.
> 
> 
> Tested with booting OVMF.
> 
> 
> Cc: Ray Ni mailto:ray...@intel.com>>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 
> 
> Signed-off-by: Laszlo Ersek mailto:ler...@redhat.com>>
> ---
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c 
> b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> index b600df487952..ca0cad9b0198 100644
> --- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> +++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> @@ -122,9 +122,10 @@ PcRtcEfiSetWakeupTime (
> @param[in] Event The Event that is being processed
> @param[in] Context Event Context
> **/
> +STATIC
> VOID
> EFIAPI
> -LibRtcVirtualNotifyEvent (
> +VirtualNotifyEvent (
> IN EFI_EVENT Event,
> IN VOID *Context
> )
> @@ -220,7 +221,7 @@ InitializePcRtc (
> Status = gBS->CreateEventEx (
> EVT_NOTIFY_SIGNAL,
> TPL_NOTIFY,
> - LibRtcVirtualNotifyEvent,
> + VirtualNotifyEvent,
> NULL,
> &gEfiEventVirtualAddressChangeGuid,
> &mVirtualAddrChangeEvent
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109750): https://edk2.groups.io/g/devel/message/109750
Mute This Topic: https://groups.io/mt/101914676/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] RedfishPkg/RedfishDiscoverDxe: introduce PcdRedfishSendReceiveTimeout

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

> -Original Message-
> From: Nickle Wang 
> Sent: Wednesday, October 18, 2023 9:08 PM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; Igor Kulchytskyy
> 
> Subject: [PATCH] RedfishPkg/RedfishDiscoverDxe: introduce
> PcdRedfishSendReceiveTimeout
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Introduce PCD PcdRedfishSendReceiveTimeout to RedfishDiscoverDxe
> driver. The SendReceiveTimeout is hard-code value in Redfish discover
> driver. With this PCD, platform owner can configure timeout value
> easily.
>
> Signed-off-by: Nickle Wang 
> Cc: Abner Chang 
> Cc: Igor Kulchytskyy 
> ---
>  RedfishPkg/RedfishPkg.dec| 5 +
>  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf | 2 +-
>  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 2 +-
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
> index cdb1528cedc9..0f18865cea0b 100644
> --- a/RedfishPkg/RedfishPkg.dec
> +++ b/RedfishPkg/RedfishPkg.dec
> @@ -142,3 +142,8 @@
># This PCD indicates that if BMC bootstrap credential service will be 
> disabled
> by BIOS or not.
>#
>
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDisableBootstrapCredentialService|
> FALSE|BOOLEAN|0x1007
> +  #
> +  # The EFI_REST_EX_HTTP_CONFIG_DATA.SendReceiveTimeout value that
> RedfishDiscoverDxe driver
> +  # set to EFI_REST_EX_PROTOCOL.
> +  #
> +
> gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout|5000|UINT3
> 2|0x1008
> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
> index 950098bf6a0d..c982056fd700 100644
> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
> @@ -54,4 +54,4 @@
>
>  [Pcd]
>gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand ##
> CONSUMES
> -
> +  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout   ##
> CONSUEMS
> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> index 17c88ad82db4..2f9e604f6cd6 100644
> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> @@ -877,7 +877,7 @@ AddAndSignalNewRedfishService (
>  goto EXIT_FREE_CONFIG_DATA;
>}
>
> -  RestExHttpConfigData->SendReceiveTimeout= 5000;
> +  RestExHttpConfigData->SendReceiveTimeout= PcdGet32
> (PcdRedfishSendReceiveTimeout);
>RestExHttpConfigData->HttpConfigData.HttpVersion= 
> HttpVersion11;
>RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6 =
> CheckIsIpVersion6 (NetworkInterface);
>if (RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6) {
> --
> 2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109749): https://edk2.groups.io/g/devel/message/109749
Mute This Topic: https://groups.io/mt/102038456/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Laszlo Ersek]

On 10/18/23 13:28, Marcin Juszkiewicz wrote:
> W dniu 18.10.2023 o 13:23, Pedro Falcato pisze:
>> On Wed, Oct 18, 2023 at 12:16 PM Marcin Juszkiewicz
>>  wrote:
>>>
>>> W dniu 18.10.2023 o 12:32, Nhi Pham pisze:
 Acked-by: Nhi Pham 

 Nit: I think you want to run uncrustify for Patch 3 as well :)
>>>
>>> Done, will check other changes too.
>>>
>>> I have a strong feeling that Qemu part of EDK2 needs a bit
>>> bigger patch when it comes to formatting:
>>>
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/Include/Library/QemuOpenFwCfgLib.h   
>>>   |   7 +-
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c  
>>>   |  33 +-
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/Library/PlatformSecLib/Ia32/SecEntry.nasm
>>>   |  99 ++-
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c 
>>>   | 108 +--
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c   
>>>   |  30 +-
>>>   
>>> Platform/Qemu/QemuOpenBoardPkg/README.md
>>>   |  43 +-
>>
>> Something must be wrong with your config because QemuOpenBoardPkg is
>> and was, AFAIK, all formatted using uncrustify. And if I run it
>> locally, it seems to agree with me.
> 
> EDK2 expects some random version of uncrustify.
> 
> It is not part of BaseTools so I use upstream version. And it looks like
> they format in different way using the same config file.

Project URL (to clone and build):

  https://projec...@dev.azure.com/projectmu/Uncrustify/_git/Uncrustify

Command line options to pass to the binary:

  -c ${EDK2_ROOT}/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg \
  --replace \
  --no-backup \
  --if-changed \

You can specify the pathnames to reformat as operands, or you can
additionally pass the "-F -" option, and then the pathnames will be read
from stdin.

Make sure you have committed or at least staged your changes, before
running this command, because these options will update the files in-place.

The only really important option is of course the "-c" one.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109748): https://edk2.groups.io/g/devel/message/109748
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Remove memory cache setting for memory under 1MB

[Laszlo Ersek]

On 10/18/23 13:55, Yuanhao Xie wrote:
> With the fact that CSM is not supported,
> the request is to remove the cache setting for memory under 1MB.
> This can be treated as the missing part of legacy CSM deprecation.
> 
> This patch only set the 0 to 9 and C to F as Write Back.
> A-B range is still uncacheable for VGA.
> 
> M: Chasel Chiu 
> M: Nate DeSimone 
> M: Isaac Oram 
> R: Liming Gao 
> R: Eric Dong 
> Signed-off-by: Yuanhao Xie 
> ---
>  Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c 
> b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
> index 05728275a5..38a8db6b3f 100644
> --- a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
> +++ b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
> @@ -245,7 +245,7 @@ SetCacheMtrrAfterEndOfPei (
>   &MtrrSetting,
>   0xC,
>   0x4,
> - CacheWriteProtected
> + CacheWriteBack
>   );
>ASSERT_EFI_ERROR ( Status);
>  

Patch subject line is bogus; first, it does not identify edk2-platforms
between the brackets, second, the subject proper does not identify
MinPlatformPkg.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109747): https://edk2.groups.io/g/devel/message/109747
Mute This Topic: https://groups.io/mt/102037244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Gerd Hoffmann]

  Hi,

> > -  if (!VirtioFsFile->IsDirectory) {
> > +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {

> It's nice to see this topic pop up on edk2-devel; apparently you started
> testing shim on top of virtio-fs. :)

Indeed.  For starters just passed the host /boot/efi into the guest to
see how far it goes.

Amazingly ranking virtiofs first in bootorder JustWorks[tm].

Next was shim trapping into this when trying to read BOOTX64.CSV (i.e.
probably it actually was fallback.efi) and a boot loop.

> > strictly since the beginning, and a few months ago I reported USWG 
> > Mantis
> > ticket #2367 [1] too, for clearing up the related confusion in the UEFI
> > spec.

I have to admit I didn't check the what the spec says yet.  Looking ...

Hmm,  EFI_FILE_PROTOCOL.Open() description says "This would typically be
an open handle to a directory".  I don't read that as "MUST be a
directory".

With an absolute path the only thing we need from the Handle passed in
is the reference to the Filesystem root, the actual file/directory is
not needed, so accepting anything and not only directories makes sense
to me.  And most existing implementations apparently agree, otherwise we
would see much more fallout from this.

Updating the spec to clearly document expected behavior in that corner
case would be good.

> (2) With this modification in place, shim is happy, but grub isn't. When
> I realized that, I looked relatively deeply into making grub work on top
> of virtio-fs as well -- and my findings were horrendous.
> 
> I wrote up my findings in a private email to some colleagues; you were
> among the recipients.

Yes, I remember.

Didn't try anything in grub yet.  It boots to the grub shell prompt, but
there is no kernel on the host ESP anyway.  And no real grub.cfg either,
only a stub pointing to the real grub.cfg on a different filesystem.

But, yes, that is probably a dead end.  IIRC grub completely ignores the
efi filesystem drivers and uses its own exclusively (using its own
interfaces, not registering them in efi).

Trying to fix that opens the can of worms where you can have both grub
and efi filesystem drivers being active and stomping on each others
feet.

> If you have a use case where you rely on shim but *not* on Grub
> (UKIs?), then I'm OK relaxing the strictness of VirtioFsDxe.

No concrete plans yet.  There are ideas/plans to allow booting container
images as VM.  In that case the root fileystem would be virtiofs, and
given that OVMF has a driver it IMHO makes sense to use that to boot the
system.  And, yes, using UKIs for that makes sense, although the exact
workflow is far from being clear.

I think one possible option would be to simply have an /EFI subdirectory
on the root filesystem, place the files you would have on the ESP there,
so the rootfs becomes EFI-bootable.  No need to have a boot filesystem
or directory, given that EFI can read the complete filesystem anyway you
can slurp the UKIs directly from /lib/modules/$kernel/vmlinuz-virt.efi.

> In that case, I'd prefer upstreaming my above patch, from April,
> rather than taking yours.  What do you think about that?

Fine with me.

The UEFI spec is not clear and I don't feel like bikeshedding whenever
shim behavior is a bug or not.  Once the UEFI spec has been fixed the
one way or other we can revisit this.

> Here's a further (independent) caveat: if you are using VirtioFsDxe with
> the rust language virtiofsd, then you might experience hangs in
> VirtioFsInit. For fixing that, you need the following *qemu* patch set:
> 
>   [PATCH v3 0/7] vhost-user: call VHOST_USER_SET_VRING_ENABLE synchronously
>   https://patchew.org/QEMU/20231002203221.17241-1-ler...@redhat.com/
> 
> (This patch set has been on qemu-devel for nearly 2 months now, counting
> from v1; I'm going to ping MST again. It's been ready for merging for
> weeks now!)

Good to know, I think I tapped into this when I tried to pass the
complete host filesystem into the guest.

IIRC mst tends to do large pulls in large intervals, I wouldn't worry
too much yet.  Pinging doesn't hurt though.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109746): https://edk2.groups.io/g/devel/message/109746
Mute This Topic: https://groups.io/mt/102036263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Pedro Falcato]

On Wed, Oct 18, 2023 at 1:20 PM Laszlo Ersek  wrote:
>
> On 10/18/23 13:33, Pedro Falcato wrote:
> > On Wed, Oct 18, 2023 at 12:20 PM Laszlo Ersek  wrote:
> >>
> >> On 10/18/23 12:33, Gerd Hoffmann wrote:
> >>> VirtiofsDxe throws an error in case the caller tries to open a file or
> >>> directory using an handle with is not a directory, claiming that opening
> >>> something relative to a file does not make sense.
> >>>
> >>> The claim is correct, but the code throws errors for both relative and
> >>> absolute paths.  Add a check to fix that.
> >>>
> >>> Signed-off-by: Gerd Hoffmann 
> >>> ---
> >>>  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> >>> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >>> index a13d4f6a1e2d..1729ea2f5cf2 100644
> >>> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >>> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >>> @@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
> >>>// it cannot be implemented consistently with how a file is referred to
> >>>// relative to a directory).
> >>>//
> >>> -  if (!VirtioFsFile->IsDirectory) {
> >>> +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
> >>>  DEBUG ((
> >>>DEBUG_ERROR,
> >>>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
> >>
> >> It's nice to see this topic pop up on edk2-devel; apparently you started
> >> testing shim on top of virtio-fs. :)
> >>
> >> I have had the following patch in my local repo, on a separate branch,
> >> since April this year:
> >>
> >>> commit cb4a6d1664ea6cabd14d2af0e5d9abb114973870
> >>> Author: Laszlo Ersek 
> >>> Date:   Sat Apr 8 22:50:50 2023 +0200
> >>>
> >>> OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. 
> >>> file
> >>>
> >>> Referring to a file relative to a regular file makes no sense (or at 
> >>> least
> >>> it cannot be implemented consistently with how a file is referred to
> >>> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> >>> strictly since the beginning, and a few months ago I reported USWG 
> >>> Mantis
> >>> ticket #2367 [1] too, for clearing up the related confusion in the 
> >>> UEFI
> >>> spec.
> >>>
> >>> Unfortunately, the shim boot loader contains such a bug [2] [3]. I 
> >>> don't
> >>> believe the shim bug is ever going to be fixed. We can however relax 
> >>> the
> >>> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> >>> opened relative to a regular file is absolute, then the base file is 
> >>> going
> >>> to be ignored anyway, so we can let the caller's bug slide. This 
> >>> happens
> >>> to make shim work.
> >>>
> >>> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> >>> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes 
> >>> you
> >>> want to build upstream shim/grub binaries, but boot the same ISO
> >>> otherwise. The fastest way for overriding the ESP for this purpose is 
> >>> to
> >>> copy its original contents to a virtio filesystem, then overwrite the 
> >>> shim
> >>> and grub binaries from the host side. Note that this is different from
> >>> direct-booting a kernel (via fw_cfg); the point is to check whether 
> >>> the
> >>> just-built shim and grub are able to boot the rest of the ISO.
> >>>
> >>> [1] https://mantis.uefi.org/mantis/view.php?id=2367
> >
> > What does the mantis ticket say/conclude? Yay for private bug trackers
> > that need corporate buy-in...
>
> I posted patches for the UEFI spec. (In two formats -- as a pull request
> to the locked-down repository on github.com, and as attachments.)
>
> Kevin W Shaw started reviewing my patches, but he seemed to
> misunderstand the git patch format in general; so I commented on that,
> but then the thread petered out. So it's stuck at the moment.
>
> I guess I could try to join USWG meetings / calls and champion the issue
> there, but I had not had time for that for a decade, and I don't have it
> now. I'd hope we could communicate asynchronously, via bug trackers...
>

Ok so I took some time to re-read the context and the spec. I think
you're going about things the wrong way.
The act of tolerating bad base "directories" in open calls is nothing
new. For instance, in POSIX:

int openat(int fd, const char *path, int oflag, ...);

[...]
The openat() function shall fail if:
[...]
[ENOTDIR] The path argument is not an absolute path and fd is a file
descriptor associated with a non-directory file.

so there's some track record in POSIX (in fact, openat is extra
tolerant and can also take bad file descriptors if the path is
absolute).

Given that there may be software out there that does rely on this, it
sure sounds like a better idea to be looser here, both in-driver and
in-spec.
What problem did GRUB have with this? GRUB freaking out with your
patch sure does seem like it wou

[edk2-devel] [PATCH] RedfishPkg/RedfishDiscoverDxe: introduce PcdRedfishSendReceiveTimeout

[Nickle Wang via groups.io]

Introduce PCD PcdRedfishSendReceiveTimeout to RedfishDiscoverDxe
driver. The SendReceiveTimeout is hard-code value in Redfish discover
driver. With this PCD, platform owner can configure timeout value
easily.

Signed-off-by: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
---
 RedfishPkg/RedfishPkg.dec| 5 +
 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf | 2 +-
 RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/RedfishPkg/RedfishPkg.dec b/RedfishPkg/RedfishPkg.dec
index cdb1528cedc9..0f18865cea0b 100644
--- a/RedfishPkg/RedfishPkg.dec
+++ b/RedfishPkg/RedfishPkg.dec
@@ -142,3 +142,8 @@
   # This PCD indicates that if BMC bootstrap credential service will be 
disabled by BIOS or not.
   #
   
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDisableBootstrapCredentialService|FALSE|BOOLEAN|0x1007
+  #
+  # The EFI_REST_EX_HTTP_CONFIG_DATA.SendReceiveTimeout value that 
RedfishDiscoverDxe driver
+  # set to EFI_REST_EX_PROTOCOL.
+  #
+  
gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout|5000|UINT32|0x1008
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
index 950098bf6a0d..c982056fd700 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
@@ -54,4 +54,4 @@
 
 [Pcd]
   gEfiRedfishPkgTokenSpaceGuid.PcdRedfishDiscoverAccessModeInBand ## CONSUMES
-
+  gEfiRedfishPkgTokenSpaceGuid.PcdRedfishSendReceiveTimeout   ## CONSUEMS
diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 17c88ad82db4..2f9e604f6cd6 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
@@ -877,7 +877,7 @@ AddAndSignalNewRedfishService (
 goto EXIT_FREE_CONFIG_DATA;
   }
 
-  RestExHttpConfigData->SendReceiveTimeout= 5000;
+  RestExHttpConfigData->SendReceiveTimeout= PcdGet32 
(PcdRedfishSendReceiveTimeout);
   RestExHttpConfigData->HttpConfigData.HttpVersion= HttpVersion11;
   RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6 = 
CheckIsIpVersion6 (NetworkInterface);
   if (RestExHttpConfigData->HttpConfigData.LocalAddressIsIPv6) {
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109744): https://edk2.groups.io/g/devel/message/109744
Mute This Topic: https://groups.io/mt/102038456/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 1/1] SbsaQemu: PCI node in DSDT does not need _ADR

[Marcin Juszkiewicz]

190: Device (PCI0) Warning  3073 -
Multiple types ^  (Device object requires either a _HID or _ADR, but not both)

PCI Firmware specification does not require _ADR for Host bridges.

Signed-off-by: Marcin Juszkiewicz 
---
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index ba3eefc975a5..b55ad6c5cc07 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -191,7 +191,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
   Name (_CID, EISAID ("PNP0A03")) // Compatible PCI Root Bridge
   Name (_SEG, Zero) // PCI Segment Group number
   Name (_BBN, Zero) // PCI Base Bus Number
-  Name (_ADR, Zero)
   Name (_UID, "PCI0")
   Name (_CCA, One)// Initially mark the PCI coherent (for JunoR1)
 
-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109743): https://edk2.groups.io/g/devel/message/109743
Mute This Topic: https://groups.io/mt/102037894/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[Sunil V L]

On Wed, Oct 18, 2023 at 02:11:17PM +0200, Laszlo Ersek wrote:
> On 10/18/23 13:21, 蔡雨晴 wrote:
> > Hi Laszlo,
> > 
> > Thank you for your comments. I will commit a new patch to add the
> > maintainers to the "Maintainers.txt" file in the root directory of the
> > edk2-platforms project.
> > 
> > Please let us know if you have more suggestions.
> 
> I do have one, but it's not specifically for this patch set, but for all
> future edk2(-platforms) patches you may post -- please add "--stat=1000
> --stat-graph-width=20" to your git-format-patch command line.
> Edk2(-platforms) use(s) long pathnames, and so the cumulative diffstat
> tends to be truncated, and on the left side at that. That fact makes it
> hard to see the extent of a patchset. If you add these options, then the
> cumulative diffstat is going to be just as wide as it needs to be -- no
> truncation, and no needless padding.
> 
> The "BaseTools/Scripts/SetupGit.py" utility creates a git-format-patch
> alias called "fp" that includes these options.
> 
> BTW I could help Ard out by pushing this patch set (well, v4, with the
> Maintainers.txt fix), I'm just not clear when a patch set counts as
> "sufficiently reviewed" for edk2-platforms.
> 
> Laszlo
> 
Hi Laszlo,

I have pushed the v5 series since they looked decent. Leif had given
some feedback which are taken care and they looked decent. Maintainer
entry needs to be added as separate patch. I know there are further
improvements planned.

BTW, I have recommended many people to read your guide [1] which I also
refer every time. Though few things like Setup.py can be added, I found
your document is really good for any one working on EDK2 patches.
Thanks!

[1] -
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers




> > 
> > Thanks,
> > Yuqing Cai
> > 
> > 
> > 
> > 
> > 
> > At 2023-10-18 17:47:04, "Laszlo Ersek"  wrote:
> >>On 10/13/23 05:03, caiyuqing...@163.com wrote:
> >>> diff --git a/Platform/Sophgo/Maintainers.md 
> >>> b/Platform/Sophgo/Maintainers.md
> >>> new file mode 100644
> >>> index ..4cb32c359a31
> >>> --- /dev/null
> >>> +++ b/Platform/Sophgo/Maintainers.md
> >>> @@ -0,0 +1,105 @@
> >>> +##Project Name: EDK2 Sophgo SG2042
> >>> +
> >>> +##Maintainers:
> >>> +1. dahogn - dah...@hotmail.com
> >>> +2. caiyuqing379 - 
> >>> +3. meng-cz - mengcz1...@gmail.com
> >>> +4. USER0FISH - 
> >>> +
> >>
> >>This "Platform/Sophgo/Maintainers.md" file / format is useless with
> >>edk2's "BaseTools/Scripts/GetMaintainer.py" utility. For that utility to
> >>work, you need to add the maintainers to the "Maintainers.txt" file in
> >>the edk2-platforms project root dir (... as well).
> >>
> >>Laszlo
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109742): https://edk2.groups.io/g/devel/message/109742
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Laszlo Ersek]

On 10/18/23 13:33, Pedro Falcato wrote:
> On Wed, Oct 18, 2023 at 12:20 PM Laszlo Ersek  wrote:
>>
>> On 10/18/23 12:33, Gerd Hoffmann wrote:
>>> VirtiofsDxe throws an error in case the caller tries to open a file or
>>> directory using an handle with is not a directory, claiming that opening
>>> something relative to a file does not make sense.
>>>
>>> The claim is correct, but the code throws errors for both relative and
>>> absolute paths.  Add a check to fix that.
>>>
>>> Signed-off-by: Gerd Hoffmann 
>>> ---
>>>  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
>>> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
>>> index a13d4f6a1e2d..1729ea2f5cf2 100644
>>> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
>>> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
>>> @@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
>>>// it cannot be implemented consistently with how a file is referred to
>>>// relative to a directory).
>>>//
>>> -  if (!VirtioFsFile->IsDirectory) {
>>> +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
>>>  DEBUG ((
>>>DEBUG_ERROR,
>>>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
>>
>> It's nice to see this topic pop up on edk2-devel; apparently you started
>> testing shim on top of virtio-fs. :)
>>
>> I have had the following patch in my local repo, on a separate branch,
>> since April this year:
>>
>>> commit cb4a6d1664ea6cabd14d2af0e5d9abb114973870
>>> Author: Laszlo Ersek 
>>> Date:   Sat Apr 8 22:50:50 2023 +0200
>>>
>>> OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. 
>>> file
>>>
>>> Referring to a file relative to a regular file makes no sense (or at 
>>> least
>>> it cannot be implemented consistently with how a file is referred to
>>> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
>>> strictly since the beginning, and a few months ago I reported USWG 
>>> Mantis
>>> ticket #2367 [1] too, for clearing up the related confusion in the UEFI
>>> spec.
>>>
>>> Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
>>> believe the shim bug is ever going to be fixed. We can however relax the
>>> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
>>> opened relative to a regular file is absolute, then the base file is 
>>> going
>>> to be ignored anyway, so we can let the caller's bug slide. This happens
>>> to make shim work.
>>>
>>> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
>>> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
>>> want to build upstream shim/grub binaries, but boot the same ISO
>>> otherwise. The fastest way for overriding the ESP for this purpose is to
>>> copy its original contents to a virtio filesystem, then overwrite the 
>>> shim
>>> and grub binaries from the host side. Note that this is different from
>>> direct-booting a kernel (via fw_cfg); the point is to check whether the
>>> just-built shim and grub are able to boot the rest of the ISO.
>>>
>>> [1] https://mantis.uefi.org/mantis/view.php?id=2367
> 
> What does the mantis ticket say/conclude? Yay for private bug trackers
> that need corporate buy-in...

I posted patches for the UEFI spec. (In two formats -- as a pull request
to the locked-down repository on github.com, and as attachments.)

Kevin W Shaw started reviewing my patches, but he seemed to
misunderstand the git patch format in general; so I commented on that,
but then the thread petered out. So it's stuck at the moment.

I guess I could try to join USWG meetings / calls and champion the issue
there, but I had not had time for that for a decade, and I don't have it
now. I'd hope we could communicate asynchronously, via bug trackers...

> 
> FWIW, Ext4Dxe does
> [...]
> 
>   if (!Ext4FileIsDir (Current)) {
> return EFI_INVALID_PARAMETER;
>   }
> 
>   // If the path starts with a backslash, we treat the root directory
> as the base directory
>   if (FileName[0] == L'\\') {
> FileName++;
> Current = Partition->Root;
>   }
> 
> so if shim/other important UEFI apps have a bug, I may need to fix
> this as well...
> 

I vaguely remember that I looked up both Ext4Dxe and EnhancedFatDxe
regarding this question, but I don't remember what my take-away was at
the time. :)

Clearly, EnhancedFatDxe must be tolerant of this bug, otherwise shim
would never boot off of "normal" (i.e., FAT32) ESPs.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109741): https://edk2.groups.io/g/devel/message/109741
Mute This Topic: https://groups.io/mt/102036263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[Laszlo Ersek]

On 10/18/23 13:21, 蔡雨晴 wrote:
> Hi Laszlo,
> 
> Thank you for your comments. I will commit a new patch to add the
> maintainers to the "Maintainers.txt" file in the root directory of the
> edk2-platforms project.
> 
> Please let us know if you have more suggestions.

I do have one, but it's not specifically for this patch set, but for all
future edk2(-platforms) patches you may post -- please add "--stat=1000
--stat-graph-width=20" to your git-format-patch command line.
Edk2(-platforms) use(s) long pathnames, and so the cumulative diffstat
tends to be truncated, and on the left side at that. That fact makes it
hard to see the extent of a patchset. If you add these options, then the
cumulative diffstat is going to be just as wide as it needs to be -- no
truncation, and no needless padding.

The "BaseTools/Scripts/SetupGit.py" utility creates a git-format-patch
alias called "fp" that includes these options.

BTW I could help Ard out by pushing this patch set (well, v4, with the
Maintainers.txt fix), I'm just not clear when a patch set counts as
"sufficiently reviewed" for edk2-platforms.

Laszlo

> 
> Thanks,
> Yuqing Cai
> 
> 
> 
> 
> 
> At 2023-10-18 17:47:04, "Laszlo Ersek"  wrote:
>>On 10/13/23 05:03, caiyuqing...@163.com wrote:
>>> diff --git a/Platform/Sophgo/Maintainers.md b/Platform/Sophgo/Maintainers.md
>>> new file mode 100644
>>> index ..4cb32c359a31
>>> --- /dev/null
>>> +++ b/Platform/Sophgo/Maintainers.md
>>> @@ -0,0 +1,105 @@
>>> +##Project Name: EDK2 Sophgo SG2042
>>> +
>>> +##Maintainers:
>>> +1. dahogn - dah...@hotmail.com
>>> +2. caiyuqing379 - 
>>> +3. meng-cz - mengcz1...@gmail.com
>>> +4. USER0FISH - 
>>> +
>>
>>This "Platform/Sophgo/Maintainers.md" file / format is useless with
>>edk2's "BaseTools/Scripts/GetMaintainer.py" utility. For that utility to
>>work, you need to add the maintainers to the "Maintainers.txt" file in
>>the edk2-platforms project root dir (... as well).
>>
>>Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109740): https://edk2.groups.io/g/devel/message/109740
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v5 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 68 +++-
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 3 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..291743b19115 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
   Silicon/Qemu/SbsaQemu/SbsaQemu.dec
 
 [LibraryClasses]
+  AcpiLib
   ArmLib
   BaseMemoryLib
   BaseLib
@@ -49,6 +50,8 @@ [Pcd]
   gArmTokenSpaceGuid.PcdGicDistributorBase
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
 
 [Depex]
@@ -58,6 +61,7 @@ [Guids]
   gEdkiiPlatformHasAcpiGuid
 
 [Protocols]
+  gEfiAcpiSdtProtocolGuid
   gEfiAcpiTableProtocolGuid   ## CONSUMES
 
 [FixedPcd]
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..464119de1457 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -682,6 +683,71 @@ AddGtdtTable (
   return Status;
 }
 
+/*
+ * A function to disable XHCI node on Platform Version lower than 0.3
+ */
+EFI_STATUS
+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  EFI_ACPI_SDT_PROTOCOL*AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER  *Table;
+  UINTNTableKey;
+  UINTNTableIndex;
+  EFI_ACPI_HANDLE  TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN (0, 3)) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+  &gEfiAcpiSdtProtocolGuid,
+  NULL,
+  (VOID **)&AcpiSdtProtocol
+  );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+Status = AcpiLocateTableBySignature (
+ AcpiSdtProtocol,
+ 
EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+ &TableIndex,
+ &Table,
+ &TableKey
+ );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, &TableHandle);
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
 EFI_STATUS
 EFIAPI
 InitializeSbsaQemuAcpiDxe (
@@ -738,5 +804,5 @@ InitializeSbsaQemuAcpiDxe (
 DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
   }
 
-  return EFI_SUCCESS;
+  return DisableXhciOnOlderPlatVer ();
 }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 543b5782580a..ba3eefc975a5 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x00)// _UID: Unique ID
 Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
 Method (_STA) {
-  Return (0xF)
+  Return (XHCI)
  

[edk2-devel] [PATCH edk2-platforms v5 3/4] SbsaQemu: initialize XHCI only if it exists

[Marcin Juszkiewicz]

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 49 +++-
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
index 36ada4270bbf..4ebbe7c93a19 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -57,28 +58,6 @@ InitializeSbsaQemuPlatformDxe (
 return Status;
   }
 
-  Base = (VOID*)(UINTN)PcdGet64 (PcdPlatformXhciBase);
-  ASSERT (Base != NULL);
-  Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
-  ASSERT (Size != 0);
-
-  DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
-  __FUNCTION__, Base, Size));
-
-  Status = RegisterNonDiscoverableMmioDevice (
-   NonDiscoverableDeviceTypeXhci,
-   NonDiscoverableDeviceDmaTypeCoherent,
-   NULL,
-   NULL,
-   1,
-   Base, Size);
-
-  if (EFI_ERROR(Status)) {
-DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device @%p 
(Staus == %r)\n",
-__FUNCTION__, Base, Status));
-return Status;
-  }
-
   SmcResult = ArmCallSmc0 (SIP_SVC_VERSION, &Arg0, &Arg1, NULL);
   if (SmcResult == SMC_ARCH_CALL_SUCCESS) {
 Result = PcdSet32S (PcdPlatformVersionMajor, Arg0);
@@ -118,5 +97,31 @@ InitializeSbsaQemuPlatformDxe (
 
   DEBUG ((DEBUG_INFO, "GICI base: 0x%x\n", Arg0));
 
+  if (!PLATFORM_VERSION_LESS_THAN (0, 3)) {
+Base = (VOID *)(UINTN)PcdGet64 (PcdPlatformXhciBase);
+ASSERT (Base != NULL);
+Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
+ASSERT (Size != 0);
+
+DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
+__FUNCTION__, Base, Size));
+
+Status = RegisterNonDiscoverableMmioDevice (
+NonDiscoverableDeviceTypeXhci,
+
NonDiscoverableDeviceDmaTypeCoherent,
+NULL,
+NULL,
+1,
+Base,
+Size
+);
+
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device 
@%p (Status == %r)\n",
+  __FUNCTION__, Base, Status));
+  return Status;
+}
+  }
+
   return EFI_SUCCESS;
 }

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109738): https://edk2.groups.io/g/devel/message/109738
Mute This Topic: https://groups.io/mt/102037245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] Remove memory cache setting for memory under 1MB

[Yuanhao Xie]

With the fact that CSM is not supported,
the request is to remove the cache setting for memory under 1MB.
This can be treated as the missing part of legacy CSM deprecation.

This patch only set the 0 to 9 and C to F as Write Back.
A-B range is still uncacheable for VGA.

M: Chasel Chiu 
M: Nate DeSimone 
M: Isaac Oram 
R: Liming Gao 
R: Eric Dong 
Signed-off-by: Yuanhao Xie 
---
 Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c 
b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
index 05728275a5..38a8db6b3f 100644
--- a/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
+++ b/Platform/Intel/MinPlatformPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.c
@@ -245,7 +245,7 @@ SetCacheMtrrAfterEndOfPei (
  &MtrrSetting,
  0xC,
  0x4,
- CacheWriteProtected
+ CacheWriteBack
  );
   ASSERT_EFI_ERROR ( Status);
 
-- 
2.36.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109737): https://edk2.groups.io/g/devel/message/109737
Mute This Topic: https://groups.io/mt/102037244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v5 1/4] SbsaQemu: introduce macro to compare platform version

[Marcin Juszkiewicz]

We want to check "if platver < 0.3" in an easy way.

Signed-off-by: Marcin Juszkiewicz 
---
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
 1 file changed, 25 insertions(+)

diff --git 
a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
new file mode 100644
index ..dd2483787002
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
@@ -0,0 +1,25 @@
+/** @file
+*
+*  Copyright (c) Linaro Limited. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SBSAQEMUPLATFORM_VERSION_H
+#define SBSAQEMUPLATFORM_VERSION_H
+
+/*
+ * Compare PlatformVersion
+ *
+ */
+
+#define PLATFORM_VERSION_LESS_THAN(Major, Minor) ( \
+  (\
+( PcdGet32 (PcdPlatformVersionMajor) < Major)   || \
+(  \
+  ( PcdGet32 (PcdPlatformVersionMajor) == Major) && \
+  ( PcdGet32 (PcdPlatformVersionMinor) < Minor)\
+)  \
+  )\
+)
+#endif

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109735): https://edk2.groups.io/g/devel/message/109735
Mute This Topic: https://groups.io/mt/102037241/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v5 0/4] Provide XHCI USB controller only for newer hardware

[Marcin Juszkiewicz]

Platform version 0.3 introduced XHCI USB controller instead of EHCI one.
But we did it in a way that there is no in-EDK2 check for platform
version (XHCI is always given).

This behaviour works with Linux as it complains about being unable to
initialize EHCI and goes on. Free/Net/Open BSD systems hang in such
situation.

Now we check are we on Platform Version 0.3 at least and then initialize
XHCI controller. Otherwise we disable it's node in DSDT table.

I checked several ways to handle the situation. 

SSDT overlay enabling with LocateAndInstallAcpiFromFvConfitional() was
first one but this function had only DBG2 and FACP tables.

Then looked at trying to detect XHCI from _STA method. But this is
sysbus device which is there or not without way to discover it.

Next attempt was to have variable in DSDT and to use it in _STA. Too
much trouble.

Then looked again at code from
Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiDsdt.c and noticed
UpdateStatusMethodObject() function. Copied some code and it worked.

Booting OpenBSD reminded me to update table checksum.

Nhi Pham pointed me to AcpiLib/AcpiAmlObjectUpdateInteger() function. So
v3 got AML variable (called XHCI) which is set to 0xF (enabled, working)
by default or to 0x0 (disabled, ignore) on Platform Version below 0.3
one.

This allowed to remove copy of UpdateStatusMethodObject() function.

---
Changes in v5:
- added missing s-o-b lines
- run uncrustify on changed code
- fixed typos
- added comments

Changes in v4:
- make use of DisableXhciOnOlderPlatVer() return value

Changes in v3:
- use AML variable in DSDT

Changes in v2:
- XHCI initialized only on PlatVer 0.3+
- XHCI disabled in DSDT for older platforms
- no SSDT overlays for EHCI/XHCI
- no EHCI at all (it does not work anyway)
- no Pcd renaming

---
Marcin Juszkiewicz (4):
  SbsaQemu: introduce macro to compare platform version
  SbsaQemu: add AcpiLib
  SbsaQemu: initialize XHCI only if it exists
  SbsaQemu: disable XHCI in DSDT if not present

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  2 +
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 +++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 68 +++-
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 49 +++---
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 6 files changed, 127 insertions(+), 24 deletions(-)
---
base-commit: 8b20188ced2318c970b3666d2a7c132c40aaee68
change-id: 20231013-ehci-xhci-fix-c529356a7a8f

Best regards,
-- 
Marcin Juszkiewicz 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109734): https://edk2.groups.io/g/devel/message/109734
Mute This Topic: https://groups.io/mt/102037240/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v5 2/4] SbsaQemu: add AcpiLib

[Marcin Juszkiewicz]

It will be needed for playing with disabling XHCI later.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 36723e21d7b5..1e650350cb63 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -172,6 +172,8 @@ [LibraryClasses.common]
 
   
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
 
+  AcpiLib|EmbeddedPkg/Library/AcpiLib/AcpiLib.inf
+
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109736): https://edk2.groups.io/g/devel/message/109736
Mute This Topic: https://groups.io/mt/102037242/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Pedro Falcato]

On Wed, Oct 18, 2023 at 12:28 PM Marcin Juszkiewicz
 wrote:
>
> W dniu 18.10.2023 o 13:23, Pedro Falcato pisze:
> > On Wed, Oct 18, 2023 at 12:16 PM Marcin Juszkiewicz
> >  wrote:
> >>
> >> W dniu 18.10.2023 o 12:32, Nhi Pham pisze:
> >>> Acked-by: Nhi Pham 
> >>>
> >>> Nit: I think you want to run uncrustify for Patch 3 as well :)
> >>
> >> Done, will check other changes too.
> >>
> >> I have a strong feeling that Qemu part of EDK2 needs a bit
> >> bigger patch when it comes to formatting:
> >>
> >>Platform/Qemu/QemuOpenBoardPkg/Include/Library/QemuOpenFwCfgLib.h   
> >>   |   7 +-
> >>Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c  
> >>   |  33 +-
> >>
> >> Platform/Qemu/QemuOpenBoardPkg/Library/PlatformSecLib/Ia32/SecEntry.nasm   
> >>|  99 ++-
> >>Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c 
> >>   | 108 +--
> >>Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c   
> >>   |  30 +-
> >>Platform/Qemu/QemuOpenBoardPkg/README.md
> >>   |  43 +-
> >
> > Something must be wrong with your config because QemuOpenBoardPkg is
> > and was, AFAIK, all formatted using uncrustify. And if I run it
> > locally, it seems to agree with me.
>
> EDK2 expects some random version of uncrustify.
>
> It is not part of BaseTools so I use upstream version. And it looks like
> they format in different way using the same config file.

Right. But we used the correct uncrustify version, so things are well
formatted. I don't see the point in formatting with upstream
uncrustify, you're just going to end up misformatting everything.

Whether the current sanctioned solution is any sane at all (it is not)
is another matter, but I seriously have no stamina to discuss these
kinds of changes anymore.


-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109733): https://edk2.groups.io/g/devel/message/109733
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Pedro Falcato]

On Wed, Oct 18, 2023 at 12:20 PM Laszlo Ersek  wrote:
>
> On 10/18/23 12:33, Gerd Hoffmann wrote:
> > VirtiofsDxe throws an error in case the caller tries to open a file or
> > directory using an handle with is not a directory, claiming that opening
> > something relative to a file does not make sense.
> >
> > The claim is correct, but the code throws errors for both relative and
> > absolute paths.  Add a check to fix that.
> >
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> > b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> > index a13d4f6a1e2d..1729ea2f5cf2 100644
> > --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> > +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> > @@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
> >// it cannot be implemented consistently with how a file is referred to
> >// relative to a directory).
> >//
> > -  if (!VirtioFsFile->IsDirectory) {
> > +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
> >  DEBUG ((
> >DEBUG_ERROR,
> >("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
>
> It's nice to see this topic pop up on edk2-devel; apparently you started
> testing shim on top of virtio-fs. :)
>
> I have had the following patch in my local repo, on a separate branch,
> since April this year:
>
> > commit cb4a6d1664ea6cabd14d2af0e5d9abb114973870
> > Author: Laszlo Ersek 
> > Date:   Sat Apr 8 22:50:50 2023 +0200
> >
> > OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. 
> > file
> >
> > Referring to a file relative to a regular file makes no sense (or at 
> > least
> > it cannot be implemented consistently with how a file is referred to
> > relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> > strictly since the beginning, and a few months ago I reported USWG 
> > Mantis
> > ticket #2367 [1] too, for clearing up the related confusion in the UEFI
> > spec.
> >
> > Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
> > believe the shim bug is ever going to be fixed. We can however relax the
> > check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> > opened relative to a regular file is absolute, then the base file is 
> > going
> > to be ignored anyway, so we can let the caller's bug slide. This happens
> > to make shim work.
> >
> > Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> > shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
> > want to build upstream shim/grub binaries, but boot the same ISO
> > otherwise. The fastest way for overriding the ESP for this purpose is to
> > copy its original contents to a virtio filesystem, then overwrite the 
> > shim
> > and grub binaries from the host side. Note that this is different from
> > direct-booting a kernel (via fw_cfg); the point is to check whether the
> > just-built shim and grub are able to boot the rest of the ISO.
> >
> > [1] https://mantis.uefi.org/mantis/view.php?id=2367

What does the mantis ticket say/conclude? Yay for private bug trackers
that need corporate buy-in...

FWIW, Ext4Dxe does
[...]

  if (!Ext4FileIsDir (Current)) {
return EFI_INVALID_PARAMETER;
  }

  // If the path starts with a backslash, we treat the root directory
as the base directory
  if (FileName[0] == L'\\') {
FileName++;
Current = Partition->Root;
  }

so if shim/other important UEFI apps have a bug, I may need to fix
this as well...

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109732): https://edk2.groups.io/g/devel/message/109732
Mute This Topic: https://groups.io/mt/102036263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

W dniu 18.10.2023 o 13:23, Pedro Falcato pisze:

On Wed, Oct 18, 2023 at 12:16 PM Marcin Juszkiewicz
 wrote:


W dniu 18.10.2023 o 12:32, Nhi Pham pisze:

Acked-by: Nhi Pham 

Nit: I think you want to run uncrustify for Patch 3 as well :)


Done, will check other changes too.

I have a strong feeling that Qemu part of EDK2 needs a bit
bigger patch when it comes to formatting:

   Platform/Qemu/QemuOpenBoardPkg/Include/Library/QemuOpenFwCfgLib.h
 |   7 +-
   Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c   
 |  33 +-
   Platform/Qemu/QemuOpenBoardPkg/Library/PlatformSecLib/Ia32/SecEntry.nasm 
 |  99 ++-
   Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c  
 | 108 +--
   Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c
 |  30 +-
   Platform/Qemu/QemuOpenBoardPkg/README.md 
 |  43 +-


Something must be wrong with your config because QemuOpenBoardPkg is
and was, AFAIK, all formatted using uncrustify. And if I run it
locally, it seems to agree with me.


EDK2 expects some random version of uncrustify.

It is not part of BaseTools so I use upstream version. And it looks like 
they format in different way using the same config file.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109731): https://edk2.groups.io/g/devel/message/109731
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Pedro Falcato]

On Wed, Oct 18, 2023 at 12:16 PM Marcin Juszkiewicz
 wrote:
>
> W dniu 18.10.2023 o 12:32, Nhi Pham pisze:
> > Acked-by: Nhi Pham 
> >
> > Nit: I think you want to run uncrustify for Patch 3 as well :)
>
> Done, will check other changes too.
>
> I have a strong feeling that Qemu part of EDK2 needs a bit
> bigger patch when it comes to formatting:
>
>   Platform/Qemu/QemuOpenBoardPkg/Include/Library/QemuOpenFwCfgLib.h   
>   |   7 +-
>   Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c  
>   |  33 +-
>   Platform/Qemu/QemuOpenBoardPkg/Library/PlatformSecLib/Ia32/SecEntry.nasm
>   |  99 ++-
>   Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c 
>   | 108 +--
>   Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c   
>   |  30 +-
>   Platform/Qemu/QemuOpenBoardPkg/README.md
>   |  43 +-

Something must be wrong with your config because QemuOpenBoardPkg is
and was, AFAIK, all formatted using uncrustify. And if I run it
locally, it seems to agree with me.

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109730): https://edk2.groups.io/g/devel/message/109730
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Laszlo Ersek]

On 10/18/23 12:33, Gerd Hoffmann wrote:
> VirtiofsDxe throws an error in case the caller tries to open a file or
> directory using an handle with is not a directory, claiming that opening
> something relative to a file does not make sense.
>
> The claim is correct, but the code throws errors for both relative and
> absolute paths.  Add a check to fix that.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> index a13d4f6a1e2d..1729ea2f5cf2 100644
> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> @@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
>// it cannot be implemented consistently with how a file is referred to
>// relative to a directory).
>//
> -  if (!VirtioFsFile->IsDirectory) {
> +  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
>  DEBUG ((
>DEBUG_ERROR,
>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "

It's nice to see this topic pop up on edk2-devel; apparently you started
testing shim on top of virtio-fs. :)

I have had the following patch in my local repo, on a separate branch,
since April this year:

> commit cb4a6d1664ea6cabd14d2af0e5d9abb114973870
> Author: Laszlo Ersek 
> Date:   Sat Apr 8 22:50:50 2023 +0200
>
> OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. file
>
> Referring to a file relative to a regular file makes no sense (or at least
> it cannot be implemented consistently with how a file is referred to
> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> strictly since the beginning, and a few months ago I reported USWG Mantis
> ticket #2367 [1] too, for clearing up the related confusion in the UEFI
> spec.
>
> Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
> believe the shim bug is ever going to be fixed. We can however relax the
> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> opened relative to a regular file is absolute, then the base file is going
> to be ignored anyway, so we can let the caller's bug slide. This happens
> to make shim work.
>
> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
> want to build upstream shim/grub binaries, but boot the same ISO
> otherwise. The fastest way for overriding the ESP for this purpose is to
> copy its original contents to a virtio filesystem, then overwrite the shim
> and grub binaries from the host side. Note that this is different from
> direct-booting a kernel (via fw_cfg); the point is to check whether the
> just-built shim and grub are able to boot the rest of the ISO.
>
> [1] https://mantis.uefi.org/mantis/view.php?id=2367
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
> [3] https://github.com/rhboot/shim/issues/382
>
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Signed-off-by: Laszlo Ersek 
>
> Notes:
> context:-U4
>
> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> index d479f76f5bc3..ec0521ac3703 100644
> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> @@ -394,22 +394,33 @@ VirtioFsSimpleFileOpen (
>
>//
>// Referring to a file relative to a regular file makes no sense (or at 
> least
>// it cannot be implemented consistently with how a file is referred to
> -  // relative to a directory).
> +  // relative to a directory). See USWG Mantis ticket #2367.
>//
>if (!VirtioFsFile->IsDirectory) {
> +BOOLEAN  BugCompat;
> +
> +//
> +// Tolerate this bug in the caller if FileName is absolute. If FileName 
> is
> +// absolute, then VirtioFsAppendPath() below will disregard
> +// VirtioFsFile->CanonicalPathname.
> +//
> +BugCompat = (FileName[0] == L'\\');
> +
>  DEBUG ((
> -  DEBUG_ERROR,
> +  BugCompat ? DEBUG_WARN : DEBUG_ERROR,
>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
> "nonsensical request to open a file or directory relative to a 
> regular "
> "file\n"),
>__FUNCTION__,
>VirtioFs->Label,
>VirtioFsFile->CanonicalPathname,
>FileName
>));
> -return EFI_INVALID_PARAMETER;
> +if (!BugCompat) {
> +  return EFI_INVALID_PARAMETER;
> +}
>}
>
>//
>// Allocate the new VIRTIO_FS_FILE object.

Note that I'm adamant that this is a shim (and UEFI spec) bug, and that
the current upstream code is right, *regardless* of whether the pathname
to open starts with a backslash or not. The spec bug is reference [1]
above, and the original incarnation of my shim bug report is reference
[2]

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

W dniu 18.10.2023 o 12:32, Nhi Pham pisze:

Acked-by: Nhi Pham 

Nit: I think you want to run uncrustify for Patch 3 as well :)


Done, will check other changes too.

I have a strong feeling that Qemu part of EDK2 needs a bit
bigger patch when it comes to formatting:

 Platform/Qemu/QemuOpenBoardPkg/Include/Library/QemuOpenFwCfgLib.h  
   |   7 +-
 Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c 
   |  33 +-
 Platform/Qemu/QemuOpenBoardPkg/Library/PlatformSecLib/Ia32/SecEntry.nasm   
   |  99 ++-
 Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c
   | 108 +--
 Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Pcie.c  
   |  30 +-
 Platform/Qemu/QemuOpenBoardPkg/README.md   
   |  43 +-
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
   |  78 +-
 Silicon/Qemu/SbsaQemu/AcpiTables/Dbg2.aslc 
   |  31 +-
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl  
   | 808 +++-
 Silicon/Qemu/SbsaQemu/AcpiTables/Fadt.aslc 
   |  14 +-
 Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc 
   |  15 +-
 Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc 
   |  37 +-
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
   |  48 +-
 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.c
   | 112 ++-
 Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h  
   |  86 +--
 Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h   
   |  50 +-
 Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h   
   |   4 +-
 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h   
   |   2 +-
 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c  
   |  37 +-
 Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.c
   |  23 +-
 Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
   |  57 +-
 Silicon/Qemu/SbsaQemu/Library/SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c
   |  14 +-
 
Silicon/Qemu/SbsaQemu/Library/SbsaQemuPciHostBridgeLib/SbsaQemuPciHostBridgeLib.c
 |  76 +-
 23 files changed, 982 insertions(+), 830 deletions(-)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109728): https://edk2.groups.io/g/devel/message/109728
Mute This Topic: https://groups.io/mt/102035954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] OvmfPkg/VirtioFsDxe: fix SimpleFileOpen

[Gerd Hoffmann]

VirtiofsDxe throws an error in case the caller tries to open a file or
directory using an handle with is not a directory, claiming that opening
something relative to a file does not make sense.

The claim is correct, but the code throws errors for both relative and
absolute paths.  Add a check to fix that.

Signed-off-by: Gerd Hoffmann 
---
 OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
index a13d4f6a1e2d..1729ea2f5cf2 100644
--- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
+++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
@@ -397,7 +397,7 @@ VirtioFsSimpleFileOpen (
   // it cannot be implemented consistently with how a file is referred to
   // relative to a directory).
   //
-  if (!VirtioFsFile->IsDirectory) {
+  if (!VirtioFsFile->IsDirectory && FileName[0] != '\\') {
 DEBUG ((
   DEBUG_ERROR,
   ("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109727): https://edk2.groups.io/g/devel/message/109727
Mute This Topic: https://groups.io/mt/102036263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Nhi Pham via groups.io]

Acked-by: Nhi Pham 

Nit: I think you want to run uncrustify for Patch 3 as well :)

Regards,
Nhi

On 10/18/2023 5:07 PM, Marcin Juszkiewicz wrote:

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 66 +++-
  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
  3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..d5ded892d6ea 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
Silicon/Qemu/SbsaQemu/SbsaQemu.dec
  
  [LibraryClasses]

+  AcpiLib
ArmLib
BaseMemoryLib
BaseLib
@@ -50,6 +51,8 @@ [Pcd]
gArmTokenSpaceGuid.PcdGicRedistributorsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
  
  [Depex]

gEfiAcpiTableProtocolGuid   ## CONSUMES
@@ -59,6 +62,7 @@ [Guids]
  
  [Protocols]

gEfiAcpiTableProtocolGuid   ## CONSUMES
+  gEfiAcpiSdtProtocolGuid
  
  [FixedPcd]

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..4d8a57d5a8e4 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -682,6 +683,69 @@ AddGtdtTable (
return Status;
  }
  
+EFI_STATUS

+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_ACPI_SDT_PROTOCOL   *AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER *Table;
+  UINTN   TableKey;
+  UINTN   TableIndex;
+  EFI_ACPI_HANDLE TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN(0, 3) ) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+&gEfiAcpiSdtProtocolGuid,
+NULL,
+(VOID **)&AcpiSdtProtocol
+);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+TableIndex = 0;
+Status = AcpiLocateTableBySignature (
+   AcpiSdtProtocol,
+   EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+   &TableIndex,
+   &Table,
+   &TableKey
+   );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, &TableHandle);
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
  EFI_STATUS
  EFIAPI
  InitializeSbsaQemuAcpiDxe (
@@ -738,5 +802,5 @@ InitializeSbsaQemuAcpiDxe (
  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
}
  
-  return EFI_SUCCESS;

+  return DisableXhciOnOlderPlatVer ();
  }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 543b5782580a..ba3eefc975a5 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
  Name (_HID, "PNP0D10")  // _HID: Hardware ID
  Name (_UID, 0x00)// _UID: Unique ID
  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
  Method (_STA) {
-

Re: [edk2-devel] [PATCH edk2-platforms v3 1/4] SbsaQemu: introduce macro to compare platform version

[Marcin Juszkiewicz]

W dniu 18.10.2023 o 10:46, Ard Biesheuvel pisze:

I don't mind adding this here but it is slightly unidiomatic so I'd
like Leif's take on this too.

... and it also lacks a s-o-b line


Oops. Added in local copy.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109725): https://edk2.groups.io/g/devel/message/109725
Mute This Topic: https://groups.io/mt/102017313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v3 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

W dniu 18.10.2023 o 10:47, Ard Biesheuvel pisze:

Nit: EDK2 Coding Style says that you need a space before (.

Ah, right. forgot to crucify the source.


Is it necessary to handle the result of Status?

EDK2 is full of handling Status on touching ACPI tables. So I followed.


Can you just do 'return DisableXhciOnOlderPlatVer();' instead?


Done. Sent v4.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109724): https://edk2.groups.io/g/devel/message/109724
Mute This Topic: https://groups.io/mt/102017316/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Marcin Juszkiewicz]

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 66 +++-
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..d5ded892d6ea 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
   Silicon/Qemu/SbsaQemu/SbsaQemu.dec
 
 [LibraryClasses]
+  AcpiLib
   ArmLib
   BaseMemoryLib
   BaseLib
@@ -50,6 +51,8 @@ [Pcd]
   gArmTokenSpaceGuid.PcdGicRedistributorsBase
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
 
 [Depex]
   gEfiAcpiTableProtocolGuid   ## CONSUMES
@@ -59,6 +62,7 @@ [Guids]
 
 [Protocols]
   gEfiAcpiTableProtocolGuid   ## CONSUMES
+  gEfiAcpiSdtProtocolGuid
 
 [FixedPcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..4d8a57d5a8e4 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -682,6 +683,69 @@ AddGtdtTable (
   return Status;
 }
 
+EFI_STATUS
+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_ACPI_SDT_PROTOCOL   *AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER *Table;
+  UINTN   TableKey;
+  UINTN   TableIndex;
+  EFI_ACPI_HANDLE TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN(0, 3) ) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+&gEfiAcpiSdtProtocolGuid,
+NULL,
+(VOID **)&AcpiSdtProtocol
+);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+TableIndex = 0;
+Status = AcpiLocateTableBySignature (
+   AcpiSdtProtocol,
+   EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+   &TableIndex,
+   &Table,
+   &TableKey
+   );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, &TableHandle);
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
 EFI_STATUS
 EFIAPI
 InitializeSbsaQemuAcpiDxe (
@@ -738,5 +802,5 @@ InitializeSbsaQemuAcpiDxe (
 DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
   }
 
-  return EFI_SUCCESS;
+  return DisableXhciOnOlderPlatVer ();
 }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 543b5782580a..ba3eefc975a5 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x00)// _UID: Unique ID
 Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
 Method (_STA) {
-  Return (0xF)
+  Return (XHCI)
 }
 Method (_CRS, 0x0, Serialized) {
 Name (RBUF, ResourceTemplate() {

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You

[edk2-devel] [PATCH edk2-platforms v4 3/4] SbsaQemu: initialize XHCI only if it exists

[Marcin Juszkiewicz]

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Signed-off-by: Marcin Juszkiewicz 
---
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 47 +++-
 1 file changed, 25 insertions(+), 22 deletions(-)

diff --git 
a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
index 36ada4270bbf..76a9cd62d4a4 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -57,28 +58,6 @@ InitializeSbsaQemuPlatformDxe (
 return Status;
   }
 
-  Base = (VOID*)(UINTN)PcdGet64 (PcdPlatformXhciBase);
-  ASSERT (Base != NULL);
-  Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
-  ASSERT (Size != 0);
-
-  DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
-  __FUNCTION__, Base, Size));
-
-  Status = RegisterNonDiscoverableMmioDevice (
-   NonDiscoverableDeviceTypeXhci,
-   NonDiscoverableDeviceDmaTypeCoherent,
-   NULL,
-   NULL,
-   1,
-   Base, Size);
-
-  if (EFI_ERROR(Status)) {
-DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device @%p 
(Staus == %r)\n",
-__FUNCTION__, Base, Status));
-return Status;
-  }
-
   SmcResult = ArmCallSmc0 (SIP_SVC_VERSION, &Arg0, &Arg1, NULL);
   if (SmcResult == SMC_ARCH_CALL_SUCCESS) {
 Result = PcdSet32S (PcdPlatformVersionMajor, Arg0);
@@ -118,5 +97,29 @@ InitializeSbsaQemuPlatformDxe (
 
   DEBUG ((DEBUG_INFO, "GICI base: 0x%x\n", Arg0));
 
+  if (! PLATFORM_VERSION_LESS_THAN(0, 3) ) {
+Base = (VOID*)(UINTN)PcdGet64 (PcdPlatformXhciBase);
+ASSERT (Base != NULL);
+Size = (UINTN)PcdGet32 (PcdPlatformXhciSize);
+ASSERT (Size != 0);
+
+DEBUG ((DEBUG_INFO, "%a: Got platform XHCI %llx %u\n",
+__FUNCTION__, Base, Size));
+
+Status = RegisterNonDiscoverableMmioDevice (
+ NonDiscoverableDeviceTypeXhci,
+ NonDiscoverableDeviceDmaTypeCoherent,
+ NULL,
+ NULL,
+ 1,
+ Base, Size);
+
+if (EFI_ERROR(Status)) {
+DEBUG ((DEBUG_ERROR, "%a: NonDiscoverable: Cannot install XHCI device @%p 
(Staus == %r)\n",
+__FUNCTION__, Base, Status));
+return Status;
+}
+  }
+
   return EFI_SUCCESS;
 }

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109721): https://edk2.groups.io/g/devel/message/109721
Mute This Topic: https://groups.io/mt/102035952/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v4 2/4] SbsaQemu: add AcpiLib

[Marcin Juszkiewicz]

It will be needed for playing with disabling XHCI later.

Signed-off-by: Marcin Juszkiewicz 
---
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 36723e21d7b5..1e650350cb63 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -172,6 +172,8 @@ [LibraryClasses.common]
 
   
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
 
+  AcpiLib|EmbeddedPkg/Library/AcpiLib/AcpiLib.inf
+
   ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
   ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
 

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109722): https://edk2.groups.io/g/devel/message/109722
Mute This Topic: https://groups.io/mt/102035953/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v4 0/4] Provide XHCI USB controller only for newer hardware

[Marcin Juszkiewicz]

Platform version 0.3 introduced XHCI USB controller instead of EHCI one.
But we did it in a way that there is no in-EDK2 check for platform
version (XHCI is always given).

This behaviour works with Linux as it complains about being unable to
initialize EHCI and goes on. Free/Net/Open BSD systems hang in such
situation.

Now we check are we on Platform Version 0.3 at least and then initialize
XHCI controller. Otherwise we disable it's node in DSDT table.

I checked several ways to handle the situation. 

SSDT overlay enabling with LocateAndInstallAcpiFromFvConfitional() was
first one but this function had only DBG2 and FACP tables.

Then looked at trying to detect XHCI from _STA method. But this is
sysbus device which is there or not without way to discover it.

Next attempt was to have variable in DSDT and to use it in _STA. Too
much trouble.

Then looked again at code from
Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiDsdt.c and noticed
UpdateStatusMethodObject() function. Copied some code and it worked.

Booting OpenBSD reminded me to update table checksum.

Nhi Pham pointed me to AcpiLib/AcpiAmlObjectUpdateInteger() function. So
v3 got AML variable (called XHCI) which is set to 0xF (enabled, working)
by default or to 0x0 (disabled, ignore) on Platform Version below 0.3
one.

This allowed to remove copy of UpdateStatusMethodObject() function.

---
Changes in v4:
- make use of DisableXhciOnOlderPlatVer() return value

Changes in v3:
- use AML variable in DSDT

Changes in v2:
- XHCI initialized only on PlatVer 0.3+
- XHCI disabled in DSDT for older platforms
- no SSDT overlays for EHCI/XHCI
- no EHCI at all (it does not work anyway)
- no Pcd renaming

---
Marcin Juszkiewicz (4):
  SbsaQemu: introduce macro to compare platform version
  SbsaQemu: add AcpiLib
  SbsaQemu: initialize XHCI only if it exists
  SbsaQemu: disable XHCI in DSDT if not present

 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  2 +
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
 .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 66 +++-
 .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 47 +++---
 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
 6 files changed, 123 insertions(+), 24 deletions(-)
---
base-commit: 06f6274d56422084281886fad447ab117fd0e487
change-id: 20231013-ehci-xhci-fix-c529356a7a8f

Best regards,
-- 
Marcin Juszkiewicz 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109719): https://edk2.groups.io/g/devel/message/109719
Mute This Topic: https://groups.io/mt/102035950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v4 1/4] SbsaQemu: introduce macro to compare platform version

[Marcin Juszkiewicz]

We want to check "if platver < 0.3" in an easy way.
---
 .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
 1 file changed, 25 insertions(+)

diff --git 
a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
new file mode 100644
index ..dd2483787002
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
@@ -0,0 +1,25 @@
+/** @file
+*
+*  Copyright (c) Linaro Limited. All rights reserved.
+*
+*  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef SBSAQEMUPLATFORM_VERSION_H
+#define SBSAQEMUPLATFORM_VERSION_H
+
+/*
+ * Compare PlatformVersion
+ *
+ */
+
+#define PLATFORM_VERSION_LESS_THAN(Major, Minor) ( \
+  (\
+( PcdGet32 (PcdPlatformVersionMajor) < Major)   || \
+(  \
+  ( PcdGet32 (PcdPlatformVersionMajor) == Major) && \
+  ( PcdGet32 (PcdPlatformVersionMinor) < Minor)\
+)  \
+  )\
+)
+#endif

-- 
2.41.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109720): https://edk2.groups.io/g/devel/message/109720
Mute This Topic: https://groups.io/mt/102035951/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[Laszlo Ersek]

On 10/13/23 05:03, caiyuqing...@163.com wrote:
> diff --git a/Platform/Sophgo/Maintainers.md b/Platform/Sophgo/Maintainers.md
> new file mode 100644
> index ..4cb32c359a31
> --- /dev/null
> +++ b/Platform/Sophgo/Maintainers.md
> @@ -0,0 +1,105 @@
> +##Project Name: EDK2 Sophgo SG2042
> +
> +##Maintainers:
> +1. dahogn - dah...@hotmail.com
> +2. caiyuqing379 - 
> +3. meng-cz - mengcz1...@gmail.com
> +4. USER0FISH - 
> +

This "Platform/Sophgo/Maintainers.md" file / format is useless with
edk2's "BaseTools/Scripts/GetMaintainer.py" utility. For that utility to
work, you need to add the maintainers to the "Maintainers.txt" file in
the edk2-platforms project root dir (... as well).

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109718): https://edk2.groups.io/g/devel/message/109718
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

[Ard Biesheuvel]

On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
 wrote:
>
> Dear Maintainers,
>
> Just a friendly reminder to ask if you could take a look at my patch. I'd 
> really appreciate your feedback and help.
>

Thanks for the reminder. I don't have time to review this myself but
I'm happy to merge it if someone else reviews it


>
> -Original Message-
> From: YuinYee Chew
> Sent: Friday, September 29, 2023 9:35 PM
> To: 'Heinrich Schuchardt' 
> Cc: Sunil V L ; Li Yong ; Leif 
> Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel 
> Schaefer ; devel@edk2.groups.io
> Subject: RE: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device 
> list
>
> Hi Heinrich,
>
> Both gd25lq128d and gd25lq128e share the same ID "{ 0xc8, 0x60, 0x18}"
> gd25lq128d : 
> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128d.html
> gd25lq128e : 
> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128e
> So, I'm thinking to put it as "gd25lq128" to represent both "d" and "e".
> If sync with Linux, gd25lq128d will be better.
>
> Do you have any suggestion on this?
> Or anyone have any opinion?
>
> Thanks again for the feedback! =)
>
> -Original Message-
> From: Heinrich Schuchardt 
> Sent: Friday, September 29, 2023 4:55 PM
> To: YuinYee Chew 
> Cc: Sunil V L ; Li Yong ; Leif 
> Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel 
> Schaefer ; devel@edk2.groups.io
> Subject: Re: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device 
> list
>
> On 9/29/23 04:02, John Chew wrote:
> > Update Gigadevice norflash list:
> > gd25q16, gd25q32, gd25q64, gd25lq64c, gd25q128, gd25lq128, gd25q256
> >
> > Add Silicon Kaiser norflash list:
> > sk25lp128
> >
> > Cc: Sunil V L 
> > Cc: Li Yong 
> > Cc: Heinrich Schuchardt 
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> > Cc: Abner Chang 
> > Cc: Daniel Schaefer 
> > Signed-off-by: John Chew 
> > ---
> >   EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 11 ++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > index e16c1c6a14..422fdac851 100644
> > --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > @@ -1,6 +1,7 @@
> >   /** @file
> >   *
> >   *  Copyright (c) 2017 Marvell International Ltd.
> > +*  Copyright (c) 2023 StarFive, Technology Co., Ltd. All rights
> > +reserved.
> >   *
> >   *  SPDX-License-Identifier: BSD-2-Clause-Patent
> >   *
> > @@ -33,12 +34,20 @@ STATIC CONST NOR_FLASH_INFO  NorFlashIds[] = {
> > { L"en25q128b",  { 0x1c, 0x30, 0x18 }, 3, 256, 64 * 1024,  256,  0  
> >   },
> > { L"en25s64",{ 0x1c, 0x38, 0x17 }, 3, 256, 64 * 1024,  128,  0  
> >   },
> > /* GIGADEVICE */
> > -  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q16",{ 0xc8, 0x40, 0x15 }, 3, 256, 64 * 1024,  32,   
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q32",{ 0xc8, 0x40, 0x16 }, 3, 256, 64 * 1024,  64,   
> > NOR_FLASH_ERASE_4K   },
> > { L"gd25lq32",   { 0xc8, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
>
> Linux calls this gd25q64 but probably we don't want to change the displayed 
> name.
>
> > +  { L"gd25lq64c",  { 0xc8, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q128",   { 0xc8, 0x40, 0x18 }, 3, 256, 64 * 1024,  256,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25lq128",  { 0xc8, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  
> > NOR_FLASH_ERASE_4K   },
>
> Linux calls this gd25lq128d.
>
> > +  { L"gd25q256",   { 0xc8, 0x40, 0x19 }, 3, 256, 64 * 1024,  512,  
> > NOR_FLASH_ERASE_4K   },
>
> Except for the two labels the changes match drivers/mtd/spi-nor/gigadevice.c 
> in Linux.
>
> > /* ISSI */
> > { L"is25lp032",  { 0x9d, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   0  
> >   },
> > { L"is25lp064",  { 0x9d, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  0  
> >   },
> > { L"is25lp128",  { 0x9d, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  0  
> >   },
> > +  /* XINKAI / SILICON KAISER */
> > +  { L"sk25lp128",  { 0x27, 0x70, 0x18 }, 3, 256, 64 * 1024,  256,  
> > NOR_FLASH_ERASE_4K   },
>
> This matches
> https://lore.kernel.org/all/20230726214401.929533-1-jo...@kwiboo.se/
>
> Acked-by: Heinrich Schuchardt 
>
>
> > /* MACR

Re: [edk2-devel] [PATCH] ArmPkg/ArmPsciMpServices Add EFI_NOT_READY return

[Ard Biesheuvel]

On Tue, 17 Oct 2023 at 00:55, Rebecca Cran  wrote:
>
> Reviewed-by: Rebecca Cran 
>
>
> Looks like this is still waiting to be merged by an ArmPkg maintainer.
>
>

Thanks for the reminder

Really queued up now


>
> On 6/29/23 14:46, Jeff Brasen wrote:
> > Add EFI_NOT_READY return if the CPU can not be enabled if the
> > processor is already on.
> >
> > This can occur in normal use if the CPU is still being turned off from
> > a previous call when this is called again.
> >
> > Signed-off-by: Jeff Brasen 
> > ---
> >   ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c 
> > b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > index f822a9877c..e7f4223513 100644
> > --- a/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > +++ b/ArmPkg/Drivers/ArmPsciMpServicesDxe/ArmPsciMpServicesDxe.c
> > @@ -103,7 +103,9 @@ DispatchCpu (
> >
> > ArmCallSmc (&Args);
> >
> > -  if (Args.Arg0 != ARM_SMC_PSCI_RET_SUCCESS) {
> > +  if (Args.Arg0 == ARM_SMC_PSCI_RET_ALREADY_ON) {
> > +Status = EFI_NOT_READY;
> > +  } else if (Args.Arg0 != ARM_SMC_PSCI_RET_SUCCESS) {
> >   DEBUG ((DEBUG_ERROR, "PSCI_CPU_ON call failed: %d\n", Args.Arg0));
> >   Status = EFI_DEVICE_ERROR;
> > }
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109716): https://edk2.groups.io/g/devel/message/109716
Mute This Topic: https://groups.io/mt/99859167/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v3 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Ard Biesheuvel]

On Wed, 18 Oct 2023 at 07:56, Marcin Juszkiewicz
 wrote:
>
> W dniu 18.10.2023 o 05:28, Nhi Pham pisze:
> > Hi Marcin,
> >
> > There is a nitpicking below.
> >
> > Other than, it looks good to me.
> >
> > Acked-by: Nhi Pham 
> >
> >> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> >> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> >> index fd849ca1594b..cf6e534ca3a0 100644
> >> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> >> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> >> @@ -10,6 +10,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -682,6 +683,63 @@ AddGtdtTable (
> >> return Status;
> >>   }
> >> +EFI_STATUS
> >> +DisableXhciOnOlderPlatVer (
> >> +  VOID
> >> +  )
> >> +{
> >> +  EFI_STATUSStatus;
> >> +  EFI_ACPI_SDT_PROTOCOL   *AcpiSdtProtocol;
> >> +  EFI_ACPI_DESCRIPTION_HEADER *Table;
> >> +  UINTN   TableKey;
> >> +  UINTN   TableIndex;
> >> +  EFI_ACPI_HANDLE TableHandle;
> >> +
> >> +  Status = EFI_SUCCESS;
> >> +
> >> +  if ( PLATFORM_VERSION_LESS_THAN(0, 3) ) {
> >> +DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
> >> +Status = gBS->LocateProtocol (
> >> +&gEfiAcpiSdtProtocolGuid,
> >> +NULL,
> >> +(VOID **)&AcpiSdtProtocol
> >> +);
> >> +if (EFI_ERROR (Status)) {
> >> +  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
> >> +  return Status;
> >> +}
> >> +
> >> +TableIndex = 0;
> >> +Status = AcpiLocateTableBySignature (
> >> +   AcpiSdtProtocol,
> >> +
> >> EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
> >> +   &TableIndex,
> >> +   &Table,
> >> +   &TableKey
> >> +   );
> >> +if (EFI_ERROR (Status)) {
> >> +  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
> >> +  ASSERT_EFI_ERROR (Status);
> >> +  return Status;
> >> +}
> >> +
> >> +Status = AcpiSdtProtocol->OpenSdt (TableKey, &TableHandle);
> >> +if (EFI_ERROR (Status)) {
> >> +  ASSERT_EFI_ERROR (Status);
> >> +  AcpiSdtProtocol->Close (TableHandle);
> >> +  return Status;
> >> +}
> >> +
> >> +AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle,
> >> "\\_SB.USB0.XHCI", 0x0);
> >> +
> >> +AcpiSdtProtocol->Close (TableHandle);
> >> +AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
> >> +  }
> >> +
> >> +  return Status;
> >> +}
> >> +
> >> +
> >>   EFI_STATUS
> >>   EFIAPI
> >>   InitializeSbsaQemuAcpiDxe (
> >> @@ -738,5 +796,7 @@ InitializeSbsaQemuAcpiDxe (
> >>   DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
> >> }
> >> +  Status = DisableXhciOnOlderPlatVer();
> >
> > Nit: EDK2 Coding Style says that you need a space before (.
>
> Ah, right. forgot to crucify the source.
>
> > Is it necessary to handle the result of Status?
>
> EDK2 is full of handling Status on touching ACPI tables. So I followed.
>

Can you just do 'return DisableXhciOnOlderPlatVer();' instead?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109715): https://edk2.groups.io/g/devel/message/109715
Mute This Topic: https://groups.io/mt/102017316/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v3 1/4] SbsaQemu: introduce macro to compare platform version

[Ard Biesheuvel]

On Wed, 18 Oct 2023 at 10:45, Ard Biesheuvel  wrote:
>
> On Tue, 17 Oct 2023 at 15:23, Marcin Juszkiewicz
>  wrote:
> >
> > We want to check "if platver < 0.3" in an easy way.
> > ---
> >  .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
> > 
> >  1 file changed, 25 insertions(+)
> >
> > diff --git 
> > a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h 
> > b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
> > new file mode 100644
> > index ..dd2483787002
> > --- /dev/null
> > +++ 
> > b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
> > @@ -0,0 +1,25 @@
> > +/** @file
> > +*
> > +*  Copyright (c) Linaro Limited. All rights reserved.
> > +*
> > +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +**/
> > +
> > +#ifndef SBSAQEMUPLATFORM_VERSION_H
> > +#define SBSAQEMUPLATFORM_VERSION_H
> > +
> > +/*
> > + * Compare PlatformVersion
> > + *
> > + */
> > +
> > +#define PLATFORM_VERSION_LESS_THAN(Major, Minor) ( \
> > +  (\
> > +( PcdGet32 (PcdPlatformVersionMajor) < Major)   || \
> > +(  \
> > +  ( PcdGet32 (PcdPlatformVersionMajor) == Major) && \
> > +  ( PcdGet32 (PcdPlatformVersionMinor) < Minor)\
> > +)  \
> > +  )\
> > +)
> > +#endif
> >
>
> I don't mind adding this here but it is slightly unidiomatic so I'd
> like Leif's take on this too.

... and it also lacks a s-o-b line


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109714): https://edk2.groups.io/g/devel/message/109714
Mute This Topic: https://groups.io/mt/102017313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v3 1/4] SbsaQemu: introduce macro to compare platform version

[Ard Biesheuvel]

On Tue, 17 Oct 2023 at 15:23, Marcin Juszkiewicz
 wrote:
>
> We want to check "if platver < 0.3" in an easy way.
> ---
>  .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 
> 
>  1 file changed, 25 insertions(+)
>
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
> new file mode 100644
> index ..dd2483787002
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuPlatformVersion.h
> @@ -0,0 +1,25 @@
> +/** @file
> +*
> +*  Copyright (c) Linaro Limited. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef SBSAQEMUPLATFORM_VERSION_H
> +#define SBSAQEMUPLATFORM_VERSION_H
> +
> +/*
> + * Compare PlatformVersion
> + *
> + */
> +
> +#define PLATFORM_VERSION_LESS_THAN(Major, Minor) ( \
> +  (\
> +( PcdGet32 (PcdPlatformVersionMajor) < Major)   || \
> +(  \
> +  ( PcdGet32 (PcdPlatformVersionMajor) == Major) && \
> +  ( PcdGet32 (PcdPlatformVersionMinor) < Minor)\
> +)  \
> +  )\
> +)
> +#endif
>

I don't mind adding this here but it is slightly unidiomatic so I'd
like Leif's take on this too.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109713): https://edk2.groups.io/g/devel/message/109713
Mute This Topic: https://groups.io/mt/102017313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-