Method for merging binary systems to save firmware space

Abstract

The invention relates to the technical field of firmware optimization, in particular to a method for merging binary systems to save firmware space, which comprises the following steps of: generating a fat binary system file based on a platform description file, merging a plurality of driving program codes into a single binary system file, and recording the offset of each driving program entry function; generating a thin binary file for each drive program, removing a code segment, and only reserving an entry function offset and link information; the extended load service supports the thin binary file to dynamically load code portions in the fat binary file. According to the method, the code redundancy is optimized through the fat binary file, and the firmware storage space is reduced; minimizing the storage requirement of each driver through the thin binary file; dynamic loading of the drive program is achieved through the extended loading service, and the flexibility of the UEFI architecture is reserved. According to the method, at least 30% of storage space can be saved, about 300 milliseconds of starting time can be reduced, and the method is transparent to developers, suitable for different hardware platforms and wide in application prospect.

Description

Technical Field

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

[0002] In firmware development, the storage space occupied by UEFI firmware is of great significance to the resource optimization of the hardware platform. However, since the executable binary file (EFI file) of UEFI firmware is statically linked, each driver needs to contain complete public library code. This method results in a large amount of duplicate code in multiple drivers, wasting firmware storage space. The prior art attempts to optimize firmware storage space by 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 in dynamic hardware platforms.

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

[0006] Enable the DLL function of the operating system to share common libraries as independent DLL instances. However, DLL retains many uncalled internal functions, resulting in additional storage waste. At the same time, DLL increases 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] In view of the many problems existing in the above-mentioned prior art, the present invention provides a method for merging binaries to save firmware space. The present invention automatically generates a fat binary file, merges the codes of multiple drivers, and uses a thin binary file to record the entry function offset of each driver. When loading the thin binary file, the loader parses the offset through the extended loading service and extracts the relevant code from the fat binary file for execution. The present invention reduces the firmware storage space requirement while retaining the flexible scheduling capability of the driver.

[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 the Edk2 build tool to automatically call the entry functions of multiple drivers, and linking the multiple driver codes into the fat binary file.

[0014] Preferably, the fat binary file reduces duplicate codes and redundant instructions by utilizing 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 only retaining 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, eliminates duplicate parts of the common library, and uses 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 realizing the ability of dynamic loading of the driver and reducing the binary file size of each driver to the maximum extent;

[0023] The present invention supports a thin binary file to load the code part in a fat binary file by extending the loading service, thereby 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 It 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 of the present invention;

[0027] Figure 3 It is a schematic diagram of the operation of loading a thin binary file of 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 exemplary only 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 obvious that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of 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 existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0031] All terms (including technical and scientific terms) used herein 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 FV and link all driver codes into the fat binary file of the common driver. The normal UEFI driver build process is to compile and link the driver code into a .dll file first, 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, and 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 for generating special data segments in the thin binary file.

[0034] like Figure 1 The present invention shown automatically combines and links all original drivers into a single common driver binary file (fat binary file). The single fat binary file can make full use of 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 process of generating thin binaries is shown in Figure 1. A thin binary is created for each original FV driver. The thin binary has no code section but has a special data segment that contains only the link to the merged FFS file and the offset of the actual original entry function in the fat binary. The thin binary has a very small binary size.

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

[0037] The present invention saves Flash chip space on the hardware platform by merging the binary files of the driver, thereby adding more firmware functions in a fixed Flash chip. In experiments, the present invention can reduce the FV code space by at least 30%. Another value is to increase the startup speed by removing the decompression step in 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, so that there is no need for a decompression process when the firmware is started, which can usually save ~300ms of startup time. The present invention does not require additional manual work for developers, and it can be used for both a single FV file and the FD file 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 a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware.

[0039] The above are only 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 changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in 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; 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 construction 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, characterized in that: The generation of the thin binary file includes: removing the code segment of the original driver and only retaining the special data segment containing the offset of the driver entry function and the link information of the fat binary file.

5. The method according to claim 4, characterized in that 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.

6. The method according to claim 1, characterized in that 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 the memory to complete the operation of the driver program.

7. The method according to claim 6, 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.

8. 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