On Wed, 19 Jun 2024 at 07:52, Marcin Juszkiewicz
wrote:
>
> QEMU no longer permits misaligned access to device memory, which breaks
> QemuVideoDxe on SbsaQemu.
>
> c1d1910be6e04a8b1a73090cf2881fb698947a6e commit in EDK2 fixed it by
> enabling WriteCombine for Framebuffer memory. This change enable
W dniu 19.06.2024 o 09:09, Ard Biesheuvel pisze:
On Wed, 19 Jun 2024 at 07:52, Marcin Juszkiewicz
wrote:
QEMU no longer permits misaligned access to device memory, which breaks
QemuVideoDxe on SbsaQemu.
c1d1910be6e04a8b1a73090cf2881fb698947a6e commit in EDK2 fixed it by
enabling WriteCombine
Hello everyone,
I was scrolling through the UEFI HII and encountered an option which i failed
to find any proper explanation about it.
Could you please explain point of mitigating DMA access for PCI.Thanks
--- Forwarded Message ---
From: memristor2
Date: On Tuesday, June 18th, 2024 at 4:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4791
This commit adds necessary changes to build and packaging scripts
to take path to edk2-libc through an environment variable.
It also updates the build and packaging instructions in
GCCCompilationBKMs.rst file and Py368ReadMe.txt files.
The P
This commit adds necessary changes to build and packaging scripts
to take path to edk2-libc through an environment variable.
It also updates the build and packaging instructions in
GCCCompilationBKMs.rst file and Py368ReadMe.txt files.
The Python368.inf file is also updated to take EDK2_LIBC_PATH
i
The DynamicTables framework has mainly been developed/tested against Arm
architecture. While still trying to have re-usable libraries, opening the
framework to other architectures implies some re-organization.
The libraries that are generic enough to be directly re-used are moved
to a Common/ dire
Some of the ACPI table generators are generic enough to be re-used
by other architectures. Move the following generators to a
'Common' folder:
- AcpiDbg2Lib
- AcpiFadtLib
- AcpiMcfgLib
- AcpiPcctLib
- AcpiPpttLib
- AcpiRawLib
- AcpiSpcrLib
- AcpiSratLib
- SsdtSerialPortLib
- SsdtCpuTopologyLib
- Ss
Allow other architectures to reuse ACPI common libraries by:
- Removing the Arm prefix from the BASE_NAME
- Moving Arm specific libraries/packages to ARM/AARCH64
specific sections in the .inf files
Also remove the empty .inf sections.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
Allow other architectures to reuse the AcpiFadtLib by extracting
the Arm specific part of the table generation.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf | 7 +
.../Common/AcpiFadtLib/Arm/ArmFadtGenerator.c | 126 ++
Allow other architectures to reuse the AcpiDbg2Lib by extracting
the Arm specific part of the table generation.
Signed-off-by: Pierre Gondois
---
.../Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf | 7 ++
.../Common/AcpiDbg2Lib/Arm/ArmDbg2Generator.c | 67 +++
.../AcpiDbg2Lib/Common/
Remove the Arm name from the generator to show the generator
can be used by other archs.
Signed-off-by: Pierre Gondois
---
.../Library/Acpi/Common/AcpiSpcrLib/SpcrGenerator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/DynamicTablesPkg/Library/Acpi/Common/Acpi
Allow other architectures to reuse the AcpiSratLib by extracting
the Arm specific part of the table generation.
Signed-off-by: Pierre Gondois
---
.../Acpi/Common/AcpiSratLib/AcpiSratLib.inf | 7 +
.../Common/AcpiSratLib/Arm/ArmSratGenerator.c | 262 ++
.../AcpiSratLib/Common/
Mandatory ACPI tables depend on the architectures.
Different architectures might also want to check other tables.
Move mAcpiVerifyTables containing the list of ACPI tables to check
to an arch specific file and introduce GetAcpiTablePresenceInfo()
to get get the relevant information from the array.
The GICC is an ARM specific structure. Other architectures have different
local interrupt controller structures from which CPU topology can be
created. Avoid the GICC reference in common code by:
- creating a wrapper CreateTopologyFromIntC() instead of
CreateTopologyFromGicC() so that different a
Create an Arm directory in the FdtHwInfoParserLib as a preparation
step to support other architectures.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../{ => Arm}/BootArch/ArmBootArchParser.c| 2 +-
.../{ => Arm}/BootArch/ArmBootArchParser.h| 0
.../GenericTimer/ArmGeneri
To allow other architectures to potentially re-use the serial port
parser and make the code arch neutral, remove the Arm prefixes.
Also remove the check searching for a GIC version.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c | 4 ++
To allow other architectures to potentially re-use the serial port
parser and make the code arch neutral, make the MainDispatcher()
function arch specific.
Other architectures can choose which parse/dispatcher are desired
to be called through the configuration of the HwInfoParserTable.
Suggested-
To allow other architectures to potentially re-use the serial port
parser and make the code arch neutral, remove the Arm prefixes.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c | 2 +-
.../FdtHwInfoParserLib/FdtHwInfoParserLib.inf
ArmLib.h is required only for building GIC in ARM. So, move it to ARM
specific file. Otherwise, FdtHwInfoParserInclude.h being a common header
across architectures will have issue on other architectures.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../Library/FdtHwInfoParserLib/Ar
Parent interrupt controller's address cells is arch specific. So,
create a wrapper function which can be implemented differently for
different archs. Move current implementation to ARM specific file.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../AcpiSsdtPcieLib/SsdtPcieGenerator
The interrupts-extended property in DT is arch specific.
Move the current implementation and the way to decode the property
to the Arm folder to prepare for other architecture support.
Suggested-by: Sunil V L
Signed-off-by: Pierre Gondois
---
.../FdtHwInfoParserLib/Arm/ArmFdtUtility.c| 85 +
I'd like to be able to run the EDK2 CI process on my AArch64 development
machine.
The edk2-acpica-iasl package version 20230628.0.1 has AArch64 support
but the mu_nasm package only supports x86_64.
Could someone add AArch64 support to the mu_nasm package or tell me how
to do so, please?
I
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Jayaprakash, N
> Sent: Wednesday, June 19, 2024 12:53 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D
> Subject: [edk2-libc Patch 1/1] edk2-libc : update build and packaging scripts
> to t
23 matches
Mail list logo
