Hi Greg,
On Thu, 20 Feb 2025 at 19:08, greg.wilson via groups.io
wrote:
>
> Hi,
>
> I am trying to automatically load an EFI file in EDK2, before the UEFI Shell
> is available.
>
> It is a prebuilt UNDI Network Driver from Intel, E4297X8.EFI, from the
> complete Ethernet Drivers package zip fi
On Tue, 28 Jan 2025 at 23:38, Tom Lendacky wrote:
>
> On 1/28/25 14:57, Lendacky, Thomas via groups.io wrote:
> > On 1/28/25 10:26, Ard Biesheuvel via groups.io wrote:
> >> Please retry with a build created from the latest HEAD. There was a
> >> bug in that change t
Please retry with a build created from the latest HEAD. There was a
bug in that change that got fixed today.
On Tue, 28 Jan 2025 at 10:09, Aithal, Srikanth via groups.io
wrote:
>
> Hello,
>
> With current edk2/master booting AMD SEV-ES guest with OvmfPkgX64 package is
> failing with below error
On Mon, 20 Jan 2025 at 11:50, Usama Arif wrote:
>
>
>
> On 20/01/2025 10:32, Ard Biesheuvel wrote:
> > On Mon, 20 Jan 2025 at 11:27, Usama Arif wrote:
> >>
> >>
> > ...
> >> Hi Ard,
> >>
> >> Just wanted to check how should
On Mon, 20 Jan 2025 at 11:27, Usama Arif wrote:
>
>
...
> Hi Ard,
>
> Just wanted to check how should we proceed forward? Should we try and fix the
> warning
> and corruption during kexec as done in this series or not initialize memory
> attributes
> table at all in kexec boot? I would prefer fi
On Tue, 14 Jan 2025 at 09:31, Xu, Min M wrote:
>
> On Tuesday, January 14, 2025 4:22 PM, Ard Biesheuvel wrote:
> >
> > On Tue, 14 Jan 2025 at 03:54, Xu, Min M wrote:
> > >
> > > Hi, Crystal
> > >
> > > PR#5939 (https://github.com/tianocore/ed
On Tue, 14 Jan 2025 at 03:54, Xu, Min M wrote:
>
> Hi, Crystal
>
> PR#5939 (https://github.com/tianocore/edk2/pull/5939) was merged yesterday
> but it seems it broke the legacy VM bootup.
>
>
>
> Below is the crash log of the failure.
>
I take it this crash occurs after loading shim?
-=-=-=-=-
On Fri, 10 Jan 2025 at 12:36, Breno Leitao wrote:
>
> Hello Ard,
>
> On Fri, Jan 10, 2025 at 08:32:08AM +0100, Ard Biesheuvel wrote:
> > On Thu, 9 Jan 2025 at 17:32, Usama Arif wrote:
>
> > > I think in the end whoevers' responsibility it is, the easiest path
On Fri, 10 Jan 2025 at 11:53, Usama Arif wrote:
>
>
>
> On 10/01/2025 07:21, Ard Biesheuvel wrote:
> > On Thu, 9 Jan 2025 at 17:36, Usama Arif wrote:
> >>
> >>
> >>
> >> On 09/01/2025 15:45, Ard Biesheuvel wrote:
> >>> On Wed, 8
On Thu, 9 Jan 2025 at 17:32, Usama Arif wrote:
>
>
>
> On 09/01/2025 16:15, Ard Biesheuvel wrote:
> > On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
> >>
> >> When this area is not reserved, it comes up as usable in
> >> /sys/firmware/memmap. This mea
On Thu, 9 Jan 2025 at 17:36, Usama Arif wrote:
>
>
>
> On 09/01/2025 15:45, Ard Biesheuvel wrote:
> > On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
> >>
> >> The commit in [1] introduced a check to see if EFI memory attributes
> >> table was corrupt
On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
>
> When this area is not reserved, it comes up as usable in
> /sys/firmware/memmap. This means that kexec, which uses that memmap
> to find usable memory regions, can select the region where
> efi_mem_attr_table is and overwrite it and relocate_kerne
On Wed, 8 Jan 2025 at 23:00, Usama Arif wrote:
>
> The commit in [1] introduced a check to see if EFI memory attributes
> table was corrupted. It assumed that efi.memmap.nr_map remains
> constant, but it changes during late boot.
> Hence, the check is valid during cold boot, but not in the subsequ
(cc Liming)
On Mon, 6 Jan 2025 at 14:29, Jose Marinho wrote:
>
> Hi All,
>
> This request was made at the end of last year, so I’ll take the opportunity
> to refresh the request, and to loop in some folks that were missing from the
> original mail.
>
> Could we please get the following 2 stagin
On Thu, 5 Dec 2024 at 17:36, Hernandez, Ronal via groups.io
wrote:
>
> Thank you for your feedback, Ard Biesheuvel.
>
> After reviewing the UEFI Specification our interpretation is that because it
> is now optional to support any of the EFI Runtime Services, the
> EFI_RT_PROP
On Thu, 5 Dec 2024 at 01:07, Hernandez, Ronal via groups.io
wrote:
>
> Hello All,
>
>
>
> I am a firmware engineer at HPI, and I would like to make a patch
> contribution to the tianocore/edk2-test project.
>
>
>
> The patch consists of adding a new test case to the UEFI Self-Certified Test
> pr
On Wed, 4 Dec 2024 at 05:20, davidr via groups.io
wrote:
>
> Hi,
>
> I was testing out dumping a raw OVMF_VARS.fd into an FDF data section and
> noticed that my rebuilds of OVMF with no code changes went from 15 seconds to
> over 1 minute. The only change was the data in the NV_VARIABLE_STORE da
On Mon, 2 Dec 2024 at 22:25, Rebecca Cran wrote:
>
> I've set up Secure Boot for my firmware, but I'm having problems when
> trying to have fwupdmgr install a DBX update.
>
> Since I've run into problems setting up arm64_DBXUpdate.bin from
> uefi.org or DefaultDbx.bin from a build of secureboot_ob
On Mon, 25 Nov 2024 at 18:10, Michael D Kinney via groups.io
wrote:
>
> If the commit is not correct, then you can revert the change and
> push the revert commit.
>
> Since this is a public repo, forced pushes to remove the commit
> are now allowed.
>
*NOT* allowed !!
-=-=-=-=-=-=-=-=-=-=-=-
Gr
(cc Gerd)
On Mon, 18 Nov 2024 at 20:26, mitchell.augustin via groups.io
wrote:
>
> Hello!
> We've identified an issue with OVMF that causes the boot time of VMs to be
> considerably slower (usually taking 10+ minutes more) under (at least) the
> following conditions:
> * CPU passthrough is use
Hi,
On Thu, 7 Nov 2024 at 19:47, Oliver Smith-Denny
wrote:
>
> Hi Ard,
>
> I wanted to follow up on the ArmSoftFloatLib removal
> work you had been doing, particularly in light of
> the recent fire around the subhook submodule going
> down.
>
> What work is left to be able to remove ArmSoftFloatL
On Mon, 4 Nov 2024 at 09:42, JC wrote:
>
> Hi all,
>
> the https://github.com/Zeex/subhook.git is not available anymore,
> since Zeex decided to hide the content.
>
> SUBHOOK was a component used in the UnitTestFrameworkPkg.
>
Thanks for the report. If the upstream has disappeared, I think we
sho
On Fri, 20 Sept 2024 at 03:26, Nhi Pham OS wrote:
>
> I think Ard approved this patch. Is it sufficient to push?
>
> https://edk2.groups.io/g/devel/message/120565
>
No objections from me.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1
On Mon, 9 Sept 2024 at 18:56, Rebecca Cran wrote:
>
> On 9/9/24 10:13 AM, Ard Biesheuvel via groups.io wrote:
> > On Mon, 9 Sept 2024 at 18:11, Rebecca Cran wrote:
> >> Replace the old X86EmulatorDxe with one built from
> >> https://github.com/intel/MultiArchUefiP
On Fri, 13 Sept 2024 at 13:38, Marcin Juszkiewicz
wrote:
>
> I looked at pull requests for edk2-platforms yesterday. Went through
> those from times when we used only mail for patches.
>
> Closed several ones as their code was already merged, left "please
> rebase or close" like comments in those
On Thu, 29 Aug 2024 at 20:59, Ard Biesheuvel wrote:
>
> On Thu, 29 Aug 2024 at 20:33, Oliver Smith-Denny
> wrote:
> >
> > edk2 PR https://github.com/tianocore/edk2/pull/6048 moved some
> > architectural pieces
> > from ArmPkg to MdePkg. This patch updates al
On Wed, 11 Sept 2024 at 12:41, Usama Arif wrote:
>
> Looking at the TPM spec [1]
>
> If the ACPI TPM2 table contains the address and size of the Platform
> Firmware TCG log, firmware “pins” the memory associated with the
> Platform FirmwareTCG log, and reports this memory as “Reserved” memory
> vi
(cc Leif)
That would work for me - thanks.
On Tue, 10 Sept 2024 at 02:22, Sean wrote:
> Hi,
>
> In the Tools and CI meeting it was brought up that there may be a few
> developers from the European region interested in joining the discussion on
> some recurring basis. Finding a time that works
On Mon, 9 Sept 2024 at 18:11, Rebecca Cran wrote:
>
> Replace the old X86EmulatorDxe with one built from
> https://github.com/intel/MultiArchUefiPkg. This is a much more modern,
> recent implementation that's more reliable and is actively maintained.
>
> Add driver binaries for both AArch64 and RI
On Fri, 6 Sept 2024 at 16:22, Rebecca Cran
wrote:
>
> Hi Andrei,
>
>
> I've been talking to a few people about X86EmulatorPkg and their
> experience with it hasn't been positive: apparently there are lots of
> cases where it's failed to work (i.e. caused crashes) which is why it's
> not been more
the TRNG
>
> Pierre Gondois (3):
> Platform/ARM: Place MdeLibs.dsc.inc as the first include
> Platform/ARM: Move PcdEnforceSecureRngAlgorithms to MdePkg
> Platform/ARM/Juno: Use DxeRngLib.inf as default RngLib implementation
>
Reviewed-by: Ard Biesheuvel
Please ping me w
From: Ard Biesheuvel
MbedTls is much smaller than OpenSSL, and does not require a softfloat
library on 32-bit ARM. So use that instead.
Note that we still need to resolve OpensslLib, given that MbedTlsLib has
a dependency on it (but only for SM3 digital signatures, which are not
used here
From: Ard Biesheuvel
Switch to the MbedTls crypto library, which uses less space, which has
run out on RPi4 (the DEBUG build can only succeed with HTTPS boot
disabled at this point)
Signed-off-by: Ard Biesheuvel
---
Platform/RaspberryPi/RPi3/RPi3.dsc | 5 +++--
Platform/RaspberryPi/RPi4/RPi4
From: Ard Biesheuvel
Fix StMmRpmb and drop the dependency on softfloat for 32-bit ARM.
Ard Biesheuvel (2):
Platform/StMmRpmb: Fix build
Platform/StMmRpmb: Switch to MbedTls for crypto
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc |
11 ++-
1 file
From: Ard Biesheuvel
Add some missing library class resolutions relating to changes in the
core upstream EDK2 repo.
Signed-off-by: Ard Biesheuvel
---
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc | 3
+++
1 file changed, 3 insertions(+)
diff --git
a/Platform
On Mon, 2 Sept 2024 at 12:54, Marcin Juszkiewicz
wrote:
>
> EDK2 requires SIP_SVC_GET_CPU_TOPOLOGY call nowadays. Bump binaries to
> provide it.
>
> Signed-off-by: Marcin Juszkiewicz
> ---
> Platform/Qemu/Sbsa/Readme.md | 15 ++-
> Platform/Qemu/Sbsa/bl1.bin | Bin 2 -> 2 b
Hi Rebecca,
On Sun, 1 Sept 2024 at 00:33, Rebecca Cran wrote:
>
> Replace the old X86EmulatorDxe with one built from
> https://github.com/intel/MultiArchUefiPkg. This is a much more modern,
> recent implementation that's more reliable and is actively maintained.
>
> Add driver binaries for both A
On Fri, 30 Aug 2024 at 20:23, Jeremy Linton wrote:
>
> Hi,
>
> On 8/30/24 3:18 AM, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > Switch to the MbedTls crypto library, which uses less space, which has
> > run out on RPi4 (the DEBUG build can only suc
On Fri, 30 Aug 2024 at 18:05, Sami Mujawar wrote:
>
> Hi Ard,
>
> Sorry saw you reply a bit later.
>
> Yes, this is the change we need.
>
Thanks. I pushed both changes to edk2-platforms as
bbdf397aabc6..4916d5e5d107
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this
On Fri, Aug 30, 2024 at 5:46 PM Sami Mujawar via Groups.Io
wrote:
>
> Hi Ard,
>
> Thank you for this patch.
>
> These changes look good to me.
>
> Reviewed-by: Sami Mujawar
>
Thanks
> In addition to this patch I required the following changes for the FVP to
> boot to the UEFI shell.
>
> edk2 r
On Thu, 29 Aug 2024 at 21:29, Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Fix StMmRpmb and drop the dependency on softfloat for 32-bit ARM.
>
> Ard Biesheuvel (2):
> Platform/StMmRpmb: Fix build
> Platform/StMmRpmb: Switch to MbedTls for crypto
>
Pushed as
ibs.
>
> This patch is dependent on the above edk2 merging and must not be merged
> before that
> goes in.
>
> It's been a little while since I've sent a patch on the mailing list, so
> hopefully I
> have everything right :).
>
> Cc: Ard Biesheuvel
> Cc:
On Thu, 29 Aug 2024 at 10:48, Nhi Pham via groups.io
wrote:
>
> Pushed as 03d3395552c5
>
Thanks for finally providing a fix for this!
Is there any way to detect whether a firmware build has this fix?
>
> From: Chuong Tran OS
> Sent: Thursday, August 29, 2024 3
On Wed, 28 Aug 2024 at 18:05, Oliver Smith-Denny
wrote:
>
> Hi folks,
>
> It appears that the TianoCore Bugzilla page is down right now.
> We are unable to access it. I know we are discussing moving to
> GitHub Issues, but that has not been completed yet, right? Is
> there anything we can do to re
On Wed, 28 Aug 2024 at 06:12, Jeremy Linton wrote:
>
> On 8/27/24 11:37, Ard Biesheuvel wrote:
> > On Tue, 6 Aug 2024 at 16:10, Leif Lindholm
> > wrote:
> >>
> >> On Thu, Aug 01, 2024 at 10:19:50 -0500, Jeremy Linton wrote:
> >>> Hi,
> &g
From: Ard Biesheuvel
Commit
8676e88233d4 ("Platform/ ARM AARCH64: Remove ArmPlatformLib MPCore
boilerplate")
inadvertently removed the implementation of ArmGetCpuCountPerCluster(),
which was hiding in the RTSM ArmPlatformLib implementation, even though
it was not part of that lib
On Tue, 6 Aug 2024 at 16:10, Leif Lindholm wrote:
>
> On Thu, Aug 01, 2024 at 10:19:50 -0500, Jeremy Linton wrote:
> > Hi,
> >
> >
> > On 8/1/24 09:44, Ard Biesheuvel wrote:
> > > On Thu, 1 Aug 2024 at 16:11, Ard Biesheuvel wrote:
> > > >
On Thu, 1 Aug 2024 at 17:42, Nhi Pham via groups.io
wrote:
>
> For Silicon/Ampere/AmpereAltraPkg,
>
> Reviewed-by: Nhi Pham
> Tested-by: Nhi Pham
>
Pushed as 7dad9da43942..8676e88233d4
Thanks all,
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Rep
On Fri, 2 Aug 2024 at 00:39, Oliver Smith-Denny
wrote:
>
> CompilerIntrinsicsLib and ArmSoftFloatLib add ARM/AARCH64 compiler
> intrinsics and floating point functions required by OpenSSL,
> respectively. CompilerIntrinsicsLib is used almost in every DSC that
> builds ARM/AARCH64 and ArmSoftFloatL
this
case, so drop those as well.
Signed-off-by: Ard Biesheuvel
---
Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 2 --
Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 1 -
Silicon/Hisilicon/Hisilicon.dsc.inc | 1 -
Silicon/Marvell/Armada7k8k
PrePeiCore has been superseded by Sec.inf, which is a more common naming
for the SEC module, aligned with other architectures. No functional
changes intended.
Switch all users to Sec.inf so the old implementation can be retired
from EDK2.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Nhi Pham
Paul Grimes
Cc: Rebecca Cran
Cc: Sami Mujawar
Cc: Thomas Abraham
Cc: Wenyi Xie
Cc: Jeremy Linton
Cc: Ling Jia
Cc: Peng Xie
Cc: Sami Mujawar
Cc: Thomas Abraham
Cc: Wenyi Xie
Cc: Yiqi Shu
Ard Biesheuvel (2):
Platform AARCH64: Move PrePeiCore users to Sec.inf
Platform AARCH64: Move
On Thu, 1 Aug 2024 at 17:50, Rebecca Cran wrote:
>
> On 8/1/24 9:43 AM, Ard Biesheuvel wrote:
>
> > Haven't noticed this one myself. The only issue I hit once in a while
> > (but only with DEBUG builds as far as I am aware) is an ASSERT() on
> > some XhciDxe con
On Thu, 1 Aug 2024 at 17:19, Jeremy Linton wrote:
>
> Hi,
>
>
> On 8/1/24 09:44, Ard Biesheuvel wrote:
> > On Thu, 1 Aug 2024 at 16:11, Ard Biesheuvel wrote:
> >>
> >> On Thu, 1 Aug 2024 at 15:49, Jeremy Linton wrote:
> >>>
> >
On Thu, 1 Aug 2024 at 16:11, Ard Biesheuvel wrote:
>
> On Thu, 1 Aug 2024 at 15:49, Jeremy Linton wrote:
> >
> > Hi,
> >
> > On 7/31/24 11:33, Ard Biesheuvel wrote:
> > > Switch all ARM platforms that use the SEC drivers in edk2/ArmPlatformPkg
> > &
On Thu, 1 Aug 2024 at 15:49, Jeremy Linton wrote:
>
> Hi,
>
> On 7/31/24 11:33, Ard Biesheuvel wrote:
> > Switch all ARM platforms that use the SEC drivers in edk2/ArmPlatformPkg
> > to the new versions called Sec or PeilessSec - these have been cleaned
> &g
Xie
Cc: Yiqi Shu
Signed-off-by: Ard Biesheuvel
---
Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
| 4 --
Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c
| 6 --
Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
this
case, so drop those as well.
Signed-off-by: Ard Biesheuvel
---
Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 1 -
Silicon/Hisilicon/Hisilicon.dsc.inc | 1 -
Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc | 1 -
Platform/ARM/JunoPkg/ArmJuno.dsc
PrePeiCore has been superseded by Sec.inf, which is a more common naming
for the SEC module, aligned with other architectures. No functional
changes intended.
Switch all users to Sec.inf so the old implementation can be retired
from EDK2.
Signed-off-by: Ard Biesheuvel
---
Platform/ARM/Morello
Cc: Narinder Dhillon
Cc: Nhi Pham
Cc: Paul Grimes
Cc: Rebecca Cran
Cc: Sami Mujawar
Cc: Thomas Abraham
Cc: Wenyi Xie
Cc: Jeremy Linton
Cc: Ling Jia
Cc: Peng Xie
Cc: Sami Mujawar
Cc: Thomas Abraham
Cc: Wenyi Xie
Cc: Yiqi Shu
Ard Biesheuvel (2):
Platform AARCH64: Move
The Chipset/ sub-directories no longer exist and the code has been moved
into MdePkg. Update the includes accordingly.
Signed-off-by: Ard Biesheuvel
---
Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
ArmPlatformStackLib is going away, which requires some careful handling
for platforms that actually rely on it. This is not the case for a
number of platforms, so just drop it from those.
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc | 1
Use CR-LF as required for DSC files.
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
b/Platform/Socionext/DeveloperBox
igned-off-by: Ard Biesheuvel
---
Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc | 1 -
Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf | 3 -
Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S | 29 +---
Platform/BeagleBoard/BeagleBoa
Use CR-LF as required for DSC files.
Signed-off-by: Ard Biesheuvel
---
Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc
b/Platform/BeagleBoard/BeagleBoardPkg
On Tue, 30 Jul 2024 at 16:19, Rebecca Cran
wrote:
>
> For the series:
> Reviewed-by: Rebecca Cran
>
> I see this is marked as an RFC, but I think it's a change that should be
> committed.
>
Thanks. I agree.
I will wait for at least your colleagues to give a tested-by on this
though - Altra/Jade
On Tue, 30 Jul 2024 at 14:40, Leif Lindholm wrote:
>
> On Sun, Jul 28, 2024 at 22:44:27 +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > The EmbeddedPkg runtime DXE is being retired in favour of the generic
> > one in MdeModulePkg which is actually bein
On Tue, 30 Jul 2024 at 14:45, Leif Lindholm wrote:
>
> On Mon, Jul 29, 2024 at 15:16:00 +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > There is a pattern that has been copy-pasted a number of times where a
> > missing references in the INFs [Ppis] se
On Tue, 30 Jul 2024 at 17:09, Leif Lindholm wrote:
>
> On 2024-07-30 16:00, Ard Biesheuvel wrote:
> > On Tue, 30 Jul 2024 at 16:49, Leif Lindholm
> > wrote:
> >>
> >> On 2024-07-30 15:30, Rebecca Cran wrote:
> >>> Ard,
> >>>
> >&
From: Ard Biesheuvel
There is a pattern that has been copy-pasted a number of times where a
missing references in the INFs [Ppis] section is 'fixed' by creating a
local GUID variable. Fix all of those.
This is just a janitorial patch with no functional changes so fixing all
of these
From: Ard Biesheuvel
The original EDK2 port to 32-bit ARM supported multi-core but on today's
ARM systems, only a single CPU enters the non-secure firmware and the
MPCore drivers are obsolete.
Stop using them in edk2-platforms so we can remove them entirely from
edk2.
Cc: Leif Lindhol
From: Ard Biesheuvel
Spec adherent AArch64 systems use PSCI to manage secondary CPUs, and
only enter the execution level where UEFI and the OS live using a single
CPU.
This means using a SEC implementation of the MPCore variety is never
needed, and in practice, those drivers don't
From: Ard Biesheuvel
Spec adherent AArch64 systems use PSCI to manage secondary CPUs, and
only enter the execution level where UEFI and the OS live using a single
CPU.
This means using a SEC implementation of the MPCore variety is never
needed, and in practice, those drivers don't
From: Ard Biesheuvel
Spec adherent AArch64 systems use PSCI to manage secondary CPUs, and
only enter the execution level where UEFI and the OS live using a single
CPU.
This means using a SEC implementation of the MPCore variety is never
needed, and in practice, those drivers don't
From: Ard Biesheuvel
Duplicate the logic that is triggered on a system reset into the
platform boot manager driver, and hook it up to the EDK2 platform
specific reset notification driver. This is supported by generic EDK2
code in MdeModulePkg, allowing us to retire the platform-specific
From: Ard Biesheuvel
gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz was made obsolete as AArch64
firmware runs in the non-secure world while programming the timer
frequency must be done from the secure world.
Drop some remaining references to the PCD.
Signed-off-by: Ard Biesheuvel
---
Silicon
From: Ard Biesheuvel
Remove references to the MPCore stack from platforms that do not use the
MPCore SEC implementations to begin with.
Signed-off-by: Ard Biesheuvel
---
Platform/ARM/Morello/MorelloPlatform.dsc.inc| 2 --
Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
From: Ard Biesheuvel
Drop the reference to the special reset runtime DXE driver in
EmbeddedPkg, and move to the one in MdeModulePkg shared between all
architectures. This version implements reset notifications, allowing us
to retire the home grown version of that functionality in a subsequent
From: Ard Biesheuvel
Drop the now unused EfiResetSystemLib implementation, which has been
superseded by the generic one from EDK2.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
Platform/RaspberryPi/RaspberryPi.dec | 1 -
Platform/RaspberryPi
From: Ard Biesheuvel
The VarBlockServiceDxe driver needs to be dispatched before the common
VariableRuntimeDxe, but we are currently relying on FDF order and lack
of transitive dependencies for this, which is fragile, and will break
once we move to the generic reset runtime.
So use the existing
From: Ard Biesheuvel
The DumpVars() routine is called directly and via an event notification
callback, and the latter therefore defines the function's prototype,
even though the arguments are unused.
We will introduce another callback into this logic, but via a reset
notifier, which ha
From: Ard Biesheuvel
Get rid of spurious LF-only line endings.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
Platform/RaspberryPi/RPi3/RPi3.dsc | 2 +-
Platform/RaspberryPi/RPi4/RPi4.dsc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Platform
From: Ard Biesheuvel
In addition to setting up the home grown reset notification, register
with the generic EFI protocol that does the same. This event is
triggered from the reset runtime implemented in MdeModulePkg, to which
we will be switching the RPi platforms in a subsequent patch.
Signed
From: Ard Biesheuvel
Mark RAM ranges as write/execute protectable in the GCD memory map. This
is needed to avoid issues with NonCoherentDmaLib in EmbeddedPkg, which
will fail if it does not manage to set the EFI_MEMORY_XP attribute on
the allocated DMA buffers.
Signed-off-by: Ard Biesheuvel
From: Ard Biesheuvel
The EmbeddedPkg runtime DXE is being retired in favour of the generic
one in MdeModulePkg which is actually being maintained.
RPi uses this driver and the associated EfiResetSystemLib, of which it
has an implementation with value-add for reset notification. So this
logic
From: Ard Biesheuvel
Drop the now unused EfiResetSystemLib implementation, which has been
superseded by the generic one from EDK2.
Signed-off-by: Ard Biesheuvel
---
Platform/RaspberryPi/RaspberryPi.dec | 1 -
Platform/RaspberryPi/Drivers/VarBlockServiceDxe
From: Ard Biesheuvel
Drop the reference to the special reset runtime DXE driver in
EmbeddedPkg, and move to the one in MdeModulePkg shared between all
architectures. This version implements reset notifications, allowing us
to retire the home grown version of that functionality in a subsequent
From: Ard Biesheuvel
Duplicate the logic that is triggered on a system reset into the
platform boot manager driver, and hook it up to the EDK2 platform
specific reset notification driver. This is supported by generic EDK2
code in MdeModulePkg, allowing us to retire the platform-specific
From: Ard Biesheuvel
The EmbeddedPkg runtime DXE is being retired in favour of the generic
one in MdeModulePkg which is actually being maintained.
RPi uses this driver and the associated EfiResetSystemLib, of which it
has an implementation with value-add for reset notification. So this
logic
From: Ard Biesheuvel
The DumpVars() routine is called directly and via an event notification
callback, and the latter therefore defines the function's prototype,
even though the arguments are unused.
We will introduce another callback into this logic, but via a reset
notifier, which ha
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
In addition to setting up the home grown reset notification, register
with the generic EFI protocol that does the same. This event is
triggered from the reset runtime implemented in MdeModulePkg, to which
we will be switching the RPi platforms in a subsequent patch.
Signed
From: Ard Biesheuvel
The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.
Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on
From: Ard Biesheuvel
Drop the CLANG3x build options, and add ones for CLANGDWARF so that
SynQuacer based platforms can be built with it.
Instead of copying the -no-integrated-as option that CLANG3x used, let's
fix the assembler code so it can be built with Clang's integrated
assem
From: Ard Biesheuvel
ArmSmcPsciResetSystemLib is being replaced with a generic implementation
that is shared between physical and virtual placement, executing at
either EL2 or EL1.
So update all library class resolutions for ResetSystemLib and provide
additional resolutions for its dependency
1 - 100 of 1024 matches
Mail list logo
