I got the same issue and already submit a patch.
https://edk2.groups.io/g/devel/topic/patch_v2_1_1/105038588?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105038588,previd%3D1710905523338626613,nextid%3D1710847665703537227=1710905523338626613=1710847665703537227
Hope it got accepted and push to
The original intention is using the string data for firmware manufacturer of
SMBIOS type 45 record which associated to PCI device. Moving to ShellPkg would
limit the usage for other purpose.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online
Declare InternalAssertJumpBuffer as EXTERN
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Sami Mujawar
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Shun Cheng Liu
Reviewed-by: levi.yun
---
MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 1 +
Declare InternalAssertJumpBuffer to fix build error.
Shun Cheng Liu (1):
MdePkg/BaseLib: Fix AARCH64 compilation error
MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 1 +
MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm | 1 +
2 files changed, 2 insertions(+)
--
2.25.1
Still waiting for the new UEFI Specification to be released. Plan to send out
the edk2 patches as soon as it is released.
From: Vivian Shi (石丽)
Sent: Tuesday, March 19, 2024 12:01 AM
To: Kasbekar, Saloni ; Sivaraman Nainar
; devel@edk2.groups.io
Cc: Dhanaraj V ; Clark-williams, Zachary
;
Hi all,
I've been trying to build the latest 2023 release of EDKII with AARCH64 using
VS2019, and I'm encountering an issue with line 51 of
MdePkg\Library\BaseLib\AArch64\SetJumpLongJump.asm.
Specifically, there's no EXTERN for InternalAssertJumpBuffer and the 64 bit ARM
cross assembler that
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented dumping of the UEFI Conformance Profiles Table using Dmem.c
Additionally added the base support for the table with new
header file ConformanceProfiles.h (Cc'd maintainers of MdePkg for this)
Cc: Ray Ni
Cc: Zhichao Gao
Cc:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented dumping of the Image Execution Table using Dmem.c
Cc: Ray Ni
Cc: Zhichao Gao
Signed-off-by: Sam Kaynor
---
ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |
138
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4352
Implemented the dumping of the UEFI RT Properties Table using Dmem.c
Cc: Ray Ni
Cc: Zhichao Gao
Signed-off-by: Sam Kaynor
---
ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c |
62
v1->v2:
- Changed how the Conformance Profile Table is iterated
- Changed how the Image Execution Table is iterated
Cc: Ray Ni
Cc: Zhichao Gao
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Sam Kaynor
Sam Kaynor (3):
ShellPkg: UefiShellDebug1CommandsLib: Dumping RT
Hi all,
We're planning to refactor the shell into a library so that shell apps
possibly used in the field for testing can be easily adapted for automation.
Our plan is:
- Refactor ShellInfoObject into base internals and interactive elements
- Migrate functions that imply interactivity into
On Tue, 19 Mar 2024 at 14:50, Marcin Juszkiewicz
wrote:
>
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
>
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
>
> Values are read from TF-A using platform specific
Hi Sunil,
On Mon, Mar 18, 2024 at 6:00 AM Sunil V L wrote:
> Hi Tuan,
>
> On Thu, Mar 14, 2024 at 01:19:16PM -0700, Tuan Phan wrote:
> > The GCD EFI_MEMORY_UC and EFI_MEMORY_WC memory attributes will be
> > supported when Svpbmt extension available.
> >
> > Cc: Gerd Hoffmann
> > Cc: Laszlo
Hi Yi, thanks for your email. I created a Bugzilla ticket for this, see
Bugzilla ID #4732: https://bugzilla.tianocore.org/show_bug.cgi?id=4732. The
Pkcs1v2Encrypt() API is maintained but the implementation is refactored. There
is currently no Pkcs1v2Decrypt(), this is also a newly
From: Xiong Yining
Provide functions to check for memory information:
- amount of memory nodes
- memory address
- NUMA node id for memory
Values are read from TF-A using platform specific SMC calls.
Signed-off-by: Xiong Yining
Signed-off-by: Chen Baozi
Signed-off-by: Marcin Juszkiewicz
---
There is no need for EDK2 to know that there is DeviceTree around.
All hardware information is read using functions from
SbsaQemuHardwareInfoLib library.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 1 -
We have SbsaQemuHardwareInfoLib to ask for hardware details. No need to
parse DeviceTree anymore.
Signed-off-by: Marcin Juszkiewicz
---
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 6 ++
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf | 5 ++---
This library provides functions to check for hardware information.
For now it covers CPU ones:
- amount of cpu cores
- MPIDR value for cpu core
- NUMA node id for cpu core
Values are read from TF-A using platform specific SMC calls.
Signed-off-by: Marcin Juszkiewicz
---
We want to stop parsing DeviceTree to gather hardware information.
Instead we ask TF-A for those details using SMC calls. On real hardware
platform it could be asking on-board Embedded Controller.
Hardware information (CPU, Memory) is now in SbsaQemuHardwareInfoLib
together with new code for
On Thu, 14 Mar 2024 at 15:21, Marcin Juszkiewicz
wrote:
>
> W dniu 14.03.2024 o 15:17, Marcin Juszkiewicz via groups.io pisze:
> > We want to stop parsing DeviceTree (in EDK2) to gather hardware information.
> >
> > Instead we ask TF-A for those details using SMC calls. On real hardware
> >
@Saloni Kasbekar,
Can you please comment on the changes?
Thanks
Siva
-Original Message-
From: Sivaraman Nainar
Sent: Monday, February 26, 2024 4:01 PM
To: devel@edk2.groups.io; Sivaraman Nainar ; Laszlo Ersek
; Santhosh Kumar V ; Saloni Kasbekar
; Zachary Clark-williams
Cc: Raj V
W dniu 19.03.2024 o 12:02, Ard Biesheuvel pisze:
EDK2 starts and one of the first DXE called is SbsaQemuPlatformDxe one:
How is this guaranteed? DXE are generally dispatched in the order in
which they appear in the FDF, but only if all DEPEX dependencies are
satisfied. DEPEXes are compiled
On Tue, 19 Mar 2024 at 11:25, Marcin Juszkiewicz
wrote:
>
> W dniu 15.03.2024 o 12:49, Marcin Juszkiewicz pisze:
> > W dniu 14.03.2024 o 16:13, Ard Biesheuvel pisze:
>
> >> How is it guaranteed that other components will only see the correct
> >> core count? DXE dispatch is ordered using a
W dniu 15.03.2024 o 12:49, Marcin Juszkiewicz pisze:
W dniu 14.03.2024 o 16:13, Ard Biesheuvel pisze:
How is it guaranteed that other components will only see the correct
core count? DXE dispatch is ordered using a dependency graph, so all
users of this PCD should never execute before this
On Tue, Mar 19, 2024 at 05:10:39PM +0800, Chao Li wrote:
> He Gerd,
>
> > Speaking of this series: maybe split it into two? The first part
> > of this series with the Mde*Pkg + UefiPkg changes looks almost ready
> > to merge to me, so maybe we can get that in while still sorting out
> > the
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/49620fa0bb9757bce13f41f604001114ea6c40de
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116888): https://edk2.groups.io/g/devel/message/116888
Mute This
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/ff8a146ace642cadc83b58cd4382181ec2dac633
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116887): https://edk2.groups.io/g/devel/message/116887
Mute
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/bebabc28d9471de17b9dbebf83d4dfb54624ac0c
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116886): https://edk2.groups.io/g/devel/message/116886
Mute This
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/244ebf6954c43496ca173e9091de92b061e0957e
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116885): https://edk2.groups.io/g/devel/message/116885
Mute This
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/7ec35ffac51d0682c1368041ca1e599189a58223
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116884): https://edk2.groups.io/g/devel/message/116884
Mute This
The patch is upstreamed by the commit:
https://github.com/tianocore/edk2-test/commit/ee928b21d8df70c5729a6ae470366d3c6a6fd84b
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116883): https://edk2.groups.io/g/devel/message/116883
Mute This
He Gerd,
Thanks,
Chao
On 2024/3/19 16:03, Gerd Hoffmann wrote:
Hi,
I can't tell the implementation scheme of the current lib and existing
lib implementation scheme which one is better, Could you give we some
advice?
I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
Clear out the variable SmmCommunicateVerifyPassword which contains password
before goto Exit.
To avoid vulnerability.
Signed-off-by: Nayana Patel
---
.../UserAuthenticationDxeSmm/UserAuthenticationSmm.c| 2 ++
1 file changed, 2 insertions(+)
diff --git
Clear out the variable SmmCommunicateSetPassword which contains password before
goto Exit.
To avoid vulnerability.
Signed-off-by: Nayana Patel
---
.../UserAuthenticationDxeSmm/UserAuthenticationSmm.c| 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi,
> > > I can't tell the implementation scheme of the current lib and existing
> > > lib implementation scheme which one is better, Could you give we some
> > > advice?
> > I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
> > it is not really loongarch-specific.
> >
>
Added Inf variable, and the error case returned value was checked properly.
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
36 matches
Mail list logo
