A method for merging binaries to save firmware space

Abstract

The present invention relates to the technical field of firmware optimization, and in particular to a method for merging binaries to save firmware space, the method comprising: generating a fat binary file based on a platform description file, merging multiple driver codes into a single binary file, and recording the offset of each driver entry function; generating a thin binary file for each driver, removing code segments, and retaining only the entry function offset and link information; and extending the loading service to support the thin binary file to dynamically load the code portion in the fat binary file. The present invention optimizes code redundancy through the fat binary file to reduce firmware storage space; minimizes the storage requirements of each driver through the thin binary file; and realizes dynamic driver loading through the extended loading service, retaining the flexibility of the UEFI architecture. The present invention can save at least 30% of storage space, reduce the startup time by about 300 milliseconds, is transparent to developers, is applicable to different hardware platforms, and has broad application prospects.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware optimization, and in particular to a method for merging binaries to save firmware space. Background Art

[0002] In firmware development, the storage space occupied by UEFI firmware is crucial for optimizing hardware platform resources. However, because the UEFI firmware's executable binary files (EFI files) are statically linked, each driver must contain its own complete set of public library code. This approach results in a large amount of duplicated code across multiple drivers, wasting firmware storage space. Existing technologies attempt to optimize firmware storage space through the following methods:

[0003] Method 1: Merge the driver

[0004] Manually merge multiple drivers into a single binary file so that they share common library code. However, this method requires developers to determine the execution order of the drivers in advance, limiting its applicability to dynamic hardware platforms.

[0005] Method 2: Dynamic Link Library (DLL)

[0006] Enabling the operating system's DLL functionality allows you to share common libraries as independent DLL instances. However, DLLs retain many uncalled internal functions, resulting in extra storage waste. They also increase the complexity of the interpreter and loader, limiting cross-module optimization opportunities.

[0007] The above method cannot meet the requirements of general firmware due to the fixed execution order, redundant code retention and limited cross-module optimization. Summary of the Invention

[0008] To address the numerous issues with the prior art, the present invention provides a method for consolidating binary files to save firmware space. This method automatically generates a fat binary file, merging the code of multiple drivers. A thin binary file is then used to record the offset of each driver's entry point function. When loading the thin binary file, the loader uses an extended loading service to parse the offset and extract the relevant code from the fat binary file for execution. This method reduces firmware storage space requirements while maintaining the flexible scheduling capabilities of the drivers.

[0009] A method for merging binaries to save firmware space includes the following steps:

[0010] Based on the platform description file, a fat binary file including multiple driver codes is generated, wherein the fat binary file records the offsets of multiple driver entry functions;

[0011] Based on the fat binary file, a thin binary file including entry function offset information is generated for each driver;

[0012] The loading service is extended to support the thin binary file, so that the thin binary file can load and run the code portion in the fat binary file.

[0013] Preferably, the generation of the fat binary file includes: using an Edk2 build tool to automatically call entry functions of multiple drivers, and linking multiple driver codes into the fat binary file.

[0014] Preferably, the fat binary file reduces duplicate codes and redundant instructions by utilizing the link time optimization technology of the compiler.

[0015] Preferably, it is characterized in that the generation of the thin binary file includes: removing the code segment of the original driver and retaining only the special data segment containing the description of the driver entry function offset and the fat binary file link information.

[0016] Preferably, the special data segment of the thin binary file contains entry function offset index data for dynamic scheduling and link information with the fat binary file.

[0017] Preferably, it is characterized in that the extension of the loading service includes: parsing a special data segment in the thin binary file to determine the code location in the fat binary file, and loading the code location into the memory to complete the operation of the driver.

[0018] Preferably, the extension of the loading service further includes supporting dynamic loading and unloading of the driver code portion in the fat binary file.

[0019] Preferably, it is characterized in that the method is applicable to UEFI firmware of different processor architectures and does not require modification of existing compilation tools or compilation methods.

[0020] Compared with the prior art, the advantages and beneficial effects of the present invention are:

[0021] The present invention uses fat binary file technology to merge multiple driver codes, eliminate the duplicate parts of the common library, and use link time optimization technology (LTO) to reduce code redundancy, thereby significantly saving firmware storage space;

[0022] The present invention uses thin binary file technology to retain only the offset and link information of the driver entry function, thereby achieving the ability to dynamically load the driver and simultaneously minimizing the binary file size of each driver.

[0023] The present invention supports thin binary files loading the code part of fat binary files by extending the loading service, retaining the flexibility of the UEFI architecture and improving the dynamic adaptation capability of the firmware;

[0024] In addition, the present invention is completely transparent to developers, does not require manual code adjustment, can be applied to different hardware platforms, saves development time and optimizes resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 This is a schematic diagram of the principle of FV size space saving of the present invention;

[0026] Figure 2 A schematic diagram of a flow chart for generating a thin binary file according to the present invention;

[0027] Figure 3 This is a schematic diagram of the operation of loading a thin binary file according to the present invention;

[0028] Figure 4 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0029] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0030] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0031] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0032] like Figure 1-Figure 4 As shown, in actual implementation, the application steps of the present invention include three steps:

[0033] Step 1. The Edk2 (UEFI open source project) build tool will automatically generate a common driver based on the platform FDF description file. Its program entry function will call the entry functions of all original drivers in the FV and link all driver codes into the fat binary file of the common driver. The normal UEFI driver build process is to first compile and link the driver code into a .dll file, and then the Edk2 build tool converts it into the PE32 format in the firmware system file and packages it into a single driver ffs file. So in a normal build, driver1 and driver2 will generate two .ffs files. The updated Edk2 build tool will call the driver1 and driver2 entry functions in the entry function of the new driver, link the two original drivers into the combined fat binary file, and then package it into a single ffs file. Together with the merged fat binary file, the offset of the original entry function in the fat binary file will also be output to generate a special data segment in the thin binary file.

[0034] like Figure 1 The present invention automatically combines and links all original drivers into a single common driver binary file (fat binary file). The single fat binary file can fully utilize the link time optimization (LTO) and code size optimization of the compiler and linker to record repeated instruction sequences in all driver codes [1], [2], [3], which will greatly reduce the code size of the entire driver.

[0035] Step 2: Figure 2 The following figure shows the process of generating thin binaries. A thin binary file is created for each original FV driver. The thin binary file has no code section, but instead has a special data section that contains only a link to the merged FFS file and the offset of the actual original entry point function in the fat binary file. The thin binary file has a very small binary size.

[0036] Step 3. Extend the LoadImage service (binary file loading function) to support a special data segment in the new thin binary file, so that it can load the code section from another fat binary file. Figure 3 A load flow that loads a new fat binary file for a thin binary file in memory. This loading strategy is suitable for the driver boot process after memory initialization (such as DXE drivers).

[0037] The present invention saves Flash chip space on the hardware platform by merging driver binary files, thereby adding more firmware functions to a fixed Flash chip. In experiments, the present invention can reduce the FV code space by at least 30%. Another value is that it improves the startup speed by removing the decompression step during the startup process. After applying the present invention, even if the user does not compress the firmware FV, it is possible to put the firmware into the Flash chip. In this way, there is no need for the decompression process when the firmware starts, which can usually save ~300ms of startup time. The present invention does not require additional manual work by developers and can be used for both single FV files and FD files of the entire platform.

[0038] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware.

[0039] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims

1. A method for merging binaries to save firmware space, characterized in that: The following steps are involved: Based on the platform description file, a fat binary file including multiple driver codes is generated, wherein the fat binary file records the offsets of multiple driver entry functions; Based on the fat binary file, a thin binary file including entry function offset information is generated for each driver, wherein the generation of the thin binary file includes: removing the code segment of the original driver and retaining only a special data segment including description of the driver entry function offset and the fat binary file link information; The loading service is extended to support the thin binary file, so that the thin binary file can load and run the code portion in the fat binary file.

2. The method according to claim 1, characterized in that The generation of the fat binary file includes: using the Edk2 build tool to automatically call the entry functions of multiple drivers and linking the multiple driver codes into the fat binary file.

3. The method according to claim 1, characterized in that The fat binary file reduces duplicate code and redundant instructions by utilizing the compiler's link time optimization technology.

4. The method according to claim 1, wherein The special data segment of the thin binary file contains entry function offset index data for dynamic scheduling and link information with the fat binary file.

5. The method according to claim 1, wherein The extension of the loading service includes: parsing a special data segment in the thin binary file to determine a code location in the fat binary file, and loading the code location into memory to complete the operation of the driver.

6. The method according to claim 5, characterized in that The extension of the loading service further includes supporting dynamic loading and unloading of the driver code portion in the fat binary file.

7. The method according to claim 1, characterized in that The method is applicable to UEFI firmware of different processor architectures and does not require modification of existing compilation tools or compilation methods.

Images