Tianocore/edk2.git/BaseTools/Source/C/GenFv, branch master

BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused

2026-07-15T21:37:05+00:00

Add XipFileCount to FV_INFO to track how many files have the ,XIP suffix. Update FfsRebase() to only apply selective XIP rebase when XipFileCount > 0. When no files have the ,XIP suffix (XipFileCount == 0), preserve the legacy ForceRebase=TRUE behavior of rebasing all files. This maintains backward compatibility for existing platforms that use FvForceRebase=TRUE without any Xip rules. Signed-off-by: Michael D Kinney

BaseTools/GenFv: Parse ,XIP suffix for per-file rebase control

2026-06-22T15:18:12+00:00

Update ParseFvInf() to detect and strip ",XIP" suffix from EFI_FILE_NAME values in the FV INF file. Store the per-file XIP flag in the new XipFile[] array in the FV_INFO structure. Add FileIndex parameter to FfsRebase() so it can look up the XIP flag for the current file. When ForceRebase is TRUE, only rebase files that have their XipFile[] entry set to TRUE. Signed-off-by: Michael D Kinney

BaseTools: GenFfs/GenFv/GenSec: Fixing Warning 4319 from MSVC

2026-03-13T19:14:49+00:00

This change fixes a warning newly emitted by the latest MSVC, which now treats this warning as an error and causes the build to fail. This change aligns operand types in bitwise expressions by casting sizeof results to UINT32, and promoting a UINT32 to UINTN where required to correctly apply the bitmask. Signed-off-by: Kun Qin

BaseTools: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Note: Some files in BaseTools are excluded from the change if they are autogenerated or direcly related to a header from a subproject, etc. In particular, headers in these directories were ignored: - BaseTools/Source/C/LzmaCompress/Sdk/ - BaseTools/Source/C/VfrCompile/Pccts/ Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

BaseTools: Remove ARM32 Support

2025-09-25T22:04:10+00:00

edk2 is dropping support for the ARM32 architecture. This commit removes ARM32 code from BaseTools. Signed-off-by: Oliver Smith-Denny

BaseTools: Add support for mingw-w64

2025-06-07T17:56:04+00:00

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 Signed-off-by: Nate DeSimone

BaseTools/GenFv: Ensure the minimum pad file size for the FV with VTF

2025-03-22T01:58:40+00:00

In case of the FV with VTF, the left size should be enough to add the minimum pad file size (EFI_FFS_FILE_HEADER, 0x18). It prevents the build error, "GenFv: ERROR 0006: invalid FFS file header checksum" caused by the pad file overwriting some header data in VTF. This includes these updates for CalculateFvSize() function. 1. If NumBlocks is not defined, ensure the minimum pad file size for the left size (if the pad file is required as VTF is not bottom aligned at end of block, insert EFI_FFS_FILE_HEADER to ensure the pad file size) 2. If NumBlocks is defined, report more clear error message (the required fv image size = 0x%x. the set fv image size = 0x%x. Free space left is not enough to add a pad file (0x18)) 3. Remove MaxPadFileSize, which is reported when the taken size is same as the total size. It can not be the actual left size to add an FFS file. It causes confusion when referring to the build log (FV Space Information) Signed-off-by: Phil Noh

BaseTools: Support custom library build for base tools on Linux ARM

2024-12-20T22:57:04+00:00

This change added the build script to cross compile the base tool binaries for Linux ARM/AARCH64 systems. The needed libuuid system library is pulled from source file and rebuilt to support the corresponding library dependencies. Individual tools' makefiles are also updated to link the cross compiled library as well. The EDK2 base tool build script was also updated to support such change. This was tested functional on Linux ARM host system. Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Kun Qin

BaseTools: Remove logic to create AP waking vector in GenFv

2023-09-18T02:39:25+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 Today for SEC core(not VTF-0), GenFv finds free 4K aligned space in FV for AP waking vector and JMP to 4G-30h in the waking vector. There is no usage of this today. Remove the logic to avoid confusing and save spaces in reset vector. Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Reviewed-by: Ray Ni Reviewed-by: Liming Gao Signed-off-by: Zhiguang Liu

BaseTools: switch from EFI_IMAGE_MACHINE_* to IMAGE_FILE_MACHINE_*

2023-06-01T10:53:35+00:00

Use the newer versions of the machine #defines. Signed-off-by: Gerd Hoffmann Reviewed-by: Chao Li Reviewed-by: Liming Gao Reviewed-by: Rebecca Cran