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.
> >
> >
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
a/Features/Intel/UserInterface/
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
a/Features/Intel/UserInterfa
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
i
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
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/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/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/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 This
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
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 remai
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 dri
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 depende
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 from
@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 Akil
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
> > platfo
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 hand
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
---
Platform/Qemu/SbsaQemu/
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 ++---
.../SbsaQemu/Library/SbsaQemu
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 -
.../SbsaQemu/Library/FdtHelperLib/FdtHelper
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
---
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 implemen
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 Erse
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 SM
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
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 Pr
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
ShellPk
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
ShellPkg/Libr
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: Mich
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 c
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
; Hunte
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
-=-=-=-=-=
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 +
MdePkg/Library/BaseLib/AA
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
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&previd=1710905523338626613&nextid=1710847665703537227
Hope it got accepted a
35 matches
Mail list logo
