Hi Mike,
Thanks for reviewing. Patch updated here:
https://edk2.groups.io/g/devel/message/114182.
From my check this change need not update with the same function header.
Can you help to review again?
Thanks
Ren, Suqiang
-Original Message-
From: Kinney,
Add the description of FileName[1] to align with UEFI spec 2.10.
REF: UEFI spec 2.10 section 13.5.16
Signed-off-by: Suqiang Ren
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
---
MdePkg/Include/Guid/FileInfo.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Sami,
On Mon, Jan 22, 2024 at 05:15:44PM +, Sami Mujawar wrote:
> Hi All,
>
> DynamicTablesPkg currently supports Arm architecture, and we welcome the
> adoption by other architectures.
>
> Following is my proposal for moving forward.
>
> Goals:
> - reuse common code
> - streamline the
We don't need the space between @ param. Please check it.
Thanks
Abner
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114180): https://edk2.groups.io/g/devel/message/114180
Mute This Topic: https://groups.io/mt/103831198/21656
Group
Sunil,
I thought "WriteBackDataCacheRange not supported" is more explicit over
"CMO not available".
@Pedro Falcato For the example you mentioned, is
your concern more about someone not being able to notice the problem (that
the system is non-coherent) at the time of development and later ending
[AMD Official Use Only - General]
Yeah, please check if AMD specific SaveStatelib library under
UefiCpuPkg/Library/MmSaveStateLib can cover the change or not.
Thanks
Abner
> -Original Message-
> From: Attar, AbdulLateef (Abdul Lateef)
> Sent: Saturday, January 20, 2024 10:38 PM
> To:
[AMD Official Use Only - General]
Please confirm if the latest edk2 SmmCpuFeatureLibCommon.c and
AmdSmmCpuFeatureLib.c under SmmCpuFeatureLib can cover your changes in this
patch or not.
Thanks
Abner
> -Original Message-
> From: duke.z...@amd.com
> Sent: Thursday, January 18, 2024
Hi Liming,
I created a PR: https://github.com/tianocore/edk2/pull/5182, could you help
push it ?
Thanks
Xu Guo
-Original Message-
From: gaoliming
Sent: Tuesday, January 16, 2024 10:20 PM
To: devel@edk2.groups.io; Xu, GuoX
Cc: Kinney, Michael D ; Liu, Zhiguang
Subject: 回复:
Hi Ashraf,
Besides DSC, PCD value also comes from the build tool command line option, DEC
and INF. This patch looks only check the PCD changes from DSC, it's not cover
all the cases.
Thanks,
Bob
-Original Message-
From: Kinney, Michael D
Sent: Tuesday, January 23, 2024 9:28 AM
To:
ok, I got it. I don't have further questions about plan A.
Thanks
Abner
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114174): https://edk2.groups.io/g/devel/message/114174
Mute This Topic: https://groups.io/mt/103679850/21656
Group
Thanks much Johnson! We will investigate it based on your comments.
> -Original Message-
> From: Brian J. Johnson
> Sent: Tuesday, January 23, 2024 3:12 AM
> To: devel@edk2.groups.io; kra...@redhat.com; West, Catharine
>
> Cc: Xu, Min M ; Ni, Ray ; Wu,
> MingliangX ; Yao, Jiewen
> ;
[AMD Official Use Only - General]
> -Original Message-
> From: duke.z...@amd.com
> Sent: Thursday, January 18, 2024 2:50 PM
> To: devel@edk2.groups.io
> Cc: Xing, Eric ; Yao, Ken ; Fu,
> Igniculus ; Chang, Abner
> Subject: [PATCH 07/33] AMD/VanGoghBoard: Check in PciPlatform
>
> From:
[AMD Official Use Only - General]
> -Original Message-
> From: duke.z...@amd.com
> Sent: Thursday, January 18, 2024 2:50 PM
> To: devel@edk2.groups.io
> Cc: Zhai, MingXin (Duke) ; Xing, Eric
> ; Fu, Igniculus ; Chang, Abner
>
> Subject: [PATCH 05/33] AMD/VanGoghBoard: Check in
[AMD Official Use Only - General]
Please review all C header files in this patch set. Remove the leading
underscore and use double underscore at trailing.
For example,
_AGESA_H_ -> AGESA_H__
Thanks
Abner
> -Original Message-
> From: duke.z...@amd.com
> Sent: Thursday, January 18, 2024
Hi Abner,
The ExceptionLib is different from other libs such as Mp and Timer.
Since ExceptionLib can provide for 32-bit service for LoongArch32 in the
future, 64-bit private files are located in LoongArch/LoongArch64/ and
the 32-bit will be located in LoongArch/LoongArch32, although the
Reviewed by Jenny Huang
-Original Message-
From: Sheng, W
Sent: Sunday, January 21, 2024 10:47 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Huang, Jenny ; Chiang,
Chris
Subject: [PATCH] MdeModulePkg/PciBusDxe: Add feedback status for PciIoMap
PciIoMap () need to feedback the status of
[AMD Official Use Only - General]
HI all,
I have no problem with the plan A, except the folder structure under
CpuExecptionHandlerLib.
It has a LoongArch folder that contains the common source files for LoongArch
and LoongArch64 folder under LoongArch for 64-buite architecture. This folder
*Reminder: TianoCore Bug Triage - APAC / NAMO*
*When:*
Tuesday, January 23, 2024
6:30pm to 7:30pm
(UTC-08:00) America/Los Angeles
*Where:*
On 1/22/2024 6:53 PM, Oliver Smith-Denny wrote:
I was able to repro your bug (by just turning on page guards on
ArmVirtQemu, allocating runtime mem and freeing it). I think you
are the first person to free runtime mem on ARM64 with page guards
enabled (and to care when it failed :).
The heap
Provide an optional method for PEI to declare a specific address
range to use for the Memory Type Information bins. The current
algorithm uses heuristics that tends to place the Memory Type
Information bins in the same location, but memory configuration
changes across boots or algorithm changes
On 1/22/2024 2:06 PM, Rebecca Cran via groups.io wrote:
On 1/19/2024 1:03 PM, Oliver Smith-Denny wrote:
Thanks for trying. In lieu of being able to test myself, all I can offer
is adding some more prints, when the memory gets allocated, making sure
it is 64k aligned then. I'd be curious to see
Hi Tan Ming,
In this case, the function header in the implementation needs to be
updated to match the MdePkg header file changes.
I agree that the device error would have to propagate from the HII
Config Routing Protocol that may use services such as UEFI Variable
Services or other device
Hi Ashraf,
The PcdValueInit feature is not limited to only PCDs of type VPD. It is
for any structured PCDs. Did you test PCDs with all types (e.g.
PcdsFixedAtBuild
PcdsPactahbleInModule, PcdsDynamicHii, PcdsDynamicDatabase, PcdsDynamicVpd,
PcdsDynamicExHii, PcdsDynamicExDatabase,
Hi Suqiang,
The comment line added look like is exceeds 80 columns. Please reformat.
Also, there are implementations of this service in the edk2 repo.
Please update those with this same function header update.
Thanks,
Mike
> -Original Message-
> From: Ren, SuqiangX
> Sent: Thursday,
Hi Suqiang,
The changes to this one .h file look ok.
However, there are implementations of the Runtime Services in the edk2 repo
that also need their function headers updates. Can you please add those
changes to this patch series?
Thanks,
Mike
> -Original Message-
> From: Ren,
*Tools, CI, Code base construction meeting series*
*When:*
Monday, January 22, 2024
4:30pm to 5:30pm
(UTC-08:00) America/Los Angeles
*Where:*
Hi Ray,
+Andrew Fish
That optimization was imported into git history 17 years ago, so
it has effectively always been there. I do not recall the performance
improvement at the time the optimization was originally implemented.
The difference in behavior is that caching the result may miss
an
*Reminder: Tools, CI, Code base construction meeting series*
*When:*
Monday, January 22, 2024
4:30pm to 5:30pm
(UTC-08:00) America/Los Angeles
*Where:*
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Joey Vagedes
> Sent: Monday, January 22, 2024 3:21 PM
> To: devel@edk2.groups.io
> Cc: Liming Gao ; Kinney, Michael D
> ; Sean Brogan
> Subject: [PATCH v1 1/1] .pytool/Plugin: UncrustifyCheck: use stat
> instead of os.stat
>
>
The UncrustifyCheck plugin passes os.stat.S_IWRITE to os.chmod, when
attempting to change file permissions. os.stat.S_IWRITE does not exist
as os.stat is a function. The correct value is stat.S_IWRITE.
Signed-off-by: Joey Vagedes
Cc: Liming Gao
Cc: Michael D Kinney
Cc: Sean Brogan
---
When UncrustifyCheck attempts to update the permissions of a file
( Only happens when a different error occurs ), it incorrectly uses
os.stat.S_IWRITE, which does not exist. The correct value is
stat.S_IWRITE.
see os.chmod documentation: https://docs.python.org/3/library/os.html#os.chmod
Cc:
Hi Guo,
Thank you for starting this task to update Firmware Management Protocol.
There are additional tasks to make sure all required code changes are
also implemented for a specification update like this.
* Create a TianoCore Bugzilla that describes the specification update
needed with links
On 1/19/2024 1:03 PM, Oliver Smith-Denny wrote:
Thanks for trying. In lieu of being able to test myself, all I can offer
is adding some more prints, when the memory gets allocated, making sure
it is 64k aligned then. I'd be curious to see what the address is that
is attempting to be freed.
My
On 1/22/2024 1:24 PM, Oliver Smith-Denny wrote:
Allocating pool memory will never be 4KB aligned because of the
POOL_HEAD. See:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Mem/Pool.c#L463-L537.
The allocated page is 4KB aligned, of course, but we store the POOL_HEAD
at
Hi Rebecca,
I do not recall any statements in the EFI Spec that require 4KB
alignment of the UEFI System Table, Boot Services Table,
or Runtime Services Table.
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Rebecca
> Cran
> Sent: Monday, January 22, 2024 11:53 AM
On 1/22/2024 11:52 AM, Rebecca Cran wrote:
I've been working on updating the T32 script EfiLoadDxe.cmm in
EmbeddedPkg/Scripts/LauterbachT32 and one of the issues I've run into is
that the EFI_SYSTEM_TABLE - pointed to by `gST` and `gDxeCoreST` - isn't
aligned to 4KB like the script expects.
I've been working on updating the T32 script EfiLoadDxe.cmm in
EmbeddedPkg/Scripts/LauterbachT32 and one of the issues I've run into is
that the EFI_SYSTEM_TABLE - pointed to by `gST` and `gDxeCoreST` - isn't
aligned to 4KB like the script expects.
Instead, I'm seeing AllocateRuntimeCopyPool
On 1/18/24 09:46, Gerd Hoffmann wrote:
On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
Disabling cache by default results in violation of BTG protections (if BTG
enabled).
BIOS cannot assume that cache is disabled before it executes as ACM may be required to enable NEM.
Originally posted at
https://twitter.com/UEFIForum/status/1745518769232077208
The Multi-ISA Driver Compatibility Survey is at
https://docs.google.com/forms/d/e/1FAIpQLScXjwaSBgLeqB1coEDxCPxho5JWF3AMqshOTJ2wd6Tf0He4LA/viewform
From that page:
Did you know Tiano today supports four 64-bit
Hello,
(Originally sent to edk2 discuss but it looks like my message has been stuck in
moderation for a week, so I thought I would try here instead.)
I am new to UEFI and trying to learn how to use EDK 2. I have been able to
build EmulatorPkg with stuart but I had a couple questions on where
Hi All,
DynamicTablesPkg currently supports Arm architecture, and we welcome the
adoption by other architectures.
Following is my proposal for moving forward.
Goals:
- reuse common code
- streamline the adoption by other architectures
- minimise the impact on migration of the existing
On 1/20/24 18:08, Michael Brown wrote:
> Suggested-by: Ray Ni
> Signed-off-by: Michael Brown
> ---
> .../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
Two comments:
On 1/20/24 18:08, Michael Brown wrote:
> NestedInterruptTplLib provides a way for timer interrupt handlers
> (which must support nested interrupts) to prevent unbounded stack
> consumption.
>
> The underlying issue was first observed in OvmfPkg, since interrupt
> storms can arise
Hi,
> I do appreciate that it's difficult to understand the internals of
> NestedInterruptTplLib. It's fundamentally having to solve a very difficult
> problem within the constraints of the UEFI API. I think the solution that
> NestedInterruptTplLib provides is as simple as it's possible to
CoreConnectSingleController() searches for the Driver Family Override
Protocol drivers by looping and checking each Driver Binding Handles.
This loop can be skipped by checking if any Driver Family Override
Protocol installed in the platform first, to improve the performance.
Cc: Liming Gao
Cc:
CoreGetProtocolInterface() is called by CoreOpenProtocol(),
CoreCloseProtocol() and CoreOpenProtocolInformation().
Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
parameter UserHandle has been already checked for validation. So does
CoreCloseProtocol().
Removing the handle
46 matches
Mail list logo
