Re: [edk2-devel] Event: Tools, CI, Code base construction meeting series - Monday, July 15, 2024 #cal-reminder

[Sean]

confirming meeting for today (in 36 minutes).


There has been a request for topic so we will host a quick 
update/discussion. Tools and CI Meeting - Date 7/1 & 7/8 · 
tianocore/edk2 · Discussion #5843 (github.com) 
<https://github.com/tianocore/edk2/discussions/5843>


Overall, very few updates from Michael Kubacki or myself.  We plan to 
build a prototype for the codeowners, github queue, and reviewer adding 
github action.  Others welcome to signup if so desired.



Thanks

Sean


On 7/15/2024 3:30 PM, Group Notification wrote:


*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, July 15, 2024
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 



View Event <https://edk2.groups.io/g/devel/viewevent?eventid=2374366>

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614


Anyone is welcome to join.

  * tianocore/edk2: EDK II (github.com)
  * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP
module (github.com) https://github.com/tianocore/edk2-basetools
  * tianocore/edk2-pytool-extensions: Extensions to the edk2 build
system allowing for a more robust and plugin based build system
and tool execution environment (github.com)
https://github.com/tianocore/edk2-pytool-extensions
  * tianocore/edk2-pytool-library: Python library package that
supports UEFI development (github.com)
https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119940): https://edk2.groups.io/g/devel/message/119940
Mute This Topic: https://groups.io/mt/107223000/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] Event: Tools, CI, Code base construction meeting series - Monday, July 8, 2024 #cal-reminder

[Sean]

Just confirming this meeting will happen today.

Discussion here: Tools and CI Meeting - Date 7/1 & 7/8 · tianocore/edk2 
· Discussion #5843 (github.com) 
<https://github.com/tianocore/edk2/discussions/5843>


Thanks

Sean



On 7/7/2024 4:30 PM, Group Notification wrote:


*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, July 8, 2024
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 



View Event <https://edk2.groups.io/g/devel/viewevent?eventid=2366031>

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614


Anyone is welcome to join.

  * tianocore/edk2: EDK II (github.com)
  * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP
module (github.com) https://github.com/tianocore/edk2-basetools
  * tianocore/edk2-pytool-extensions: Extensions to the edk2 build
system allowing for a more robust and plugin based build system
and tool execution environment (github.com)
https://github.com/tianocore/edk2-pytool-extensions
  * tianocore/edk2-pytool-library: Python library package that
supports UEFI development (github.com)
https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119814): https://edk2.groups.io/g/devel/message/119814
Mute This Topic: https://groups.io/mt/107094023/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] Event: Tools, CI, Code base construction meeting series - Monday, June 3, 2024 #cal-reminder

[Sean]

confirming this meeting will be held today.

Topics and agenda posted: Tools and CI Meeting - Date 6/3 · 
tianocore/edk2 · Discussion #5723 (github.com) 
<https://github.com/tianocore/edk2/discussions/5723>


Add additional agenda topics to the github discussion.

Thanks

Sean



On 6/2/2024 4:30 PM, Group Notification wrote:


*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, June 3, 2024
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 



View Event <https://edk2.groups.io/g/devel/viewevent?eventid=2159801>

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614


Anyone is welcome to join.

  * tianocore/edk2: EDK II (github.com)
  * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP
module (github.com) https://github.com/tianocore/edk2-basetools
  * tianocore/edk2-pytool-extensions: Extensions to the edk2 build
system allowing for a more robust and plugin based build system
and tool execution environment (github.com)
https://github.com/tianocore/edk2-pytool-extensions
  * tianocore/edk2-pytool-library: Python library package that
supports UEFI development (github.com)
https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119432): https://edk2.groups.io/g/devel/message/119432
Mute This Topic: https://groups.io/mt/106453021/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] Event: Tools, CI, Code base construction meeting series - Monday, May 20, 2024 #cal-reminder

[Sean]

FYI - Since PRs are targeted to be enabled on Friday may 24th we will 
host this meeting today to close/align on any concerns.


Look forward to seeing everyone there.

thanks

Sean




On 5/19/2024 4:30 PM, Group Notification wrote:


*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, May 20, 2024
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 



View Event <https://edk2.groups.io/g/devel/viewevent?eventid=2159799>

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614


Anyone is welcome to join.

  * tianocore/edk2: EDK II (github.com)
  * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP
module (github.com) https://github.com/tianocore/edk2-basetools
  * tianocore/edk2-pytool-extensions: Extensions to the edk2 build
system allowing for a more robust and plugin based build system
and tool execution environment (github.com)
https://github.com/tianocore/edk2-pytool-extensions
  * tianocore/edk2-pytool-library: Python library package that
supports UEFI development (github.com)
https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119090): https://edk2.groups.io/g/devel/message/119090
Mute This Topic: https://groups.io/mt/106194775/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 0/9] Allocate and unblock variable runtime cache buffer in PEI

[Sean]

I can't find patch 1 in the series in my email so putting a few comments 
here.  I really hope this patch series can wait for PRs so code comments 
can more easily be correlated with code change.


Looking at your PR with commit: Allocate Varaible cache buffer in PEI by 
td36 · Pull Request #5607 · tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/pull/5607/commits/36c2cac5fa4196be7fc85d842e8056e376010479>


A few comments for now.

Variable is spelled incorrectly in commit message.

I would really prefer to not mix PCDs and Hobs.  It is really confusing 
what has to be turned on and set to what to get the different 
behaviors.  For a hob producer it is OK to take that info from PCDs but 
lets not mix in the consumer code PCDs and hob data.  The HOB definition 
should not reference a PCD and a HOB definition should not be focused on 
producer/consumer but on the data.


The existence of a hob is also a good indicator that a feature is used 
so you may not need to have "enable" PCDs anymore.


Please don't include other header files in public header files 
(especially for super common headers like PiPei.h.  i know over the last 
few years this practice has become more common but it just creates pain 
when debugging build errors.  The trade off is not worth it.


Hobs really shouldn't use UINTN sizes.  Since hobs helps transfer config 
state across phases where the size of UINTN may be different this causes 
problems.


Hobs used for cross phase sharing shouldn't have pointers for the reason.

Better and more complete comments on the different field members would 
be helpful.  I assume the "Buffer" fields are physical addresses and the 
"Pages" are number of 4K pages.   I would suggest EFI_PHYSICAL_ADDRESS 
for addresses and UINT64 for lengths.


More details on what the three cache's are would be helpful or at least 
reference the feature of the cache they are supporting.


This hob definition file isn't perfect and I believe some of the comment 
in the file header belong in different places, it is at least a good 
template for a hob definition.


edk2/MdeModulePkg/Include/Guid/VariableFlashInfo.h at 
284dbac43da752ee34825c8b3f6f9e8281cb5a19 · tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/blob/284dbac43da752ee34825c8b3f6f9e8281cb5a19/MdeModulePkg/Include/Guid/VariableFlashInfo.h>



Thanks

Sean



On 5/17/2024 2:49 AM, duntan wrote:

This patch set defines a new VARIABLE_RUNTIME_CACHE_INFO HOB. The HOB is used 
to store the address and size of the buffer that will be used for variable 
runtime service when the PcdEnableVariableRuntimeCache is TRUE.
In following patches, when PcdEnableVariableRuntimeCache is TRUE, VariablePei 
will install a callback of gEfiPeiMemoryDiscoveredPpiGuid to allocate the 
needed buffer for different type variable runtime cache and build the HOB.
Then VariableSmmRuntimeDxe driver will consume 
gEdkiiVariableRuntimeCacheInfoHobGuid to initialize the variable runtime cache 
related content. The code to allocate and unblock the runtime cache buffer in 
VariableSmmRuntimeDxe is also removed in this patc set.

PR for review:https://github.com/tianocore/edk2/pull/5607

Cc: Ray Ni
Cc: Liming Gao
Cc: Jiaxin Wu
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Sami Mujawar
Cc: Gerd Hoffmann
Cc: Andrew Fish
Cc: Jiewen Yao

Dun Tan (9):
   MdeModulePkg:Add new gEdkiiVariableRuntimeCacheInfoHobGuid
   ArmVirtPkg: Add MmUnblockMemoryLib in DSC
   EmulatorPkg: Add MmUnblockMemoryLib in DSC
   OvmfPkg: Add MmUnblockMemoryLib in DSC
   MdeModulePkg:Create gEdkiiVariableRuntimeCacheInfoHobGuid
   MdeModulePkg:Remove unnecessary global variable
   MdeModulePkg:Consume gEdkiiVariableRuntimeCacheInfoHobGuid
   MdeModulePkg: Refine InitVariableCache()
   MdeModulePkg:Add global variable mVariableRtCacheInfo

  ArmVirtPkg/ArmVirtCloudHv.dsc|   2 ++
  EmulatorPkg/EmulatorPkg.dsc  |   1 +
  MdeModulePkg/Include/Guid/VariableRuntimeCacheInfo.h |  65 
+
  MdeModulePkg/MdeModulePkg.dec|   3 +++
  MdeModulePkg/Universal/Variable/Pei/Variable.c   | 298 
+-
  MdeModulePkg/Universal/Variable/Pei/Variable.h   |   3 +++
  MdeModulePkg/Universal/Variable/Pei/VariablePei.inf  |   8 
+++-
  MdeModulePkg/Universal/Variable/

Re: [edk2-devel] [PATCH RESEND v1] MdePkg: Adds a PCD to define IPMI interface type

[Sean]

Shoving everything into mdepkg to avoid a perceived dependency issue doesn't 
really solve the problem. If dynamictables pkg wants to be tied to an 
implementation of ipmi then you will have that dependency problem regardless.  
If dynamic tables really wants to be the producer of SPMI then it could query 
information from the protocol which would allow it to scale to the 3+ 
implementations of ipmi I mentioned earlier (assuming the protocol definition 
can be agreed upon and made common). Or manageability package could be producer 
of the table.  Traditionally many of the ACPI tables have come from the realm 
of the platform because of the detailed information they require.  I don't 
think dynamic tables package will be able to produce all tables without more 
complete abstractions and dependencies.

So yes, until there is much better alignment in uefi for ipmi support, I would 
prefer the pcds and all implementation details be kept in or moved back to 
manageability pkg.

Thanks
Sean



From: Attar, AbdulLateef (Abdul Lateef) 
Sent: Monday, April 22, 2024 9:47:32 PM
To: Chang, Abner ; Sean Brogan ; 
devel@edk2.groups.io ; Liming Gao 
; Michael D Kinney ; 
Zhiguang Liu 
Cc: Chris Fernald 
Subject: RE: [edk2-devel] [PATCH RESEND v1] MdePkg: Adds a PCD to define IPMI 
interface type


[AMD Official Use Only - General]


HI Abner,

Moving the IPMI related PCD’s will cause additional package 
dependencies.

Suppose if someone wants to implement SPMI table using DynamicTablesPkg (and 
using this PCD);

then it will cause dependencies on ManageabilityPkg which is not accepted.



Thanks

AbduL





From: Chang, Abner 
Sent: Tuesday, April 23, 2024 7:22 AM
To: Sean Brogan ; devel@edk2.groups.io; Attar, 
AbdulLateef (Abdul Lateef) ; Liming Gao 
; Michael D Kinney ; 
Zhiguang Liu 
Cc: Chris Fernald 
Subject: RE: [edk2-devel] [PATCH RESEND v1] MdePkg: Adds a PCD to define IPMI 
interface type



[AMD Official Use Only - General]



Hi Sean,

I was struggling when introduce IPMI KCS base IO PCD in Mde, although it is a  
industry value but seems it is fine to have it in ManageabilityPkg. How do you 
think if we relocate those IPMI PCDs back to ManageabilityPkg?



Thanks

Abner





From: Sean Brogan mailto:spbro...@outlook.com>>
Sent: Tuesday, April 23, 2024 4:18 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Attar, AbdulLateef 
(Abdul Lateef) mailto:abdullateef.at...@amd.com>>; 
Liming Gao mailto:gaolim...@byosoft.com.cn>>; Michael 
D Kinney mailto:michael.d.kin...@intel.com>>; 
Zhiguang Liu mailto:zhiguang@intel.com>>
Cc: Chang, Abner mailto:abner.ch...@amd.com>>; Chris 
Fernald mailto:chris.fern...@outlook.com>>
Subject: Re: [edk2-devel] [PATCH RESEND v1] MdePkg: Adds a PCD to define IPMI 
interface type



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



This seems like a bad design to require the ipmi interface type at such a high 
level in the code tree.  UEFI provides plenty protocol and library abstractions 
for IPMI so I would really prefer not to leak this type of information into a 
PCD defined in MdePkg.  Happy to discuss IPMI support and I would really like 
to see edk2, edk2-platforms/Features/ManageabilityPkg at master · 
tianocore/edk2-platforms 
(github.com)<https://github.com/tianocore/edk2-platforms/tree/master/Features/ManageabilityPkg>,
  microsoft/mu_feature_ipmi: Project Mu - Feature Repo- Firmware support for 
IPMI (github.com)<https://github.com/microsoft/mu_feature_ipmi>, and commercial 
vendors find some sort of alignment going forward as no one wins with the mess 
that is in the industry now.

Thanks

Sean



On 4/22/2024 3:50 AM, Abdul Lateef Attar via groups.io wrote:

Gentle reminder, review please.

On 30-03-2024 10:52, Abdul Lateef Attar wrote:

Define IPMI interface type as per specification version 2.0,
section C1-1.1.

Cc: Abner Chang <mailto:abner.ch...@amd.com>
Cc: Michael D Kinney 
<mailto:michael.d.kin...@intel.com>
Cc: Liming Gao <mailto:gaolim...@byosoft.com.cn>
Cc: Zhiguang Liu <mailto:zhiguang@intel.com>
Signed-off-by: Abdul Lateef Attar 
<mailto:abdullateef.at...@amd.com>
---
  MdePkg/MdePkg.dec | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 0c18e1decd..396d960dca 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -9,7 +9,7 @@
  # (C) Copyright 2016 - 2021 Hewlett Packard Enterprise Development LP
  # Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
reserved.
  # Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
-# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights 
reserved.
  # Copyright (c) 2023, Ampere Computing LLC. All

Re: [edk2-devel] [PATCH RESEND v1] MdePkg: Adds a PCD to define IPMI interface type

[Sean]

This seems like a bad design to require the ipmi interface type at such 
a high level in the code tree.  UEFI provides plenty protocol and 
library abstractions for IPMI so I would really prefer not to leak this 
type of information into a PCD defined in MdePkg.  Happy to discuss IPMI 
support and I would really like to see edk2, 
edk2-platforms/Features/ManageabilityPkg at master · 
tianocore/edk2-platforms (github.com) 
<https://github.com/tianocore/edk2-platforms/tree/master/Features/ManageabilityPkg>, 
microsoft/mu_feature_ipmi: Project Mu - Feature Repo- Firmware support 
for IPMI (github.com) <https://github.com/microsoft/mu_feature_ipmi>, 
and commercial vendors find some sort of alignment going forward as no 
one wins with the mess that is in the industry now.


Thanks

Sean


On 4/22/2024 3:50 AM, Abdul Lateef Attar via groups.io wrote:

Gentle reminder, review please.

On 30-03-2024 10:52, Abdul Lateef Attar wrote:

Define IPMI interface type as per specification version 2.0,
section C1-1.1.

Cc: Abner Chang 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Signed-off-by: Abdul Lateef Attar 
---
  MdePkg/MdePkg.dec | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 0c18e1decd..396d960dca 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -9,7 +9,7 @@
  # (C) Copyright 2016 - 2021 Hewlett Packard Enterprise Development 
LP
  # Copyright (c) 2022, Loongson Technology Corporation Limited. All 
rights reserved.

  # Copyright (c) 2021 - 2022, Arm Limited. All rights reserved.
-# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights 
reserved.
+# Copyright (C) 2023 - 2024, Advanced Micro Devices, Inc. All rights 
reserved.

  # Copyright (c) 2023, Ampere Computing LLC. All rights reserved.
  #
  # SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -2401,6 +2401,15 @@
    # @Prompt Time-out for a response, internal
gEfiMdePkgTokenSpaceGuid.PcdIpmiSsifResponseRetryIntervalMicrosecond|6|UINT32|0x0036
  +  ## Indicates IPMI Interface Type
+  # The IPMI specification defines the following interface types: 
(section C1-1.1)

+  # 0 - Unknown
+  # 1 - KCS : Keyboard Controller Style
+  # 2 - SMIC    : Server Management Interface Chip
+  # 3 - BT  : Block Transfer
+  # 4 - SSIF    : SMBus System Interface
+ gEfiMdePkgTokenSpaceGuid.PcdIpmiInterfaceType|0|UINT8|0x0038
+
  [PcdsFixedAtBuild.AARCH64, PcdsPatchableInModule.AARCH64]
    ## GUID identifying the Rng algorithm implemented by CPU 
instruction.

    # @Prompt CPU Rng algorithm's GUID.









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

Re: [edk2-devel] [PATCH 3/3] PlatformHookLib: Set PcdSerialClockRate using HOB data

[Sean Rhodes]

PR created - https://github.com/tianocore/edk2/pull/5513

LGTM but I can't check it against UPL.

@Dong, Guo  Would you be able to take a look please'?

On Wed, 4 Oct 2023 at 21:02, MrChromebox  wrote:

> Fixes serial output on platforms using coreboot and a non-default
> clock rate such as AMD Picasso and newer Zen-based platforms.
>
> Signed-off-by: Matt DeVillier 
> Change-Id: I91290397852176754e9a34ec6e5829044f41d15a
> ---
>  UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c   | 5 +
>  UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf | 1 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
> b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
> index 60a17b8fc2..e3d47ac2fa 100644
> --- a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
> +++ b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c
> @@ -90,6 +90,11 @@ PlatformHookSerialPortInitialize (
>return Status;
>  }
>
> +Status = PcdSet32S (PcdSerialClockRate, SerialPortInfo->ClockRate);
> +if (RETURN_ERROR (Status)) {
> +  return Status;
> +}
> +
>  return RETURN_SUCCESS;
>}
>
> diff --git a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
> b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
> index 7ac6bfa1b1..e2908cfbca 100644
> --- a/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
> +++ b/UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.inf
> @@ -38,3 +38,4 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase## PRODUCES
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate## PRODUCES
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride  ## PRODUCES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate   ## PRODUCES
> --
> 2.34.1
>
>
>
> 
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#109337): https://edk2.groups.io/g/devel/message/109337
> Mute This Topic: https://groups.io/mt/101763377/6718866
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [sean@starlabs.systems]
> 
>
>
>


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

Re: [edk2-devel] Cancelled Event: Tools, CI, Code base construction meeting series - Monday, March 25, 2024 #cal-cancelled

[Sean]

No requests listed here: Tools and CI Meeting - vNext - Date TBD · 
tianocore/edk2 · Discussion #5366 (github.com) 
<https://github.com/tianocore/edk2/discussions/5366>


Cancelling for today.


Thanks

Sean



On 3/25/2024 4:16 PM, Group Notification wrote:


*Cancelled: Tools, CI, Code base construction meeting series*

This event has been cancelled.

*When:*
Monday, March 25, 2024
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 



*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614


Anyone is welcome to join.

  * tianocore/edk2: EDK II (github.com)
  * tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP
module (github.com) https://github.com/tianocore/edk2-basetools
  * tianocore/edk2-pytool-extensions: Extensions to the edk2 build
system allowing for a more robust and plugin based build system
and tool execution environment (github.com)
https://github.com/tianocore/edk2-pytool-extensions
  * tianocore/edk2-pytool-library: Python library package that
supports UEFI development (github.com)
https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client



devel@edk2.groups.io Group has cancelled this event: Tools, CI, Code 
base construction meeting series

Title:  Tools, CI, Code base construction meeting series
Location: 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDI2ZDg4NmMtMjI1My00MzI5LWFmYjAtMGQyNjUzNTBjZGYw%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2223af6561-6e1c-450d-b917-d9d674eb3cb6%22%7d 


When:   Monday, March 25, 2024 4:30 PM – 5:30 PM




Organizer:  
devel@edk2.groups.io Group 
Description:TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to 
discuss build, CI, tools, and other related topics. If you are 
interested, have ideas/opinions please join us. These meetings will be 
Monday 4:30pm Pacific Time on Microsoft Teams.


MS Teams Link in following discussion:
* https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP 
module (github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build 
system allowing for a more robust and plugin based build system and 
tool execution environment (github.com) 
https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports 
UEFI development (github.com) 
https://github.com/tianocore/edk2-pytool-library


MS Teams Browser Clients
* 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client 














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

Re: [edk2-devel] Cancelled Event: Tools, CI, Code base construction meeting series - Monday, March 11, 2024 #cal-cancelled

[Sean]

Not enough content requested here Tools and CI Meeting - vNext - Date TBD · 
tianocore/edk2 · Discussion #5366 (github.com) ( 
https://github.com/tianocore/edk2/discussions/5366 )
Cancelling the meeting for the week.


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

Re: [edk2-devel] [PATCH] UefiPayloadPkg: CbParseLib: Fix integer overflow

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Fri, 12 Jan 2024 at 11:43, Guo, Gua  wrote:

> Reviewed-by: Gua Guo 
> --
> *From:* Lean Sheng Tan 
> *Sent:* Friday, January 12, 2024 7:33:00 PM
> *To:* Rudolph, Patrick 
> *Cc:* devel@edk2.groups.io ; Rhodes, Sean
> ; Guo, Gua ; Lu, James <
> james...@intel.com>; Ni, Ray ; Dong, Guo <
> guo.d...@intel.com>
> *Subject:* Re: [PATCH] UefiPayloadPkg: CbParseLib: Fix integer overflow
>
> Hi Gua or Sean,
> Would you mind to help review this?
> Thanks!
>
> Best Regards,
> *Lean Sheng Tan*
>
>
>
> 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email: sheng@9elements.com
> Phone: *+49 234 68 94 188 <+492346894188>*
> Mobile: *+49 176 76 113842 <+4917676113842>*
>
> Registered office: Bochum
> Commercial register: Amtsgericht Bochum, HRB 17519
> Management: Sebastian German, Eray Bazaar
>
> Data protection information according to Art. 13 GDPR
> <https://9elements.com/privacy>
>
>
> On Mon, 8 Jan 2024 at 08:00, Patrick Rudolph <
> patrick.rudo...@9elements.com> wrote:
>
> The IMD entry uses the 32bit start field as relative offset
> to root. On Ia32X64 this works fine as UINTN is also 32 bit and
> negative relative offsets are properly calculated due to an
> integer overflow.
>
> On X64 this doesn't work as UINTN is 64 bit and the offset
> is no longer subtracted, but it's added to the root. Fix that
> by sign extending the start field to 64 bit.
>
> Test: Booting UefiPayloadPkg still works on Ia32X64 and now also
>   works on X64.
>
> Signed-off-by: Patrick Rudolph 
> ---
>  UefiPayloadPkg/Library/CbParseLib/CbParseLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
> b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
> index 8a353f77f6..9e149532a7 100644
> --- a/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
> +++ b/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c
> @@ -282,7 +282,7 @@ FindCbMemTable (
>for (Idx = 0; Idx < Root->num_entries; Idx++) {
>  if (Entries[Idx].id == TableId) {
>if (IsImdEntry) {
> -*MemTable = (VOID *)((UINTN)Entries[Idx].start + (UINTN)Root);
> +*MemTable = (VOID *)((INTN)(INT32)Entries[Idx].start +
> (UINTN)Root);
>} else {
>  *MemTable = (VOID *)(UINTN)Entries[Idx].start;
>}
> --
> 2.43.0
>
>


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

[edk2-devel] Tools and CI meeting moved to as needed basis + call for topics

[Sean]

The weekly Tools & CI meeting meeting is moving to an as needed basis.

There is a Github discussion item for each weeks meeting that will 
indicate the status and agenda.  If you have a topic please use the 
appropriate weeks discussion to raise it and the meeting will be 
confirmed as scheduled.  Otherwise meeting with no agenda will be 
cancelled.



Dec 11th meeting discussion here:

Tools and CI Meeting - Dec 11, 2023 · tianocore/edk2 · Discussion #5118 
(github.com) <https://github.com/tianocore/edk2/discussions/5118>



Thanks

Sean



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112204): https://edk2.groups.io/g/devel/message/112204
Mute This Topic: https://groups.io/mt/103039030/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] BaseTools KeyError When Building EmulatorPkg

[Sean]

@Ryder

We have identified the issue.

A new issue will be created here Issues · tianocore/edk2-basetools 
(github.com) <https://github.com/tianocore/edk2-basetools/issues> to 
track it.


In the meantime there are two easy workarounds (pick one).


1. Create your venv named something like "venv" instead of ".venv".  It 
just must come later in the default directory sort than "Basetools".


or

2. Create your venv outside the edk2 source code tree.  Generally this 
is what I do as I don't like my virtual environment mixed with my source 
code.



As mentioned before don't forget to build the basetools.  From there, my 
experience is everything works.  Thanks for reporting your issue.



Thanks

Sean


On 11/27/2023 10:16 AM, Sean wrote:


We are looking at it.

It seems to be a problem in the edk2-basetools but at this point it 
still isn't obvious.


You can do a 'pip uninstall edk2-basetools' and then I would expect 
your build would work.


I also see that you didn't build edk2 basetools (step 6) documented 
here: edk2/EmulatorPkg/PlatformCI at master · tianocore/edk2 
(github.com) 
<https://github.com/tianocore/edk2/tree/master/EmulatorPkg/PlatformCI>.  
Without doing that your build will fail as well.



The CI system is building fine so we are still looking into it.

I'll update the thread when we have more info.


Thanks

Sean



On 11/21/2023 8:22 AM, Laszlo Ersek wrote:

Adding Sean

Laszlo

On 11/19/23 23:43, ryderkeys via groups.io wrote:

Hi all,

I am trying to build EDK2 from most recent Github (namely, EmulatorPkg) with 
the new Stuart build system on Windows 10 22H2 64 bit with VS 2019. I'm getting 
the following error which directed me to this mailing list. More details on my 
build process below.

INFO - build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\users\ryder\edk2_2023\edk2\EmulatorPkg\EmulatorPkg.dsc]
INFO -
INFO - (Please send email tode...@edk2.groups.io  for help, attaching following 
call stack trace!)
INFO -
INFO - (Python 3.11.5 on win32) Traceback (most recent call last):
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
2692, in Main
INFO - MyBuild = Build(Target, Workspace, Option,LogQ)
INFO -   ^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
815, in __init__
INFO - self.InitPreBuild()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
1015, in InitPreBuild
INFO - self.LoadConfiguration()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
971, in LoadConfiguration
INFO - self.GetToolChainAndFamilyFromDsc (self.PlatformFile)
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
905, in GetToolChainAndFamilyFromDsc
INFO - dscobj = self.BuildDatabase[File, BuildArch]
INFO -  ~~^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\WorkspaceDatabase.py",
 line 104, in __getitem__
INFO - BuildObject = self.CreateBuildObject(FilePath, Arch, Target, 
Toolchain)
INFO -   
^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\WorkspaceDatabase.py",
 line 125, in CreateBuildObject
INFO - BuildObject = self._GENERATOR_[FileType](
INFO -   ^^^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 231, in __init__
INFO - self.SkuIdMgr = SkuClass(self.SkuName, self.SkuIds)
INFO -  
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 510, in SkuName
INFO - self._GetHeaderInfo()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 310, in _GetHeaderInfo
INFO - RecordList = self._RawData[MODEL_META_DATA_HEADER, self._Arch]
INFO -  ~
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 250, in __getitem__
INFO - self._PostProcess()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 1429, in _PostProcess
INFO - Processer[self._ItemType]()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 1609, in __ProcessDirective
INFO - __IncludeMacros['WORKSPACE'] = Glo

Re: [edk2-devel] BaseTools KeyError When Building EmulatorPkg

[Sean]

We are looking at it.

It seems to be a problem in the edk2-basetools but at this point it 
still isn't obvious.


You can do a 'pip uninstall edk2-basetools' and then I would expect your 
build would work.


I also see that you didn't build edk2 basetools (step 6) documented 
here: edk2/EmulatorPkg/PlatformCI at master · tianocore/edk2 
(github.com) 
<https://github.com/tianocore/edk2/tree/master/EmulatorPkg/PlatformCI>.  
Without doing that your build will fail as well.



The CI system is building fine so we are still looking into it.

I'll update the thread when we have more info.


Thanks

Sean



On 11/21/2023 8:22 AM, Laszlo Ersek wrote:

Adding Sean

Laszlo

On 11/19/23 23:43, ryderkeys via groups.io wrote:

Hi all,

I am trying to build EDK2 from most recent Github (namely, EmulatorPkg) with 
the new Stuart build system on Windows 10 22H2 64 bit with VS 2019. I'm getting 
the following error which directed me to this mailing list. More details on my 
build process below.

INFO - build.py...
INFO -  : error C0DE: Unknown fatal error when processing 
[c:\users\ryder\edk2_2023\edk2\EmulatorPkg\EmulatorPkg.dsc]
INFO -
INFO - (Please send email tode...@edk2.groups.io  for help, attaching following 
call stack trace!)
INFO -
INFO - (Python 3.11.5 on win32) Traceback (most recent call last):
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
2692, in Main
INFO - MyBuild = Build(Target, Workspace, Option,LogQ)
INFO -   ^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
815, in __init__
INFO - self.InitPreBuild()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
1015, in InitPreBuild
INFO - self.LoadConfiguration()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
971, in LoadConfiguration
INFO - self.GetToolChainAndFamilyFromDsc (self.PlatformFile)
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\BaseTools\Source\Python\build\build.py", line 
905, in GetToolChainAndFamilyFromDsc
INFO - dscobj = self.BuildDatabase[File, BuildArch]
INFO -  ~~^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\WorkspaceDatabase.py",
 line 104, in __getitem__
INFO - BuildObject = self.CreateBuildObject(FilePath, Arch, Target, 
Toolchain)
INFO -   
^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\WorkspaceDatabase.py",
 line 125, in CreateBuildObject
INFO - BuildObject = self._GENERATOR_[FileType](
INFO -   ^^^
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 231, in __init__
INFO - self.SkuIdMgr = SkuClass(self.SkuName, self.SkuIds)
INFO -  
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 510, in SkuName
INFO - self._GetHeaderInfo()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\DscBuildData.py",
 line 310, in _GetHeaderInfo
INFO - RecordList = self._RawData[MODEL_META_DATA_HEADER, self._Arch]
INFO -  ~
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 250, in __getitem__
INFO - self._PostProcess()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 1429, in _PostProcess
INFO - Processer[self._ItemType]()
INFO -   File 
"C:\Users\ryder\edk2_2023\edk2\.venv\Lib\site-packages\edk2basetools\Workspace\MetaFileParser.py",
 line 1609, in __ProcessDirective
INFO - __IncludeMacros['WORKSPACE'] = GlobalData.gGlobalDefines['WORKSPACE']
INFO -~^
INFO - KeyError: 'WORKSPACE'

I followed the directions 
on<https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart>  
and<https://github.com/tianocore/edk2/tree/master/EmulatorPkg/PlatformCI>. Are these 
the correct set of instructions to follow? If so, I entered the following commands and 
received the error above.

git clonehttps://github.com/tianocore/edk2.git
cd edk2
python -m venv .venv
.\.venv\Scripts\Activate.ps1
stuart_setup -c EmulatorPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAG=VS2019 
-a X64
stuart_update -c EmulatorPkg/PlatformCI/PlatformBuild.py TOOL_CHAIN_TAG=VS2019 
-a X64
stuart_build -c EmulatorPkg/Platf

Re: [edk2-devel] [PATCH v1 1/3] .pytool/UncrustifyCheck: Update to 73.0.8

[Sean]

Reviewed-by: Sean Brogan 


From: devel@edk2.groups.io  on behalf of Michael Kubacki 

Sent: Tuesday, November 14, 2023 12:22:24 PM
To: devel@edk2.groups.io 
Cc: Sean Brogan ; Michael Kubacki 
; Michael D Kinney ; 
Liming Gao 
Subject: [edk2-devel] [PATCH v1 1/3] .pytool/UncrustifyCheck: Update to 73.0.8

From: Michael Kubacki 

Updates to the latest release.

- Includes a fix for preventing endless indentation in struct
  assignment.
- Include Windows Arm, Linux Arm, and Mac OS builds.

Cc: Sean Brogan 
Cc: Michael Kubacki 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Michael Kubacki 
---
 .pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml 
b/.pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml
index d8c22403b4b1..74f3ffe41acf 100644
--- a/.pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml
+++ b/.pytool/Plugin/UncrustifyCheck/uncrustify_ext_dep.yaml
@@ -10,7 +10,7 @@
   "type": "nuget",
   "name": "mu-uncrustify-release",
   "source": 
"https://pkgs.dev.azure.com/projectmu/Uncrustify/_packaging/mu_uncrustify/nuget/v3/index.json;,
-  "version": "73.0.3",
+  "version": "73.0.8",
   "flags": ["set_shell_var", "host_specific"],
   "var_name": "UNCRUSTIFY_CI_PATH"
 }
--
2.42.0.windows.2



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111216): https://edk2.groups.io/g/devel/message/111216
Mute This Topic: https://groups.io/mt/102591691/1686594
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [spbro...@outlook.com]
-=-=-=-=-=-=




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

Re: [edk2-devel] [PATCH v4 0/8] Use CodeQL CLI

[Sean]

for the series

Reviewed-by: Sean Brogan 

Thanks

Sean

On 11/2/2023 1:03 PM, Michael Kubacki wrote:

From: Michael Kubacki 

CodeQL currently runs via the codeql-analysis.yml GitHub workflow
which uses the github/codeql-action/init@v2 action (pre-build)
and the github/codeql-action/analyze@v2 action (post-build) to
setup the CodeQL environment and extract results.

This infrastructure is removed in preparation for a new design that
will directly run the CodeQL CLI as part of the build. This will
allow CodeQL to be run locally as part of the normal build process
with results that match 1:1 with CI builds.

The CodeQL CLI design is automatically driven by a set of CodeQL
plugins:

   1. `CodeQlBuildPlugin` - Used to produce a CodeQL database from a
   build.
   2. `CodeQlAnalyzePlugin` - Used to analyze a CodeQL database.

This approach offers the following advantages:

   1. Provides exactly the same results locally as on a CI server.
   2. Integrates very well into IDEs such as VS Code.
   3. Very simple to use - just use normal Stuart update and build
  commands.
   4. Very simple to understand - minimally wraps the official CodeQL
  CLI.
   5. Very simple to integrate - works like any other Stuart build
  plugin.
   6. Portable - not tied to Azure DevOps specific, GitHub specific,
  or other host infrastructure.
   7. Versioned - the query and filters are versioned in source
  control so easy to find and track.

The appropriate CodeQL CLI is downloaded for the host OS by passing
the `--codeql` argument to the update command.

   `stuart_update -c .pytool/CISettings.py --codeql`

After that, CodeQL can be run in a build by similarly passing the
`--codeql` argument to the build command. For example:

   `stuart_ci_build -c .pytool/CISettings.py --codeql`

Going forward, CI will simply use those commands in CodeQL builds
to get results instead of the CodeQL GitHub actions.

When `--codeql` is specified in the build command, each package will
contain two main artifacts in the Build directory.

   1. The CodeQL database for the package
   2. The CodeQL SARIF (result) file for the package

The CodeQL database (1) can be used to run queries against without
rebuilding any code. The SARIF result file (2) is the result of
running enabled queries against the database.

SARIF stands for Static Analysis Results Interchange Format and it
is an industry standard format for output from static analysis tools.

https://sarifweb.azurewebsites.net/

The SARIF file can be opened with any standard SARIF file viewer
such as this one for VS Code:

https://marketplace.visualstudio.com/items?itemName=MS-SarifVSCode.sarif-viewer

That includes the ability to jump directly to issues in the source
code file with relevant code highlighted and suggestions included.

This means that after simply adding `--codeql` to the normal build
commands, a database will be present for future querying and a SARIF
result file will be present to allow the developer to immediately
start fixing issues.

More details about the location of these and usage is in the
BaseTools/Plugin/CodeQL/Readme.md included in this patch series.

The CI process pushes the SARIF file to GitHub Code Scanning so the
results are generated exactly the same way they are locally.

All build logs and the SARIF file for each package are uploaded to
the GitHub action run as artifacts. If a CodeQL issue is found, a
developer can download the SARIF file directly from the GitHub action
run to fix the problem without needing to rebuild locally.

An example run of these changes showing the packages built and output
logs and SARIF files is available here:

https://github.com/tianocore/edk2/actions/runs/6317077528

The series enables a new set of CodeQL queries that helps find useful
issues in the codebase. So, new CodeQL results will appear in the edk2
GitHub Code Scanning area after the change. It is expected that the
community will work together to prioritize and resolve issues to improve
the quality of the codebase.

V4 changes:

1. BaseTools/Plugin/CodeQL/analyze - Remove BSD-2-Clause Plus Patent
license. Drop Microsoft copyright. Clean up the licensing header
so its easier to read and follows the declaration provided in
https://www.apache.org/licenses/LICENSE-2.0.
2. Add a new patch to add the "analyze" directory under the list of
paths in the project with an acceptable but different license
than BSD-2-Clause Plus Patent.

V3 changes:

1. Add a "Resolution Guidelines" section to the CodeQL plugin readme
file based on feedback in the October 16, 2023 Tianocore Tools &
CI meeting to capture some notes useful in solving issues in the
file.

V2 Changes:

1. Enable CodeQL audit mode. This is because a new patch also enables
queries that will result in unresolved issues so audit mode is needed
for the build to succeed.
2. Enable new CodeQL queries. This will enable new CodeQL queries so the
i

Re: [edk2-devel] [PATCH v4 6/8] .pytool/CISettings: Enable CodeQL audit mode

[Sean]

Reviewed-by: Sean Brogan 

On 11/2/2023 1:03 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Since a large number of CodeQL queries are being enabled to identify
issues that the community can collectively resolve, audit mode needs to
be enabled to prevent the build from failing.

In the future, this global audit mode can be disabled and individual
packages can enable/disable audit mode in their package CI YAML file
using the instructions in the CodeQL plugin readme.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Michael Kubacki 
Acked-by: Michael D Kinney 
---
  .pytool/CISettings.py | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/.pytool/CISettings.py b/.pytool/CISettings.py
index b8b8080439c1..ec3beb0dcf9d 100644
--- a/.pytool/CISettings.py
+++ b/.pytool/CISettings.py
@@ -196,6 +196,12 @@ class Settings(CiBuildSettingsManager, 
UpdateSettingsManager, SetupSettingsManag
  
  try:

  scopes += codeql_helpers.get_scopes(self.codeql)
+
+if self.codeql:
+shell_environment.GetBuildVars().SetValue(
+"STUART_CODEQL_AUDIT_ONLY",
+"TRUE",
+"Set in CISettings.py")
  except NameError:
  pass
  



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

Re: [edk2-devel] [PATCH v4 7/8] BaseTools/Plugin/CodeQL: Enable 30 queries

[Sean]

Reviewed-by: Sean Brogan 

On 11/2/2023 1:03 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Updates the CodeQL queries opted into by edk2 to a set of queries from
the standard CodeQL query package `codeql/cpp-queries`.

After testing a large number of queries the included set here were
found to be the most useful with the least number of false positives.
Some queries had a number of issues that led to them being placed on
the exclusion list so that they are not considered in the future
without the notes there being taken into account.

General details about queries available in the pack are available here:
https://codeql.github.com/codeql-query-help/cpp/

The issues found by these queries will need to be fixed over time. In
the meantime, the results will show to those that have permission in
the repo's GitHub Code Scanning area. The build will not fail due to
CodeQL issues (since they are not all fixed) but that can be enabled in
the future.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Rebecca Cran 
Cc: Sean Brogan 
Cc: Yuwei Chen 
Signed-off-by: Michael Kubacki 
Acked-by: Michael D Kinney 
---
  BaseTools/Plugin/CodeQL/CodeQlQueries.qls | 57 +---
  1 file changed, 50 insertions(+), 7 deletions(-)

diff --git a/BaseTools/Plugin/CodeQL/CodeQlQueries.qls 
b/BaseTools/Plugin/CodeQL/CodeQlQueries.qls
index 3f97bcd583d5..1a5098322193 100644
--- a/BaseTools/Plugin/CodeQL/CodeQlQueries.qls
+++ b/BaseTools/Plugin/CodeQL/CodeQlQueries.qls
@@ -8,28 +8,71 @@
  # Queries
  
##
  
-## Enable When Time is Available to Fix Issues

-# Hundreds of issues. Most appear valid. Type: Recommendation.
-#- include:
-#id: cpp/missing-null-test
-
  ## Errors
  - include:
-id: cpp/overrunning-write
+id: cpp/badoverflowguard
  - include:
-id: cpp/overrunning-write-with-float
+id: cpp/infiniteloop
+- include:
+id: 
cpp/likely-bugs/memory-management/v2/conditionally-uninitialized-variable
+- include:
+id: cpp/missing-null-test
+- include:
+id: cpp/missing-return
+- include:
+id: cpp/no-space-for-terminator
  - include:
  id: cpp/pointer-overflow-check
+- include:
+id: cpp/redundant-null-check-simple
+- include:
+id: cpp/sizeof/const-int-argument
+- include:
+id: cpp/sizeof/sizeof-or-operation-as-argument
+- include:
+id: cpp/unguardednullreturndereferenc
  - include:
  id: cpp/very-likely-overrunning-write
  
  ## Warnings

+- include:
+id: cpp/comparison-with-wider-type
  - include:
  id: cpp/conditionallyuninitializedvariable
+- include:
+id: cpp/comparison-precedence
+- include:
+id: cpp/implicit-bitfield-downcast
  - include:
  id: cpp/infinite-loop-with-unsatisfiable-exit-condition
+- include:
+id: cpp/offset-use-before-range-check
  - include:
  id: cpp/overflow-buffer
+- include:
+id: cpp/overflow-calculated
+- include:
+id: cpp/overflow-destination
+- include:
+id: cpp/paddingbyteinformationdisclosure
+- include:
+id: cpp/return-stack-allocated-memory
+- include:
+id: cpp/static-buffer-overflow
+- include:
+id: cpp/unsigned-comparison-zero
+- include:
+id: cpp/uselesstest
+
+## Recommendations
+- include:
+id: cpp/missing-header-guard
+- include:
+id: cpp/unused-local-variable
+- include:
+id: cpp/unused-static-function
+- include:
+id: cpp/unused-static-variable
  
  # Note: Some queries above are not active by default with the below filter.

  #   Update the filter and run the queries again to get all results.



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

Re: [edk2-devel] [PATCH v1 0/2] Fix Python minor version

[Sean]

for the series

Reviewed-by: Sean Brogan 

On 10/6/2023 4:10 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Python 3.12 released recently. The Python version is currently
specified to allow updates to newer minor versions. Time is
needed to adjust scripts for Python 3.12 so this series fixes
the Python version to 3.11.

Some places that were already fixed but need the version updated
to 3.11 for consistency are updated as well.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
   .azurepipelines: Fix Python version (to 3.11)
   .github: Fix Python version (to 3.11)

  .azurepipelines/Ubuntu-PatchCheck.yml  | 2 +-
  .azurepipelines/templates/defaults.yml | 2 +-
  .github/workflows/codeql-analysis.yml  | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)




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

Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg: Enable Early Serial For DxeCore

[Sean]

On 9/7/2023 1:54 PM, Laszlo Ersek wrote:

On 9/7/23 19:50, Sean Brogan wrote:

I would argue that by declaring that your library class supports type
DXE_CORE (or any core type) that you have declared you understand the
uniqueness of the environment and have accounted for it.

For instances that support DXE_CORE or MM_CORE module types we often use
a global variable (to the library) to determine if the init routine has
been completed.  This does require a single byte check on each serial
message write (hot path) but given all the code on that path this is not
noticeable in performance measurements.   In the case below this pattern
could be used by the FdtPL011SerialPortLib to detect if it's init
routine has been called.

Good point, but then I still claim that the "init check in each API"
should be done in a dedicated "DxeCoreDebugLibSerialPort" instance, and
not in a SerialPortLib instance. Here's why:

(1) The SerialPortLib *class* requires SerialPortInitialize() to be
called before the other APIs.


Where do you see this? Looking at the file here: 
edk2/MdePkg/Include/Library/SerialPortLib.h at master · tianocore/edk2 
(github.com) 
<https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/SerialPortLib.h> 
I don't see that.  I don't necessarily disagree with you but I am just 
trying to find out where this is documented.




  The FdtPL011SerialPortLib instance does
nothing in its implementation of that function, because it relies on the
constructor doing the same work. Therefore I agree that
FdtPL011SerialPortLib is not suitable for DXE_CORE, and I would suggest
removing DXE_CORE from LIBRARY_CLASS in the INF file, after the pipe
sign ("|").

Agree


(2) A new SerialPortLib instance should be added, very similar to
FdtPL011SerialPortLib -- the difference should be that it should have no
constructor, and the same job should be done in SerialPortInitialize().
This library instance sould be suitable for *direct use* in DXE_CORE
(and should likely be restricted to DXE_CORE exclusively).

The reason for that is the following. The DXE Core is entitled to
consume a lib instance without calling its constructor, in case the lib
instance declares itself DXE_CORE-capable (this is your argument). (In
fact such a lib instance is not supposed to have a constructor at all --
it might not be called anyway.) However, the DXE Core is *not* entitled
to ignore library *class* restrictions, and an explicit call to
SerialPortInitialize() is required by the SerialPortLib *class*. IOW, if
the DXE Core ever wanted to use SerialPortLib *directly*, it would have
to call SerialPortInitialize() before calling the other SerialPortLib
APIs, regardless of where and when the DXE Core ran the library
constructor list.

So that's why such a new FdtPL011SerialPortLib variant would be proper
for DXE_CORE.

(3) In turn, the new DxeCoreDebugLibSerialPort instance -- which would
have no constructor -- would be responsible for tracking in each API
implementation whether SerialPortInitialize() had been called before.

Agree


(4) This also means that the current BaseDebugLibSerialPort in MdePkg is
unsuitable for DXE_CORE usage, and so its LIBRARY_CLASS module type list
should be made explicit -- it should *exclude* the DXE_CORE. Even though
BaseDebugLibSerialPort has a BASE type entry point, this lib instance
relies on having a constructor (where it calls SerialPortInitialize()!),
and that rules it out for DXE_CORE usage.

Agree



IOW, I agree with you; my point is only that the serial init tracking
belongs in a new DebugLib instance (because, at the *class* level,
DebugLib permits the DXE_CORE to call its APIs in any order; whereas
SerialPortLib requires SerialPortInitialize() to be called first, also
at the *class* level).

Laszlo

Just for discussions sake you could also imagine a solution where the 
"base" instance does init tracking and then a new library instance is 
used only for XIP PEI that executes from RO memory (flash or 
otherwise).   Also note that this isn't just a DXE_CORE problem.  SEC, 
PEI_CORE, MM_CORE_STANDALONE and SMM_CORE types may have these similar 
restrictions.



Thanks

Sean



On 9/7/2023 8:24 AM, Oliver Smith-Denny wrote:

On 9/7/2023 6:10 AM, Laszlo Ersek wrote:

(replying on the webui... sorry!)

The problem is actually embedded in MdePkg and MdeModulePkg.

- In DxeMain() (and in functions called by DxeMain()), we call
DebugLib APIs *before* reaching ProcessLibraryConstructorList().

- In ArmVirtQemu, we resolve the DXE Core's DebugLib dependency to
BaseDebugLibSerialPort (from MdePkg).

- BaseDebugLibSerialPort has a constructor function
(BaseDebugLibSerialPortConstructor()).

These already suffice for broken DebugLib behavior. APIs of a library
class should not be called because the library instance has a chance
to initialize.

The rest is circumstantial. Like, BaseDebugLibSerialPortConstructor
calls SerialPortInitialize, but our SerialPortInit

Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg: Enable Early Serial For DxeCore

[Sean]

I would argue that by declaring that your library class supports type 
DXE_CORE (or any core type) that you have declared you understand the 
uniqueness of the environment and have accounted for it.


For instances that support DXE_CORE or MM_CORE module types we often use 
a global variable (to the library) to determine if the init routine has 
been completed.  This does require a single byte check on each serial 
message write (hot path) but given all the code on that path this is not 
noticeable in performance measurements.   In the case below this pattern 
could be used by the FdtPL011SerialPortLib to detect if it's init 
routine has been called.


Thanks

Sean


On 9/7/2023 8:24 AM, Oliver Smith-Denny wrote:

On 9/7/2023 6:10 AM, Laszlo Ersek wrote:

(replying on the webui... sorry!)

The problem is actually embedded in MdePkg and MdeModulePkg.

- In DxeMain() (and in functions called by DxeMain()), we call 
DebugLib APIs *before* reaching ProcessLibraryConstructorList().


- In ArmVirtQemu, we resolve the DXE Core's DebugLib dependency to 
BaseDebugLibSerialPort (from MdePkg).


- BaseDebugLibSerialPort has a constructor function 
(BaseDebugLibSerialPortConstructor()).


These already suffice for broken DebugLib behavior. APIs of a library 
class should not be called because the library instance has a chance 
to initialize.


The rest is circumstantial. Like, BaseDebugLibSerialPortConstructor 
calls SerialPortInitialize, but our SerialPortInitialize (in 
FdtPL011SerialPortLib) does nothing. Well, the latter doesn't need to 
do anything, because FdtPL011SerialPortLib has its own constructor 
(FdtPL011SerialPortLibInitialize), thus, if constructors were called 
properly, then BaseDebugLibSerialPort + FdtPL011SerialPortLib would 
work properly together, regardless of SerialPortInitialize being 
empty in the latter.


Basically the DXE Core has a hidden requirement -- it can only use 
such DebugLib instances that need no explicit initialization.


The proposed patch works around the problem by satisfying that hidden 
requirement one level lower down: in the SerialPortLib instance. The 
initialization of BaseDebugLibSerialPort is still busted (its 
constructor is not called, so it cannot call SerialPortInitialize 
either), but now it is masked, because EarlyFdtPL011SerialPortLib 
works withouth *both* SerialPortInitialize and construction.


The real fix would be to make the DXE Core requirement explicit, by 
introducing separate (dedicated) DebugLib and SerialPortLib *classes* 
(whose APIs are guaranteed to work without initialization).


Laszlo


Thanks for the comprehensive breakdown! :). I completely agree that
fixing this at the upper level (and ideally documenting this
requirement) is the better move.

I can drop this patch and take a crack at that. I'm in the last few
weeks leading up to an extended parental leave, so we'll see if I can
squeeze it in prior to then :).

Oliver








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

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Sean]

The breaking change would be in the future to move/make these structural 
changes (package /repo)  in the future after checking in this patch.


Thanks

Sean


On 8/31/2023 11:45 AM, Michael D Kinney wrote:


How is the current patch set a breaking change?

Mike

*From:* Sean Brogan 
*Sent:* Thursday, August 31, 2023 10:52 AM
*To:* devel@edk2.groups.io; Kinney, Michael D 
; Yao, Jiewen ; Leif 
Lindholm ; Hou, Wenxing 

*Cc:* af...@apple.com
*Subject:* Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add 
HMAC/HKDF/RSA/HASH features based on Mbedtls ***


replying to the whole chain.

I am not encouraging importing the source directly but still trying to 
isolate the "wrapper code" and the external mbedtls submodule management.


I am advocating that the underlying crypto implementation is 100% 
"hidden" from public include/dependency and the rest of the edk2 
tree.  I am advocating that crypto "releases" are in essence 
independent of Edk2 stable tags (obviously a stable tag would still 
have reference to version tested at that time) because crypto needs to 
be updated more quickly and regularly and should have very minimal 
breaking dependencies.


Regarding Jiewen's options for layout my proposal would be more like 
option 5.  :)


Tianocore/Edk2: CryptoPkg

  * Header files for the crypto api of edk2(protocol, ppi, pcd,
library definitions).
  * Modules that are underlying crypto library independent.
  * Null libraries that support compile test of edk2 CI

Tianocore/MbedTlsRepo: MbedTlsCryptoPkg

  * No public header files for consumption outside package.
  * Wrapper code and modules to support edk2 crypto using mbedtls library.
  * submodule tracking info for mbedtls upstream project
  * tests
  * release notes
  * Security vulnerability management for mbedtls based work

Tianocore/OpenSslRepo: OpenSslCryptoPkg

  * No public header files for consumption outside package.
  * Wrapper code and modules to support edk2 crypto using openssl library.
  * submodule tracking info for openssl upstream project
  * tests
  * release notes
  * Security vulnerability management for OpenSSL based work

I hope that helps explain.

Regarding checking in and then moving later...well i am skeptical.  
This is a breaking change and once dependencies are formed, edk2 has 
historically had challenges in making these kinds of changes.


Thanks for consideration.

Sean

On 8/31/2023 10:24 AM, Michael D Kinney wrote:

Jiewen,

Thanks.  Option #1 makes more sense if it is the Mbedtls

wrapper code.

I prefer Option #1.

Breaking out into multiple repos also makes it hard to align

Releases across multiple repos.  We already have this as an

unsolved problem for edk2-platforms repo, and I am not interested

in adding more repos until we have a complete solution to do

edk2-platforms releases in place.

Mike

-Original Message-

From: Yao, Jiewen  <mailto:jiewen@intel.com>

Sent: Thursday, August 31, 2023 9:07 AM

To: Kinney, Michael D  
<mailto:michael.d.kin...@intel.com>; Leif Lindholm

  
<mailto:quic_llind...@quicinc.com>;devel@edk2.groups.io;spbro...@outlook.com;

Hou, Wenxing  <mailto:wenxing@intel.com>

Cc:af...@apple.com

Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add

HMAC/HKDF/RSA/HASH features based on Mbedtls ***

Hi Mike

We are using submodule for mbedtls in this patch. Copying source code is

not preferred.

I think we are discussing multiple ways to layout the *mbedtls crypto

wrapper*. See following 4 options.

Thank you

Yao, Jiewen

-Original Message-

From: Kinney, Michael D  
<mailto:michael.d.kin...@intel.com>

Sent: Thursday, August 31, 2023 11:45 PM

To: Leif Lindholm  
<mailto:quic_llind...@quicinc.com>; Yao, Jiewen

  
<mailto:jiewen@intel.com>;devel@edk2.groups.io;spbro...@outlook.com;

Hou,

Wenxing  <mailto:wenxing@intel.com>

Cc:af...@apple.com; Kinney, Michael D  
<mailto:michael.d.kin...@intel.com>

Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add

HMAC/HKDF/RSA/HASH features based on Mbedtls ***

I have not looked at the Mbedtls patches in detail yet, but I

am curious if it is possible to add the mbedtls based library

instances of the edk2 crypto libraries to the existing

CryptoPkg and pull the mbedtls sources into the CryptoPkg using

a submodule just like openssl?  This way, platforms can choose

either openssl or mbedtls library instances from CryptoPkg and

all INFs would continue to only list CryptoPkg.dec.

I think use of submodules makes the most sense for conten

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Sean]

replying to the whole chain.

I am not encouraging importing the source directly but still trying to 
isolate the "wrapper code" and the external mbedtls submodule management.


I am advocating that the underlying crypto implementation is 100% 
"hidden" from public include/dependency and the rest of the edk2 tree.  
I am advocating that crypto "releases" are in essence independent of 
Edk2 stable tags (obviously a stable tag would still have reference to 
version tested at that time) because crypto needs to be updated more 
quickly and regularly and should have very minimal breaking dependencies.


Regarding Jiewen's options for layout my proposal would be more like 
option 5.  :)


Tianocore/Edk2: CryptoPkg

 * Header files for the crypto api of edk2(protocol, ppi, pcd, library
   definitions).
 * Modules that are underlying crypto library independent.
 * Null libraries that support compile test of edk2 CI

Tianocore/MbedTlsRepo: MbedTlsCryptoPkg

 * No public header files for consumption outside package.
 * Wrapper code and modules to support edk2 crypto using mbedtls library.
 * submodule tracking info for mbedtls upstream project
 * tests
 * release notes
 * Security vulnerability management for mbedtls based work

Tianocore/OpenSslRepo: OpenSslCryptoPkg

 * No public header files for consumption outside package.
 * Wrapper code and modules to support edk2 crypto using openssl library.
 * submodule tracking info for openssl upstream project
 * tests
 * release notes
 * Security vulnerability management for OpenSSL based work


I hope that helps explain.

Regarding checking in and then moving later...well i am skeptical.  This 
is a breaking change and once dependencies are formed, edk2 has 
historically had challenges in making these kinds of changes.


Thanks for consideration.

Sean




On 8/31/2023 10:24 AM, Michael D Kinney wrote:

Jiewen,

Thanks.  Option #1 makes more sense if it is the Mbedtls
wrapper code.

I prefer Option #1.

Breaking out into multiple repos also makes it hard to align
Releases across multiple repos.  We already have this as an
unsolved problem for edk2-platforms repo, and I am not interested
in adding more repos until we have a complete solution to do
edk2-platforms releases in place.

Mike


-Original Message-
From: Yao, Jiewen
Sent: Thursday, August 31, 2023 9:07 AM
To: Kinney, Michael D; Leif Lindholm
;devel@edk2.groups.io;spbro...@outlook.com;
Hou, Wenxing
Cc:af...@apple.com
Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
HMAC/HKDF/RSA/HASH features based on Mbedtls ***

Hi Mike
We are using submodule for mbedtls in this patch. Copying source code is
not preferred.

I think we are discussing multiple ways to layout the *mbedtls crypto
wrapper*. See following 4 options.

Thank you
Yao, Jiewen



-Original Message-
From: Kinney, Michael D
Sent: Thursday, August 31, 2023 11:45 PM
To: Leif Lindholm; Yao, Jiewen
;devel@edk2.groups.io;spbro...@outlook.com;

Hou,

Wenxing
Cc:af...@apple.com; Kinney, Michael D
Subject: RE: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
HMAC/HKDF/RSA/HASH features based on Mbedtls ***

I have not looked at the Mbedtls patches in detail yet, but I
am curious if it is possible to add the mbedtls based library
instances of the edk2 crypto libraries to the existing
CryptoPkg and pull the mbedtls sources into the CryptoPkg using
a submodule just like openssl?  This way, platforms can choose
either openssl or mbedtls library instances from CryptoPkg and
all INFs would continue to only list CryptoPkg.dec.

I think use of submodules makes the most sense for content that
edk2 consumes as read-only and edk2 makes decisions to jump from
one validated release to the next validated release of the submodule
content.

In general, we do not want to copy source from a different project
into TianoCore repos because of the overhead to keep them in sync.
An exception to this is something like cmocka where this was done
for CI stability issues and the copy in TianoCore is an automated
sync of the upstream repo.

Thanks,

Mike



-Original Message-
From: Leif Lindholm
Sent: Thursday, August 31, 2023 4:15 AM
To: Yao, Jiewen;devel@edk2.groups.io;
spbro...@outlook.com; Hou, Wenxing
Cc:af...@apple.com; Kinney, Michael D
Subject: Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add
HMAC/HKDF/RSA/HASH features based on Mbedtls ***

Like Sean, I'm very positive to the work - and I'm excited about the
opportunity to formalise the abstractions.

But Sean is also asking to import the mbedTLS code outright instead

of

using submodules, which adds an additional dimension to the matrix

below.

I'm not too concerned over the infrastructure change as such, but I
would prefer to not move the dial even further in the direction of
"upstream is a swarm of repositories". This adds complexity for new
developers. And submodules are way easier for upstream to track

external

projects through. At the cost

Re: [edk2-devel] [edk2/add_mbedtls PATCH 0/9] *** Add HMAC/HKDF/RSA/HASH features based on Mbedtls ***

[Sean]

I appreciate and really like this work to enable mbedtls but I don't 
like the idea of adding another submodule to edk2.


For a long time there has been discussion about formalizing the 
abstraction of the edk2 crypto api so that it would be practical to 
implement edk2's crypto using various libraries.   I propose we remove 
openssl from the edk2 CryptoPkg and into the OpenSslCryptoPkg in another 
new tianocore repository dedicated to OpenSsl.  MbedTls could then be 
checked into the MbedTlsCryptoPkg and added to another new repository.  
This would also have the benefit of breaking the tight coupling of edk2 
stable tags from the crypto used in the code base (crypto has more 
widely tracked vulnerabilities).


Happy to discuss more if others have different ideas.

Thanks

Sean



On 8/30/2023 12:52 AM, Wenxing Hou wrote:

*** Add BaseCryptLibMbedTls for CryptoPkg, which can be an alternative to 
OpenSSL in some scenarios. There are four features in the patch: 
HMAC/HKDF/RSA/HASH.***

Wenxing Hou (9):
   CryptoPkg: Add mbedtls submodule for EDKII
   CryptoPkg: Add mbedtls_config and MbedTlsLib.inf
   CryptoPkg: Add HMAC functions based on Mbedtls
   CryptoPkg: Add HKDF functions based on Mbedtls
   CryptoPkg: Add RSA functions based on Mbedtls
   CryptoPkg: Add all .inf files for BaseCryptLibMbedTls
   CryptoPkg: Add Null functions for building pass
   CryptoPkg: Add MD5/SHA1/SHA2 functions based on Mbedtls
   CryptoPkg: Add Mbedtls submodule in CI

  .gitmodules   |3 +
  .pytool/CISettings.py |2 +
  CryptoPkg/CryptoPkg.ci.yaml   |   66 +-
  CryptoPkg/CryptoPkg.dec   |4 +
  CryptoPkg/CryptoPkgMbedTls.dsc|  280 ++
  .../BaseCryptLibMbedTls/BaseCryptLib.inf  |   81 +
  .../BaseCryptLibMbedTls/Bn/CryptBnNull.c  |  520 +++
  .../Cipher/CryptAeadAesGcmNull.c  |  100 +
  .../BaseCryptLibMbedTls/Cipher/CryptAesNull.c |  159 +
  .../BaseCryptLibMbedTls/Hash/CryptMd5.c   |  234 +
  .../BaseCryptLibMbedTls/Hash/CryptMd5Null.c   |  163 +
  .../Hash/CryptParallelHashNull.c  |   40 +
  .../BaseCryptLibMbedTls/Hash/CryptSha1.c  |  234 +
  .../BaseCryptLibMbedTls/Hash/CryptSha1Null.c  |  166 +
  .../BaseCryptLibMbedTls/Hash/CryptSha256.c|  227 +
  .../Hash/CryptSha256Null.c|  162 +
  .../BaseCryptLibMbedTls/Hash/CryptSha512.c|  447 ++
  .../Hash/CryptSha512Null.c|  275 ++
  .../BaseCryptLibMbedTls/Hash/CryptSm3Null.c   |  164 +
  .../BaseCryptLibMbedTls/Hmac/CryptHmac.c  |  620 +++
  .../BaseCryptLibMbedTls/Hmac/CryptHmacNull.c  |  359 ++
  .../BaseCryptLibMbedTls/InternalCryptLib.h|   44 +
  .../BaseCryptLibMbedTls/Kdf/CryptHkdf.c   |  372 ++
  .../BaseCryptLibMbedTls/Kdf/CryptHkdfNull.c   |  192 +
  .../BaseCryptLibMbedTls/PeiCryptLib.inf   |  101 +
  .../BaseCryptLibMbedTls/PeiCryptLib.uni   |   25 +
  .../BaseCryptLibMbedTls/Pem/CryptPemNull.c|   69 +
  .../Pk/CryptAuthenticodeNull.c|   45 +
  .../BaseCryptLibMbedTls/Pk/CryptDhNull.c  |  150 +
  .../BaseCryptLibMbedTls/Pk/CryptEcNull.c  |  578 +++
  .../Pk/CryptPkcs1OaepNull.c   |   51 +
  .../Pk/CryptPkcs5Pbkdf2Null.c |   48 +
  .../Pk/CryptPkcs7Internal.h   |   83 +
  .../Pk/CryptPkcs7SignNull.c   |   53 +
  .../Pk/CryptPkcs7VerifyEkuNull.c  |  152 +
  .../Pk/CryptPkcs7VerifyEkuRuntime.c   |   56 +
  .../Pk/CryptPkcs7VerifyNull.c |  163 +
  .../Pk/CryptPkcs7VerifyRuntime.c  |   38 +
  .../BaseCryptLibMbedTls/Pk/CryptRsaBasic.c|  268 ++
  .../Pk/CryptRsaBasicNull.c|  121 +
  .../BaseCryptLibMbedTls/Pk/CryptRsaExt.c  |  337 ++
  .../BaseCryptLibMbedTls/Pk/CryptRsaExtNull.c  |  117 +
  .../BaseCryptLibMbedTls/Pk/CryptRsaPss.c  |  164 +
  .../BaseCryptLibMbedTls/Pk/CryptRsaPssNull.c  |   46 +
  .../BaseCryptLibMbedTls/Pk/CryptRsaPssSign.c  |  231 +
  .../Pk/CryptRsaPssSignNull.c  |   60 +
  .../BaseCryptLibMbedTls/Pk/CryptTsNull.c  |   42 +
  .../BaseCryptLibMbedTls/Pk/CryptX509Null.c|  753 
  .../BaseCryptLibMbedTls/Rand/CryptRandNull.c  |   56 +
  .../BaseCryptLibMbedTls/RuntimeCryptLib.inf   |   92 +
  .../BaseCryptLibMbedTls/RuntimeCryptLib.uni   |   22 +
  .../BaseCryptLibMbedTls/SecCryptLib.inf   |   84 +
  .../BaseCryptLibMbedTls/SecCryptLib.uni   |   17 +
  .../BaseCryptLibMbedTls/SmmCryptLib.inf   |   92 +
  .../BaseCryptLibMbedTls/SmmCryptLib.uni   |   22 +
  .../SysCall/ConstantTimeClock.c   |   75 +
  .../BaseCryptLibMbedTls/SysCall/CrtWrapper.c  |   58 +
  .../SysCall/RuntimeMemAllocation.c|  462 ++
  .../SysCall/TimerWrapper.c|  198 +
  .../BaseCryptLibMbedTls/TestBaseCryptLib.inf  |   78 +
  CryptoPkg/Library/MbedTlsLib/CrtWrapper.c |   96 +
  CryptoPkg/Library

Re: [edk2-devel] 回复: [PATCH v1 00/24] Update Edk2-pytools to latest versions

[Sean]

Liming,


In general, due to feedback on this list we have tried to require 
explicit opt-in for all the stuart based validation tools.  So could 
that be done yes, but it goes against our current consistent approach of 
requiring opt-in and then would put the burden on a platform/package 
owner to opt-out if they didn't want this new functionality.



Thanks

Sean



On 6/26/2023 5:59 PM, gaoliming via groups.io wrote:

Joey:
   So, this change is required for all package YAML. If yes, can PrEval be
auto set to the package dsc if only one DSC is in Package directory?



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106526): https://edk2.groups.io/g/devel/message/106526
Mute This Topic: https://groups.io/mt/99801431/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] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL

[Sean]

I think that is an interesting idea but I would expect some push back 
from OS loader maintainers. I would expect they don't want to be 
constrained by the lowest common capabilities of the platforms they 
still support/run on in the ecosystem.   Not to mention the challenges 
around servicing and/or updating for bugs or features.


Example: Shim would not have been able to implement their version of 
SBAT in said scenario.


I know the Windows Boot team has been cautious about taking a dependency 
on the platform's UEFI and I would expect strong push back on them 
moving to using the platform's provided UEFI loader.


But I do agree with your goals.  Is there a better way using open 
source?  Could the PE loader/authenticode be a library managed as it's 
own project and be integrated into other pre-boot applications?   Would 
that help to eliminate bugs like this one and provide a better 
infrastructure to build on?


Thanks

Sean



On 6/23/2023 9:26 AM, Ard Biesheuvel wrote:

On Tue, 20 Jun 2023 at 19:07, Sean Brogan  wrote:

I don't think a MemoryAttributes2Protocol with a single API would have avoided 
the errors.

The programming pattern that triggered this would still need multiple calls to 
any API and in the future where all memory is allocated as NX this possibility 
would still exist.

A short term effort to minimize the compatibility problem in the ecosystem is 
documented here Memory Protections: Document compatibility challenges · Issue 
#18 · tianocore/projects (github.com)  It does not address (and i don't see any 
reason to try to) a loader that uses the protocol incorrectly.

We have provided virtual reference platforms with these features enabled (both arm and x86) and 
have been working with the relevant communities for multiple years now.  The UEFI CA for option 
roms already have compliance requirements (UPDATED: UEFI Signing Requirements - Microsoft Community 
Hub).  But there are and will continue to be compatibility challenges when enabling a more 
restrictive execution environment in uefi and the uefi ecosystem.  The more things we make optional 
the longer this transition period will take."Memory Mitigations" were proposed and 
mostly coded over a decade ago.  The code changes are not that difficult. To change our vast and 
unwieldy ecosystem is the hard part.   Please help to "stay the course" for this very 
necessary industry change.   If a production platform has requirements that force such a 
configuration option that is understandable but it is counter productive in open-source industry 
standard reference Edk2 code.


Fair enough.

But I will note that the only reason we are in this situation in the
first place is because shim has to re-implement the PE loader, cert
handling and all related crypto, and needs the memory attributes
protocol to manipulate the RO/NX permissions.

Now that we are taking these things seriously, wouldn't it be *much*
better to get rid of all this cruft, and specify a method by which a
loader can provide an ephemeral DB that the system firmware will
authenticate against? That way, we can reduce shim to a single
SetVariable() call that creates the ephemeral DB (and perhaps a call
into the TPM code to measure it), which is arguably a lot easier to
audit than the code we have today.



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

Re: [edk2-devel] Port C Tools to Python

[Sean]

This has moved over to https://github.com/tianocore/edk2-basetools/issues

I am sure any help you could offer would be appreciated.


Thanks
Sean

From: devel@edk2.groups.io  on behalf of Rebecca Cran 

Sent: Tuesday, June 20, 2023 6:25:21 PM
To: joe.hasselst...@icloud.com ; 
devel@edk2.groups.io 
Subject: Re: [edk2-devel] Port C Tools to Python

I believe someone is currently working on it.

—
Rebecca

On Tue, Jun 20, 2023, at 4:56 PM, joe.hasselst...@icloud.com wrote:
> Greetings,
>
> I was wondering if the wiki task "Port C Tools to Python” is still
> relevant for the EDK2 project and if so I’d like to start working on
> it. Any suggestions on getting started?
>
> Task description found at
> https://github.com/tianocore/tianocore.github.io/wiki/Tasks#port-c-tools-to-python
>
> … snip
> Large Projects
>
> Port C Tools to Python
>
> Port tools currently implemented in C to Python. This removes the need
> to run a C compiler to build the tools required to build EDK II
> firmware.
>
>  • Project Size: Large
>  • Difficulty: Hard
>  • Language: C, Python
>  • Mentor:
>  • Suggested by: @mdkinney <https://github.com/mdkinney>
> … end snip
>
> Thanks,
> - Joe







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106253): https://edk2.groups.io/g/devel/message/106253
Mute This Topic: https://groups.io/mt/99668359/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] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL

[Sean]

I don't think a MemoryAttributes2Protocol with a single API would have 
avoided the errors.


The programming pattern that triggered this would still need multiple 
calls to any API and in the future where all memory is allocated as NX 
this possibility would still exist.


A short term effort to minimize the compatibility problem in the 
ecosystem is documented here Memory Protections: Document compatibility 
challenges · Issue #18 · tianocore/projects (github.com) 
<https://github.com/tianocore/projects/issues/18>  It does not address 
(and i don't see any reason to try to) a loader that uses the protocol 
incorrectly.


We have provided virtual reference platforms with these features enabled 
(both arm and x86) and have been working with the relevant communities 
for multiple years now.  The UEFI CA for option roms already have 
compliance requirements (UPDATED: UEFI Signing Requirements - Microsoft 
Community Hub 
<https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916>).  
But there are and will continue to be compatibility challenges when 
enabling a more restrictive execution environment in uefi and the uefi 
ecosystem.  The more things we make optional the longer this transition 
period will take.    "Memory Mitigations" were proposed and mostly coded 
over a decade ago.  The code changes are not that difficult. To change 
our vast and unwieldyecosystem is the hard part.   Please help to "stay 
the course" for this very necessary industry change.   If a production 
platform has requirements that force such a configuration option that is 
understandable but it is counter productive in open-source industry 
standard reference Edk2 code.


Thanks

Sean




On 6/20/2023 9:03 AM, Gerd Hoffmann wrote:

On Tue, Jun 20, 2023 at 04:16:40PM +0300, Ard Biesheuvel wrote:

On Tue, Jun 20, 2023, 12:33 Gerd Hoffmann  wrote:


On Mon, Jun 19, 2023 at 10:32:25PM +0200, Oliver Steffen wrote:

Recent versions of shim (15.6 and 15.7) crash when the newly added
EFI_MEMORY_ATTRIBUTE_PROTOCOL is provided by the firmware.  To allow
existing installations to boot, provide a workaround in form of a Pcd
that allows tuning it off at build time (defaults to 'enabled').

Background:  We have untested + broken code for
EFI_MEMORY_ATTRIBUTE_PROTOCOL support in the listed shim releases.

Now that firmware starts to actually provide that protocol the
time bomb explodes.

Fantastic.

This is kind of a big deal, really, and just turning it off for ArmVirtQemu
does not help at all with the fact that these shim builds will crash on any
platform that implements the protocol. (Including x86)

Sure.  This hits VM firmware first because we quickly rebase our builds
to new edk2 stable tags.  But yes, this is not limited to VMs and
likewise not limited to arm.


Given that secure boot is kind of pointless on this particular platform
anyway, maybe this is a good opportunity to make shim optional in the boot
chain? I understand that this does not fix existing builds but shim proves
to be such a problematic component that you really should not be using it
if there is no need.

I'd love to ditch shim.efi, even with secure boot.  For VMs one can
just enroll the distro signing certificate to 'db' and be done with
it.

Unfortunately shim has a solid position being *the* entry point for
linux efi systems due to being the only piece of software carrying a
microsoft signature.  Especially on install media you can't really have
more than one (such as different binaries depending on whenever secure
boot is on or off).  For installed systems and cloud images shim also
creates/restores Boot entries.

Additional problem is that shim is the piece of software which handles
sbat revocations, so even in case the distro cert is enrolled in 'db' so
the certificate handling implemented by shim is not needed I can't just
ignore shim.efi.


As for the protocol, this has its own set of problems, and the bug in
question can partly be blamed on the misdesigned api, which has separate
set and clear methods. Not only does this force the implementation to
traverse the page tables twice for the common case of switching between RO
and XP or vice versa, it also means we lose any transactional properties of
a RO <-> XP switch. I.e., if we could make it the implementation's
responsibility to ensure that such a transformation either completes
successfully, or otherwise, doesn't make any modifications at all, the risk
of ending up in a limbo state is reduced significantly.

So maybe there is still opportunity for specifying a MemoryAttributes2
protocol with a single method for set and clear? We could just drop the
current one in that case.

Sounds reasonable to me.


In any case, while i can see how this patch helps make all your ci status
icons turn green again, it does so by papering over the underlying issue so
I'm not a fan.

Yes.  It's not a solution, it's a wor

Re: [edk2-devel] [PATCH 2/2] UefiCpuPkg/CpuMpPei X64: Reallocate page tables in permanent DRAM

[Sean]

On 6/8/2023 10:48 AM, Ard Biesheuvel wrote:

On Thu, 8 Jun 2023 at 19:39, Oliver Smith-Denny
 wrote:

On 6/8/2023 10:23 AM, Ard Biesheuvel wrote:

Currently, we rely on the logic in DXE IPL to create new page tables
from scratch when executing in X64 mode, which means that we run with
the initial page tables all throughout PEI, and never enable protections
such as the CPU stack guard, even though the logic is already in place
for IA32.

So let's enable the existing logic for X64 as well. This will permit us
to apply stricter memory permissions to code and data allocations, as
well as the stack, when executing in PEI. It also makes the DxeIpl logic
redundant, and should allow us to make the PcdDxeIplBuildPageTables
feature PCD limited to IA32 DxeIpl loading the x64 DXE core.

When running in long mode, use the same logic that DxeIpl uses to
determine the size of the address space, whether or not to use 1 GB leaf
entries and whether or not to use 5 level paging. Note that in long
mode, PEI is entered with paging enabled, and given that switching
between 4 and 5 levels of paging is not currently supported without
dropping out of 64-bit mode temporarily, all we can do is carry on
without changing the number of levels.


I certainly agree with extending the ability to have memory protections
in PEI (and trying to unify across x86 and ARM (and beyond :)).

A few things I am trying to understand:

Does ARM today rebuild the page table in DxeIpl? Or is it using an
earlier built page table?


No. Most platforms run without any page tables until the permanent
memory is installed, at which point it essentially maps what the
platform describes as device memory and as normal memory.



If I understand your proposal correctly, with the addition of this
patch, you are suggesting we can drop creating new page tables in DxeIpl
and use only one page table throughout.

Yes.


Again, I like the idea of having
mapped memory protections that continue through, but do you have
concerns that we may end up with garbage from PEI in DXE in the page
table? For OEMs, they may not control PEI and therefore be at the whim
of another's PEI page table. Would you envision the GCD gets built from
the existing page table or that the GCD gets built according to resource
descriptor HOBs and DxeCore ensures that the page table reflects what
the HOBs indicated?


If there is a reason to start with a clean slate when DxeIpl hands
over to DXE core, I'd prefer that to be a conscious decision rather
than a consequence of the X64 vs IA32 legacy.

I think you can make a case for priming the GCD map based on resource
descriptors rather than current mappings, with the exception of DXE
core itself and the DXE mode stack. But I'd like to understand better
what we think might be wrong with the page tables as PEI leaves them.



On many platforms there are different "owners" for these different parts 
of firmware code.  The PEI phase is a place where the Silicon vendor and 
Platform teams must work together.  The Dxe Phase may have a different 
set of partners.  Industry trends definitely show more silicon vendor 
driven diversity in the PEI phase of the boot process and with this 
diversity it is much harder to make solid assumptions about the 
execution environment.   We have also discussed in the past meeting that 
PEI should be configurable using different solutions given it isn't a 
place where unknown 3rd party compatibility is critical.  This means 
that PEI might have different requirements than DXE and thus the 
configuration inherited from PEI may not be compliant. Additionally, the 
code and driver mappings from PEI phase should not be relevant in DXE.  
Even with the same architecture being used these are different execution 
phases with different constructs.  Keeping the PEI code mapped will only 
lead to additional security and correctness challenges.  Finally, as an 
overarching theme of this project we have suggested we should not be 
coupling the various phases, their requirements, and their assumptions 
together.  You could just as easily apply this to DXE and SMM/MM.  These 
are all independent execution environments and the more we can provide 
simplification and consistency the better our chances are of getting 
correct implementations across the ecosystem.











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

Re: [edk2-devel] failed Pr

[Sean]

It has changed over time and I no longer see a button on the "checks" page of 
GitHub.  I only see the button in the azure pipeline which would mean 
maintainers would need to be "contributors" in the azure DevOps 
organization/project. I have no problem with that and it looks like you can 
sign in with a GitHub account so it should just be a matter of collecting the 
email address associated with their GitHub and inviting them to join.  We only 
get 5 free basic users but we get unlimited free "stakeholder" accounts. I 
assume we might need basic accounts to interact with the pipeline stuff but I 
don't know for sure.  Anyone who has paid Microsoft visual studio subscriptions 
(like from an employer) usually doesn't count towards the 5.

Regardless for those actively contributing and interested we should add them up 
to the limit.  This was one of the reasons we had desired long term to align on 
GitHub build services instead.

Other thoughts?

Thanks
Sean

From: Kinney, Michael D 
Sent: Monday, May 29, 2023 8:13:32 AM
To: devel@edk2.groups.io ; spbro...@outlook.com 
; a...@kernel.org ; Rebecca Cran 

Cc: Kubacki, Michael ; Gao, Liming 
; Kinney, Michael D 
Subject: RE: [edk2-devel] failed Pr


Hi Sean,



Do you know what GitHub permissions are required to see the re-run button?



I think it is reasonable for all Maintainers to have that available.



Mike



From: devel@edk2.groups.io  On Behalf Of Sean
Sent: Monday, May 29, 2023 8:12 AM
To: devel@edk2.groups.io; a...@kernel.org; Rebecca Cran 
Cc: devel@edk2.groups.io; Kinney, Michael D ; 
Kubacki, Michael ; Gao, Liming 

Subject: Re: [edk2-devel] failed Pr



It has been rerun.





From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>> on behalf of Ard Biesheuvel 
mailto:a...@kernel.org>>
Sent: Monday, May 29, 2023 7:44:37 AM
To: Rebecca Cran mailto:rebe...@bsdio.com>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>; Michael Kinney 
mailto:michael.d.kin...@intel.com>>; Michael 
Kubacki mailto:michael.kuba...@microsoft.com>>; 
Liming Gao (Byosoft address) 
mailto:gaolim...@byosoft.com.cn>>
Subject: Re: [edk2-devel] failed Pr



On Mon, 29 May 2023 at 16:37, Rebecca Cran 
mailto:rebe...@bsdio.com>> wrote:
>
> It looks like the agent or machine running the CI task crashed.
>
> "##[error]We stopped hearing from agent Azure Pipelines 18. Verify the
> agent machine is running and has a healthy network connection. Anything
> that terminates an agent process, starves it for CPU, or blocks its
> network access can cause this error. For more information, see:
> https://go.microsoft.com/fwlink/?linkid=846610;<https://go.microsoft.com/fwlink/?linkid=846610%22>
>

Hmm, it would be nice if this thing could distinguish between 'error
in your code' and 'internal error' where the latter does not mark your
PR as being rejected.

>
>
>
>
> The only way I've found to make CI run again is to do something to cause
> the commit hash to change, for example by making a change to ReadMe.rst
> then reverting it.
>

Mike Kinney mentioned last time that there is a button I could push. Mike?

I am reluctant to make unnecessary changes to the state of the branch
just to trick the CI into having another go at it.








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

Re: [edk2-devel] failed Pr

[Sean]

It has been rerun.


From: devel@edk2.groups.io  on behalf of Ard Biesheuvel 

Sent: Monday, May 29, 2023 7:44:37 AM
To: Rebecca Cran 
Cc: devel@edk2.groups.io ; Michael Kinney 
; Michael Kubacki ; 
Liming Gao (Byosoft address) 
Subject: Re: [edk2-devel] failed Pr

On Mon, 29 May 2023 at 16:37, Rebecca Cran  wrote:
>
> It looks like the agent or machine running the CI task crashed.
>
> "##[error]We stopped hearing from agent Azure Pipelines 18. Verify the
> agent machine is running and has a healthy network connection. Anything
> that terminates an agent process, starves it for CPU, or blocks its
> network access can cause this error. For more information, see:
> https://go.microsoft.com/fwlink/?linkid=846610;
>

Hmm, it would be nice if this thing could distinguish between 'error
in your code' and 'internal error' where the latter does not mark your
PR as being rejected.

>
>
>
>
> The only way I've found to make CI run again is to do something to cause
> the commit hash to change, for example by making a change to ReadMe.rst
> then reverting it.
>

Mike Kinney mentioned last time that there is a button I could push. Mike?

I am reluctant to make unnecessary changes to the state of the branch
just to trick the CI into having another go at it.







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

Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ?

[Sean]

On 5/3/2023 10:56 PM, Gerd Hoffmann wrote:

   Hi,


I agree the iasl dependency for CI has not been managed consistently.   When
all of the CI was setup we decided that iasl should be controlled by the
platform and thus EmulatorPkg, ArmVirt, and OVMF have their own extdep.
This gives those platforms control to rev their version as necessary for
their platform.   We have found it very common in platform development for
platforms to have different required versions of iasl.exe.

Are there cases where /old/ iasl versions are required?


Yes.  On the commercial PC side we see this a lot.  Given how much ASL 
is in modern PCs it is very common for a platform's ASL code to not 
compile with the latest version.  That product and by extension, the ASL 
code, is often supported for 5+ years and then if you add on that the 
ASL compiler was probably already a year old at initial release that 
means the compiler can often be pretty old.  Additionally for those 
building brand new products that are using new capabilities in ACPI, 
they often need the newest version and can't wait for the distro package 
repository to pick up.  As a outsider/consumer of Linux, we have 
definitely had pain caused by the distro's default/available version.  
For the Edk2 repo I can remember a lot of challenges around python 2 and 
3 and versions and the various distro's package management.


Additionally, for CI we want to drive consistency between Windows and 
Linux.  We want visibility into versions used and reproducibility.   
Depending on distro package management make this significantly harder.


EmulatorPkg, ArmVirtPkg, and OVMF could all opt into using the "scope" 
(edk2/Readme.md at master · tianocore/edk2 · GitHub 
) 
that would leverage the Core CI's version of iasl so that they don't 
need to manage this but my initial hope was to showcase this capability 
and allow those "platforms" some of their own autonomy.  Obviously they 
haven't needed or used that yet so as we update Core CI we could also 
update those platforms to follow with the same extdep and version.





As for the feed.  Yes they are inconsistent.   We were moving away from a
global nuget.org feed as it just didn't seem necessary to push to
nuget.org.  But now we are evaluating ways to move entirely away from
nuget.  Nuget.exe worked pretty well for Windows development and our initial
use cases but has definitely created a headache on Linux, MacOS and other.
There really isn't a generic package management solution that is supported
cross platform that has free/high quality/secure hosting.  If anyone has
ideas please share.

On linux / macos / *bsd there is usually no need to create your own
package management.  Standard stuff like iasl / nasm is available as
linux distro package / bsd ports collection package.

Usually you can't pick specific versions.  Usually this isn't a big
issue though, unless you are using an older distro (such as ubuntu 18.04
we used for CI before switching to containers) and need a recent version.

take care,
   Gerd




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

Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ?

[Sean]

Rebecca,

I agree the iasl dependency for CI has not been managed consistently.   
When all of the CI was setup we decided that iasl should be controlled 
by the platform and thus EmulatorPkg, ArmVirt, and OVMF have their own 
extdep.  This gives those platforms control to rev their version as 
necessary for their platform.   We have found it very common in platform 
development for platforms to have different required versions of iasl.exe.


For Core CI (meaning just package builds) we managed iasl in Basetools.  
We decided that this would only need to be updated when newer features 
were used by core components (not very often given the very little ASL 
in edk2 tree).



As for the feed.  Yes they are inconsistent.   We were moving away from 
a global nuget.org feed as it just didn't seem necessary to push to 
nuget.org.  But now we are evaluating ways to move entirely away from 
nuget.  Nuget.exe worked pretty well for Windows development and our 
initial use cases but has definitely created a headache on Linux, MacOS 
and other.  There really isn't a generic package management solution 
that is supported cross platform that has free/high quality/secure 
hosting.  If anyone has ideas please share.



So my suggestion is to hold off for a couple of weeks (unless something 
is broken) and lets see if we can use web downloads from github 
releases.  This should still allow consistency with tools, work cross 
platform, and give the flexibility needed per platform.



Regarding the steps in that document.  In that example it doesn't call 
out all the steps needed as that would just rehash the section before.  
Instead it relies on a user having followed the generic steps in the 
section above (How to Build With Stuart · tianocore/tianocore.github.io 
Wiki 
<https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart#how-to-build-in-edk2-with-stuart>). 
For example the user would need to have also done:  setup python virtual 
env, install pypi dependencies, and clone source + submodules.



Thanks

Sean




On 5/3/2023 12:34 PM, Rebecca Cran wrote:
I noticed OvmfPkg/PlatformCI/iasl_ext_dep.yaml specifies iasl version 
20190215.0.0 while BaseTools/Bin/iasl_ext_dep.yaml has the newer 
20200717.0.0, and "mono .../edk2toolext/bin/NuGet.exe list -Source 
https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/v3/index.json; 
shows there's version 20210105.0.6 available.



Though OvmfPkg is using source https://api.nuget.org/v3/index.json 
while BaseTools uses 
https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/v3/index.json 
- I don't know why they're different.



I was wondering if iasl_ext_dep.yaml should be updated?


Also, the example in 
https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart 
of using stuart_build to build OVMF seems to be missing a step: 
running "stuart_update -c PlatformBuild.py TOOL_CHAIN_TAG=GCC5 -a X64" 
appears to be required otherwise stuart_build will complain that the 
iasl dependency hasn't been met.






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

Re: [edk2-devel][PATCH v1 2/2] UefiPayloadPkg: Enable RNG support

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Tue, 25 Apr 2023 at 18:09, Benjamin Doron 
wrote:

> From: Benjamin Doron 
>
> Uses CPU RDRAND support and installs the EfiRngProtocol.
> The protocol may be used by iPXE or the Linux kernel to gather entropy.
>
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Benjamin Doron 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 3 +++
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 1e803ba01567..486af2396731 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -634,6 +634,9 @@
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  !endif
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> +!if $(CPU_RNG_ENABLE) == TRUE
> +  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
> +!endif
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>  !if $(BOOTSPLASH_IMAGE)
>MdeModulePkg/Logo/LogoDxe.inf
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index f8c2aa8c4a02..53add65a6a40 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -157,6 +157,9 @@ INF CryptoPkg/Driver/CryptoDxe.inf
>  INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  !endif
>  INF UefiCpuPkg/CpuDxe/CpuDxe.inf
> +!if $(CPU_RNG_ENABLE) == TRUE
> +INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
> +!endif
>
>  INF RuleOverride = UI MdeModulePkg/Application/UiApp/UiApp.inf
>  INF MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
> --
> 2.39.2
>
>


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

Re: [edk2-devel][PATCH v1 1/2] UefiPayloadPkg: Define RngLibTimerLib for systems without RDRAND

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Tue, 25 Apr 2023 at 18:09, Benjamin Doron 
wrote:

> From: Benjamin Doron 
>
> Presently, `ArchIsRngSupported()` always returns TRUE, per
>
> https://github.com/tianocore/edk2/blob/1eeca0750af5af2f0e78437bf791ac2de74bde74/MdePkg/Library/BaseRngLib/Rand/RdRand.c#L124-L125
> .
> Therefore, `BaseRngLibConstructor()` should continue to assert RDRAND
> support.
>
> However, older platforms do not support RDRAND, such as QEMU in some
> configurations. Therefore, define an RngLib library class for such
> systems, using a new flag. Maintain current behaviour by default.
>
> Note that this is less secure behaviour, and should be avoided in
> production.
>
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Benjamin Doron 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 9847f189fff5..1e803ba01567 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -130,6 +130,7 @@
># This is how BaseCpuTimerLib works, and a recommended way to get
> Frequence, so set the default value as TRUE.
># Note: for emulation platform such as QEMU, this may not work and
> should set it as FALSE
>DEFINE CPU_TIMER_LIB_ENABLE  = TRUE
> +  DEFINE CPU_RNG_ENABLE= TRUE
>
>DEFINE MULTIPLE_DEBUG_PORT_SUPPORT = FALSE
>
> @@ -204,7 +205,11 @@
>  !endif
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +!if $(CPU_RNG_ENABLE) == TRUE
>RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
> +!else
> +  RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
> +!endif
>HobLib|UefiPayloadPkg/Library/DxeHobLib/DxeHobLib.inf
>
>#
> --
> 2.39.2
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103645): https://edk2.groups.io/g/devel/message/103645
Mute This Topic: https://groups.io/mt/98497421/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 2/2] .azurepipelines: Install code coverage tool

[Sean]

Sorry a little late to review this. It looks like these are container based 
builds. If that is the case we should handle this by updating the container. 
The whole point of the container is to get the requirements all included in the 
container. @Chris Fernald<mailto:chfer...@microsoft.com> can you share details.

Thanks
Sean

From: devel@edk2.groups.io  on behalf of Michael D Kinney 

Sent: Saturday, April 22, 2023 8:15:56 PM
To: Guo, Gua ; devel@edk2.groups.io 
Cc: Sean Brogan ; Michael Kubacki 
; Oliver Steffen ; Kinney, 
Michael D 
Subject: Re: [edk2-devel] [PATCH v2 2/2] .azurepipelines: Install code coverage 
tool

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Guo, Gua 
> Sent: Saturday, April 22, 2023 6:22 PM
> To: devel@edk2.groups.io
> Cc: Guo, Gua ; Kinney, Michael D 
> ; Sean Brogan ;
> Michael Kubacki ; Oliver Steffen 
> 
> Subject: [PATCH v2 2/2] .azurepipelines: Install code coverage tool
>
> From: Gua Guo 
>
> Azure should install code coverage tool (lcov), it didn't
> exist on Fedora and Ubuntu by default.
>
> Cc: Michael D Kinney 
> Cc: Sean Brogan 
> Cc: Michael Kubacki 
> Cc: Oliver Steffen 
> Signed-off-by: Gua Guo 
> ---
>  .azurepipelines/Ubuntu-GCC5.yml | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/.azurepipelines/Ubuntu-GCC5.yml b/.azurepipelines/Ubuntu-GCC5.yml
> index b9a3b851cf..d884256148 100644
> --- a/.azurepipelines/Ubuntu-GCC5.yml
> +++ b/.azurepipelines/Ubuntu-GCC5.yml
> @@ -24,3 +24,7 @@ jobs:
>  container: ${{ variables.default_linux_image }}
>
>  arch_list: "IA32,X64,ARM,AARCH64,RISCV64,LOONGARCH64"
>
>  usePythonVersion: ''  # use Python from the container image
>
> +extra_install_step:
>
> +- bash: sudo dnf install -y lcov
>
> +  displayName: Install Code Coverage Tools
>
> +  condition: and(gt(variables.pkg_count, 0), succeeded())
>
> --
> 2.39.2.windows.1








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

Re: [edk2-devel][PATCH v1 2/2] UefiPayloadPkg: Update default memory type information for S4

[Sean Rhodes]

PR created at https://github.com/tianocore/edk2/pull/4231

On Mon, 3 Apr 2023 at 08:32, Sean Rhodes  wrote:

> Reviewed-by: Sean Rhodes 
>
> On Sat, 1 Apr 2023 at 00:58, Benjamin Doron 
> wrote:
>
>> Copied values from OVMF, these are sufficient for a debug build.
>>
>> Now that those are improved, remove
>> PcdResetOnMemoryTypeInformationChange override. If the memory map must
>> change, reset system so that an S4 resume will succeed.
>>
>> Requires testing a hibernate resume to OS.
>>
>> Cc: Guo Dong 
>> Cc: Ray Ni 
>> Cc: Sean Rhodes 
>> Cc: James Lu 
>> Cc: Gua Guo 
>> Signed-off-by: Benjamin Doron 
>> ---
>>  UefiPayloadPkg/UefiPayloadPkg.dec | 6 +++---
>>  UefiPayloadPkg/UefiPayloadPkg.dsc | 1 -
>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec
>> b/UefiPayloadPkg/UefiPayloadPkg.dec
>> index 2ed73513700d..a5004a2b616e 100644
>> --- a/UefiPayloadPkg/UefiPayloadPkg.dec
>> +++ b/UefiPayloadPkg/UefiPayloadPkg.dec
>> @@ -71,11 +71,11 @@
>> gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter|0|UINT64|0x1004
>>  gUefiPayloadPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C,
>> 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1
>> }|VOID*|0x1005
>>
>>  ## Used to help reduce fragmentation in the EFI memory map
>>
>> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x08|UINT32|0x1012
>>
>> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12|UINT32|0x1012
>>
>>  
>> gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x04|UINT32|0x1013
>>
>>  
>> gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x04|UINT32|0x0014
>>
>> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0xC0|UINT32|0x0015
>>
>> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x80|UINT32|0x0016
>>
>> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100|UINT32|0x0015
>>
>> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100|UINT32|0x0016
>>
>>  # Size of the region used by UEFI in permanent memory
>>
>>  
>> gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x0017
>> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
>> b/UefiPayloadPkg/UefiPayloadPkg.dsc
>> index 9847f189fff5..ba6cc7e1a4d8 100644
>> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
>> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
>> @@ -539,7 +539,6 @@
>>  !else
>>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
>>  !endif
>> -
>> gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
>>gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
>>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
>>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
>> --
>> 2.39.1
>>
>>


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

Re: [edk2-devel][PATCH v1 2/2] UefiPayloadPkg: Update default memory type information for S4

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Sat, 1 Apr 2023 at 00:58, Benjamin Doron 
wrote:

> Copied values from OVMF, these are sufficient for a debug build.
>
> Now that those are improved, remove
> PcdResetOnMemoryTypeInformationChange override. If the memory map must
> change, reset system so that an S4 resume will succeed.
>
> Requires testing a hibernate resume to OS.
>
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Benjamin Doron 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dec | 6 +++---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 1 -
>  2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec
> b/UefiPayloadPkg/UefiPayloadPkg.dec
> index 2ed73513700d..a5004a2b616e 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dec
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dec
> @@ -71,11 +71,11 @@
> gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter|0|UINT64|0x1004
>  gUefiPayloadPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C,
> 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1
> }|VOID*|0x1005
>
>  ## Used to help reduce fragmentation in the EFI memory map
>
> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x08|UINT32|0x1012
>
> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12|UINT32|0x1012
>
>  
> gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x04|UINT32|0x1013
>
>  
> gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x04|UINT32|0x0014
>
> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0xC0|UINT32|0x0015
>
> -gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x80|UINT32|0x0016
>
> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100|UINT32|0x0015
>
> +gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100|UINT32|0x0016
>
>  # Size of the region used by UEFI in permanent memory
>
>  
> gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x0017
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 9847f189fff5..ba6cc7e1a4d8 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -539,7 +539,6 @@
>  !else
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
>  !endif
> -
> gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
>gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
> --
> 2.39.1
>
>


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

Re: [edk2-devel][PATCH v1 1/2] UefiPayloadPkg: Always build MemoryTypeInformation HOB for DXE GCD

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Sat, 1 Apr 2023 at 00:58, Benjamin Doron 
wrote:

> MemoryType information assists GCD with defragmenting the memory map.
> When the DXE core starts, GCD adds memory descriptors for the resource
> descriptors HOBs. This allocates heap space which can be reused later
> as the bins by memory type. It seems memory allocation prefers low
> ranges.
>
> It seems "below 4G" is an artifact of this heap reuse. However, the
> memory type information determines the DXE core's
> `MinimalMemorySizeNeeded`, determining which system memory descriptor
> HOB may be used by DXE. Furthermore, it's important that the memory
> type information be correct, for an S4 memory map.
>
> Therefore, follow other bootloaders, such as [MinPlatform][1], and do
> this unconditionally. As of [edk2-stable202011][2], it was.
>
> [1]:
> https://github.com/tianocore/edk2-platforms/blob/b6f96743891be51541184bf61dd2970c008e2c43/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c#L164-L201
> [2]:
> https://github.com/tianocore/edk2/blob/edk2-stable202011/UefiPayloadPkg/BlSupportPei/BlSupportPei.c#L462-L466
>
> Cc: Guo Dong 
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Benjamin Doron 
> ---
>  .../UefiPayloadEntry/UefiPayloadEntry.c   | 36 +--
>  .../UefiPayloadEntry/UefiPayloadEntry.inf |  2 --
>  UefiPayloadPkg/UefiPayloadPkg.dec |  3 --
>  UefiPayloadPkg/UefiPayloadPkg.dsc |  2 --
>  4 files changed, 8 insertions(+), 35 deletions(-)
>
> diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
> b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
> index 780348eadfa8..030a5baed914 100644
> --- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
> +++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
> @@ -19,30 +19,6 @@ EFI_MEMORY_TYPE_INFORMATION
> mDefaultMemoryTypeInformation[] = {
>{ EfiMaxMemoryType,   0
>}
>  };
>
> -/**
> -   Function to reserve memory below 4GB for EDKII Modules.
> -
> -   This causes the DXE to dispatch everything under 4GB and allows
> Operating
> -   System's that require EFI_LOADED_IMAGE to be under 4GB to start.
> -   e.g. Xen hypervisor used in Qubes.
> -**/
> -VOID
> -ForceModulesBelow4G (
> -  VOID
> -  )
> -{
> -  DEBUG ((DEBUG_INFO, "Building hob to restrict memory resorces to below
> 4G.\n"));
> -
> -  //
> -  // Create Memory Type Information HOB
> -  //
> -  BuildGuidDataHob (
> -,
> -mDefaultMemoryTypeInformation,
> -sizeof (mDefaultMemoryTypeInformation)
> -);
> -}
> -
>  /**
> Callback function to build resource descriptor HOB
>
> @@ -472,10 +448,14 @@ _ModuleEntryPoint (
>// Build other HOBs required by DXE
>BuildGenericHob ();
>
> -  // Create a HOB to make resources for EDKII modules below 4G
> -  if (!FixedPcdGetBool (PcdDispatchModuleAbove4GMemory)) {
> -ForceModulesBelow4G ();
> -  }
> +  //
> +  // Create Memory Type Information HOB
> +  //
> +  BuildGuidDataHob (
> +,
> +mDefaultMemoryTypeInformation,
> +sizeof (mDefaultMemoryTypeInformation)
> +);
>
>// Load the DXE Core
>Status = LoadDxeCore ();
> diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
> b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
> index d47e8e76cf4c..e2af8a4b7c1b 100644
> --- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
> +++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
> @@ -96,5 +96,3 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ##
> SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ##
> SOMETIMES_CONSUMES
>
> -  gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory
> -
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec
> b/UefiPayloadPkg/UefiPayloadPkg.dec
> index 7d61d6eeae6c..2ed73513700d 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dec
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dec
> @@ -82,9 +82,6 @@
> gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x
>
>  gUefiPayloadPkgTokenSpaceGuid.PcdPcdDriverFile|{ 0x57, 0x72, 0xcf, 0x80,
> 0xab, 0x87, 0xf9, 0x47, 0xa3, 0xfe, 0xD5, 0x0B, 0x76, 0xd8, 0x95, 0x41
> }|VOID*|0x0018
>
> -# Above 4G Memory
>
> -gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory|TRUE|BOOLEAN|0x0019
> -
>  # Boot Manager Key
>
>  gUefiPayloadPkgTokenSpaceGuid.PcdBootManagerEscape|FALSE|BOOLEAN|0x0020
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc
> b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index bca5d3f335bc..9847f189fff5 10064

Re: [edk2-devel] [PATCH v1 1/1] .github/dependabot.yml: Disable automatic rebasing

[Sean]

reviewed-by: Sean Brogan 


On 3/31/2023 4:48 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Sets the rebase-strategy to "disabled" to prevent automatic
rebasing.

Rebasing can be done manually in the dependabot PR either through
the GitHub UI or the dependabot command.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
  .github/dependabot.yml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b4e0b93b16ca..479440fe6397 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -20,6 +20,7 @@ updates:
- "makubacki"
- "mdkinney"
- "spbrogan"
+rebase-strategy: "disabled"
  
- package-ecosystem: "github-actions"

  directory: "/"
@@ -32,3 +33,4 @@ updates:
- "makubacki"
- "mdkinney"
- "spbrogan"
+rebase-strategy: "disabled"



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102339): https://edk2.groups.io/g/devel/message/102339
Mute This Topic: https://groups.io/mt/97985364/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 1/3] Platform/AMD: Adds MinBoardPkg to support MinPlatformPkg

[Sean]

Regardless of directory path I would suggest that all "Packages" have a 
unique and descriptive name.  MinBoardPkg doesn't meet that 
suggestion.   If/when the edk2 CI tools run I would expect problems/odd 
behavior if two packages collide in naming.


Thanks

Sean



On 3/22/2023 11:13 PM, Abdul Lateef Attar via groups.io wrote:

Adds initial DEC and DSC file for MinBoardPkg.
This package provides supporting modules for AMD boards to
leverage MinPlatformPkg framework.

Signed-off-by: Abdul Lateef Attar 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Abner Chang 
Cc: Michael D Kinney 
---
  Platform/AMD/MinBoardPkg/MinBoardPkg.dec | 19 +++
  Platform/AMD/MinBoardPkg/MinBoardPkg.dsc | 21 +
  2 files changed, 40 insertions(+)
  create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dec
  create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dsc

diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dec 
b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
new file mode 100644
index ..23d737d196a2
--- /dev/null
+++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
@@ -0,0 +1,19 @@
+## @file MinBoardPkg.dec
+#  Declaration file for AMD's MinBoardPkg.
+#
+#  This package supports AMD processor family based board as per the 
MinPlatform
+#  Arch specification.
+#
+#  Copyright (c) 2023, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#  @par Specification Reference:
+#   -https://tianocore-docs.github.io/edk2-MinimumPlatformSpecification/draft/ 
0.7
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 1.27
+  PACKAGE_NAME   = MinBoardPkg
+  PACKAGE_GUID   = 44F9D761-9ECB-43DD-A5AC-177E5048701B
+  PACKAGE_VERSION= 0.1
+
diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc 
b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
new file mode 100644
index ..8c120c0649e7
--- /dev/null
+++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
@@ -0,0 +1,21 @@
+## @file
+#  MinBoardPkg.dsc
+#
+#  Description file for AMD MinBoardPkg
+#
+#  Copyright (c) 2023, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  DSC_SPECIFICATION   = 1.30
+  PLATFORM_GUID   = 88F8A9AE-2FA0-4D58-A6F9-05F635C05F4E
+  PLATFORM_NAME   = MinBoardPkg
+  PLATFORM_VERSION= 0.1
+  OUTPUT_DIRECTORY= Build/$(PLATFORM_NAME)
+  BUILD_TARGETS   = DEBUG | RELEASE | NOOPT
+  SUPPORTED_ARCHITECTURES = IA32 | X64
+
+[Packages]
+  MinBoardPkg/MinBoardPkg.dec
+



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

[Sean]

Thanks Ray.  Lets discuss this style of testing next week at the tools 
and CI meeting.



Reviewed-by: Sean Brogan 


On 3/31/2023 11:22 AM, Ni, Ray wrote:

The random test cases just run for too long that may cause timeout
in CI test.
Disable them for now.

Signed-off-by: Ray Ni 
---
  .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c 
b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
index 547f6c2e50..745b774c66 100644
--- a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
@@ -881,11 +881,11 @@ UefiTestMain (
  goto EXIT;

}

  


-  AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test Case5", 
TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );

  


//

// Execute the tests.




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

Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Ray

Some members of the coreboot community want to centre the logo (as it is
currently) and some want to use the Microsoft recommended position. All we
want to do is have the option to build edk2 with one or the other.

Thanks

Sean

On Mon, 20 Mar 2023 at 09:56, Ni, Ray  wrote:

> Sheng Lean Tan,
>
>
>
> In short, I am looking forward to be convinced by you and Sean, but so far
> I haven’t been.
>
>
>
>1. In the beginning, I left comments to suggest you use the logic
>below to meet your requirement.
>Status = gBS->HandleProtocol (gST->ConsoleOutHandle,
>, (VOID **) );
>
> if (!EFI_ERROR (Status)) {
>   //
>   // Center of LOGO is in the vertical position 38.2% when
> PcdBootLogoOnlyEnable is TRUE
>   // Y = (VerticalResolution - LogoHeight) / 2
>   // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
>   // OffsetY + Y = Y'
>   // OffsetY = Y' - Y = -0.118 * VerticalResolution
>   //
>   *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
>   *OffsetX   = 0;
>   *OffsetY   = -118 * (INTN)
> GraphicsOutput->Mode->Info->VerticalResolution / 1000;
> }
>
>
>
>1. Then, Sean replied following: “Thank you, it does, and I think it
>will work for most splash images. However, the way it's written in my patch
>accounts for the Image size. This will handle splash images that are equal
>to, or larger than the resolution of the display. “
>
>
>
>1. Then, I replied “The logic I shared below is from the LogoDxe
>driver which produces EDKII_PLATFORM_LOGO_PROTOCOL. This driver should know
>the image size and it can account for the image size.”
>
> Then, I don’t think we are talking in the same page. Maybe I didn’t
> understand your problem, maybe you didn’t understand my above sample code.
>
> Thanks,
>
> Ray
>
>
>
>
>
>
>
> *From:* Sheng Lean Tan 
> *Sent:* Monday, March 20, 2023 4:12 PM
> *To:* devel@edk2.groups.io; Ni, Ray ; Kinney, Michael D
> 
> *Cc:* Rhodes, Sean ; Gao, Zhichao <
> zhichao@intel.com>; Wang, Jian J ; Gao, Liming
> 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Hi Ray,
>
> Any feedback per Mic feedback?
>
> Sent from my iPhone
>
>
> On 15. Mar 2023, at 16:35, Michael D Kinney 
> wrote:
>
> 
>
> HI Ray,
>
>
>
> I think it is a reasonable request to have the EDK II logo driver support
> multiple standards for the logo location.  Especially if they are
> documented in public specifications.
>
>
>
> The additional conditions of supporting a logo larger than the display
> resolution also looks like a good corner case to cover no matter what logo
> location standard is used.
>
>
>
> Perhaps a single PCD that is a enum of logo locations.  Default 0x00 can
> be EDK II default that is centered in the display.  0x01 can be BGRT.
> Leaves from for more if there are additional public standard logo locations.
>
>
>
> Mike
>
>
>
>
>
> *From:* Ni, Ray 
> *Sent:* Wednesday, March 15, 2023 2:24 AM
> *To:* devel@edk2.groups.io; Rhodes, Sean 
> *Cc:* Kinney, Michael D ; Gao, Zhichao <
> zhichao@intel.com>; Wang, Jian J ; Gao, Liming
> 
> *Subject:* RE: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> What’s the meaning of “have both options”?
>
> If you want to support two cases, put the logic in your platform specific
> Logo driver.
>
> This Logo driver is just for reference.
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Sean
> Rhodes
> *Sent:* Friday, March 10, 2023 9:43 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Kinney, Michael D ;
> Gao, Zhichao ; Wang, Jian J ;
> Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Hi Ray
>
>
>
> > You can return a carefully-calculated X/Y value to make
> the logo at MS preferred position.
>
> As we discussed before, we need to have both options.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Wed, 8 Mar 2023 at 09:01, Ni, Ray  wrote:
>
> Maybe I didn’t explain my idea clearly.
>
> That is:
>
> You can get the screen resolution in the code that
> produces Logo protocol.
>
> You can return a carefully-calculated X/Y value to make
> the logo at MS preferred position.
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Ni, Ray
> *Sent:* Wednesday, October 26, 2022 10:32 AM
> *To:* Kinne

Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Ray

> You can return a carefully-calculated X/Y value to make
the logo at MS preferred position.

As we discussed before, we need to have both options.

Thanks

Sean

On Wed, 8 Mar 2023 at 09:01, Ni, Ray  wrote:

> Maybe I didn’t explain my idea clearly.
>
> That is:
>
> You can get the screen resolution in the code that
> produces Logo protocol.
>
> You can return a carefully-calculated X/Y value to make
> the logo at MS preferred position.
>
>
>
> *From:* devel@edk2.groups.io  * On Behalf Of *Ni,
> Ray
> *Sent:* Wednesday, October 26, 2022 10:32 AM
> *To:* Kinney, Michael D ; devel@edk2.groups.io;
> Rhodes, Sean 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Are you suggesting that the exiting logic be updated for this use case
> without adding a new enum?
>
>- yes.
>
>
>
> *From:* Kinney, Michael D 
> *Sent:* Wednesday, October 26, 2022 12:21 AM
> *To:* devel@edk2.groups.io; Ni, Ray ; Rhodes, Sean <
> sean@starlabs.systems>; Kinney, Michael D 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* RE: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Ray,
>
>
>
> Are you suggesting that the exiting logic be updated for this use case
> without adding a new enum?
>
>
>
> Sean, can you provide a revised patch that does this?
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Ni, Ray
> *Sent:* Tuesday, October 25, 2022 12:58 AM
> *To:* devel@edk2.groups.io; Rhodes, Sean 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> I need a reason of adding
> EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended.
>
> In my opinion, without adding this new enum value, it’s still possible to
> support MS recommendation.
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Sean
> Rhodes
> *Sent:* Tuesday, October 25, 2022 3:27 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Wang,
> Jian J ; Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Hi Ray
>
>
>
> Where would you suggest this code goes? edk2 should support both Microsoft
> recommended and "normal". The original patch handled this well.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Mon, 10 Oct 2022 at 10:25, Ni, Ray  wrote:
>
> The logic I shared below is from the LogoDxe driver which produces
> EDKII_PLATFORM_LOGO_PROTOCOL.
>
> This driver should know the image size and it can account for the image
> size.
>
>
>
> Thanks,
>
> Ray
>
>
>
> *From:* Sean Rhodes 
> *Sent:* Monday, October 10, 2022 4:51 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Wang,
> Jian J ; Gao, Liming 
> *Subject:* Re: [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the
> position of the Logo
>
>
>
> Hi Ray
>
>
>
> Thank you, it does, and I think it will work for most splash images.
> However, the way it's written in my patch accounts for the Image size. This
> will handle splash images that are equal to, or larger than the resolution
> of the display.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Sat, 8 Oct 2022 at 03:02, Ni, Ray  wrote:
>
> Sean,
> I remember that I evaluated the BGRT requirement when designing the
> PlatformLogo protocol.
>
> So, I went back to got the code I wrote long time ago as below.
> I didn't try to understand them now. Does it make sense to you?
>
> Status = gBS->HandleProtocol (gST->ConsoleOutHandle,
> , (VOID **) );
> if (!EFI_ERROR (Status)) {
>   //
>   // Center of LOGO is in the vertical position 38.2% when
> PcdBootLogoOnlyEnable is TRUE
>   // Y = (VerticalResolution - LogoHeight) / 2
>   // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
>   // OffsetY + Y = Y'
>   // OffsetY = Y' - Y = -0.118 * VerticalResolution
>   //
>   *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
>   *OffsetX   = 0;
>   *OffsetY   = -118 * (INTN)
> GraphicsOutput->Mode->Info->VerticalResolution / 1000;
> }
>
> Thanks,
> Ray
>
> > -Original Me

Re: [edk2-devel] [PATCH 3/3] ShellPkg/TftpDynamicCommand.inf: Add missing DEPEX

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Mon, 6 Mar 2023 at 08:38, Patrick Rudolph 
wrote:

> Add protocol gEfiHiiPackageListProtocolGuid to DEPEX
> to make sure it's present before using it.
>
> Fixes ASSERTION seen on DEBUG build.
>
> Signed-off-by: Patrick Rudolph 
> ---
>  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> index b0c8e8f84b..d0d849a1eb 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> @@ -57,4 +57,4 @@
>gEfiShellDynamicCommandProtocolGuid## PRODUCES
>
>  [DEPEX]
> -  TRUE
> +  gEfiHiiPackageListProtocolGuid
> --
> 2.39.1
>
>


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

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

[Sean Rhodes]

Reviewed-by: Sean Rhodes 

On Mon, 6 Mar 2023 at 08:38, Patrick Rudolph 
wrote:

> Drop the "-z max-page-size=0x40" option as it causes the ELF
> header to overflow into the .text section, causing undefined
> behaviour.
>
> With high optimization level it corrupts essential code and
> the binary would crash. It might work with low optimization
> level though. As the default is to use Oz and LTO, it always
> crashes.
>
> Test:
> The ELF generated by
> 'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' boots.
>
> Signed-off-by: Patrick Rudolph 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4357
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 9b59bd75c3..0c584ab390 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -2866,7 +2866,7 @@ DEFINE CLANGDWARF_X64_PREFIX= ENV(CLANG_BIN)
>
>  # LLVM/CLANG doesn't support -n link option. So, it can't share the same
> IA32_X64_DLINK_COMMON flag.
>  # LLVM/CLANG doesn't support common page size. So, it can't share the
> same GccBase.lds script.
> -DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib
> -Wl,-q,--gc-sections -z max-page-size=0x40
> +DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--gc-sections
>  DEFINE CLANGDWARF_DLINK2_FLAGS_COMMON =
> -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
>  DEFINE CLANGDWARF_IA32_X64_ASLDLINK_FLAGS =
> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--defsym=PECOFF_HEADER_SIZE=0
> DEF(CLANGDWARF_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u
> ReferenceAcpiTable
>  DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS=
> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--entry,$(IMAGE_ENTRY_POINT) -u
> $(IMAGE_ENTRY_POINT)
> -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
> --
> 2.39.1
>
>


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

Re: [edk2-devel] regarding uefipayload build warning for pcd

[Sean Rhodes]

L36 is help text that says what you are trying to do, wont work

On Tue, 7 Feb 2023 at 20:51, ritul guru  wrote:

> fatal: repository 'payloads/external/edk2/workspace/tianocore' does not
> exist
> make[1]: *** [Makefile:123:
> /home/amd/src/phx2/coreboot_phx2/coreboot/payloads/external/edk2/workspace/edk2]
> Error 128
> make: *** [payloads/external/Makefile.inc:158: build/UEFIPAYLOAD.fd] Error
> 2
>
>
>
>
>
> *Thanks & RegardsRitul Guru+91-9916513186*
>
>
> On Wed, Feb 8, 2023 at 2:19 AM ritul guru  wrote:
>
>> I do not get debug logs from edk2 payload even though debug payload is
>> selected in menuconfig of coreboot.
>> and also updated FD_BASE, if not then getting GCD assert while adding
>> regions in phit table.
>>
>> below path should be give at L36 for custom edk2 repo?
>> payloads/external/edk2/workspace/tianocore/
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
>>
>> On Wed, Feb 8, 2023 at 2:06 AM Sean Rhodes  wrote:
>>
>>> Why the edk2 changes? Just to fix this issue?
>>>
>>> Have you seen L36 of payloads/external/edk2/Kconfig
>>>
>>> On Tue, 7 Feb 2023 at 20:30, ritul guru  wrote:
>>>
>>>>
>>>>
>>>> Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1
>>>> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0
>>>> Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi
>>>> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 51A3ED98
>>>> ProtectUefiImageCommon - 0x51A3E1C0
>>>>   - 0x51DD1000 - 0x8000
>>>> SetUefiImageMemoryAttributes - 0x51DD1000 - 0x1000
>>>> (0x4008)
>>>> SetUefiImageMemoryAttributes - 0x51DD2000 - 0x6000
>>>> (0x00020008)
>>>> SetUefiImageMemoryAttributes - 0x51DD8000 - 0x1000
>>>> (0x4008)
>>>> PROGRESS CODE: V03040002 I0
>>>>
>>>> ASSERT_EFI_ERROR (Status = Device Error)
>>>>
>>>> *ASSERT [PcRtc]
>>>> /home//src/p/coreboot/payloads/external/edk2/workspace/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c(1)*
>>>> getting above assert after changed to FD_BASE to below value,
>>>> This error is coming while booting to coreboot with edk2 payload:
>>>>
>>>> UefiPayloadPkg/UefiPayloadPkg.fdf
>>>> DEFINE FD_BASE   = 0x02182000
>>>>
>>>> need to change FD_BASE, as it was going outside Available memory.
>>>> any hint would be appreciated.
>>>>
>>>>
>>>>
>>>>
>>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>>
>>>>
>>>> On Tue, Feb 7, 2023 at 10:09 PM ritul guru 
>>>> wrote:
>>>>
>>>>> UefiPayloadPkg/UefiPayloadPkg.fdf
>>>>> DEFINE FD_BASE   = 0x0080
>>>>>
>>>>> Is the above address correct in uefipaylaod?
>>>>> As observing some regions are getting out of limit of FD limit,
>>>>>
>>>>> and when setting DEFINE FD_BASE   = 0x0220, then seeing assert
>>>>> in
>>>>> [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister].
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>>>
>>>>>
>>>>> On Tue, Feb 7, 2023 at 8:29 PM ritul guru 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I am building edk2 payload and getting below warning for
>>>>>> PcdRtcIndexRegister,
>>>>>> and if try to boot to then observing that there is assert at:
>>>>>>
>>>>>> ASSERT_EFI_ERROR (Status = Device Error)
>>>>>>
>>>>>> DXE_ASSERT!:
>>>>>> /home/amd/src///coreboot/payloads/external/tianocore/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>>>>>> (141): !EFI_ERROR (Status)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> build time warning:
>>>>>> Active Platform  =
>>>>>> /home//src///coreboot/payloads/external/edk2/workspace/tianocore/UefiPayloadPkg/UefiPayloadPkg.dsc
>>>>>> .build: : warning: The PCD was not specified by any INF module in the
>>>>>> platform for the given architecture.
>>>>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister]
>>>>>> Platform: [UefiPayloadPkg.dsc]
>>>>>> Arch: ['IA32']
>>>>>> build: : warning: The PCD was not specified by any INF module in the
>>>>>> platform for the given architecture.
>>>>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister]
>>>>>> Platform: [UefiPayloadPkg.dsc]
>>>>>> Arch: ['IA32']
>>>>>> . done!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>>>>
>>>>> 
>>>>
>>>>


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

Re: [edk2-devel] regarding uefipayload build warning for pcd

[Sean Rhodes]

Why the edk2 changes? Just to fix this issue?

Have you seen L36 of payloads/external/edk2/Kconfig

On Tue, 7 Feb 2023 at 20:30, ritul guru  wrote:

>
>
> Loading driver 378D7B65-8DA9-4773-B6E4-A47826A833E1
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 51A3E1C0
> Loading driver at 0x00051DD1000 EntryPoint=0x00051DD5670 PcRtc.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 51A3ED98
> ProtectUefiImageCommon - 0x51A3E1C0
>   - 0x51DD1000 - 0x8000
> SetUefiImageMemoryAttributes - 0x51DD1000 - 0x1000
> (0x4008)
> SetUefiImageMemoryAttributes - 0x51DD2000 - 0x6000
> (0x00020008)
> SetUefiImageMemoryAttributes - 0x51DD8000 - 0x1000
> (0x4008)
> PROGRESS CODE: V03040002 I0
>
> ASSERT_EFI_ERROR (Status = Device Error)
>
> *ASSERT [PcRtc]
> /home//src/p/coreboot/payloads/external/edk2/workspace/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c(1)*
> getting above assert after changed to FD_BASE to below value,
> This error is coming while booting to coreboot with edk2 payload:
>
> UefiPayloadPkg/UefiPayloadPkg.fdf
> DEFINE FD_BASE   = 0x02182000
>
> need to change FD_BASE, as it was going outside Available memory.
> any hint would be appreciated.
>
>
>
>
> *Thanks & RegardsRitul Guru+91-9916513186*
>
>
> On Tue, Feb 7, 2023 at 10:09 PM ritul guru  wrote:
>
>> UefiPayloadPkg/UefiPayloadPkg.fdf
>> DEFINE FD_BASE   = 0x0080
>>
>> Is the above address correct in uefipaylaod?
>> As observing some regions are getting out of limit of FD limit,
>>
>> and when setting DEFINE FD_BASE   = 0x0220, then seeing assert in
>> [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister].
>>
>>
>>
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
>>
>> On Tue, Feb 7, 2023 at 8:29 PM ritul guru  wrote:
>>
>>> Hi,
>>> I am building edk2 payload and getting below warning for
>>> PcdRtcIndexRegister,
>>> and if try to boot to then observing that there is assert at:
>>>
>>> ASSERT_EFI_ERROR (Status = Device Error)
>>>
>>> DXE_ASSERT!:
>>> /home/amd/src///coreboot/payloads/external/tianocore/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>>> (141): !EFI_ERROR (Status)
>>>
>>>
>>>
>>>
>>> build time warning:
>>> Active Platform  =
>>> /home//src///coreboot/payloads/external/edk2/workspace/tianocore/UefiPayloadPkg/UefiPayloadPkg.dsc
>>> .build: : warning: The PCD was not specified by any INF module in the
>>> platform for the given architecture.
>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister]
>>> Platform: [UefiPayloadPkg.dsc]
>>> Arch: ['IA32']
>>> build: : warning: The PCD was not specified by any INF module in the
>>> platform for the given architecture.
>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister]
>>> Platform: [UefiPayloadPkg.dsc]
>>> Arch: ['IA32']
>>> . done!
>>>
>>>
>>>
>>>
>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>
>> 
>
>


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

Re: [edk2-devel] regarding uefipayload build warning for pcd

[Sean Rhodes]

For anyone to be able to help, you'd need to post a build log, .config, tag
and what custom patches you are using.

On Tue, 7 Feb 2023 at 19:02, ritul guru  wrote:

> CONFIG_PAYLOAD_EDK2=y
> # CONFIG_PAYLOAD_LINUX is not set
> CONFIG_PAYLOAD_FILE="build/UEFIPAYLOAD.fd"
> CONFIG_PAYLOAD_OPTIONS=""
> CONFIG_EDK2_UEFIPAYLOAD=y
> # CONFIG_EDK2_REPO_MRCHROMEBOX is not set
> CONFIG_EDK2_REPO_OFFICIAL=y
> # CONFIG_EDK2_REPO_CUSTOM is not set
> CONFIG_EDK2_REPOSITORY="https://github.com/tianocore/edk2;
> CONFIG_EDK2_TAG_OR_REV="origin/master"
> CONFIG_EDK2_DEBUG=y
> # CONFIG_EDK2_RELEASE is not set
> CONFIG_EDK2_VERBOSE_BUILD=y
> # CONFIG_EDK2_ABOVE_4G_MEMORY is not set
> CONFIG_EDK2_BOOT_MANAGER_ESCAPE=y
>
>
>
>
> *Thanks & RegardsRitul Guru+91-9916513186*
>
>
> On Wed, Feb 8, 2023 at 12:31 AM ritul guru  wrote:
>
>> building it inside coreboot only.
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
>>
>> On Wed, Feb 8, 2023 at 12:00 AM Sean Rhodes 
>> wrote:
>>
>>> Hi Ritul
>>>
>>> It might be easier to build it inside coreboot; that'll use coreboots
>>> tool chain and Kconfig so everything will just work.
>>>
>>> I.e. CONFIG_PAYLOAD_EDK2=y
>>>
>>> Sean
>>>
>>> On Tue, 7 Feb 2023, 18:24 ritul guru,  wrote:
>>>
>>>> UefiPayloadPkg/UefiPayloadPkg.fdf
>>>> DEFINE FD_BASE   = 0x0080
>>>>
>>>> Is the above address correct in uefipaylaod?
>>>> As observing some regions are getting out of limit of FD limit,
>>>>
>>>> and when setting DEFINE FD_BASE   = 0x0220, then seeing assert
>>>> in
>>>> [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister].
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>>
>>>>
>>>> On Tue, Feb 7, 2023 at 8:29 PM ritul guru  wrote:
>>>>
>>>>> Hi,
>>>>> I am building edk2 payload and getting below warning for
>>>>> PcdRtcIndexRegister,
>>>>> and if try to boot to then observing that there is assert at:
>>>>>
>>>>> ASSERT_EFI_ERROR (Status = Device Error)
>>>>>
>>>>> DXE_ASSERT!:
>>>>> /home/amd/src///coreboot/payloads/external/tianocore/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>>>>> (141): !EFI_ERROR (Status)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> build time warning:
>>>>> Active Platform  =
>>>>> /home//src///coreboot/payloads/external/edk2/workspace/tianocore/UefiPayloadPkg/UefiPayloadPkg.dsc
>>>>> .build: : warning: The PCD was not specified by any INF module in the
>>>>> platform for the given architecture.
>>>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister]
>>>>> Platform: [UefiPayloadPkg.dsc]
>>>>> Arch: ['IA32']
>>>>> build: : warning: The PCD was not specified by any INF module in the
>>>>> platform for the given architecture.
>>>>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister]
>>>>> Platform: [UefiPayloadPkg.dsc]
>>>>> Arch: ['IA32']
>>>>> . done!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Thanks & RegardsRitul Guru+91-9916513186*
>>>>>
>>>> 
>>>>
>>>>


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

Re: [edk2-devel] regarding uefipayload build warning for pcd

[Sean Rhodes]

Hi Ritul

It might be easier to build it inside coreboot; that'll use coreboots tool
chain and Kconfig so everything will just work.

I.e. CONFIG_PAYLOAD_EDK2=y

Sean

On Tue, 7 Feb 2023, 18:24 ritul guru,  wrote:

> UefiPayloadPkg/UefiPayloadPkg.fdf
> DEFINE FD_BASE   = 0x0080
>
> Is the above address correct in uefipaylaod?
> As observing some regions are getting out of limit of FD limit,
>
> and when setting DEFINE FD_BASE   = 0x0220, then seeing assert in
> [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister].
>
>
>
>
>
>
> *Thanks & RegardsRitul Guru+91-9916513186*
>
>
> On Tue, Feb 7, 2023 at 8:29 PM ritul guru  wrote:
>
>> Hi,
>> I am building edk2 payload and getting below warning for
>> PcdRtcIndexRegister,
>> and if try to boot to then observing that there is assert at:
>>
>> ASSERT_EFI_ERROR (Status = Device Error)
>>
>> DXE_ASSERT!:
>> /home/amd/src///coreboot/payloads/external/tianocore/tianocore/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
>> (141): !EFI_ERROR (Status)
>>
>>
>>
>>
>> build time warning:
>> Active Platform  =
>> /home//src///coreboot/payloads/external/edk2/workspace/tianocore/UefiPayloadPkg/UefiPayloadPkg.dsc
>> .build: : warning: The PCD was not specified by any INF module in the
>> platform for the given architecture.
>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcIndexRegister]
>> Platform: [UefiPayloadPkg.dsc]
>> Arch: ['IA32']
>> build: : warning: The PCD was not specified by any INF module in the
>> platform for the given architecture.
>> PCD: [gPcAtChipsetPkgTokenSpaceGuid.PcdRtcTargetRegister]
>> Platform: [UefiPayloadPkg.dsc]
>> Arch: ['IA32']
>> . done!
>>
>>
>>
>>
>> *Thanks & RegardsRitul Guru+91-9916513186*
>>
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99761): https://edk2.groups.io/g/devel/message/99761
Mute This Topic: https://groups.io/mt/96810837/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/3] MdeModulePkg/BmBoot: Skip removable media if it is not present

[Sean Rhodes]

Hi Ray

Would it be possible to merge this?

Thanks

Sean

On Fri, 16 Dec 2022, 09:03 Ni, Ray,  wrote:

> Reviewed-by: Ray Ni 
>
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> Rhodes
> > Sent: Friday, December 16, 2022 4:58 PM
> > To: devel@edk2.groups.io
> > Cc: Matt DeVillier ; Wu, Hao A <
> hao.a...@intel.com>; Wang, Jian J ;
> > Gao, Liming ; Gao, Zhichao <
> zhichao@intel.com>; Ni, Ray ; Rhodes,
> > Sean 
> > Subject: [edk2-devel] [PATCH 1/3] MdeModulePkg/BmBoot: Skip removable
> media if it is not present
> >
> > From: Matt DeVillier 
> >
> > Only enumerate devices that have media present.
> >
> > Cc: Hao A Wu 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Cc: Zhichao Gao 
> > Cc: Ray Ni 
> > Reviewed-by: Sean Rhodes 
> > Signed-off-by: Matt DeVillier 
> > Change-Id: I78a0b8be3e2f33edce2d43bbdd7670e6174d0ff8
> > ---
> >  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 962892d38f..bde22fa659 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -2218,6 +2218,15 @@ BmEnumerateBootOptions (
> >  continue;
> >
> >}
> >
> >
> >
> > +  //
> >
> > +  // Skip removable media if not present
> >
> > +  //
> >
> > +  if ((BlkIo->Media->RemovableMedia == TRUE) &&
> >
> > +  (BlkIo->Media->MediaPresent == FALSE))
> >
> > +  {
> >
> > +continue;
> >
> > +  }
> >
> > +
> >
> >Description = BmGetBootDescription (Handles[Index]);
> >
> >BootOptions = ReallocatePool (
> >
> >sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) *
> (*BootOptionCount),
> >
> > --
> > 2.37.2
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#97498): https://edk2.groups.io/g/devel/message/97498
> > Mute This Topic: https://groups.io/mt/95706437/1712937
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe: https://edk2.groups.io/g/devel/unsub [ray...@intel.com]
> > -=-=-=-=-=-=
> >
>
>
>
> 
>
>
>


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

Re: [edk2-devel] [PATCH v1 0/4] Don't require self-signed PK in setup mode

[Sean]

Did i mention how much i hate reviewing code over email?  :)

Even after looking at it a few times I missed that change.

I think this change looks fine.  Personally, i think this code has 
terrible readability and high complexity and with high impact.  It would 
be great to at least get unit tests if not a full refactor of the 
library.  I also think the edk2 idea of "custom mode" should be 
removed.  But that feedback isn't for this patch and I don't think this 
patch should be held up just because the surrounding code is less than 
ideal.


For patch 1 and 4.

Reviewed-by: Sean Brogan 

Thanks

Sean




On 1/27/2023 2:05 PM, Jan Bobek wrote:

I read your replacement a little different.

-  if ((InCustomMode () && UserPhysicalPresent ()) || ((mPlatformMode == SETUP_MODE) 
&& !IsPk)) {

with

+  if (  (InCustomMode () && UserPhysicalPresent ())
+ || (  (mPlatformMode == SETUP_MODE)
+&& !(FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk)))
+  {


In the upper part you replaced it says !IsPk.  What am i missing?


If a payload was in this function targeting a KEK change with no PK
installed it would go in the original IF condition.  In the new code
it would because device is not in custom mode and the payload is not
targeted PK.

Is it possible that you're missing the negation (i.e. exclamation mark)
in front of the parethesis? The old code was

   !IsPk

The new code is

   !(FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk)

If IsPk is FALSE, both of these evaluate to TRUE no matter what the PCD
is.

-Jan


On 1/25/2023 1:38 PM, Jan Bobek wrote:

Hi Sean,


  From looking over the patch 1/4 email i have a concern.

In AuthService.c on the conditional change you made. Aren't we losing
a case where we are evaluating a nonPK payload signed by the PK?
Given the system is in SetupMode that means there is no PK but is this
the conditional path that is used when installing Secure boot keys in
reverse (DBX,DX,KEK,PK) order?

Thanks for sharing your concern! They way I think about the change is
that I've replaced the expression

  IsPk

with

  FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk

and nothing else. When you look at it this way, it's fairly easy to
break down how it affects the logic:

1. Assume PcdRequireSelfSignedPk is TRUE. In this case, the two
 expressions are exactly the same and no change in behavior occurs,
 just as we want.

2. Assume IsPk is FALSE. In this case, both expressions evaluate to
 FALSE, no matter what the PCD is configured to. That's also good,
 because we don't want to change how non-PK payloads are handled.

3. In fact, the only change in behavior that occurs is when
 PcdRequireSelfSignedPk is FALSE and IsPk is TRUE; here the former
 expression would be TRUE, whereas the latter is FALSE. That's exactly
 what we want: we wish to enter the first block of the if-else branch
 (which changes the variable similarly to when we're in custom mode)
 rather than falling through to the third block (which checks the
 self-signature).

To directly answer your question, I don't think the behavior changes at
all when processing non-PK payloads, by virtue of IsPk being FALSE and
what I said in point (2.) above.

Additionally, yes, the first block of the if-else branch is exactly the
path that's taken when enrolling KEK/DB/DBX in Setup mode, and one that
has always been available even without Custom mode. It used to be that
you couldn't use this path to enroll PK without Custom mode (precisely
because of !IsPk in the condition), but I'm hoping to enable this path
with my patch.

Let me know if I haven't answered or misunderstood your question.


Is there testing you have done?  This code should be pretty easy to do
host based unit testing on. Any chance you have authored that to
confirm use cases are not unexpectedly impacted?  Example of host
based unit test of library is here:
edk2/SecurityPkg/Library/SecureBootVariableLib/UnitTest at master ·
tianocore/edk2
(github.com)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FSecurityPkg%2FLibrary%2FSecureBootVariableLib%2FUnitTest=05%7C01%7Cjbobek%40nvidia.com%7Cf2eff15ce44945cc0b4e08db00ad6625%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638104516992386171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=djptmpLUwESbPeqFwFUz5sVbS1MBnD%2FPua9H2y1nxFE%3D=0>

I've done an ad-hoc test by commenting out the switch to/from Custom
mode in EnrollFromDefaultKeysApp from SecurityPkg, booting in Setup mode
and using the modified app to enroll the keys. You could do a similar
test from the OS, but in my case this was more straightforward.

I am aware of the host-based unit testing library in edk2, and I agree
that it would be great to have the code in AuthVariableLib tested for
all the different cases. However, I d

Re: [edk2-devel] [PATCH v1 0/4] Don't require self-signed PK in setup mode

[Sean]

I read your replacement a little different.

-  if ((InCustomMode () && UserPhysicalPresent ()) || ((mPlatformMode == SETUP_MODE) 
&& !IsPk)) {

with

+  if (  (InCustomMode () && UserPhysicalPresent ())
+ || (  (mPlatformMode == SETUP_MODE)
+&& !(FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk)))
+  {


In the upper part you replaced it says !IsPk.  What am i missing?


If a payload was in this function targeting a KEK change with no PK installed 
it would go in the original IF condition.
In the new code it would  because device is not in custom mode and the payload 
is not targeted PK.

Thanks
Sean
 




On 1/25/2023 1:38 PM, Jan Bobek wrote:

Hi Sean,


 From looking over the patch 1/4 email i have a concern.

In AuthService.c on the conditional change you made. Aren't we losing
a case where we are evaluating a nonPK payload signed by the PK?
Given the system is in SetupMode that means there is no PK but is this
the conditional path that is used when installing Secure boot keys in
reverse (DBX,DX,KEK,PK) order?

Thanks for sharing your concern! They way I think about the change is
that I've replaced the expression

 IsPk

with

 FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk

and nothing else. When you look at it this way, it's fairly easy to
break down how it affects the logic:

1. Assume PcdRequireSelfSignedPk is TRUE. In this case, the two
expressions are exactly the same and no change in behavior occurs,
just as we want.

2. Assume IsPk is FALSE. In this case, both expressions evaluate to
FALSE, no matter what the PCD is configured to. That's also good,
because we don't want to change how non-PK payloads are handled.

3. In fact, the only change in behavior that occurs is when
PcdRequireSelfSignedPk is FALSE and IsPk is TRUE; here the former
expression would be TRUE, whereas the latter is FALSE. That's exactly
what we want: we wish to enter the first block of the if-else branch
(which changes the variable similarly to when we're in custom mode)
rather than falling through to the third block (which checks the
self-signature).

To directly answer your question, I don't think the behavior changes at
all when processing non-PK payloads, by virtue of IsPk being FALSE and
what I said in point (2.) above.

Additionally, yes, the first block of the if-else branch is exactly the
path that's taken when enrolling KEK/DB/DBX in Setup mode, and one that
has always been available even without Custom mode. It used to be that
you couldn't use this path to enroll PK without Custom mode (precisely
because of !IsPk in the condition), but I'm hoping to enable this path
with my patch.

Let me know if I haven't answered or misunderstood your question.


Is there testing you have done?  This code should be pretty easy to do
host based unit testing on. Any chance you have authored that to
confirm use cases are not unexpectedly impacted?  Example of host
based unit test of library is here:
edk2/SecurityPkg/Library/SecureBootVariableLib/UnitTest at master ·
tianocore/edk2
(github.com)<https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/SecureBootVariableLib/UnitTest>

I've done an ad-hoc test by commenting out the switch to/from Custom
mode in EnrollFromDefaultKeysApp from SecurityPkg, booting in Setup mode
and using the modified app to enroll the keys. You could do a similar
test from the OS, but in my case this was more straightforward.

I am aware of the host-based unit testing library in edk2, and I agree
that it would be great to have the code in AuthVariableLib tested for
all the different cases. However, I don't have any such tests right now,
and while I'm willing to potentially look into writing some, I'd have to
do it more or less on the side, meaning it could take a while.

Best,
-Jan


On 1/22/2023 10:13 PM, Yao, Jiewen wrote:

Hi Sean
I would like to hear your feedback, since it is a little different from the 
original MSFT patch.

Would you please take a look?

Thank you
Yao, Jiewen



-Original Message-
From: Jan Bobek <mailto:jbo...@nvidia.com>
Sent: Saturday, January 21, 2023 6:59 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Jan Bobek <mailto:jbo...@nvidia.com>; Laszlo Ersek 
<mailto:ler...@redhat.com>; Yao,
Jiewen <mailto:jiewen@intel.com>
Subject: [PATCH v1 0/4] Don't require self-signed PK in setup mode

Hi all,

I'm sending out v1 of my patch series that addresses a UEFI spec
non-compliance when enrolling PK in setup mode. Additional info can be
found in bugzilla [1]; the changes are split into 4 patches as
suggested by Laszlo Ersek in comment #4.

I've based my work on the patch by Matthew Carlson; I've credited him
with co-authorship of the first patch even though in the end I decided
to do the implementation a bit differently.

Comments & reviews welcome!

Cheers,
-Jan

References:
1. https://bugzilla.tianocore.o

Re: [edk2-devel] [PATCH v1 0/4] Don't require self-signed PK in setup mode

[Sean]

Jan,

From looking over the patch 1/4 email i have a concern.

In AuthService.c on the conditional change you made.  Aren't we losing a 
case where we are evaluating a nonPK payload signed by the PK?  Given 
the system is in SetupMode that means there is no PK but is this the 
conditional path that is used when installing Secure boot keys in 
reverse (DBX,DX,KEK,PK) order?


Is there testing you have done?  This code should be pretty easy to do 
host based unit testing on.  Any chance you have authored that to 
confirm use cases are not unexpectedly impacted?  Example of host based 
unit test of library is here: 
edk2/SecurityPkg/Library/SecureBootVariableLib/UnitTest at master · 
tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/SecureBootVariableLib/UnitTest>



Thanks

Sean




On 1/22/2023 10:13 PM, Yao, Jiewen wrote:

Hi Sean
I would like to hear your feedback, since it is a little different from the 
original MSFT patch.

Would you please take a look?

Thank you
Yao, Jiewen


-Original Message-
From: Jan Bobek
Sent: Saturday, January 21, 2023 6:59 AM
To:devel@edk2.groups.io
Cc: Jan Bobek; Laszlo Ersek; Yao,
Jiewen
Subject: [PATCH v1 0/4] Don't require self-signed PK in setup mode

Hi all,

I'm sending out v1 of my patch series that addresses a UEFI spec
non-compliance when enrolling PK in setup mode. Additional info can be
found in bugzilla [1]; the changes are split into 4 patches as
suggested by Laszlo Ersek in comment #4.

I've based my work on the patch by Matthew Carlson; I've credited him
with co-authorship of the first patch even though in the end I decided
to do the implementation a bit differently.

Comments & reviews welcome!

Cheers,
-Jan

References:
1.https://bugzilla.tianocore.org/show_bug.cgi?id=2506

Jan Bobek (4):
   SecurityPkg: limit verification of enrolled PK in setup mode
   OvmfPkg: require self-signed PK when secure boot is enabled
   ArmVirtPkg: require self-signed PK when secure boot is enabled
   SecurityPkg: don't require PK to be self-signed by default

  SecurityPkg/SecurityPkg.dec | 7 +++
  ArmVirtPkg/ArmVirtCloudHv.dsc   | 4 
  ArmVirtPkg/ArmVirtQemu.dsc  | 4 
  ArmVirtPkg/ArmVirtQemuKernel.dsc| 4 
  OvmfPkg/Bhyve/BhyveX64.dsc  | 3 +++
  OvmfPkg/CloudHv/CloudHvX64.dsc  | 3 +++
  OvmfPkg/IntelTdx/IntelTdxX64.dsc| 3 +++
  OvmfPkg/Microvm/MicrovmX64.dsc  | 3 +++
  OvmfPkg/OvmfPkgIa32.dsc | 3 +++
  OvmfPkg/OvmfPkgIa32X64.dsc  | 3 +++
  OvmfPkg/OvmfPkgX64.dsc  | 3 +++
  SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 3 +++
  SecurityPkg/Library/AuthVariableLib/AuthService.c   | 9 +++--
  13 files changed, 50 insertions(+), 2 deletions(-)

--
2.30.2









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

Re: [edk2-devel] edk2-platforms, continuous integration, testing, and you

[Sean]

how about 10am pacific Jan 17th.  should be 7pm your time?

Thanks

Sean


On 1/5/2023 3:48 PM, Théo Jehl wrote:
it work that day I believe, but only 2-3 hours later. Does that work 
for you folks? 



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

Re: [edk2-devel] How to select boot device for current boot in response to IPMI System Boot Options commands?

[Sean]

Jeshua,

I did ask my team how we have incorporated IPMI boot features into BDS.  
There are two main points.


1.  The BDS you see in edk2 is very rarely used as is for commercial 
products.  In fact, most PC class systems and servers have a lot of 
customization in the BDS.


2. The BDS you see in edk2 has no concept of "generic boot options".  
IPMI basically says I want to boot some "generic" thing like HDD.  Some 
platform code has to convert HDD into something real that the BDS/UEFI 
system can actually boot.   For example in Project Mu we have a BDS with 
a concept of generic platform boot options.  These boot options actually 
just boot a platform defined firmware application which then can 
interpret the "generic" request and runs a platform defined algorithm 
for finding something bootable.   Using the HDD example, it would 
connect the storage drivers  (say NVME Dxe driver) and then enumerate 
each of storage device found in a defined order and look for a 
efi/boot{arch} file.  This would then allow the IPMI defined generic 
options to actually convert into a boot path that BDS could use.



Regarding the handling of BootNext specifically this is modified as part 
of the larger overhaul to the BDS and its relevant libraries/APIs.


My expectation is this doesn't really help you with your current problem 
but might give some context as to why this functionality isn't 
integrated in the edk2 BDS and you haven't got a lot of feedback from 
the mailing list.  If interested I can provide more info on our BDS in 
Project Mu and reference platform bds implementation used here 
microsoft/mu_tiano_platforms: Project Mu Virtual Platform Firmware 
(github.com) <https://github.com/microsoft/mu_tiano_platforms>


Thanks

Sean




On 1/10/2023 7:53 AM, Jeshua Smith via groups.io wrote:


Any input on this?

It seems that the current behavior isn’t ideal:

  * If BootNext is already set when PlatformBootManagerLib APIs are
called, a new BootNext value from the PlatformBootManagerLib code
will be *ignored* (because the original value is cached before the
APIs have a chance to set it) and then deleted (when the cached
value is consumed after the APIs have been called)
  * If BootNext is not already set, then the current boot will not be
affected by the BootNext value that PlatformBootManagerLib API
code sets (because there was no value when the value was cached),
but the *subsequent* boot will boot with the BootNext value set by
the APIs during the current boot (because not having a cached
value skips the deletion of BootNext).

To me this seems inconsistent and confusing.

*From:* devel@edk2.groups.io  *On Behalf Of 
*Jeshua Smith via groups.io

*Sent:* Tuesday, January 3, 2023 11:32 AM
*To:* devel@edk2.groups.io
*Cc:* Zhichao Gao ; Ray Ni 
*Subject:* [edk2-devel] How to select boot device for current boot in 
response to IPMI System Boot Options commands?


*External email: Use caution opening links or attachments*

Happy New Year!

I’m trying to figure out the proper place to add code to allow the EFI 
boot code to respond to the IPMI System Boot Options request to boot a 
device on the current boot. My initial thought was to change BootNext 
in the PlatformBootManagerLib APIs, but based on the comment 
https://www.mail-archive.com/edk2-devel@lists.01.org/msg30378.html it 
looks like that is **intentionally** unsupported. Does anyone know why 
we want to avoid PlatformBootManagerLib hooks from being able to set 
BootNext to control what gets booted on the current boot? Is there an 
intended alternative way to support the IPMI System Boot Options 
Command request to use a boot device for the current boot?


Thanks,

Jeshua Smith





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

Re: [edk2-devel] [PATCH] .azurepipelines: Skip CodeCoverage if coverage.xml not found

[Sean]

Reviewed-by: Sean Brogan 


On 1/5/2023 4:44 PM, Guo, Gua wrote:

From: Gua Guo 

Skip CodeCoverage if coverage.xml not found

Cc: Sean Brogan 
Cc: Michael Kubacki 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Gua Guo 
---
  .azurepipelines/templates/pr-gate-build-job.yml | 8 
  1 file changed, 8 insertions(+)

diff --git a/.azurepipelines/templates/pr-gate-build-job.yml 
b/.azurepipelines/templates/pr-gate-build-job.yml
index 840852b606..fff61a3193 100644
--- a/.azurepipelines/templates/pr-gate-build-job.yml
+++ b/.azurepipelines/templates/pr-gate-build-job.yml
@@ -100,16 +100,24 @@ jobs:
  buildType: 'current'

  targetPath: '$(Build.ArtifactStagingDirectory)'

  


+- powershell: Write-Host "##vso[task.setvariable 
variable=is_code_coverage]0"

+  displayName: Give default value for whether CodeCoverage or not

+

+- powershell: if (Test-Path -Path $(Build.ArtifactStagingDirectory)/**/coverage.xml) 
{Write-Host "##vso[task.setvariable variable=is_code_coverage]1"}

+  displayName: Check coverage.xml exist or not

+

  - task: CmdLine@2

displayName: Create code coverage report

inputs:

  script: |

dotnet tool install -g dotnet-reportgenerator-globaltool

reportgenerator 
-reports:$(Build.ArtifactStagingDirectory)/**/coverage.xml 
-targetdir:$(Build.ArtifactStagingDirectory)/Coverage -reporttypes:Cobertura 
-filefilters:-*Build*;-*UnitTest*;-*Mock*;-*usr*

+  condition: eq(variables.is_code_coverage, 1)

  


  - task: PublishCodeCoverageResults@1

displayName: 'Publish code coverage'

inputs:

  codeCoverageTool: Cobertura

  summaryFileLocation: 
'$(Build.ArtifactStagingDirectory)/Coverage/Cobertura.xml'

+  condition: eq(variables.is_code_coverage, 1)

  




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

Re: [edk2-devel] edk2-platforms, continuous integration, testing, and you

[Sean]

Pedro,

Thanks.  Happy to get some feedback.  I hope others also provide 
feedback.  :)



Regarding the Edk2 tools & CI meeting:  If we scheduled the Jan 16th 
meeting for Jan 17th at 8am Pacific (should be 5 pm your time) would 
that work?  In the meeting we have discussed that we need to rotate the 
time of the meetings to accommodate more world wide attendance and given 
the standard time would fall on a US holiday it seems like a good week 
to do it.  Could you make it that day?


At a minimum we could talk about your packages:

Like should ext4 really depend on redfishpkg?  More likely the library 
should be promoted to a more "core" package.


Could your qemu open board pkg be built using stuart and setup to run 
tests?  More details about the goals and plans for the qemu open board pkg.



Thanks

Sean




On 1/4/2023 3:57 PM, Pedro Falcato wrote:

Sean,

Thank you for making edk2 better :)

I have replied to your github discussion with a bunch of my ideas, as 
both a feature package maintainer and platform maintainer.

(https://github.com/tianocore/edk2/discussions/3721#discussioncomment-4596465)

I'm willing to discuss these things further as long as it's not at 
*checks edk2 tools & CI meeting time* 1am (email, chat, 1-on-1, you 
name it).
I am also interested in getting QemuOpenBoardPkg into your platform CI 
initiative as it's a simple platform that only requires QEMU to boot 
(plus a copy of edk2-platforms and edk2 to build).


--
Pedro



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

[edk2-devel] edk2-platforms, continuous integration, testing, and you

[Sean]

There has been a long standing ask to/from the Edk2/UEFI community to 
improve the code contribution process, quality, and consistency of the 
edk2-platforms repository.


In the weekly Tianocore Tools & CI meeting this topic has come up and 
was discussed at the last meeting (12/12) Tools & CI Meeting - 
2022-12-12 - YouTube 
<https://www.youtube.com/watch?v=RlHv5v6YvCM=PLzduEkFEN7nXFjWyGOldPBO-aX02zwZc3=1>



There are two asks.

1. If you own any feature package or platform in edk2-platforms please 
get involved in the discussion.  The CI system should reflect the tests 
and features that are important to the contributors of the repository.


A CI system for Edk2-Platforms · Discussion #3721 · tianocore/edk2 
(github.com) <https://github.com/tianocore/edk2/discussions/3721>



2.  If you own a feature package help get your package passing "Core CI" 
and look at enabling more testing (host based unit tests and/or on 
device functional tests).


There is a branch here: spbrogan/edk2-platforms at enable_ci_v1 
(github.com) 
<https://github.com/spbrogan/edk2-platforms/tree/enable_ci_v1> where I 
have started to enable Core CI (started with Ext4Pkg and 
Usb3DebugFeaturePkg as examples).




Thanks

Sean





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

Re: [edk2-devel] [PATCH v8 0/3] Add code coverage support for GCC/MSVC

[Sean]

Looks like a great first step for code coverage collection.

The container support patch series will need to be updated (since it 
hasn't yet been merged) and it will need to account for the new 
requirements for code coverage.


In the future i would like to see the local experience improved (HTML 
reports generated) and metrics tracked per package instead of build 
wide.  These topics can be discussed at the Monday tools meeting but I 
think this series as is should be merged now to start collecting this data.


Thanks for all your efforts.


Series Reviewed-by: Sean Brogan



On 1/2/2023 3:24 AM, Guo, Gua wrote:

From: Gua Guo 

V1: Add coverage option for GCC
V2: Add ReadMe.md for how to generate coverage report
V3: Add VS2019 and GCC code coverage support
V4: Add VS2019 and GCC Azure CI/CD support
V5: Fix some typo and some flow issue
V6: Remove html coverage information
   - Due to python 3.11 install lxml will be failure,
   pycobertura need it to convert cobertura format to
   html file.
   - Add section for developer how to use OpenCppCoverage
   on IDE Visual Studio
V7: Remove redundant code and add code coverage pipeline support
   - Remove redundant code on HostBasedUnitTestRunner.py
   - Unify coding rule on HostBasedUnitTestRunner.py
   - Add CodeCoverage Azure pipeline support for GCC5 and VS2019

Gua Guo (3):
   UnitTestFrameworkPkg: Add code coverage support for GCC
   BaseTools/Plugin: Add coverage support for Unit Test
   .azurepipelines: Install code coverage tool

  .azurepipelines/Ubuntu-GCC5.yml   |   5 +-
  .azurepipelines/Windows-VS2019.yml|   5 +
  .../templates/pr-gate-build-job.yml   |  36 +++
  .azurepipelines/templates/pr-gate-steps.yml   |   4 +
  .../HostBasedUnitTestRunner.py| 101 +-
  UnitTestFrameworkPkg/ReadMe.md|  41 +++
  .../UnitTestFrameworkPkg.ci.yaml  |   1 +
  .../UnitTestFrameworkPkgHost.dsc.inc  |   3 +-
  pip-requirements.txt  |   2 +
  9 files changed, 195 insertions(+), 3 deletions(-)




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

Re: [edk2-devel] edk2-wiki: "How to build with Stuart" - suggested changes/additions

[Sean]

Rebecca,

I don't see detailed instructions for how to build the base tools in the new 
wiki pages. But if you use the python /pytool method then a path file is 
generated and Stuart will set the path correctly.

This file should be used to build the base tools
https://github.com/tianocore/edk2/blob/master/BaseTools/Edk2ToolsBuild.py

You can read a little more about the feature here. 
https://www.tianocore.org/edk2-pytool-extensions/features/sde/#path_env-descriptors

Thanks
Sean



From: devel@edk2.groups.io  on behalf of Michael D Kinney 

Sent: Thursday, December 29, 2022 9:22 AM
To: devel@edk2.groups.io ; rebe...@bsdio.com 
; Kubacki, Michael 
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] edk2-wiki: "How to build with Stuart" - suggested 
changes/additions

+Michael Kubacki

> -Original Message-
> From: Rebecca Cran 
> Sent: Wednesday, December 28, 2022 7:47 PM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] edk2-wiki: "How to build with Stuart" - suggested 
> changes/additions
>
> I also found a problem on Windows. It seems that BaseTools\Bin\Win32
> isn't added to %PATH% unless you run edksetup.bat - or, if you're using
> PowerShell, you can run:
>
>
> $Env:PATH =
> "$pwd\BaseTools\Bin\Win32$([System.IO.Path]::PathSeparator)$Env:PATH"
>
>
> --
> Rebecca Cran
>
>
> On 12/24/22 10:37, Rebecca Cran wrote:
> > Mike,
> >
> >
> > I tried following the "How to build with Stuart" document and ran into
> > a some issues on my Ubuntu 20.04 system:
> >
> >
> > First, we now need to use "python3.9" on Ubuntu 20.04 since "python3"
> > is 3.8 which no longer works.
> >
> >
> > Secondly, the loongarch64 gcc download is 930MB - 3.2GB once unpacked.
> > We might want to add something about specifying "-a LOONGARCH64" etc.
> > if you want to build it, or '-a X64,AARCH64' etc. if you want to skip
> > it. I ended up canceling "stuart_update" because I thought it had hung.
> >
> >
> > Lastly, the "stuart_update" command listed doesn't work: it seems you
> > need to specify a TOOL_CHAIN_TAG to have it download anything.
> >
> >







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

Re: [edk2-devel] [PATCH] MdeModulePkg/Bus/Pci/XhciDxe: Reset the port if status change returns an error

[Sean Rhodes]

Hi Hao

This PR has passed CI - https://github.com/tianocore/edk2/pull/3353

Thanks

Sean

On Fri, 23 Dec 2022 at 08:56, Wu, Hao A  wrote:

> Sorry,
>
> The CI tests failed for the proposed patch:
> https://github.com/tianocore/edk2/pull/3824
>
> Could you help to check and resolve? Thanks.
>
> Best Regards,
> Hao Wu
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> > Rhodes
> > Sent: Wednesday, December 21, 2022 4:15 PM
> > To: devel@edk2.groups.io
> > Cc: Rhodes, Sean 
> > Subject: [edk2-devel] [PATCH] MdeModulePkg/Bus/Pci/XhciDxe: Reset the
> > port if status change returns an error
> >
> > Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit in
> > PortChangeStatus
> > when XhcPollPortStatusChange fails
> >
> > Signed-off-by: Sean Rhodes 
> > ---
> >  MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > index 461b2cd9b5..d8fa41f68f 100644
> > --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> > @@ -471,7 +471,16 @@ XhcGetRootHubPortStatus (
> >// For those devices behind hub, we get its attach/detach event by
> hooking
> > Get_Port_Status request at control transfer for those hub.
> >
> >//
> >
> >ParentRouteChart.Dword = 0;
> >
> > -  XhcPollPortStatusChange (Xhc, ParentRouteChart, PortNumber,
> PortStatus);
> >
> > +  Status = XhcPollPortStatusChange (Xhc,
> ParentRouteChart,
> > PortNumber, PortStatus);
> >
> > +
> >
> > +  //
> >
> > +  // Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit
> in
> > PortChangeStatus
> >
> > +  // when XhcPollPortStatusChange fails
> >
> > +  //
> >
> > +  if (EFI_ERROR (Status)) {
> >
> > +PortStatus->PortChangeStatus &= ~(USB_PORT_STAT_C_RESET);
> >
> > +Status= EFI_SUCCESS;
> >
> > +  }
> >
> >
> >
> >  ON_EXIT:
> >
> >gBS->RestoreTPL (OldTpl);
> >
> > --
> > 2.37.2
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#97683): https://edk2.groups.io/g/devel/message/97683
> > Mute This Topic: https://groups.io/mt/95802798/1768737
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe: https://edk2.groups.io/g/devel/unsub [hao.a...@intel.com]
> > -=-=-=-=-=-=
> >
>
>
>
> 
>
>
>


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

Re: [edk2-devel][PATCH] UefiPayloadPkg: Fix boot issue for non-universal payload

[Sean Rhodes]

Okay, a bit more testing - it seems all debug builds hang at that point. I
tested back to edk2-stable202111 so I think that's a coreboot problem.

Your patch does resolve release builds not booting.

> Could you help to use latest Edk2 repo UPL to reproduce the issue that @Sean
Rhodes  encounter from Coreboot + ShimLayer + UPL ?


I'm only testing non-universal payload - the shimlayer doesn't work as
no-one could figure out how to make `ElfCt->FileSize` the right size.

On Thu, 22 Dec 2022 at 02:49, Lu, James  wrote:

> Reviewed-by: James Lu 
>
> -Original Message-
> From: Dong, Guo 
> Sent: Thursday, December 22, 2022 5:25 AM
> To: devel@edk2.groups.io
> Cc: Dong, Guo ; Ni, Ray ; Rhodes,
> Sean ; Lu, James ; Guo, Gua <
> gua@intel.com>
> Subject: [edk2-devel][PATCH] UefiPayloadPkg: Fix boot issue for
> non-universal payload
>
> From: Guo Dong 
>
> BDS module was moved from DXEFV to newly created BDSFV recently.
> Non-universal UEFI payload doesn't support multiple FV, so it failed to
> boot since BDS module could not be found.
> This patch add BDS back to DXEFV when UNIVERSAL_PAYLOAD is not set.
>
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Guo Dong 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index 94ba922244..ee7d718b3f 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -59,9 +59,6 @@ INF UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
>  FILE FV_IMAGE = 4E35FD93-9C72-4c15-8C4B-E77F1DB2D793 { SECTION
> FV_IMAGE = DXEFV }-FILE FV_IMAGE = FBE6C1E3-2F80-4770-88B0-494186E3346F {-
>   SECTION FV_IMAGE = BDSFV-}
> 
> [FV.BDSFV]@@ -277,6 +274,10 @@ INF
> MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
>  INF
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> !endif +!if $(UNIVERSAL_PAYLOAD) == FALSE+INF
> MdeModulePkg/Universal/BdsDxe/BdsDxe.inf+!endif+ # # UEFI network modules
> #--
> 2.35.1.windows.2
>
>
>
> 
>
>
>


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

Re: [edk2-devel][PATCH] UefiPayloadPkg: Fix boot issue for non-universal payload

[Sean Rhodes]

LGTM but it still hangs on Qemu and real hardware.

Debug build shows:
Building ResourceDescriptorHobs for reserved memory:
0.  - 0FFF [10]
buildhob: base = 0x0, size = 0x1000, type = 0x5
1. 1000 - 0009 [01]
2. 000A - 000F [02]
buildhob: base = 0xA, size = 0x6, type = 0x5
3. 0010 - 00F4CFFF [01]
4. 00F4D000 - 00FF [10]
buildhob: base = 0xF4D000, size = 0xB3000, type = 0x5
5. 0100 - 07FF [01]
6. B000 - BFFF [02]
buildhob: base = 0xB000, size = 0x1000, type = 0x1
Building hob to restrict memory resorces to below 4G.
DxeCoreEntryPoint = 0x4DE7DA1
PayloadEntry: AddressBits=40 5LevelPaging=0 1GPage=0
Pml5=1 Pml4=2 Pdp=512 TotalPage=1027
HandOffToDxeCore() Stack Base: 0x4DAE000, Stack Size: 0x2

On Wed, 21 Dec 2022 at 21:24,  wrote:

> From: Guo Dong 
>
> BDS module was moved from DXEFV to newly created BDSFV recently.
> Non-universal UEFI payload doesn't support multiple FV, so it failed
> to boot since BDS module could not be found.
> This patch add BDS back to DXEFV when UNIVERSAL_PAYLOAD is not set.
>
> Cc: Ray Ni 
> Cc: Sean Rhodes 
> Cc: James Lu 
> Cc: Gua Guo 
> Signed-off-by: Guo Dong 
> ---
>  UefiPayloadPkg/UefiPayloadPkg.fdf | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.fdf
> b/UefiPayloadPkg/UefiPayloadPkg.fdf
> index 94ba922244..ee7d718b3f 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.fdf
> +++ b/UefiPayloadPkg/UefiPayloadPkg.fdf
> @@ -59,9 +59,6 @@ INF UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
>  FILE FV_IMAGE = 4E35FD93-9C72-4c15-8C4B-E77F1DB2D793 {
>  SECTION FV_IMAGE = DXEFV
>  }
> -FILE FV_IMAGE = FBE6C1E3-2F80-4770-88B0-494186E3346F {
> -SECTION FV_IMAGE = BDSFV
> -}
>
>
>  
> 
>  [FV.BDSFV]
> @@ -277,6 +274,10 @@ INF
> MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
>  INF
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>  !endif
>
> +!if $(UNIVERSAL_PAYLOAD) == FALSE
> +INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> +!endif
> +
>  #
>  # UEFI network modules
>  #
> --
> 2.35.1.windows.2
>
>


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

[edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

When set to true, the Logo is positioned according to the BGRT
specification, 38.2% from the top of the screen. When set to false,
no behaviour is changed and the logo is positioned centrally.

Cc: Zhichao Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/MdeModulePkg.dec |  6 ++
 MdeModulePkg/Logo/LogoDxe.inf |  4 
 MdeModulePkg/Logo/Logo.c  | 28 +++-
 MdeModulePkg/MdeModulePkg.uni |  6 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index be5e829ca9..c8bb51df3b 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2102,6 +2102,12 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # @Prompt The shared bit mask when Intel Tdx is enabled.
   gEfiMdeModulePkgTokenSpaceGuid.PcdTdxSharedBitMask|0x0|UINT64|0x1025
 
+  ## This PCD sets the position of the Boot Logo.
+  #   TRUE  - The Logo is positioned following the recommendations from 
Microsoft.
+  #   FALSE - The logo is positioned in the center of the screen.
+  # @ Prompt This position of the boot logo
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended|FALSE|BOOLEAN|0x1026
+
 [PcdsPatchableInModule]
   ## Specify memory size with page number for PEI code when
   #  Loading Module at Fixed Address feature is enabled.
diff --git a/MdeModulePkg/Logo/LogoDxe.inf b/MdeModulePkg/Logo/LogoDxe.inf
index 41215d25d8..ce29950089 100644
--- a/MdeModulePkg/Logo/LogoDxe.inf
+++ b/MdeModulePkg/Logo/LogoDxe.inf
@@ -41,6 +41,7 @@ [LibraryClasses]
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   DebugLib
+  PcdLib
 
 [Protocols]
   gEfiHiiDatabaseProtocolGuid## CONSUMES
@@ -48,6 +49,9 @@ [Protocols]
   gEfiHiiPackageListProtocolGuid ## PRODUCES CONSUMES
   gEdkiiPlatformLogoProtocolGuid ## PRODUCES
 
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended ## CONSUMES
+
 [Depex]
   gEfiHiiDatabaseProtocolGuid AND
   gEfiHiiImageExProtocolGuid
diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
index 8ab874d2da..96e34b2011 100644
--- a/MdeModulePkg/Logo/Logo.c
+++ b/MdeModulePkg/Logo/Logo.c
@@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 typedef struct {
   EFI_IMAGE_ID ImageId;
@@ -51,12 +52,14 @@ GetImage (
   IN EDKII_PLATFORM_LOGO_PROTOCOL*This,
   IN OUT UINT32  *Instance,
   OUT EFI_IMAGE_INPUT*Image,
+  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput,
   OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE  *Attribute,
   OUT INTN   *OffsetX,
   OUT INTN   *OffsetY
   )
 {
-  UINT32  Current;
+  UINT32  Current;
+  EFI_STATUS  Status;
 
   if ((Instance == NULL) || (Image == NULL) ||
   (Attribute == NULL) || (OffsetX == NULL) || (OffsetY == NULL))
@@ -69,6 +72,29 @@ GetImage (
 return EFI_NOT_FOUND;
   }
 
+  if (PcdGetBool (PcdFollowMicrosoftRecommended)) {
+//
+// Get current video resolution and text mode
+//
+Status = gBS->HandleProtocol (
+gST->ConsoleOutHandle,
+,
+(VOID **)
+);
+if (!EFI_ERROR (Status)) {
+  //
+  // Center of LOGO is in the vertical position 38.2% when 
PcdBootLogoOnlyEnable is TRUE
+  // Y = (VerticalResolution - LogoHeight) / 2
+  // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
+  // OffsetY + Y = Y'
+  // OffsetY = Y' - Y = -0.118 * VerticalResolution
+  //
+  *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
+  *OffsetX   = 0;
+  *OffsetY   = -118 * (INTN)GraphicsOutput->Mode->Info->VerticalResolution 
/ 1000;
+}
+  }
+
   (*Instance)++;
   *Attribute = mLogos[Current].Attribute;
   *OffsetX   = mLogos[Current].OffsetX;
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 33ce9f6198..09c1ac1cc1 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1338,3 +1338,9 @@
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdPcieResizableBarSupport_HELP 
#language en-US "Indicates if the PCIe Resizable BAR Capability 
Supported.\n"

 "TRUE  - PCIe Resizable BAR Capability is supported.\n"

 "FALSE - PCIe Resizable BAR Capability is not supported."
+
+#string 
STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommended_PROMPT 
#language en-US "The position of the Boot Logo"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommend_HELP   
#language en-US "Sets the pos

[edk2-devel] [PATCH] MdeModulePkg/Bus/Pci/XhciDxe: Reset the port if status change returns an error

[Sean Rhodes]

Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit in 
PortChangeStatus
when XhcPollPortStatusChange fails

Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 461b2cd9b5..d8fa41f68f 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -471,7 +471,16 @@ XhcGetRootHubPortStatus (
   // For those devices behind hub, we get its attach/detach event by hooking 
Get_Port_Status request at control transfer for those hub.
   //
   ParentRouteChart.Dword = 0;
-  XhcPollPortStatusChange (Xhc, ParentRouteChart, PortNumber, PortStatus);
+  Status = XhcPollPortStatusChange (Xhc, ParentRouteChart, 
PortNumber, PortStatus);
+
+  //
+  // Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit in 
PortChangeStatus
+  // when XhcPollPortStatusChange fails
+  //
+  if (EFI_ERROR (Status)) {
+PortStatus->PortChangeStatus &= ~(USB_PORT_STAT_C_RESET);
+Status= EFI_SUCCESS;
+  }
 
 ON_EXIT:
   gBS->RestoreTPL (OldTpl);
-- 
2.37.2



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

[edk2-devel] [PATCH 1/3] MdeModulePkg/BmBoot: Skip removable media if it is not present

[Sean Rhodes]

From: Matt DeVillier 

Only enumerate devices that have media present.

Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Zhichao Gao 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I78a0b8be3e2f33edce2d43bbdd7670e6174d0ff8
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 962892d38f..bde22fa659 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2218,6 +2218,15 @@ BmEnumerateBootOptions (
 continue;
   }
 
+  //
+  // Skip removable media if not present
+  //
+  if ((BlkIo->Media->RemovableMedia == TRUE) &&
+  (BlkIo->Media->MediaPresent == FALSE))
+  {
+continue;
+  }
+
   Description = BmGetBootDescription (Handles[Index]);
   BootOptions = ReallocatePool (
   sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount),
-- 
2.37.2



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

[edk2-devel] [PATCH 2/3] MdeModulePkg/XhciDxe/Xhci: Don't check for invalid PSIV

[Sean Rhodes]

From: Matt DeVillier 

PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: If15c55ab66d2e7faa832ce8576d2e5b47157cc9a
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 44 -
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 15fb49f28f..8dd7a8fbb7 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -371,6 +371,7 @@ XhcGetRootHubPortStatus (
   UINT32 TotalPort;
   UINTN  Index;
   UINTN  MapSize;
+  UINT8  PortSpeed;
   EFI_STATUS Status;
   USB_DEV_ROUTE  ParentRouteChart;
   EFI_TPLOldTpl;
@@ -397,32 +398,37 @@ XhcGetRootHubPortStatus (
 
   State = XhcReadOpReg (Xhc, Offset);
 
+  PortSpeed = (State & XHC_PORTSC_PS) >> 10;
+
   //
   // According to XHCI 1.1 spec November 2017,
   // Section 7.2 xHCI Support Protocol Capability
   //
-  PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, ((State & 
XHC_PORTSC_PS) >> 10));
-  if (PortStatus->PortStatus == 0) {
-//
-// According to XHCI 1.1 spec November 2017,
-// bit 10~13 of the root port status register identifies the speed of the 
attached device.
-//
-switch ((State & XHC_PORTSC_PS) >> 10) {
-  case 2:
-PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
-break;
+  if (PortSpeed > 0) {
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+// If no match found in ext cap reg, fall back to PORTSC
+if (PortStatus->PortStatus == 0) {
+  //
+  // According to XHCI 1.1 spec November 2017,
+  // bit 10~13 of the root port status register identifies the speed of 
the attached device.
+  //
+  switch (PortSpeed) {
+case 2:
+  PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
+  break;
 
-  case 3:
-PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
-break;
+case 3:
+  PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
+  break;
 
-  case 4:
-  case 5:
-PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
-break;
+case 4:
+case 5:
+  PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
+  break;
 
-  default:
-break;
+default:
+  break;
+  }
 }
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 3/3] MdeModulePkg/Bus/Pci/XhciDxe: Check port is compatible before getting PSIV

[Sean Rhodes]

On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indices are shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).

An example can be found below:

XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248

The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.

To avoid incorrect detection, check the Compatible Port Offset to find
the starting Port of Root Hubs that support the protocol.

Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c|  2 +-
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 35 +-
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  8 +++---
 3 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 8dd7a8fbb7..461b2cd9b5 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -405,7 +405,7 @@ XhcGetRootHubPortStatus (
   // Section 7.2 xHCI Support Protocol Capability
   //
   if (PortSpeed > 0) {
-PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed, 
PortNumber);
 // If no match found in ext cap reg, fall back to PORTSC
 if (PortStatus->PortStatus == 0) {
   //
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
index 2b4a4b2444..5700fc5fb8 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
@@ -636,6 +636,7 @@ XhcGetSupportedProtocolCapabilityAddr (
   @param  XhcThe XHCI Instance.
   @param  ExtCapOffset   The USB Major Version in xHCI Support Protocol 
Capability Field
   @param  PortSpeed  The Port Speed Field in USB PortSc register
+  @param  PortNumber The Port Number (0-indexed)
 
   @return The Protocol Speed ID (PSI) from xHCI Supported Protocol capability 
register.
 
@@ -644,12 +645,15 @@ UINT32
 XhciPsivGetPsid (
   IN USB_XHCI_INSTANCE  *Xhc,
   IN UINT32 ExtCapOffset,
-  IN UINT8  PortSpeed
+  IN UINT8  PortSpeed,
+  IN UINT8  PortNumber
   )
 {
   XHC_SUPPORTED_PROTOCOL_DW2PortId;
   XHC_SUPPORTED_PROTOCOL_PROTOCOL_SPEED_ID  Reg;
   UINT32Count;
+  UINT32MinPortIndex;
+  UINT32MaxPortIndex;
 
   if ((Xhc == NULL) || (ExtCapOffset == 0x)) {
 return 0;
@@ -663,6 +667,23 @@ XhciPsivGetPsid (
   //
   PortId.Dword = XhcReadExtCapReg (Xhc, ExtCapOffset + 
XHC_SUPPORTED_PROTOCOL_DW2_OFFSET);
 
+  //
+  // According to XHCI 1.1 spec November 2017, valid values
+  // for CompPortOffset are 1 to CompPortCount - 1.
+  //
+  // PortNumber is zero-indexed, so subtract 1.
+  //
+  if ((PortId.Data.CompPortOffset == 0) || (PortId.Data.CompPortCount == 0)) {
+return 0;
+  }
+
+  MinPortIndex = PortId.Data.CompPortOffset - 1;
+  MaxPortIndex = MinPortIndex + PortId.Data.CompPortCount - 1;
+
+  if ((PortNumber < MinPortIndex) || (PortNumber > MaxPortIndex)) {
+return 0;
+  }
+
   for (Count = 0; Count < PortId.Data.Psic; Count++) {
 Reg.Dword = XhcReadExtCapReg (Xhc, ExtCapOffset + 
XHC_SUPPORTED_PROTOCOL_PSI_OFFSET + (Count << 2));
 if (Reg.Data.Psiv == PortSpeed) {
@@ -676,8 +697,9 @@ XhciPsivGetPsid (
 /**
   Find PortSpeed value match case in XHCI Supported Protocol Capability
 
-  @param  XhcThe XHCI Instance.
-  @param  PortSpeed  The Port Speed Field in USB PortSc register
+  @param  Xhc The XHCI Instance.
+  @param  PortSpeed   The Port Speed Field in USB PortSc register
+  @param  PortNumber  The Port Number (0-indexed)
 
   @return The USB Port Speed.
 
@@ -685,7 +707,8 @@ XhciPsivGetPsid (
 UINT16
 XhcCheckUsbPortSpeedUsedPsic (
   IN USB_XHCI_INSTANCE  *Xhc,
-  IN UINT8  PortSpeed
+  IN UINT8  PortSpeed,
+  IN UINT8  PortNumber
   )
 {
   XHC_SUPPORTED_PROTOCOL_PROTOCOL_SPEED_ID  SpField;
@@ -703,7 +726,7 @@ XhcCheckUsbPortSpeedUsedPsic (
   // PortSpeed definition when the Major Revision is 03h.
   //
   if (Xhc->Usb3SupOffset != 0x) {
-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
+SpField.

Re: [edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Mike

Thanks; didn't work but I'll have a play wth it!

Sean

On Thu, 15 Dec 2022 at 22:55, Michael D Kinney 
wrote:

> Hi Sean,
>
>
>
> Yes, that is the correct section.  Hard to tell from patch email alone.
>
>
>
> There is a git config that can always include the name of the section of
> the INF/DEC/DSC/FDF file where a change is made.
>
> Can make it a bit easier to review.
>
>
>
>
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
>
>
>
> Specifically this one I think:
>
>
>
> git config diff.ini.xfuncname '^\[[A-Za-z0-9_., ]+]'
>
>
>
> Mike
>
>
>
> *From:* Sean Rhodes 
> *Sent:* Thursday, December 15, 2022 2:17 PM
> *To:* Kinney, Michael D 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Ni, Ray
> ; Wang, Jian J ; Gao, Liming <
> gaolim...@byosoft.com.cn>
> *Subject:* Re: [edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Hi Mike
>
>
>
> Thank you; changed to PcdGetBool.
>
>
>
> It's in `[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx]` - is that not right?
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Thu, 15 Dec 2022 at 22:09, Kinney, Michael D <
> michael.d.kin...@intel.com> wrote:
>
> Hi Sean,
>
> A couple comments related to the PCD type below.
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> Rhodes
> > Sent: Thursday, December 15, 2022 1:12 PM
> > To: devel@edk2.groups.io
> > Cc: Rhodes, Sean ; Gao, Zhichao <
> zhichao@intel.com>; Ni, Ray ; Wang, Jian J
> > ; Gao, Liming 
> > Subject: [edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control
> the position of the Logo
> >
> > When set to true, the Logo is positioned according to the BGRT
> > specification, 38.2% from the top of the screen. When set to false,
> > no behaviour is changed and the logo is positioned centrally.
> >
> > Cc: Zhichao Gao 
> > Cc: Ray Ni 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Signed-off-by: Sean Rhodes 
> > ---
> >  MdeModulePkg/Logo/Logo.c  | 28 +++-
> >  MdeModulePkg/Logo/LogoDxe.inf |  4 
> >  MdeModulePkg/MdeModulePkg.dec |  6 ++
> >  MdeModulePkg/MdeModulePkg.uni |  6 ++
> >  4 files changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
> > index 8ab874d2da..48862d3207 100644
> > --- a/MdeModulePkg/Logo/Logo.c
> > +++ b/MdeModulePkg/Logo/Logo.c
> > @@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #include 
> >
> >  #include 
> >
> >  #include 
> >
> > +#include 
> >
> >
> >
> >  typedef struct {
> >
> >EFI_IMAGE_ID ImageId;
> >
> > @@ -51,12 +52,14 @@ GetImage (
> >IN EDKII_PLATFORM_LOGO_PROTOCOL*This,
> >
> >IN OUT UINT32  *Instance,
> >
> >OUT EFI_IMAGE_INPUT*Image,
> >
> > +  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput,
> >
> >OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE  *Attribute,
> >
> >OUT INTN   *OffsetX,
> >
> >OUT INTN   *OffsetY
> >
> >)
> >
> >  {
> >
> > -  UINT32  Current;
> >
> > +  UINT32  Current;
> >
> > +  EFI_STATUS  Status;
> >
> >
> >
> >if ((Instance == NULL) || (Image == NULL) ||
> >
> >(Attribute == NULL) || (OffsetX == NULL) || (OffsetY == NULL))
> >
> > @@ -69,6 +72,29 @@ GetImage (
> >  return EFI_NOT_FOUND;
> >
> >}
> >
> >
> >
> > +  if (FixedPcdGetBool (PcdFollowMicrosoftRecommended)) {
>
> Should be PcdGetBool().  The only time FixedPcdGetxxx() is required is
> if the PCD value is being used to initialize a struct where the value
> is needed at build time.  This allows the PCD type to be flexible and
> can be set in platform scope in the DSC file.
>
> >
> > +//
> >
> > +// Get current video resolution and text mode
> >
> > +//
> >
> > +Status = gBS->HandleProtocol (
> >
> > +gST->ConsoleOutHandle,
> >
> > +,
> >
> > +(VOID **)
> >
&

[edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

When set to true, the Logo is positioned according to the BGRT
specification, 38.2% from the top of the screen. When set to false,
no behaviour is changed and the logo is positioned centrally.

Cc: Zhichao Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Logo/Logo.c  | 28 +++-
 MdeModulePkg/Logo/LogoDxe.inf |  4 
 MdeModulePkg/MdeModulePkg.dec |  6 ++
 MdeModulePkg/MdeModulePkg.uni |  6 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
index 8ab874d2da..96e34b2011 100644
--- a/MdeModulePkg/Logo/Logo.c
+++ b/MdeModulePkg/Logo/Logo.c
@@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 typedef struct {
   EFI_IMAGE_ID ImageId;
@@ -51,12 +52,14 @@ GetImage (
   IN EDKII_PLATFORM_LOGO_PROTOCOL*This,
   IN OUT UINT32  *Instance,
   OUT EFI_IMAGE_INPUT*Image,
+  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput,
   OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE  *Attribute,
   OUT INTN   *OffsetX,
   OUT INTN   *OffsetY
   )
 {
-  UINT32  Current;
+  UINT32  Current;
+  EFI_STATUS  Status;
 
   if ((Instance == NULL) || (Image == NULL) ||
   (Attribute == NULL) || (OffsetX == NULL) || (OffsetY == NULL))
@@ -69,6 +72,29 @@ GetImage (
 return EFI_NOT_FOUND;
   }
 
+  if (PcdGetBool (PcdFollowMicrosoftRecommended)) {
+//
+// Get current video resolution and text mode
+//
+Status = gBS->HandleProtocol (
+gST->ConsoleOutHandle,
+,
+(VOID **)
+);
+if (!EFI_ERROR (Status)) {
+  //
+  // Center of LOGO is in the vertical position 38.2% when 
PcdBootLogoOnlyEnable is TRUE
+  // Y = (VerticalResolution - LogoHeight) / 2
+  // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
+  // OffsetY + Y = Y'
+  // OffsetY = Y' - Y = -0.118 * VerticalResolution
+  //
+  *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
+  *OffsetX   = 0;
+  *OffsetY   = -118 * (INTN)GraphicsOutput->Mode->Info->VerticalResolution 
/ 1000;
+}
+  }
+
   (*Instance)++;
   *Attribute = mLogos[Current].Attribute;
   *OffsetX   = mLogos[Current].OffsetX;
diff --git a/MdeModulePkg/Logo/LogoDxe.inf b/MdeModulePkg/Logo/LogoDxe.inf
index 41215d25d8..ce29950089 100644
--- a/MdeModulePkg/Logo/LogoDxe.inf
+++ b/MdeModulePkg/Logo/LogoDxe.inf
@@ -41,6 +41,7 @@
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   DebugLib
+  PcdLib
 
 [Protocols]
   gEfiHiiDatabaseProtocolGuid## CONSUMES
@@ -48,6 +49,9 @@
   gEfiHiiPackageListProtocolGuid ## PRODUCES CONSUMES
   gEdkiiPlatformLogoProtocolGuid ## PRODUCES
 
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended ## CONSUMES
+
 [Depex]
   gEfiHiiDatabaseProtocolGuid AND
   gEfiHiiImageExProtocolGuid
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index be5e829ca9..c8bb51df3b 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2102,6 +2102,12 @@
   # @Prompt The shared bit mask when Intel Tdx is enabled.
   gEfiMdeModulePkgTokenSpaceGuid.PcdTdxSharedBitMask|0x0|UINT64|0x1025
 
+  ## This PCD sets the position of the Boot Logo.
+  #   TRUE  - The Logo is positioned following the recommendations from 
Microsoft.
+  #   FALSE - The logo is positioned in the center of the screen.
+  # @ Prompt This position of the boot logo
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended|FALSE|BOOLEAN|0x1026
+
 [PcdsPatchableInModule]
   ## Specify memory size with page number for PEI code when
   #  Loading Module at Fixed Address feature is enabled.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 33ce9f6198..09c1ac1cc1 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1338,3 +1338,9 @@
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdPcieResizableBarSupport_HELP 
#language en-US "Indicates if the PCIe Resizable BAR Capability 
Supported.\n"

 "TRUE  - PCIe Resizable BAR Capability is supported.\n"

 "FALSE - PCIe Resizable BAR Capability is not supported."
+
+#string 
STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommended_PROMPT 
#language en-US "The position of the Boot Logo"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommend_HELP   
#language en-US "Sets the position of the Logo. When set to

Re: [edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Mike

Thank you; changed to PcdGetBool.

It's in `[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
PcdsDynamicEx]` - is that not right?

Thanks

Sean

On Thu, 15 Dec 2022 at 22:09, Kinney, Michael D 
wrote:

> Hi Sean,
>
> A couple comments related to the PCD type below.
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> Rhodes
> > Sent: Thursday, December 15, 2022 1:12 PM
> > To: devel@edk2.groups.io
> > Cc: Rhodes, Sean ; Gao, Zhichao <
> zhichao@intel.com>; Ni, Ray ; Wang, Jian J
> > ; Gao, Liming 
> > Subject: [edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control
> the position of the Logo
> >
> > When set to true, the Logo is positioned according to the BGRT
> > specification, 38.2% from the top of the screen. When set to false,
> > no behaviour is changed and the logo is positioned centrally.
> >
> > Cc: Zhichao Gao 
> > Cc: Ray Ni 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Signed-off-by: Sean Rhodes 
> > ---
> >  MdeModulePkg/Logo/Logo.c  | 28 +++-
> >  MdeModulePkg/Logo/LogoDxe.inf |  4 
> >  MdeModulePkg/MdeModulePkg.dec |  6 ++
> >  MdeModulePkg/MdeModulePkg.uni |  6 ++
> >  4 files changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
> > index 8ab874d2da..48862d3207 100644
> > --- a/MdeModulePkg/Logo/Logo.c
> > +++ b/MdeModulePkg/Logo/Logo.c
> > @@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #include 
> >
> >  #include 
> >
> >  #include 
> >
> > +#include 
> >
> >
> >
> >  typedef struct {
> >
> >EFI_IMAGE_ID ImageId;
> >
> > @@ -51,12 +52,14 @@ GetImage (
> >IN EDKII_PLATFORM_LOGO_PROTOCOL*This,
> >
> >IN OUT UINT32  *Instance,
> >
> >OUT EFI_IMAGE_INPUT*Image,
> >
> > +  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput,
> >
> >OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE  *Attribute,
> >
> >OUT INTN   *OffsetX,
> >
> >OUT INTN   *OffsetY
> >
> >)
> >
> >  {
> >
> > -  UINT32  Current;
> >
> > +  UINT32  Current;
> >
> > +  EFI_STATUS  Status;
> >
> >
> >
> >if ((Instance == NULL) || (Image == NULL) ||
> >
> >(Attribute == NULL) || (OffsetX == NULL) || (OffsetY == NULL))
> >
> > @@ -69,6 +72,29 @@ GetImage (
> >  return EFI_NOT_FOUND;
> >
> >}
> >
> >
> >
> > +  if (FixedPcdGetBool (PcdFollowMicrosoftRecommended)) {
>
> Should be PcdGetBool().  The only time FixedPcdGetxxx() is required is
> if the PCD value is being used to initialize a struct where the value
> is needed at build time.  This allows the PCD type to be flexible and
> can be set in platform scope in the DSC file.
>
> >
> > +//
> >
> > +// Get current video resolution and text mode
> >
> > +//
> >
> > +Status = gBS->HandleProtocol (
> >
> > +gST->ConsoleOutHandle,
> >
> > +,
> >
> > +(VOID **)
> >
> > +);
> >
> > +if (!EFI_ERROR (Status)) {
> >
> > +  //
> >
> > +  // Center of LOGO is in the vertical position 38.2% when
> PcdBootLogoOnlyEnable is TRUE
> >
> > +  // Y = (VerticalResolution - LogoHeight) / 2
> >
> > +  // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
> >
> > +  // OffsetY + Y = Y'
> >
> > +  // OffsetY = Y' - Y = -0.118 * VerticalResolution
> >
> > +  //
> >
> > +  *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
> >
> > +  *OffsetX   = 0;
> >
> > +  *OffsetY   = -118 *
> (INTN)GraphicsOutput->Mode->Info->VerticalResolution / 1000;
> >
> > +}
> >
> > +  }
> >
> > +
> >
> >(*Instance)++;
> >
> >*Attribute = mLogos[Current].Attribute;
> >
> >*OffsetX   = mLogos[Current].OffsetX;
> >
> > diff --git a/MdeModulePkg/Logo/LogoDxe.inf
> b/MdeModulePkg/Logo/LogoDxe.inf
> > index 41215d25d8..ce29950089 100644
> > --- a/MdeModulePkg/Logo/LogoDxe.inf
> > +++ b/Md

[edk2-devel] [PATCH] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

When set to true, the Logo is positioned according to the BGRT
specification, 38.2% from the top of the screen. When set to false,
no behaviour is changed and the logo is positioned centrally.

Cc: Zhichao Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
Cc: Liming Gao 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Logo/Logo.c  | 28 +++-
 MdeModulePkg/Logo/LogoDxe.inf |  4 
 MdeModulePkg/MdeModulePkg.dec |  6 ++
 MdeModulePkg/MdeModulePkg.uni |  6 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
index 8ab874d2da..48862d3207 100644
--- a/MdeModulePkg/Logo/Logo.c
+++ b/MdeModulePkg/Logo/Logo.c
@@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 typedef struct {
   EFI_IMAGE_ID ImageId;
@@ -51,12 +52,14 @@ GetImage (
   IN EDKII_PLATFORM_LOGO_PROTOCOL*This,
   IN OUT UINT32  *Instance,
   OUT EFI_IMAGE_INPUT*Image,
+  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput,
   OUT EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE  *Attribute,
   OUT INTN   *OffsetX,
   OUT INTN   *OffsetY
   )
 {
-  UINT32  Current;
+  UINT32  Current;
+  EFI_STATUS  Status;
 
   if ((Instance == NULL) || (Image == NULL) ||
   (Attribute == NULL) || (OffsetX == NULL) || (OffsetY == NULL))
@@ -69,6 +72,29 @@ GetImage (
 return EFI_NOT_FOUND;
   }
 
+  if (FixedPcdGetBool (PcdFollowMicrosoftRecommended)) {
+//
+// Get current video resolution and text mode
+//
+Status = gBS->HandleProtocol (
+gST->ConsoleOutHandle,
+,
+(VOID **)
+);
+if (!EFI_ERROR (Status)) {
+  //
+  // Center of LOGO is in the vertical position 38.2% when 
PcdBootLogoOnlyEnable is TRUE
+  // Y = (VerticalResolution - LogoHeight) / 2
+  // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
+  // OffsetY + Y = Y'
+  // OffsetY = Y' - Y = -0.118 * VerticalResolution
+  //
+  *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
+  *OffsetX   = 0;
+  *OffsetY   = -118 * (INTN)GraphicsOutput->Mode->Info->VerticalResolution 
/ 1000;
+}
+  }
+
   (*Instance)++;
   *Attribute = mLogos[Current].Attribute;
   *OffsetX   = mLogos[Current].OffsetX;
diff --git a/MdeModulePkg/Logo/LogoDxe.inf b/MdeModulePkg/Logo/LogoDxe.inf
index 41215d25d8..ce29950089 100644
--- a/MdeModulePkg/Logo/LogoDxe.inf
+++ b/MdeModulePkg/Logo/LogoDxe.inf
@@ -41,6 +41,7 @@
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   DebugLib
+  PcdLib
 
 [Protocols]
   gEfiHiiDatabaseProtocolGuid## CONSUMES
@@ -48,6 +49,9 @@
   gEfiHiiPackageListProtocolGuid ## PRODUCES CONSUMES
   gEdkiiPlatformLogoProtocolGuid ## PRODUCES
 
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended ## CONSUMES
+
 [Depex]
   gEfiHiiDatabaseProtocolGuid AND
   gEfiHiiImageExProtocolGuid
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index be5e829ca9..c8bb51df3b 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2102,6 +2102,12 @@
   # @Prompt The shared bit mask when Intel Tdx is enabled.
   gEfiMdeModulePkgTokenSpaceGuid.PcdTdxSharedBitMask|0x0|UINT64|0x1025
 
+  ## This PCD sets the position of the Boot Logo.
+  #   TRUE  - The Logo is positioned following the recommendations from 
Microsoft.
+  #   FALSE - The logo is positioned in the center of the screen.
+  # @ Prompt This position of the boot logo
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdFollowMicrosoftRecommended|FALSE|BOOLEAN|0x1026
+
 [PcdsPatchableInModule]
   ## Specify memory size with page number for PEI code when
   #  Loading Module at Fixed Address feature is enabled.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index 33ce9f6198..09c1ac1cc1 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1338,3 +1338,9 @@
 #string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdPcieResizableBarSupport_HELP 
#language en-US "Indicates if the PCIe Resizable BAR Capability 
Supported.\n"

 "TRUE  - PCIe Resizable BAR Capability is supported.\n"

 "FALSE - PCIe Resizable BAR Capability is not supported."
+
+#string 
STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommended_PROMPT 
#language en-US "The position of the Boot Logo"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFollowMicrosoftRecommend_HELP   
#language en-US "Sets the position of the Logo. When set to

Re: [edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle incorrect PSIV indices

[Sean Rhodes]

Thank you :)

On Thu, 8 Dec 2022 at 07:06, Chiu, Ian  wrote:

> Hi Sean, Matt DeVillier,
>
> I checked the patch 0001-0004, we are find and agree with 0002-0004.
> For the patch
> 0001-MdeModulePkg-XhciDxe-XhciReg-Handle-incorrect-PSIV-indices.
> The case you mention below with same PSIV in USB3/USB2.
>
> We consider if there exist a case that actually want to go with USB3
> speed,
> then will fail when data transmit. Since USB3 protocol is different than
> USB2.
> Otherwise we may need to fix it again, once issue coming out.
>
> We think about a solution to using the "Compatible Port Count" &
> "Compatible Port Offset" to ensure the port is supported this protocol or
> not.
> Would you able to dump the xHCI Supported Protocol Capability raw data and
> check if this solution works with you case.
>
> Attach sample code snippet and data dump from my side.
>
> Thanks,
> Ian Chiu
>
>
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sean Rhodes
> Sent: Monday, December 5, 2022 5:18 PM
> To: devel@edk2.groups.io
> Cc: Matt DeVillier ; Wu, Hao A <
> hao.a...@intel.com>; Ni, Ray ; Rhodes, Sean
> 
> Subject: [edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle
> incorrect PSIV indices
>
> From: Matt DeVillier 
>
> On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
> Speed ID Value) indices are shared between Protocol Speed ID DWORD' in the
> extended capabilities registers for both USB2 (Full Speed) and USB3 (Super
> Speed).
>
> An example can be found below:
>
> XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
> XhciPsivGetPsid: found 3 PSID entries
> XhciPsivGetPsid: looking for port speed 1
> XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
> XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
> XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
> XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
> XhciPsivGetPsid: found 3 PSID entries
> XhciPsivGetPsid: looking for port speed 1
> XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
> XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
> XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248
>
> The result is edk2 detecting USB2 devices as USB3 devices, which
> consequently causes enumeration to fail.
>
> To avoid incorrect detection, check the extended capability registers for
> USB2 before USB3. If edk2 finds a match for a USB 2 device, don't check for
> USB 3.
>
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Reviewed-by: Sean Rhodes 
> Signed-off-by: Matt DeVillier 
> Change-Id: I5bcf32105ce85fda95b4ba98a5e420e8f522374c
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 36 +++---
> MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  1 +
>  2 files changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> index 2b4a4b2444..c992323443 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> @@ -698,25 +698,11 @@ XhcCheckUsbPortSpeedUsedPsic (
>SpField.Dword = 0;   UsbSpeedIdMap = 0; -  //-  // Check xHCI Supported
> Protocol Capability, find the PSIV field to match-  // PortSpeed definition
> when the Major Revision is 03h.-  //-  if (Xhc->Usb3SupOffset !=
> 0x) {-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset,
> PortSpeed);-if (SpField.Dword != 0) {-  //-  // Found the
> corresponding PORTSC value in PSIV field of USB3 offset.-  //-
> UsbSpeedIdMap = USB_PORT_STAT_SUPER_SPEED;-}-  }-   //   // Check xHCI
> Supported Protocol Capability, find the PSIV field to match   // PortSpeed
> definition when the Major Revision is 02h.   //-  if ((UsbSpeedIdMap == 0)
> && (Xhc->Usb2SupOffset != 0x)) {+  if (Xhc->Usb2SupOffset !=
> 0x) { SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb2SupOffset,
> PortSpeed); if (SpField.Dword != 0) {   //@@ -733,6 +719,12 @@
> XhcCheckUsbPortSpeedUsedPsic (
>// PSIM shows as default High-speed protocol, apply to
> High-speed mapping   //   UsbSpeedIdMap =
> USB_PORT_STAT_HIGH_SPEED;+} else if (SpField.Data.Psim ==
> XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM) {+  //+  //
> PSIM shows as default Full-speed protocol, return 0+  // to ensure
> no port status set+  //+  return 0; }   } else
> if (SpField.Data.Psie == 1) { //@@ -750,6 +742,20 @@
> XhcCheckUsbPortSpeedUsedPsic (
>  }   } +  //+  // Check xHCI Supported Protocol Capability, find the
> PSIV field to match+  // PortSpeed definition when the Major

[edk2-devel] [PATCH 2/3] MdeModulePkg/XhciDxe/Xhci: Don't check for invalid PSIV

[Sean Rhodes]

From: Matt DeVillier 

PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: If15c55ab66d2e7faa832ce8576d2e5b47157cc9a
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 44 -
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 15fb49f28f..8dd7a8fbb7 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -371,6 +371,7 @@ XhcGetRootHubPortStatus (
   UINT32 TotalPort;
   UINTN  Index;
   UINTN  MapSize;
+  UINT8  PortSpeed;
   EFI_STATUS Status;
   USB_DEV_ROUTE  ParentRouteChart;
   EFI_TPLOldTpl;
@@ -397,32 +398,37 @@ XhcGetRootHubPortStatus (
 
   State = XhcReadOpReg (Xhc, Offset);
 
+  PortSpeed = (State & XHC_PORTSC_PS) >> 10;
+
   //
   // According to XHCI 1.1 spec November 2017,
   // Section 7.2 xHCI Support Protocol Capability
   //
-  PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, ((State & 
XHC_PORTSC_PS) >> 10));
-  if (PortStatus->PortStatus == 0) {
-//
-// According to XHCI 1.1 spec November 2017,
-// bit 10~13 of the root port status register identifies the speed of the 
attached device.
-//
-switch ((State & XHC_PORTSC_PS) >> 10) {
-  case 2:
-PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
-break;
+  if (PortSpeed > 0) {
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+// If no match found in ext cap reg, fall back to PORTSC
+if (PortStatus->PortStatus == 0) {
+  //
+  // According to XHCI 1.1 spec November 2017,
+  // bit 10~13 of the root port status register identifies the speed of 
the attached device.
+  //
+  switch (PortSpeed) {
+case 2:
+  PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
+  break;
 
-  case 3:
-PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
-break;
+case 3:
+  PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
+  break;
 
-  case 4:
-  case 5:
-PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
-break;
+case 4:
+case 5:
+  PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
+  break;
 
-  default:
-break;
+default:
+  break;
+  }
 }
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 3/3] MdeModulePkg/Bus/Pci/XhciDxe: Handle incorrect PSIV indices

[Sean Rhodes]

On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indices are shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).

An example can be found below:

XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248

The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.

To avoid incorrect detection, check the Compatible Port Offset to find
the starting Port of Root Hubs that support the protocol.

Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c|  2 +-
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 26 ++
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  3 ++-
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 8dd7a8fbb7..461b2cd9b5 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -405,7 +405,7 @@ XhcGetRootHubPortStatus (
   // Section 7.2 xHCI Support Protocol Capability
   //
   if (PortSpeed > 0) {
-PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed, 
PortNumber);
 // If no match found in ext cap reg, fall back to PORTSC
 if (PortStatus->PortStatus == 0) {
   //
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
index 2b4a4b2444..bca53e9ac0 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
@@ -636,6 +636,7 @@ XhcGetSupportedProtocolCapabilityAddr (
   @param  XhcThe XHCI Instance.
   @param  ExtCapOffset   The USB Major Version in xHCI Support Protocol 
Capability Field
   @param  PortSpeed  The Port Speed Field in USB PortSc register
+  @param  PortNumber The Port Number (0-indexed)
 
   @return The Protocol Speed ID (PSI) from xHCI Supported Protocol capability 
register.
 
@@ -644,12 +645,15 @@ UINT32
 XhciPsivGetPsid (
   IN USB_XHCI_INSTANCE  *Xhc,
   IN UINT32 ExtCapOffset,
-  IN UINT8  PortSpeed
+  IN UINT8  PortSpeed,
+  IN UINT8  PortNumber
   )
 {
   XHC_SUPPORTED_PROTOCOL_DW2PortId;
   XHC_SUPPORTED_PROTOCOL_PROTOCOL_SPEED_ID  Reg;
   UINT32Count;
+  UINT32MinPortIndex;
+  UINT32MaxPortIndex;
 
   if ((Xhc == NULL) || (ExtCapOffset == 0x)) {
 return 0;
@@ -663,6 +667,19 @@ XhciPsivGetPsid (
   //
   PortId.Dword = XhcReadExtCapReg (Xhc, ExtCapOffset + 
XHC_SUPPORTED_PROTOCOL_DW2_OFFSET);
 
+  //
+  // According to XHCI 1.1 spec November 2017, valid values
+  // for CompPortOffset are 1 to CompPortCount - 1.
+  //
+  // PortNumber is zero-indexed, so subtract 1.
+  //
+  MinPortIndex = PortId.Data.CompPortOffset - 1;
+  MaxPortIndex = MinPortIndex + PortId.Data.CompPortCount - 1;
+
+  if ((PortNumber < MinPortIndex) || (PortNumber > MaxPortIndex)) {
+return 0;
+  }
+
   for (Count = 0; Count < PortId.Data.Psic; Count++) {
 Reg.Dword = XhcReadExtCapReg (Xhc, ExtCapOffset + 
XHC_SUPPORTED_PROTOCOL_PSI_OFFSET + (Count << 2));
 if (Reg.Data.Psiv == PortSpeed) {
@@ -685,7 +702,8 @@ XhciPsivGetPsid (
 UINT16
 XhcCheckUsbPortSpeedUsedPsic (
   IN USB_XHCI_INSTANCE  *Xhc,
-  IN UINT8  PortSpeed
+  IN UINT8  PortSpeed,
+  IN UINT8  PortNumber
   )
 {
   XHC_SUPPORTED_PROTOCOL_PROTOCOL_SPEED_ID  SpField;
@@ -703,7 +721,7 @@ XhcCheckUsbPortSpeedUsedPsic (
   // PortSpeed definition when the Major Revision is 03h.
   //
   if (Xhc->Usb3SupOffset != 0x) {
-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
+SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed, 
PortNumber);
 if (SpField.Dword != 0) {
   //
   // Found the corresponding PORTSC value in PSIV field of USB3 offset.
@@ -717,7 +735,7 @@ XhcCheckUsbPortSpeedUsedPsic (
   // PortSpeed definition when the Major Revision is 02h.
   //
   if ((UsbSpeedIdMap == 0) && (Xhc->Usb2SupOffset != 0x)) {
-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb2SupOffset, PortSpeed);
+SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb2SupOf

[edk2-devel] [PATCH 1/3] MdeModulePkg/BmBoot: Skip removable media if it is not present

[Sean Rhodes]

From: Matt DeVillier 

Only enumerate devices that have media present.

Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Zhichao Gao 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I78a0b8be3e2f33edce2d43bbdd7670e6174d0ff8
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 962892d38f..bde22fa659 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2218,6 +2218,15 @@ BmEnumerateBootOptions (
 continue;
   }
 
+  //
+  // Skip removable media if not present
+  //
+  if ((BlkIo->Media->RemovableMedia == TRUE) &&
+  (BlkIo->Media->MediaPresent == FALSE))
+  {
+continue;
+  }
+
   Description = BmGetBootDescription (Handles[Index]);
   BootOptions = ReallocatePool (
   sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount),
-- 
2.37.2



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

Re: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand PlatformCI template for Shell UnitTest

[Sean Brogan via groups.io]

Dun,

I created this discussion on github hoping that others might have 
ideas/feedback.
Integrate target-based testing into Platform CI for Edk2 using OVMF · 
Discussion #3739 · tianocore/edk2 
(github.com)<https://github.com/tianocore/edk2/discussions/3739>

Lets use that to discuss and then on monday we can talk more if needed.

Thanks
Sean


[https://opengraph.githubassets.com/1743f87e9d9139f88783fef5e0cdeb31d956f016a4ea69c0c5489778f4834eb7/tianocore/edk2/discussions/3739]<https://github.com/tianocore/edk2/discussions/3739>
Integrate target-based testing into Platform CI for Edk2 using OVMF · 
Discussion #3739 · 
tianocore/edk2<https://github.com/tianocore/edk2/discussions/3739>
Starting a discussion here to see if more individuals in the community have 
opinions on how best to integrate target-based testing into edk2 CI. There is a 
current proposed patch on the mailing lis...
github.com


From: Tan, Dun 
Sent: Thursday, December 8, 2022 12:17 AM
To: Michael Kubacki ; devel@edk2.groups.io 

Cc: Sean Brogan ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 

Subject: [EXTERNAL] RE: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand 
PlatformCI template for Shell UnitTest

Thank you and Sean a lot! I'll attend the CI meeting if there is any open.

Thanks,
Dun
-Original Message-
From: Michael Kubacki 
Sent: Thursday, December 8, 2022 10:57 AM
To: devel@edk2.groups.io; Tan, Dun 
Cc: Sean Brogan ; Kinney, Michael D 
; Gao, Liming ; Ni, Ray 

Subject: Re: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand PlatformCI 
template for Shell UnitTest

Hi Dun,

Sean Brogan and I have some feedback we'll send soon after we sync on it. If 
anything is still open as of the upcoming TianoCore tools & CI meeting and 
you're able to attend, we can talk there as well.

Thanks,
Michael

On 12/5/2022 11:46 PM, duntan wrote:
> Hi Michael,
> Thanks for the reply! In the following PR, I added an unit test list in the 
> new OvmfPkg platform CI JOB. In  PlatformCI_OvmfPkg_Ubuntu_GCC5_PR and 
> PlatformCI_OvmfPkg_Windows_VS2019_PR, the CI for specific unit test list was 
> triggered.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fpull%2F3651=05%7C01%7Csean.brogan%40microsoft.com%7C884211b3375b4f0618de08dad8f4bdea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638060842928005678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FPbU3fGHlHv5%2FlKn8tvUdEO6%2Ff2SjCAzc7u2KVRxyK0%3D=0
>
> Thanks,
> Dun
>
> -Original Message-
> From: Michael Kubacki 
> Sent: Tuesday, December 6, 2022 9:24 AM
> To: devel@edk2.groups.io; Tan, Dun 
> Cc: Sean Brogan ; Kinney, Michael D
> ; Gao, Liming ;
> Ni, Ray 
> Subject: Re: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand
> PlatformCI template for Shell UnitTest
>
> Sorry for the delay Dun. Can you please share an edk2 pull request with this 
> change?
>
> Thanks,
> Michael
>
> On 12/4/2022 10:57 PM, duntan wrote:
>> Hi all,
>> Is there anything else I can do to speed up the review process for this 
>> patch set? Looking forward to your reply.
>>
>> Thanks,
>> Dun
>> -Original Message-
>> From: Tan, Dun
>> Sent: Monday, November 28, 2022 5:34 PM
>> To: devel@edk2.groups.io; Tan, Dun 
>> Cc: Sean Brogan ; Michael Kubacki
>> ; Kinney, Michael D
>> ; Gao, Liming ;
>> Ni, Ray 
>> Subject: RE: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand
>> PlatformCI template for Shell UnitTest
>>
>> Hi all,
>> Could you please help to review this patch? Thanks a lot!
>>
>> Thanks,
>> Dun
>>
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of duntan
>> Sent: Tuesday, November 22, 2022 7:48 PM
>> To: devel@edk2.groups.io
>> Cc: Sean Brogan ; Michael Kubacki
>> ; Kinney, Michael D
>> ; Gao, Liming ;
>> Ni, Ray 
>> Subject: [edk2-devel] [PATCH 3/3] .azurepipelines: Expand PlatformCI
>> template for Shell UnitTest
>>
>> Expand PlatformCI build and run steps template for Shell UnitTest. Add a new 
>> parameter unit_test_list to support building and running specific Shell 
>> UnitTest modules.
>>
>> In stuart_pr_eval step, if the unit_test_list passed from platform yml file 
>> is not null, it will select some packages from the packages which contain 
>> the module in unit_test_list and set them into a new variable pkgs_to_build 
>> base on its evaluation rule.
>> In stuart_build step, if unit_test_list is not null, '${{ 
>> parameters.unit_test_list}} -p $(pkgs_to_build)' will be added into the 
>> arguments to build specific UnitTest modules in pkgs_to_build.
>> In 'Run 

[edk2-devel] Tools and CI meeting

[Sean]

Sorry, super late in getting this notice out.

Tonight was scheduled to be a brainstorming discussion on how to enable 
CI in edk2 platforms and what kind of changes would be required to the 
repo and the platforms hosted.


If anyone is interested please join the meeting.  If we don't get enough 
representation we will host the topic next week as well (12/12/2022).



Join us for the Tools, CI, Code base construction meeting series · 
Discussion #2614 · tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/discussions/2614>



Thanks

Sean





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

Re: [edk2-devel] [PATCH 4/4] MdeModulePkg/UsbBusDxe: Adjust the MaxPacketLength to real world values

[Sean Rhodes]

Link to PR passing CI - https://github.com/tianocore/edk2/pull/3353

On Mon, 5 Dec 2022 at 09:18, Sean Rhodes via groups.io  wrote:

> Adjusts the requirements for the MaxPacketLength to match what is seen on
> real world devices that do not follow the USB specification.
>
> This fixes enumeration on the multiple USB 3 devices made by SanDisk,
> Integral, Kingston and other generic brands.
>
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Signed-off-by: Sean Rhodes 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> index 62535cad54..043b7d4cea 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
> @@ -906,19 +906,16 @@ XhcControlTransfer (
>  return EFI_INVALID_PARAMETER;
>}
>
> -  if ((MaximumPacketLength != 8)  && (MaximumPacketLength != 16) &&
> -  (MaximumPacketLength != 32) && (MaximumPacketLength != 64) &&
> -  (MaximumPacketLength != 512)
> -  )
> -  {
> +  // Check for valid maximum packet size
> +  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength >
> 1024)) {
>  return EFI_INVALID_PARAMETER;
>}
>
> -  if ((DeviceSpeed == EFI_USB_SPEED_LOW) && (MaximumPacketLength != 8)) {
> +  if ((DeviceSpeed == EFI_USB_SPEED_HIGH) && (MaximumPacketLength > 512))
> {
>  return EFI_INVALID_PARAMETER;
>}
>
> -  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength !=
> 512)) {
> +  if ((DeviceSpeed == EFI_USB_SPEED_FULL) && (MaximumPacketLength > 64)) {
>  return EFI_INVALID_PARAMETER;
>}
>
> --
> 2.37.2
>
>
>
> 
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#96951): https://edk2.groups.io/g/devel/message/96951
> Mute This Topic: https://groups.io/mt/95465401/6718866
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [sean@starlabs.systems]
> 
>
>
>


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

[edk2-devel] [PATCH 2/4] MdeModulePkg/XhciDxe/Xhci: Don't check for invalid PSIV

[Sean Rhodes]

From: Matt DeVillier 

PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: If15c55ab66d2e7faa832ce8576d2e5b47157cc9a
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 44 -
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index c05431ff30..62535cad54 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -371,6 +371,7 @@ XhcGetRootHubPortStatus (
   UINT32 TotalPort;
   UINTN  Index;
   UINTN  MapSize;
+  UINT8  PortSpeed;
   EFI_STATUS Status;
   USB_DEV_ROUTE  ParentRouteChart;
   EFI_TPLOldTpl;
@@ -397,32 +398,37 @@ XhcGetRootHubPortStatus (
 
   State = XhcReadOpReg (Xhc, Offset);
 
+  PortSpeed = (State & XHC_PORTSC_PS) >> 10;
+
   //
   // According to XHCI 1.1 spec November 2017,
   // Section 7.2 xHCI Support Protocol Capability
   //
-  PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, ((State & 
XHC_PORTSC_PS) >> 10));
-  if (PortStatus->PortStatus == 0) {
-//
-// According to XHCI 1.1 spec November 2017,
-// bit 10~13 of the root port status register identifies the speed of the 
attached device.
-//
-switch ((State & XHC_PORTSC_PS) >> 10) {
-  case 2:
-PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
-break;
+  if (PortSpeed > 0) {
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+// If no match found in ext cap reg, fall back to PORTSC
+if (PortStatus->PortStatus == 0) {
+  //
+  // According to XHCI 1.1 spec November 2017,
+  // bit 10~13 of the root port status register identifies the speed of 
the attached device.
+  //
+  switch (PortSpeed) {
+case 2:
+  PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
+  break;
 
-  case 3:
-PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
-break;
+case 3:
+  PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
+  break;
 
-  case 4:
-  case 5:
-PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
-break;
+case 4:
+case 5:
+  PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
+  break;
 
-  default:
-break;
+default:
+  break;
+  }
 }
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 4/4] MdeModulePkg/UsbBusDxe: Adjust the MaxPacketLength to real world values

[Sean Rhodes]

Adjusts the requirements for the MaxPacketLength to match what is seen on
real world devices that do not follow the USB specification.

This fixes enumeration on the multiple USB 3 devices made by SanDisk,
Integral, Kingston and other generic brands.

Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 62535cad54..043b7d4cea 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -906,19 +906,16 @@ XhcControlTransfer (
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((MaximumPacketLength != 8)  && (MaximumPacketLength != 16) &&
-  (MaximumPacketLength != 32) && (MaximumPacketLength != 64) &&
-  (MaximumPacketLength != 512)
-  )
-  {
+  // Check for valid maximum packet size
+  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength > 1024)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((DeviceSpeed == EFI_USB_SPEED_LOW) && (MaximumPacketLength != 8)) {
+  if ((DeviceSpeed == EFI_USB_SPEED_HIGH) && (MaximumPacketLength > 512)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength != 512)) {
+  if ((DeviceSpeed == EFI_USB_SPEED_FULL) && (MaximumPacketLength > 64)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle incorrect PSIV indices

[Sean Rhodes]

From: Matt DeVillier 

On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indices are shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).

An example can be found below:

XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248

The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.

To avoid incorrect detection, check the extended capability registers
for USB2 before USB3. If edk2 finds a match for a USB 2 device, don't
check for USB 3.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I5bcf32105ce85fda95b4ba98a5e420e8f522374c
---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 36 +++---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  1 +
 2 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
index 2b4a4b2444..c992323443 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
@@ -698,25 +698,11 @@ XhcCheckUsbPortSpeedUsedPsic (
   SpField.Dword = 0;
   UsbSpeedIdMap = 0;
 
-  //
-  // Check xHCI Supported Protocol Capability, find the PSIV field to match
-  // PortSpeed definition when the Major Revision is 03h.
-  //
-  if (Xhc->Usb3SupOffset != 0x) {
-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
-if (SpField.Dword != 0) {
-  //
-  // Found the corresponding PORTSC value in PSIV field of USB3 offset.
-  //
-  UsbSpeedIdMap = USB_PORT_STAT_SUPER_SPEED;
-}
-  }
-
   //
   // Check xHCI Supported Protocol Capability, find the PSIV field to match
   // PortSpeed definition when the Major Revision is 02h.
   //
-  if ((UsbSpeedIdMap == 0) && (Xhc->Usb2SupOffset != 0x)) {
+  if (Xhc->Usb2SupOffset != 0x) {
 SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb2SupOffset, PortSpeed);
 if (SpField.Dword != 0) {
   //
@@ -733,6 +719,12 @@ XhcCheckUsbPortSpeedUsedPsic (
   // PSIM shows as default High-speed protocol, apply to High-speed 
mapping
   //
   UsbSpeedIdMap = USB_PORT_STAT_HIGH_SPEED;
+} else if (SpField.Data.Psim == 
XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM) {
+  //
+  // PSIM shows as default Full-speed protocol, return 0
+  // to ensure no port status set
+  //
+  return 0;
 }
   } else if (SpField.Data.Psie == 1) {
 //
@@ -750,6 +742,20 @@ XhcCheckUsbPortSpeedUsedPsic (
 }
   }
 
+  //
+  // Check xHCI Supported Protocol Capability, find the PSIV field to match
+  // PortSpeed definition when the Major Revision is 03h.
+  //
+  if ((UsbSpeedIdMap == 0) && (Xhc->Usb3SupOffset != 0x)) {
+SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
+if (SpField.Dword != 0) {
+  //
+  // Found the corresponding PORTSC value in PSIV field of USB3 offset.
+  //
+  UsbSpeedIdMap = USB_PORT_STAT_SUPER_SPEED;
+}
+  }
+
   return UsbSpeedIdMap;
 }
 
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
index 5fe2ba4f0e..74ac6297ba 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
@@ -85,6 +85,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define XHC_SUPPORTED_PROTOCOL_DW2_OFFSET   0x08
 #define XHC_SUPPORTED_PROTOCOL_PSI_OFFSET   0x10
 #define XHC_SUPPORTED_PROTOCOL_USB2_HIGH_SPEED_PSIM 480
+#define XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM 12
 #define XHC_SUPPORTED_PROTOCOL_USB2_LOW_SPEED_PSIM  1500
 
 #pragma pack (1)
-- 
2.37.2



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

[edk2-devel] [PATCH 3/4] MdeModulePkg/BmBoot: Skip removable media if it is not present

[Sean Rhodes]

From: Matt DeVillier 

Only enumerate devices that have media present.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I78a0b8be3e2f33edce2d43bbdd7670e6174d0ff8
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 962892d38f..bde22fa659 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2218,6 +2218,15 @@ BmEnumerateBootOptions (
 continue;
   }
 
+  //
+  // Skip removable media if not present
+  //
+  if ((BlkIo->Media->RemovableMedia == TRUE) &&
+  (BlkIo->Media->MediaPresent == FALSE))
+  {
+continue;
+  }
+
   Description = BmGetBootDescription (Handles[Index]);
   BootOptions = ReallocatePool (
   sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount),
-- 
2.37.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96952): https://edk2.groups.io/g/devel/message/96952
Mute This Topic: https://groups.io/mt/95465402/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 v2 1/1] CryptoPkg/BaseCryptLib:time overflow

[Sean]

We have a great unit test framework. Is there any reason we can’t write or 
extend a unit test for bugs like this?

Thanks
Sean

From: devel@edk2.groups.io  on behalf of Yao, Jiewen 

Sent: Saturday, December 3, 2022 7:19:26 AM
To: Wenyi Xie ; devel@edk2.groups.io 
; Wang, Jian J ; Lu, Xiaoyu1 
; Jiang, Guomin 
Cc: songdongku...@huawei.com ; yizih...@huawei.com 

Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1] CryptoPkg/BaseCryptLib:time 
overflow

Merged https://github.com/tianocore/edk2/pull/3710

> -Original Message-
> From: Wenyi Xie 
> Sent: Friday, December 2, 2022 1:52 PM
> To: devel@edk2.groups.io; Yao, Jiewen ; Wang, Jian
> J ; Lu, Xiaoyu1 ; Jiang,
> Guomin 
> Cc: songdongku...@huawei.com; xiewen...@huawei.com;
> yizih...@huawei.com
> Subject: [PATCH EDK2 v2 1/1] CryptoPkg/BaseCryptLib:time overflow
>
> From: Zihong Yi 
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4167
>
> In CrtLibSupport.h, time_t is defined as INT32, and its maximum value
> is 2147483647. That is, the corresponding maximum timestamp is
> 2038-01-19 11:14:07. Therefore, overflow occurs when the test time
> exceeds 2038-01-19 11:14:07. So change the type of time_t to INT64 and
> also change the type of variables in function gmtime which calculated
> with time_t.
>
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Cc: Guomin Jiang 
> Signed-off-by: Zihong Yi 
> ---
>  CryptoPkg/Library/Include/CrtLibSupport.h |  2 +-
>  CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c | 51
> ++--
>  2 files changed, 38 insertions(+), 15 deletions(-)
>
> diff --git a/CryptoPkg/Library/Include/CrtLibSupport.h
> b/CryptoPkg/Library/Include/CrtLibSupport.h
> index 5072c343da57..94b0e6b6014f 100644
> --- a/CryptoPkg/Library/Include/CrtLibSupport.h
> +++ b/CryptoPkg/Library/Include/CrtLibSupport.h
> @@ -109,7 +109,7 @@ typedef UINTN   off_t;
>  typedef UINTN   u_int;
>  typedef INTNptrdiff_t;
>  typedef INTNssize_t;
> -typedef INT32   time_t;
> +typedef INT64   time_t;
>  typedef UINT8   __uint8_t;
>  typedef UINT8   sa_family_t;
>  typedef UINT8   u_char;
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> index bf8a5325817f..2dfc6fe6c593 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/TimerWrapper.c
> @@ -15,7 +15,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  // -- Time Management Routines --
>  //
>
> -#define IsLeap(y)  (((y) % 4) == 0 && (((y) % 100) != 0 || ((y) % 400) == 0))
>  #define SECSPERMIN   (60)
>  #define SECSPERHOUR  (60 * 60)
>  #define SECSPERDAY   (24 * SECSPERHOUR)
> @@ -60,6 +59,26 @@ UINTN  CumulativeDays[2][14] = {
>}
>  };
>
> +/* Check the year is leap or not. */
> +// BOOLEAN IsLeap(
> +//  INTN timer
> +//  )
> +BOOLEAN
> +IsLeap (
> +  time_t  timer
> +  )
> +{
> +  INT64  Remainder1;
> +  INT64  Remainder2;
> +  INT64  Remainder3;
> +
> +  DivS64x64Remainder (timer, 4, );
> +  DivS64x64Remainder (timer, 100, );
> +  DivS64x64Remainder (timer, 400, );
> +
> +  return (Remainder1 == 0 && (Remainder2 != 0 || Remainder3 == 0));
> +}
> +
>  /* Get the system time as seconds elapsed since midnight, January 1, 1970.
> */
>  // INTN time(
>  //  INTN *timer
> @@ -117,12 +136,13 @@ gmtime (
>)
>  {
>struct tm  *GmTime;
> -  UINT16 DayNo;
> -  UINT32 DayRemainder;
> +  UINT64 DayNo;
> +  UINT64 DayRemainder;
>time_t Year;
>time_t YearNo;
> -  UINT16 TotalDays;
> -  UINT16 MonthNo;
> +  UINT32 TotalDays;
> +  UINT32 MonthNo;
> +  INT64  Remainder;
>
>if (timer == NULL) {
>  return NULL;
> @@ -135,18 +155,21 @@ gmtime (
>
>ZeroMem ((VOID *)GmTime, (UINTN)sizeof (struct tm));
>
> -  DayNo= (UINT16)(*timer / SECSPERDAY);
> -  DayRemainder = (UINT32)(*timer % SECSPERDAY);
> +  DayNo= (UINT64)DivS64x64Remainder (*timer, SECSPERDAY,
> );
> +  DayRemainder = (UINT64)Remainder;
>
> -  GmTime->tm_sec  = (int)(DayRemainder % SECSPERMIN);
> -  GmTime->tm_min  = (int)((DayRemainder % SECSPERHOUR) /
> SECSPERMIN);
> -  GmTime->tm_hour = (int)(DayRemainder / SECSPERHOUR);
> -  GmTime->tm_wday = (int)((DayNo + 4) % 7);
> +  DivS64x64Remainder (DayRemainder, SECSPERMIN, );
> +  GmTime->tm_sec = (int)Remainder;
> +  DivS64x64Remainder (DayRemainder, SECSPERHOUR, );
> +  GmTime->tm_min  = (int)DivS64x64Remainder (Remainder, SECSPERMIN,
> NULL);
> +  GmTime->tm_hour = (int)DivS64x64Remainder (DayRemainder,

Re: [edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle incorrect PSIV indices

[Sean Rhodes]

Hi Hao

They are now resolved

Thanks

Sean

On Fri, 2 Dec 2022 at 06:25, Wu, Hao A  wrote:

> Hello,
>
> I saw there are several CI check failures for this 4 patches:
> https://github.com/tianocore/edk2/pull/3702
>
> Could you help to resolve them? Thanks.
>
> Best Regards,
> Hao Wu
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sean
> > Rhodes
> > Sent: Friday, December 2, 2022 4:25 AM
> > To: devel@edk2.groups.io
> > Cc: Matt DeVillier ; Wu, Hao A
> > ; Ni, Ray ; Rhodes, Sean
> > 
> > Subject: [edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle
> > incorrect PSIV indices
> >
> > From: Matt DeVillier 
> >
> > On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
> Speed
> > ID Value) indicesare shared between Protocol Speed ID DWORD' in the
> > extended capabilities registers for both USB2 (Full Speed) and USB3
> (Super
> > Speed).
> >
> > An example can be found below:
> >
> > XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
> > XhciPsivGetPsid: found 3 PSID entries
> > XhciPsivGetPsid: looking for port speed 1
> > XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
> > XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
> > XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
> > XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
> > XhciPsivGetPsid: found 3 PSID entries
> > XhciPsivGetPsid: looking for port speed 1
> > XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
> > XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
> > XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248
> >
> > The result is edk2 detecting USB2 devices as USB3 devices, which
> consequently
> > causes enumeration to fail.
> >
> > To avoid incorrect detection, check the extended capability registers
> for USB2
> > before USB3. If edk2 finds a match for a USB 2 device, don't check for
> USB 3.
> >
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > Reviewed-by: Sean Rhodes 
> > Signed-off-by: Matt DeVillier 
> > Change-Id: I5bcf32105ce85fda95b4ba98a5e420e8f522374c
> > ---
> >  MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 36 +++---
> > MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  1 +
> >  2 files changed, 22 insertions(+), 15 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > index 2b4a4b2444..c992323443 100644
> > --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > @@ -698,25 +698,11 @@ XhcCheckUsbPortSpeedUsedPsic (
> >SpField.Dword = 0;   UsbSpeedIdMap = 0; -  //-  // Check xHCI
> Supported
> > Protocol Capability, find the PSIV field to match-  // PortSpeed
> definition when
> > the Major Revision is 03h.-  //-  if (Xhc->Usb3SupOffset != 0x)
> {-
> > SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);-
>   if
> > (SpField.Dword != 0) {-  //-  // Found the corresponding PORTSC
> value in
> > PSIV field of USB3 offset.-  //-  UsbSpeedIdMap =
> > USB_PORT_STAT_SUPER_SPEED;-}-  }-   //   // Check xHCI Supported
> Protocol
> > Capability, find the PSIV field to match   // PortSpeed definition when
> the Major
> > Revision is 02h.   //-  if ((UsbSpeedIdMap == 0) && (Xhc->Usb2SupOffset
> !=
> > 0x)) {+  if (Xhc->Usb2SupOffset != 0x) {
>  SpField.Dword =
> > XhciPsivGetPsid (Xhc, Xhc->Usb2SupOffset, PortSpeed); if
> (SpField.Dword != 0)
> > {   //@@ -733,6 +719,12 @@ XhcCheckUsbPortSpeedUsedPsic (
> >// PSIM shows as default High-speed protocol, apply to
> High-speed
> > mapping   //   UsbSpeedIdMap =
> > USB_PORT_STAT_HIGH_SPEED;+} else if (SpField.Data.Psim ==
> > XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM) {+  //+  //
> > PSIM shows as default Full-speed protocol, return 0+  // to
> ensure no port
> > status set+  //+  return 0; }   } else if
> (SpField.Data.Psie == 1)
> > { //@@ -750,6 +742,20 @@ XhcCheckUsbPortSpeedUsedPsic (
> >  }   } +  //+  // Check xHCI Supported Protocol Capability, find the
> PSIV field to
> > match+  // PortSpeed definition when the Major Revision is 03h.+  //+  if
> > ((UsbSpeedIdMap == 0) && (Xhc->Usb3SupOffset != 0x)) {+
> > SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);+
>   if
>

[edk2-devel] [PATCH 4/4] MdeModulePkg/UsbBusDxe: Adjust the MaxPacketLength to real world values

[Sean Rhodes]

Adjusts the requirements for the MaxPacketLength to match what is seen on
real world devices that do not follow the USB specification.

This fixes enumeration on the multiple USB 3 devices made by SanDisk,
Integral, Kingston and other generic brands.

Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Sean Rhodes 
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index 51ae57db21..73bfc62512 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -906,19 +906,16 @@ XhcControlTransfer (
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((MaximumPacketLength != 8)  && (MaximumPacketLength != 16) &&
-  (MaximumPacketLength != 32) && (MaximumPacketLength != 64) &&
-  (MaximumPacketLength != 512)
-  )
-  {
+  // Check for valid maximum packet size
+  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength > 1024)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((DeviceSpeed == EFI_USB_SPEED_LOW) && (MaximumPacketLength != 8)) {
+  if ((DeviceSpeed == EFI_USB_SPEED_HIGH) && (MaximumPacketLength > 512)) {
 return EFI_INVALID_PARAMETER;
   }
 
-  if ((DeviceSpeed == EFI_USB_SPEED_SUPER) && (MaximumPacketLength != 512)) {
+  if ((DeviceSpeed == EFI_USB_SPEED_FULL) && (MaximumPacketLength > 64)) {
 return EFI_INVALID_PARAMETER;
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 2/4] MdeModulePkg/XhciDxe/Xhci: Don't check for invalid PSIV

[Sean Rhodes]

From: Matt DeVillier 

PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: If15c55ab66d2e7faa832ce8576d2e5b47157cc9a
---
 MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 44 -
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
index c05431ff30..51ae57db21 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
@@ -371,6 +371,7 @@ XhcGetRootHubPortStatus (
   UINT32 TotalPort;
   UINTN  Index;
   UINTN  MapSize;
+  UINTN  PortSpeed;
   EFI_STATUS Status;
   USB_DEV_ROUTE  ParentRouteChart;
   EFI_TPLOldTpl;
@@ -397,32 +398,37 @@ XhcGetRootHubPortStatus (
 
   State = XhcReadOpReg (Xhc, Offset);
 
+  PortSpeed = (State & XHC_PORTSC_PS) >> 10;
+
   //
   // According to XHCI 1.1 spec November 2017,
   // Section 7.2 xHCI Support Protocol Capability
   //
-  PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, ((State & 
XHC_PORTSC_PS) >> 10));
-  if (PortStatus->PortStatus == 0) {
-//
-// According to XHCI 1.1 spec November 2017,
-// bit 10~13 of the root port status register identifies the speed of the 
attached device.
-//
-switch ((State & XHC_PORTSC_PS) >> 10) {
-  case 2:
-PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
-break;
+  if (PortSpeed > 0) {
+PortStatus->PortStatus = XhcCheckUsbPortSpeedUsedPsic (Xhc, PortSpeed);
+// If no match found in ext cap reg, fall back to PORTSC
+if (PortStatus->PortStatus == 0) {
+  //
+  // According to XHCI 1.1 spec November 2017,
+  // bit 10~13 of the root port status register identifies the speed of 
the attached device.
+  //
+  switch (PortSpeed) {
+case 2:
+  PortStatus->PortStatus |= USB_PORT_STAT_LOW_SPEED;
+  break;
 
-  case 3:
-PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
-break;
+case 3:
+  PortStatus->PortStatus |= USB_PORT_STAT_HIGH_SPEED;
+  break;
 
-  case 4:
-  case 5:
-PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
-break;
+case 4:
+case 5:
+  PortStatus->PortStatus |= USB_PORT_STAT_SUPER_SPEED;
+  break;
 
-  default:
-break;
+default:
+  break;
+  }
 }
   }
 
-- 
2.37.2



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

[edk2-devel] [PATCH 3/4] MdeModulePkg/BmBoot: Skip removable media if it is not present

[Sean Rhodes]

From: Matt DeVillier 

Only enumerate devices that have media present.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I78a0b8be3e2f33edce2d43bbdd7670e6174d0ff8
---
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 962892d38f..bde22fa659 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2218,6 +2218,15 @@ BmEnumerateBootOptions (
 continue;
   }
 
+  //
+  // Skip removable media if not present
+  //
+  if ((BlkIo->Media->RemovableMedia == TRUE) &&
+  (BlkIo->Media->MediaPresent == FALSE))
+  {
+continue;
+  }
+
   Description = BmGetBootDescription (Handles[Index]);
   BootOptions = ReallocatePool (
   sizeof (EFI_BOOT_MANAGER_LOAD_OPTION) * 
(*BootOptionCount),
-- 
2.37.2



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

[edk2-devel] [PATCH 1/4] MdeModulePkg/XhciDxe/XhciReg: Handle incorrect PSIV indices

[Sean Rhodes]

From: Matt DeVillier 

On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indicesare shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).

An example can be found below:

XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248

The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.

To avoid incorrect detection, check the extended capability registers
for USB2 before USB3. If edk2 finds a match for a USB 2 device, don't
check for USB 3.

Cc: Hao A Wu 
Cc: Ray Ni 
Reviewed-by: Sean Rhodes 
Signed-off-by: Matt DeVillier 
Change-Id: I5bcf32105ce85fda95b4ba98a5e420e8f522374c
---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 36 +++---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h |  1 +
 2 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
index 2b4a4b2444..c992323443 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
@@ -698,25 +698,11 @@ XhcCheckUsbPortSpeedUsedPsic (
   SpField.Dword = 0;
   UsbSpeedIdMap = 0;
 
-  //
-  // Check xHCI Supported Protocol Capability, find the PSIV field to match
-  // PortSpeed definition when the Major Revision is 03h.
-  //
-  if (Xhc->Usb3SupOffset != 0x) {
-SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
-if (SpField.Dword != 0) {
-  //
-  // Found the corresponding PORTSC value in PSIV field of USB3 offset.
-  //
-  UsbSpeedIdMap = USB_PORT_STAT_SUPER_SPEED;
-}
-  }
-
   //
   // Check xHCI Supported Protocol Capability, find the PSIV field to match
   // PortSpeed definition when the Major Revision is 02h.
   //
-  if ((UsbSpeedIdMap == 0) && (Xhc->Usb2SupOffset != 0x)) {
+  if (Xhc->Usb2SupOffset != 0x) {
 SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb2SupOffset, PortSpeed);
 if (SpField.Dword != 0) {
   //
@@ -733,6 +719,12 @@ XhcCheckUsbPortSpeedUsedPsic (
   // PSIM shows as default High-speed protocol, apply to High-speed 
mapping
   //
   UsbSpeedIdMap = USB_PORT_STAT_HIGH_SPEED;
+} else if (SpField.Data.Psim == 
XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM) {
+  //
+  // PSIM shows as default Full-speed protocol, return 0
+  // to ensure no port status set
+  //
+  return 0;
 }
   } else if (SpField.Data.Psie == 1) {
 //
@@ -750,6 +742,20 @@ XhcCheckUsbPortSpeedUsedPsic (
 }
   }
 
+  //
+  // Check xHCI Supported Protocol Capability, find the PSIV field to match
+  // PortSpeed definition when the Major Revision is 03h.
+  //
+  if ((UsbSpeedIdMap == 0) && (Xhc->Usb3SupOffset != 0x)) {
+SpField.Dword = XhciPsivGetPsid (Xhc, Xhc->Usb3SupOffset, PortSpeed);
+if (SpField.Dword != 0) {
+  //
+  // Found the corresponding PORTSC value in PSIV field of USB3 offset.
+  //
+  UsbSpeedIdMap = USB_PORT_STAT_SUPER_SPEED;
+}
+  }
+
   return UsbSpeedIdMap;
 }
 
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
index 5fe2ba4f0e..74ac6297ba 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.h
@@ -85,6 +85,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #define XHC_SUPPORTED_PROTOCOL_DW2_OFFSET   0x08
 #define XHC_SUPPORTED_PROTOCOL_PSI_OFFSET   0x10
 #define XHC_SUPPORTED_PROTOCOL_USB2_HIGH_SPEED_PSIM 480
+#define XHC_SUPPORTED_PROTOCOL_USB2_FULL_SPEED_PSIM 12
 #define XHC_SUPPORTED_PROTOCOL_USB2_LOW_SPEED_PSIM  1500
 
 #pragma pack (1)
-- 
2.37.2



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

Re: [edk2-devel] [PATCH v7 0/6] CI: Use Fedora 35 container for Linux jobs

[Sean]

Oliver,

Thanks for this changeset and i think this is getting closer but over 
the past few months there have been a few changes that I don't think 
this series takes into account.


A few comments i hope we can address quickly (since 18.04 is going 
offline tomorrow).


1. Can the whole block at 
https://github.com/tianocore/edk2/blob/dd3ba82d31a6d3cc4564dc83c9229e13773b55da/.pytool/CISettings.py#L172 
be removed.  The only reason these exist is to pick up and download the 
compilers.


2. what about supporting the loongarch64 compiler? Can we add to container?

3. If loongarch64 is included in container should you delete this file 
too: edk2/gcc_loongarch64_unknown_linux_ext_dep.yaml at master · 
tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/blob/master/BaseTools/Bin/gcc_loongarch64_unknown_linux_ext_dep.yaml>


4.  Patch 4 has changes in multiple packages.  I believe it is a 
requirement in edk2 to only change a single package per commit. It makes 
reviews and cherry-picking/bisection easier.


5. Since only Core CI as controlled by  file 
.azurepipelines/Ubuntu_GCC5.yml why not use the base container instead 
of test container?  The Core CI Process will not use qemu.  The platform 
Ci files have their own yml with container specifier.


6. what about removing the steps for installing node and cspell from the 
container build?  Since these are managed in the container they should 
be skipped.



Thanks

Sean



On 11/29/2022 11:26 AM, Oliver Steffen wrote:

-18.04 vm_image since this will no longer be available
   after Dec 1st.  Use ubuntu-latest instead.



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

Re: [edk2-devel] [PATCH v1 1/1] .github/ISSUE_TEMPLATE/config.yml: Add initial issue template

[Sean]

Reviewed-by: Sean Brogan 

On 11/15/2022 5:47 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Adds a GitHub issue template to direct contributors familiar with
GitHub's issue tracker to the external resources used by TianoCore.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---

Notes:
 An example of what this looks like is in the Issues
 section of my edk2 fork:
 
 https://github.com/makubacki/edk2/issues/new/choose
 
 This was discussed in the Nov 14th, 2022 TianoCore

 Tools and CI Meeting and received positive feedback
 with the suggestion to add this change.

  .github/ISSUE_TEMPLATE/config.yml | 24 
  1 file changed, 24 insertions(+)

diff --git a/.github/ISSUE_TEMPLATE/config.yml 
b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index ..7866c2197aca
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,24 @@
+## @file
+# GitHub issue configuration file.
+#
+# This file is meant to direct contributors familiar with GitHub's issue 
tracker
+# to the external resources used by TianoCore.
+#
+# Copyright (c) Microsoft Corporation.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+blank_issues_enabled: false
+contact_links:
+  - name: Bugs and Feature Requests
+url: https://bugzilla.tianocore.org/
+about: Submit bug reports and feature requests here
+  - name: Reporting Security Issues
+url: 
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues
+about: Read the wiki page that describes the process here
+  - name: EDK II Development Mailing List
+url: https://edk2.groups.io/g/devel
+about: Submit code patches and ask questions on the mailing list 
(devel@edk2.groups.io)
+  - name: EDK II Discussions
+url: https://github.com/tianocore/edk2/discussions
+about: You can also reach out on the Discussion section of this repository



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

Re: [edk2-devel] [PATCH v1 1/1] .github/dependabot.yml: Enable dependabot

[Sean]

Reviewed-by: Sean Brogan 



On 11/10/2022 5:46 AM, Michael Kubacki wrote:

From: Michael Kubacki 

Enables dependabot in this repo so we can better alerted when
dependency updates are available.

This GitHub action will automatically create pull requests and
summarize the dependency details. Because it is a pull request,
the CI system will validate the dependency update in the pull
request.

Configures dependabot for:

1. PIP module updates
2. Submodule updates
3. GitHub action updates

The maintainers/reviewers of the .github directory were added as
pull request reviewers so they can be notified when the pull request
is available.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---

Notes:
 An example of the pull requests created by this change
 are available on my edk2 fork:
 
 https://github.com/makubacki/edk2/pulls


  .github/dependabot.yml | 45 
  1 file changed, 45 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index ..7f405721fd3d
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,45 @@
+## @file
+# Dependabot configuration file to enable GitHub services for managing and 
updating
+# dependencies.
+#
+# Copyright (c) Microsoft Corporation.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+# Please see the documentation for all configuration options:
+# 
https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
+##
+version: 2
+updates:
+  - package-ecosystem: "pip"
+directory: "/"
+schedule:
+  interval: "daily"
+commit-message:
+  prefix: "pip"
+reviewers:
+  - "makubacki"
+  - "mdkinney"
+  - "spbrogan"
+
+  - package-ecosystem: "gitsubmodule"
+directory: "/"
+schedule:
+  interval: "daily"
+commit-message:
+  prefix: "submodule"
+reviewers:
+  - "makubacki"
+  - "mdkinney"
+  - "spbrogan"
+
+  - package-ecosystem: "github-actions"
+directory: "/"
+schedule:
+  interval: "weekly"
+  day: "monday"
+commit-message:
+  prefix: "GitHub Action"
+reviewers:
+  - "makubacki"
+  - "mdkinney"
+  - "spbrogan"



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

Re: [edk2-devel] [PATCH v1 0/2] Update Pytool PIP Versions

[Sean]

This looks good.  To avoid any odd failures in stuart_pr_eval, it is 
important to pick both of these up.  Without these updates we have seen 
pr_eval reporting a package doesn't need to be tested when it should.  
this leads to bad changes getting through the PR process and breaking 
the mainline.



Reviewed-by: Sean Brogan 


Thanks

Sean



On 11/11/2022 5:04 PM, Michael Kubacki wrote:

From: Michael Kubacki 

1. Updates edk2-pytool-library to 0.12.1
- Picks up a minor bug fix

2. Updates edk2-pytool-extensions to 0.20.0
- Picks up a major release

The changes in each update are in the respective patch commit
messages.

CI was run against both of these patches in this pull request:
https://github.com/tianocore/edk2/pull/3632

Cc: Sean Brogan 
Cc: Michael Kubacki 
Cc: Liming Gao 
Cc: Andrew Fish 
Cc: Leif Lindholm 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
   pip-requirements.txt: Update to edk2-pytool-library 0.12.1
   pip-requirements.txt: Update to edk2-pytool-extensions 0.20.0

  pip-requirements.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)




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

Re: [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 2/2] Source Files / Spacing / Multi-line func. calls: allow condensed arguments

[Sean]

If you look through the bugs you will see there is some debate. 
Personally, I think there is never a single right answer on style and 
there will always be differing opinions.  The underlying goal that most 
agree on is providing consistency for a project and to make it easy for 
someone to contribute code that aligns with that consistent standard.   
Since 2017, a lot has changed but the biggest thing is we have a 
relatively easy, well documented, industry standard tool that supports 
style/formatting of edk2. These tools can be run locally by those 
contributing and are run by the CI system on pull request to enforce 
this consistency.  We have already reformatted the entire code base of 
edk2 to align with that and although i am not opposed to auto 
reformatting in the future for a great reason I don't see anything is 
these proposed changes that would justify that.



Thanks

Sean



On 11/14/2022 10:49 AM, Michael Kubacki wrote:
I saw those, but they're from over 5 years ago and the community has 
changed since then.


This is an impactful change. It will impact every line of code written.

I'm not suggesting this go to the Tools & CI Meeting because of 
uncrustify. I'm not concerned with any impact to uncrustify.


This came to my attention because I was added to thread. I would like 
to suggest that we raise more awareness about this change in a meeting 
with members of the community to capture additional feedback.


Also, the logistics (uncrustify aside) about how to execute this 
change are unclear (as written in this thread and the BZ) and it would 
be easier/faster to discuss in a community call.


Is that possible?

Thanks,
Michael

On 11/14/2022 1:25 PM, Kinney, Michael D wrote:

Hi Michael,

Yes.  They have been discussed.  There were patches and discussion on 
mailing
lists back in 2017.  Long before enabling uncrustify. I provided 
links to

these conversations in the following email about a week ago.

https://edk2.groups.io/g/devel/message/96038


Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of 
Michael Kubacki

Sent: Monday, November 14, 2022 10:05 AM
To: devel@edk2.groups.io; Kinney, Michael D 
; abner.ch...@amd.com; Laszlo Ersek 
;

Kubacki, Michael 
Subject: Re: [edk2-devel] [edk2-CCodingStandardsSpecification PATCH 
2/2] Source Files / Spacing / Multi-line func. calls: allow

condensed arguments

Have these changes been discussed in a community forum? Do you think we
could talk about it in the Tianocore Tools & CI Meeting today?

Thanks,
Michael

On 11/14/2022 12:37 PM, Michael Kubacki wrote:

I'm catching up on this thread so let me know if I miss something.

Uncrustify can perform conversions/enforcements like adjusting code 
to <

80 columns.

The edk2 uncrustify configuration file is here and you will see that I
commented column width enforcement:

https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/UncrustifyCheck/uncrustify.cfg#L19. 




Uncrustify aside, column width is particularly difficult to adjust
consistently. Both humans and tools have to make many (constant)
situational decisions based on code structure.

However, it should be possible. I've taken the current uncrustify
configuration file, made minimal changes to restrict code to 80 
columns,

and published the results based on the current edk2 code tree here:

https://github.com/makubacki/edk2/tree/uncrustify_80_column_change

You can see the I ran uncrustify 3 times to reach a mostly steady 
state.
The issue after the second run is that uncrustify is confused about 
what

to do with single macros that exceed 80 columns.

Examples:
1.
https://github.com/makubacki/edk2/blob/uncrustify_80_column_change/MdePkg/Include/IndustryStandard/Acpi30.h#L702-#L704 



2.
https://github.com/makubacki/edk2/blob/uncrustify_80_column_change/MdePkg/Include/IndustryStandard/IpmiNetFnApp.h#L1023-#L1031 




There are other cases there as well.

Anyway, if those were reduced in length, I think we could reach a 
steady

state. Some other minor tweaks might also be required.

Regarding function calls, I put together the following branch to
demonstrate some examples of what is done now.

In summary, multiple arguments can be provided on a single line 
(with no
width or argument count maximum) or multiple lines. If a single 
argument
is multi-line, then all arguments must be on a unique line to 
follow the

multi-line argument convention.

See the top two commits in this branch for examples:

https://github.com/makubacki/edk2/tree/func_arg_formatting_demo

I agree uncrustify and the spec be in sync.

Regards,
Michael

On 11/14/2022 12:07 PM, Michael D Kinney wrote:

I disagree that they can coexist.

If uncrustify is forcing 1 arg per line, then a developer that 
follows

a CSS that allows multiple per line, the code change will be rejected
by EDK II CI.

The CSS and Uncristify behavior need to be aligned.If we want a CSS
change that requires Uncristify changes, then they have to be
coordin

Re: [edk2-devel] [PATCH v1 0/2] Enable CodeQL Failures and Add New Queries

[Sean]

For the codeql series

Reviewed-by: Sean Brogan 

On 11/8/2022 11:51 AM, Michael Kubacki wrote:

From: Michael Kubacki 

When CodeQL was enabled, the goal was to enable the flow and not
impact build results. cpp/conditionallyuninitializedvariable was
the first and only query enabled with all CodeQL results filtered
out from affecting CI results.

This achieved the goal to enable CodeQL for future changes to build
upon but always get CodeQL successful runs in the meantime.

This patch series:
1. Swaps out that initial "placeholder" query with two queries that
can be enabled with no code changes.
2. Enables "error" level CodeQL alerts.
3. Makes fixes made for a default query
cpp/wrong-type-format-argument in BaseTools.

The results for (3) can be seen in the following Code Scanning
results that show the PR with these changes fixed the alerts raised
by CodeQL.

PR: https://github.com/tianocore/edk2/pull/3617

Code Scanning results (access may be required):
https://github.com/tianocore/edk2/security/code-scanning?query=pr%3A3617+tool%3ACodeQL+is%3Aclosed

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
   BaseTools: Fix wrong type of arguments to formatting functions
   edk2.qls: Allow error severity results and add new queries

  BaseTools/Source/C/EfiRom/EfiRom.c  | 2 +-
  BaseTools/Source/C/GenFv/GenFvInternalLib.c | 2 +-
  BaseTools/Source/C/GenFw/Elf32Convert.c | 2 +-
  BaseTools/Source/C/GenFw/Elf64Convert.c | 6 +++---
  BaseTools/Source/C/GenSec/GenSec.c  | 4 ++--
  .github/codeql/codeql-config.yml| 1 -
  .github/codeql/edk2.qls | 4 +++-
  7 files changed, 11 insertions(+), 10 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96120): https://edk2.groups.io/g/devel/message/96120
Mute This Topic: https://groups.io/mt/94898431/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] UnitTestFrameworkPkg: Support FILE_GUID override in host based unit tests

[Sean]

Look good. Good find.


reviewed-by: Sean Brogan 

On 10/28/2022 8:59 AM, Michael D Kinney wrote:

Always use the module name with FILE_GUID to generate the host-based
unit test executable image and symbol files.  This allows the same
host-based unit test INF file to be used more than once in a single
DSC file with FILE_GUID override.  This is valuable when there is a
requirement to run the same host-based unit test with different PCD
settings, library mappings, or build options.

Cc: Michael Kubacki 
Cc: Sean Brogan 
Signed-off-by: Michael D Kinney 
---
  UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc 
b/UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc
index 4dd8d4ac678a..f249813713a8 100644
--- a/UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc
+++ b/UnitTestFrameworkPkg/UnitTestFrameworkPkgHost.dsc.inc
@@ -30,7 +30,7 @@ [BuildOptions.common.EDKII.HOST_APPLICATION]
#
# MSFT
#
-  MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(BASE_NAME).exe" 
/pdb:"$(BIN_DIR)\$(BASE_NAME).pdb" /IGNORE:4001 /NOLOGO /SUBSYSTEM:CONSOLE /DEBUG 
/STACK:0x4,0x4 /NODEFAULTLIB:libcmt.lib libcmtd.lib
+  MSFT:*_*_*_DLINK_FLAGS== /out:"$(BIN_DIR)\$(MODULE_NAME_GUID).exe" 
/pdb:"$(BIN_DIR)\$(MODULE_NAME_GUID).pdb" /IGNORE:4001 /NOLOGO /SUBSYSTEM:CONSOLE /DEBUG 
/STACK:0x4,0x4 /NODEFAULTLIB:libcmt.lib libcmtd.lib
MSFT:*_*_IA32_DLINK_FLAGS = /MACHINE:I386
MSFT:*_*_X64_DLINK_FLAGS  = /MACHINE:AMD64
  
@@ -47,8 +47,8 @@ [BuildOptions.common.EDKII.HOST_APPLICATION]

#
# GCC
#
-  GCC:*_*_IA32_DLINK_FLAGS == -o $(BIN_DIR)/$(BASE_NAME) -m32 -no-pie
-  GCC:*_*_X64_DLINK_FLAGS  == -o $(BIN_DIR)/$(BASE_NAME) -m64 -no-pie
+  GCC:*_*_IA32_DLINK_FLAGS == -o $(BIN_DIR)/$(MODULE_NAME_GUID) -m32 -no-pie
+  GCC:*_*_X64_DLINK_FLAGS  == -o $(BIN_DIR)/$(MODULE_NAME_GUID) -m64 -no-pie
GCC:*_*_*_DLINK2_FLAGS   == -lgcov
  
#

@@ -56,10 +56,10 @@ [BuildOptions.common.EDKII.HOST_APPLICATION]
#
XCODE:*_*_IA32_DLINK_PATH == gcc
XCODE:*_*_IA32_CC_FLAGS = 
-I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack
-  XCODE:*_*_IA32_DLINK_FLAGS == -arch i386 -o $(BIN_DIR)/Host -L/usr/X11R6/lib 
-lXext -lX11 -framework Carbon
+  XCODE:*_*_IA32_DLINK_FLAGS == -arch i386 -o $(BIN_DIR)/$(MODULE_NAME_GUID) 
-L/usr/X11R6/lib -lXext -lX11 -framework Carbon
XCODE:*_*_IA32_ASM_FLAGS == -arch i386 -g
  
XCODE:*_*_X64_DLINK_PATH == gcc

-  XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/Host -L/usr/X11R6/lib -lXext 
-lX11 -framework Carbon -Wl,-no_pie
+  XCODE:*_*_X64_DLINK_FLAGS == -o $(BIN_DIR)/$(MODULE_NAME_GUID) 
-L/usr/X11R6/lib -lXext -lX11 -framework Carbon -Wl,-no_pie
XCODE:*_*_X64_ASM_FLAGS == -g
XCODE:*_*_X64_CC_FLAGS = -O0 -target x86_64-apple-darwin 
-I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack 
"-DEFIAPI=__attribute__((ms_abi))"



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

Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Mike

This patch is being upstreamed from the coreboot fork; about 70% of the
coreboot community wants the logo centred (as the target OS is not
Windows), and the rest want to use the 38.2% rule!

Thanks

Sean

On Wed, 26 Oct 2022 at 05:55, Kinney, Michael D 
wrote:

> Sean provided a sample PR that adds a PCD.
>
>
>
> I think we agree that a PCD is not required.  The existing logic that
> centers the logo should be updated to use the 38.2% rule.
>
>
>
> Mike
>
>
>
> *From:* Ni, Ray 
> *Sent:* Tuesday, October 25, 2022 7:32 PM
> *To:* Kinney, Michael D ; devel@edk2.groups.io;
> Rhodes, Sean 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* RE: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Are you suggesting that the exiting logic be updated for this use case
> without adding a new enum?
>
>- yes.
>
>
>
> *From:* Kinney, Michael D 
> *Sent:* Wednesday, October 26, 2022 12:21 AM
> *To:* devel@edk2.groups.io; Ni, Ray ; Rhodes, Sean <
> sean@starlabs.systems>; Kinney, Michael D 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* RE: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Ray,
>
>
>
> Are you suggesting that the exiting logic be updated for this use case
> without adding a new enum?
>
>
>
> Sean, can you provide a revised patch that does this?
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Ni, Ray
> *Sent:* Tuesday, October 25, 2022 12:58 AM
> *To:* devel@edk2.groups.io; Rhodes, Sean 
> *Cc:* Gao, Zhichao ; Wang, Jian J <
> jian.j.w...@intel.com>; Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> I need a reason of adding
> EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended.
>
> In my opinion, without adding this new enum value, it’s still possible to
> support MS recommendation.
>
>
>
> *From:* devel@edk2.groups.io  *On Behalf Of *Sean
> Rhodes
> *Sent:* Tuesday, October 25, 2022 3:27 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Wang,
> Jian J ; Gao, Liming 
> *Subject:* Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to
> control the position of the Logo
>
>
>
> Hi Ray
>
>
>
> Where would you suggest this code goes? edk2 should support both Microsoft
> recommended and "normal". The original patch handled this well.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Mon, 10 Oct 2022 at 10:25, Ni, Ray  wrote:
>
> The logic I shared below is from the LogoDxe driver which produces
> EDKII_PLATFORM_LOGO_PROTOCOL.
>
> This driver should know the image size and it can account for the image
> size.
>
>
>
> Thanks,
>
> Ray
>
>
>
> *From:* Sean Rhodes 
> *Sent:* Monday, October 10, 2022 4:51 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Wang,
> Jian J ; Gao, Liming 
> *Subject:* Re: [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the
> position of the Logo
>
>
>
> Hi Ray
>
>
>
> Thank you, it does, and I think it will work for most splash images.
> However, the way it's written in my patch accounts for the Image size. This
> will handle splash images that are equal to, or larger than the resolution
> of the display.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Sat, 8 Oct 2022 at 03:02, Ni, Ray  wrote:
>
> Sean,
> I remember that I evaluated the BGRT requirement when designing the
> PlatformLogo protocol.
>
> So, I went back to got the code I wrote long time ago as below.
> I didn't try to understand them now. Does it make sense to you?
>
> Status = gBS->HandleProtocol (gST->ConsoleOutHandle,
> , (VOID **) );
> if (!EFI_ERROR (Status)) {
>   //
>   // Center of LOGO is in the vertical position 38.2% when
> PcdBootLogoOnlyEnable is TRUE
>   // Y = (VerticalResolution - LogoHeight) / 2
>   // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
>   // OffsetY + Y = Y'
>   // OffsetY = Y' - Y = -0.118 * VerticalResolution
>   //
>   *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
>   *OffsetX   = 0;
>   *OffsetY   = -118 * (INTN)
> GraphicsOutput->Mode->Info->VerticalResolution / 1000;
> }
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Sean Rhodes 
> > Sent: Monday, September 26, 2022 4:10 PM
> 

Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Mike/Ray

Thanks - so you mean something like 
https://github.com/tianocore/edk2/pull/3528? ( 
https://github.com/tianocore/edk2/pull/3528 ) (Just for example)

If not, I'm not sure how to control it without the PCD?

Sean


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

Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the position of the Logo

[Sean Rhodes]

Hi Ray

Where would you suggest this code goes? edk2 should support both Microsoft
recommended and "normal". The original patch handled this well.

Thanks

Sean

On Mon, 10 Oct 2022 at 10:25, Ni, Ray  wrote:

> The logic I shared below is from the LogoDxe driver which produces
> EDKII_PLATFORM_LOGO_PROTOCOL.
>
> This driver should know the image size and it can account for the image
> size.
>
>
>
> Thanks,
>
> Ray
>
>
>
> *From:* Sean Rhodes 
> *Sent:* Monday, October 10, 2022 4:51 PM
> *To:* Ni, Ray 
> *Cc:* devel@edk2.groups.io; Gao, Zhichao ; Wang,
> Jian J ; Gao, Liming 
> *Subject:* Re: [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the
> position of the Logo
>
>
>
> Hi Ray
>
>
>
> Thank you, it does, and I think it will work for most splash images.
> However, the way it's written in my patch accounts for the Image size. This
> will handle splash images that are equal to, or larger than the resolution
> of the display.
>
>
>
> Thanks
>
>
>
> Sean
>
>
>
> On Sat, 8 Oct 2022 at 03:02, Ni, Ray  wrote:
>
> Sean,
> I remember that I evaluated the BGRT requirement when designing the
> PlatformLogo protocol.
>
> So, I went back to got the code I wrote long time ago as below.
> I didn't try to understand them now. Does it make sense to you?
>
> Status = gBS->HandleProtocol (gST->ConsoleOutHandle,
> , (VOID **) );
> if (!EFI_ERROR (Status)) {
>   //
>   // Center of LOGO is in the vertical position 38.2% when
> PcdBootLogoOnlyEnable is TRUE
>   // Y = (VerticalResolution - LogoHeight) / 2
>   // Y' = VerticalResolution * 0.382 - LogoHeight * 0.5
>   // OffsetY + Y = Y'
>   // OffsetY = Y' - Y = -0.118 * VerticalResolution
>   //
>   *Attribute = EdkiiPlatformLogoDisplayAttributeCenter;
>   *OffsetX   = 0;
>   *OffsetY   = -118 * (INTN)
> GraphicsOutput->Mode->Info->VerticalResolution / 1000;
> }
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Sean Rhodes 
> > Sent: Monday, September 26, 2022 4:10 PM
> > To: devel@edk2.groups.io
> > Cc: Rhodes, Sean ; Gao, Zhichao
> > ; Ni, Ray ; Wang, Jian J
> > ; Gao, Liming 
> > Subject: [PATCH 2/3] MdeModulePkg/Logo: Add a PCD to control the
> > position of the Logo
> >
> > When set to true, the Logo is positioned according to the BGRT
> > specification, 38.2% from the top of the screen. When set to false,
> > no behaviour is changed and the logo is positioned centrally.
> >
> > Cc: Zhichao Gao 
> > Cc: Ray Ni 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> > Signed-off-by: Sean Rhodes 
> > ---
> >  MdeModulePkg/Logo/Logo.c  | 5 +
> >  MdeModulePkg/Logo/LogoDxe.inf | 4 
> >  MdeModulePkg/MdeModulePkg.dec | 6 ++
> >  MdeModulePkg/MdeModulePkg.uni | 6 ++
> >  4 files changed, 21 insertions(+)
> >
> > diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
> > index 8ab874d2da..1638d0f984 100644
> > --- a/MdeModulePkg/Logo/Logo.c
> > +++ b/MdeModulePkg/Logo/Logo.c
> > @@ -13,6 +13,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #include 
> >
> >  #include 
> >
> >  #include 
> >
> > +#include 
> >
> >
> >
> >  typedef struct {
> >
> >EFI_IMAGE_ID ImageId;
> >
> > @@ -69,6 +70,10 @@ GetImage (
> >  return EFI_NOT_FOUND;
> >
> >}
> >
> >
> >
> > +  if (FixedPcdGetBool (PcdFollowMicrosoftRecommended)) {
> >
> > +mLogos[Current].Attribute =
> > EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended;
> >
> > +  }
> >
> > +
> >
> >(*Instance)++;
> >
> >*Attribute = mLogos[Current].Attribute;
> >
> >*OffsetX   = mLogos[Current].OffsetX;
> >
> > diff --git a/MdeModulePkg/Logo/LogoDxe.inf
> > b/MdeModulePkg/Logo/LogoDxe.inf
> > index 41215d25d8..ce29950089 100644
> > --- a/MdeModulePkg/Logo/LogoDxe.inf
> > +++ b/MdeModulePkg/Logo/LogoDxe.inf
> > @@ -41,6 +41,7 @@
> >UefiBootServicesTableLib
> >
> >UefiDriverEntryPoint
> >
> >DebugLib
> >
> > +  PcdLib
> >
> >
> >
> >  [Protocols]
> >
> >gEfiHiiDatabaseProtocolGuid## CONSUMES
> >
> > @@ -48,6 +49,9 @@
> >gEfiHiiPackageListProtocolGuid ## PRODUCES CONSUMES
> >
> >gEdkiiPlatformLogoProtocolGuid ## PRODUCES
> >
> >
> >
> > +[Pcd]
> >