The latest VS2022 update replaces some code patterns with struct
assignments with `memcpy`. This change convert the code to
explicitly use `CopyMem`.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
The latest VS2022 update replaces some code patterns with struct
assignments with `memcpy`. This change convert the code to
explicitly use `CopyMem`.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds support for building the C language BaseTools for Windows using
toolchains based on mingw-w64.
Mingw-w64 is a collection of header files, libraries, and tools that
when combined with a compiler enable development of Windows software.
Mingw-w64 is a fork of the original MinGW (Minimalist GNU for Windows).
Most active development on MinGW has ceased and mingw-w64 is now the
actively maintained successor. Mingw-w64 provides a libc implementation
built on top of Microsoft's UCRT (Universal C Runtime) with all
nessesary compiler bindings needed to support the C++11 feature set.
Modern mingw-w64 development appears to have coalesced around MSYS2,
which produces a distributions of both GCC and LLVM/Clang that use
mingw-w64 to target the Windows OS. This MSYS2 Clang distribution has a
UNIX-like directory layout and includes Windows binaries of GNU Make.
Combined with the open source licensing, MSYS2's Clang distribution is a
highly attractive choice as an alternative Windows SDK for open source
projects such as TianoCore.
If one wishes to use EDK II to build UEFI firmware on the Windows
platform, then the C BaseTools need to be compiled as Windows
applications. This includes the PcdValueInit.exe program, which needs
to be recompiled every time a firmware build is run in order to
regenerate the initial values for structured PCDs. Currently, BaseTools
only supports the Visual C++ toolchain on the Windows platform. The
following new features have been added to enable usage of the toolchains
derived from mingw-w64:
- Fixes to the BaseTools C source code to support the use of a
GCC-style compiler on the Windows OS.
- The GNU Make-style Makefiles for the C BaseTools have been modified
to support Windows. Both GCC + mingw-w64 and Clang + mingw-w64 have
been tested and confirmed to build a working BaseTools.
- BaseTools now supports generating GNU Make-style Makefiles on the
Windows platform for the purpose of building firmware.
- edksetup.bat has been modified to optionally build BaseTools via
mingw-w64. There is no impact to the existing support for Visual C++
and Visual C++ remains the default toolchain.
Usage Instructions:
For the vast majority of users, the only system setup change nessesary
to use a mingw-w64 toolchain is to set the BASETOOLS_MINGW_PATH to the
directory containing the desired mingw-w64 based toolchain.
A new command line argument has been added to edksetup.bat: Mingw-w64
If this command line argument is set, then the script will set the
BASETOOLS_MINGW_BUILD environment variable. The user can also opt to set
this environment variable manually before running edksetup.bat
If BASETOOLS_MINGW_BUILD is defined, then the BASETOOLS_MINGW_PATH
environment variable must point to the directory containing the
mingw-w64 toolchain.
If CLANG_BIN is not defined and %BASETOOLS_MINGW_PATH%\bin\clang.exe
exists, then edksetup.bat will set CLANG_BIN=%BASETOOLS_MINGW_PATH%\bin\
This removes the requirement to configure the CLANG_BIN environment
variable manually in order to run a CLANGPDB or CLANGDWARF build if one
has the MSYS2 Clang distribution installed. If one wishes to use a
different copy of Clang (for example official LLVM binaries) to build
firmware and only use the MSYS2 Clang to build BaseTools, then one can
continue to set the CLANG_BIN environment variable, same as before. I
have tested the MSYS2 Clang distribution against the official LLVM
distribution and can confirm that if the compiler version is the same
the emitted machine code is identical between the two. Interestingly,
the MSYS2 Clang distribution emits the path to the PDB file using "/" as
the path seperator instead of "\". That appears to be the only
difference in output. Therefore, using the MSYS2 Clang distribution to
compile firmware seems a reasonable choice.
If CLANG_HOST_BIN is not defined and BASETOOLS_MINGW_BUILD is defined
and %BASETOOLS_MINGW_PATH%\bin\mingw32-make.exe exists, then
edksetup.bat will add %BASETOOLS_MINGW_PATH%\bin\ to the PATH and set
CLANG_HOST_BIN=mingw32-
This enable usage of the GNU Make included in the mingw-w64 toolchain
to build firmware in addition to BaseTools. if BASETOOLS_MINGW_BUILD is
not defined, edksetup.bat will continue to set CLANG_HOST_BIN=n, which
uses nmake to build firmware. This behavior can be overridden by
manually setting the value of CLANG_HOST_BIN before executing
edksetup.bat if one wishes to use a specific Make utility for the
CLANGPDB/CLANGDWARF toolchains.
References:
- https://www.mingw-w64.org/
- https://www.msys2.org/
Co-authored-by: Sandesh Jain <sandesh.jain@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Fixes a BaseTools Bin directory path detection bug in the the BaseTools
Unit Tests. The script incorrectly assumes that sys.platform
will be win64 on a 64-bit Python interperter.
The "win64" platform string has not been used for 64-bit Python
interperters since May 10, 2000:
https://github.com/python/cpython/commit/da5cc82d
Moreover, this patch was merged before the Python 2.0 release, so there
never has been a released Python interperter that used the "win64"
string.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
PatchCheck error messages can be improved by adding the line number.
The line itself may consist of only whitespace for some errors.
Adding the line number can help better locate the error source.
Signed-off-by: Gary Beihl <garybeihl@microsoft.com>
To get a SPI_MAX_INTID, interrupt controller type Register
should be masked with ARM_GIC_ICDICTR_GET_SPI_RANGE.
However, since ARM_GIC_ICDICTR_SPI_RANGE_TO_MAX_INTID macro
uses ARM_GIC_ICDICTR_GET_EXT_SPI_RANGE mask,
it returns wrong SPI_MAX_INITID.
This makes a failure of loading GenericWatchDog in FVP RevC model.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Fixes: d6d2f68e38 ("ArmPkg/Drivers/ArmGicDxe: ...")
As new interfaces are made available to support UUID-GUID conversion,
this change is made to leverage new interfaces and remove the locally
duplicated code.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change moves the existing ConvertEfiGuidToUuid function to public
interface to support newly defined functions prototypes.
This change also adds the `ArmConvertUuidToEfiGuid` function
implementation, which is an inverse of the original conversion.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
With interactions between Standalone MM partitions and normal UEFI
environment, there is constant need to convert UUID to GUID and back.
This change added 2 new interfaces to BaseLib that support such usage.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This is needed in a MM_CORE_STANDALONE module. Since this null
instance is so simple, remove individual module types to allow
it be integrated more easily.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
- Updated the PciGetBusRange function signature to use IN OUT for
the Descriptors parameter.
- Introduced a new DescriptorsBuffer variable in PciLib.c to
temporarily hold descriptor data.
- Clean up DescriptorsBuffer and set Descriptors to NULL after use.
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
KEYBOARD_TIMER_INTERVAL is used as TriggerTime parameter of
gBS->SetTimer() function. TriggerTime parameter represents the number of
100ns units, so number 500000 indicates 0.05s.
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
Original logic skips to call MmDispatcher() when number of FV HOBs exceeds
the max supported FVs even for the already-discovered FVs.
Original logic skips to call MmDispatcher() and even skips to process other
FVs when insufficient MM memory for shadowing a FV.
For both cases, replace "return" with "continue" to try best to dispatch
more FVs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Refine debug output for better troubleshooting:
1. Consolidate FV address and size into one log message
2. Add function name to error messages for better traceability
3. Use AllocateCopyPool() instead of separate AllocatePool() and CopyMem()
Signed-off-by: Ray Ni <ray.ni@intel.com>
Previously, MmDispatchFvs could enter an infinite loop if a Firmware Volume
HOB with zero length was encountered, because GetNextHob() was called with
the same FvHob pointer repeatedly. This patch fixes the issue by passing
GET_NEXT_HOB(FvHob) to GetNextHob(), ensuring the loop advances to the next
HOB and preventing hangs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
This commit enables extended SPI support for GicV3. GicV3 must decide,
based on the source intid, whether to access the SPI-range registers,
PPI-range registers in the redistributor, or the extended SPI-range
registers.
The protocol interfaces must also support registering an interrupt
handler with an extended SPI intid. To save ~24KB of memory, handler
allocation and access is delegated to GicV2 and GicV3. GicV2 retains the
existing handler mapping scheme using intids literally. GicV3 remaps
extended SPI intids to be immediately after the highest SPI intids.
Tested on qemu with the BSA test suite.
Signed-off-by: Nick Graves <nicholasgraves@google.com>
PrePiLib.h is missing the header file that defines
the structures used in the file.
For example:
- EFI_PEI_FV_HANDLE
- EFI_PEI_FILE_HANDLE
Signed-off-by: Doug Flick <dougflick@microsoft.com>
With all in-tree users migrated, finally delete this.
Any out-of-tree users need to migrate to MdePkg BaseFdtLib.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
ArmStandaloneMmCoreEntryPoint makes use of GetNextHob
which comes from HobLib. The inf does not specify
HobLib has one of its library classes. Specify
HobLib in the LibraryClasses section of the
inf.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
When calling to initialize the PL011 Uart, Rx buffer is
not cleared. In a 16550 uart device, during initialization,
the 16550's Fifo control registers would be used to clear
the Rx buffer, but no such register exists on PL011.
Modify the PL011 SerialPortInitialize function
to clear anything that was in the Rx buffer
after initialization is completed. This will prevent
any stale data from being interpreted as valid data.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Commit e25331fc45
("MdePkg,UefiPayloadPkg: clean up BaseFdtLib API confusion"),
missed out aligning the wrapper for fdt_node_offset_by_property_value
between heade and implementation.
Fix this by updating the header to declare FdtNodeOffsetByPropValue
instead of FdtNodeOffsetByPropertyValue.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
When building with gcc 15.1, building RegularExpressionDxe fails
because it can't find the type ptrdiff_t. Therefore, add a typedef
for it in OniguramaUefiPort.h.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Align HTTP Boot behavior with PXE by inserting a delay to wait for IPv6 Duplicate Address Detection (DAD) to complete before issuing DHCPv6 requests. This avoids EFI_NO_MAPPING errors caused by early DHCP attempts before a valid IPv6 address is ready.
Problem:
On some platforms, HTTP boot over IPv6 fails with EFI_NO_MAPPING during initial DHCPv6 attempts. The failure is due to the system trying to send Solicit messages before IPv6 DAD finishes, resulting in no usable IP address at that time.
Solution:
Insert a retry mechanism to poll DAD completion when the initial call to Dhcp6->Start() fails with EFI_NO_MAPPING. This behavior mirrors PXE's handling, where it waits for a valid IPv6 address to be assigned before retrying the DHCPv6 flow.
Signed-off-by: Sam Tsai [Wiwynn] <sam_tsai@wiwynn.com>
When booting under Xen/Arm64 with a flattened devicetree, XenioFdtDxe.c
performs a runtime assert on the size of the hypervisor node. At some
point the hypervisor devicetree node changed size in upstream Xen, which
makes booting under Xen impossible because the assertion fails:
ASSERT [XenioFdtDxe] XenioFdtDxe.c(64): RegSize == 2 * sizeof (UINT64)
By putting a debug print in InitializeXenioFdtDxe we can see the value
of RegSize is 48, instead of 2 * sizeof (UINT64)=16.
Change the equality check to equal or greater than (>=).
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
If there is a slow device on the PCI Bus, and the HostBridge is
programmed to allow CRS, the slow device may return 0x0001 to inform the
config space reader of the Vendor Id that pci device is not ready. The
current PciBus enumerator will treat 0001 as a valid Vendor Id, but it
is not. It indicates that all other config space is invalid. This code
changes that operation to skip slow devices.
PCI EXPRESS BASE SPECIFICATION, REV. 3.1 section
2.3.1 Request Handling Rules.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Given that CPACR_EL1 is aliased to CPTR_EL2 when running at EL2 with VHE
enabled, we can just fall back to SetupExceptionLevel1() instead of
fiddling with the init values for CPTR_EL2.
While at it, use the existing define to refer to the E2H bit in HCR_EL2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Avoid a call and use a jump instead, so that the LR value does not
need to be recorded in a different register. This is generally neater,
but it also avoids potential confusion in the debugger, given that no
frame record is created for this call.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Even though the UEFI spec mentions that the EL1PCTEN and EL1PCEN bits in
CNTHCTL_EL2 must be set, this is not a requirement that applies to the
UEFI implementation, but a requirement that applies to the firmware
running at EL2 in cases where UEFI executes at EL1. (Note that the same
paragraphs mentions that CNTFRQ must be programmed with the timer
frequency, and this is only permitted at EL3).
Setting these bits has no effect when executing at EL2, and it is the
OS's job to reason about how to configure lower exception levels.
So drop the initialization of CNTHCTL_EL2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tpm2AcpiTable revision 5 adds new START_METHOD with Arm FF-A transfer.
add related information and update its generator.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
commit 26fb5edff3
("MdeModulePkg/ArmFfaLib: Add depex on gEfiPeiMemoryDiscoveredPpiGuid")
restricts ArmFfaPeiLib usage only after PEI phase can be used
permanent memory. However, This would be problem for PEIM
which runs before gEfiPeiMemoryDiscoveredPpiGuid Ppi installed.
(i.e) Tcg2Pei PEIM.
To resolve this, remove dependency on gEfiPeiMemoryDiscoveredPpiGuid
and let ArmFfaPeiLib remap the Rx/Tx buffer after
gEfiPeiMemoryDiscoveredPpiGuid is installed so that ArmFfaPeiLib can be
used with temporary memory.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Fixes: 26fb5edff3 ("MdeModulePkg/ArmFfaLib: ...")
The current warm reset implementation attempts the PSCI SYSTEM_RESET2
command twice without clearing the local variable used for Arg1. This can
result in passing a random value as the reset type, which may cause the
PSCI call to behave unexpectedly and fall back to a cold reset.
This change addresses the issue by:
- Correcting the monitor call function ID.
- Explicitly zeroing the reset type field before invoking the PSCI
interface.
The updated warm reset flow has been tested and confirmed to invoke
SYSTEM_RESET2 as expected.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Add GUID section for build report.
Also, change the GUID format to string format to be easier to parse
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
When the Wifi network is enabled the connection
manager will trigger a network scan without a
profile to use. If there is a connected network
or attempting a connection, the scan will
interrupt and break the connection.
Fix - The Wifi Connection Manager will register
the scan on timer tick but will not set the timer.
This timer will only be set when the user enters or
selects a profile for connection in the BIOS menu.
If the user does not select a profile there is no
need to start a scan timer. Additionally the scan
on timer tick will check for a profile to connect
and if no profile found then cancel the timer and
exit. When the driver loads it will check for a
profile and if one is found then the scan timer
will be set. If no profile is found then the
driver will not set the scan timer and will
not attempt to scan. This will prevent the
driver from scanning and breaking a connection
if the user does not select a profile.
Signed-off-by: Zachary Clark-Williams <zachary.clark-williams@intel.com>
