A method and apparatus for generating a self-decompressing firmware
Patent Information
- Application Number
- CN202611122380.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-27
- Publication Date
- 2026-10-27
AI Technical Summary
[0015]本申请实施例的有益效果之一在于：通过根据压缩固件中各个数据块对应的熵值范围来确定各个数据块对应的压缩参数，由此，为每一个数据块匹配最优的压缩参数，从而针对该待压缩固件形成随熵值范围动态变化的可变压缩参数，实现压缩率和解压速度的平衡。
Smart Images
Figure CN122993729A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this application relate to the field of industrial control. Background Technology
[0002] In the field of industrial automation, self-extracting firmware formats are typically used to update firmware versions and burn programs to industrial control equipment, programmable logic controllers (PLCs), and drives. This compressed firmware is adaptable to the limited computing power, memory, and storage resources of various embedded hardware in industrial scenarios, meeting the needs of multiple deployment scenarios such as batch burning on production lines, on-site maintenance upgrades, and remote operation and maintenance updates, ensuring stable firmware decoding, verification, and burning.
[0003] In the existing technology, self-extracting firmware consists of a self-extracting program and compressed firmware. The compressed firmware is encapsulated using a dictionary-based lossless compression algorithm, and the compression window parameters are fixed hard-coded configurations.
[0004] It should be noted that the above introduction to the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of this application and for the convenience of those skilled in the art to understand them. It should not be assumed that the above technical solutions are known to those skilled in the art simply because these solutions have been described in the background section of this application. Summary of the Invention
[0005] The inventors of this application have discovered that in the prior art, self-extracting firmware consists of two parts: a self-extracting program and compressed firmware, with the compressed firmware using a fixed compression window for encapsulation. However, since the original firmware data is not evenly distributed, setting a smaller fixed compression window results in faster firmware decompression, but a lower overall compression ratio, a larger firmware file size, and higher storage and transmission resource consumption. Conversely, setting a larger fixed compression window, while achieving a higher compression ratio and reducing firmware size, increases memory usage and computational overhead, leading to slower decompression. Therefore, it is difficult to balance both compression efficiency and decoding speed.
[0006] To address at least one or more of the aforementioned technical problems, embodiments of this application provide a method and apparatus for generating self-decompressing firmware. By determining the compression parameters corresponding to each data block based on the entropy range of each data block in the compressed firmware, and compressing each data block according to the compression parameters, an optimal compression parameter is matched for each data block, thereby forming a variable compression parameter that dynamically changes with the entropy range for the firmware to be compressed, achieving a balance between compression ratio and decompression speed.
[0007] According to an embodiment of the first aspect of this application, a method for generating self-extracting firmware is provided, the method comprising: The firmware to be compressed is divided into multiple data blocks; The entropy value corresponding to each data block is determined, and the entropy value is used to characterize the degree of disorder in the bit distribution in the corresponding data block; Based on the entropy range to which the entropy value of each data block belongs, and the preset correspondence between the entropy range and the compression parameters, the compression parameters corresponding to each data block are generated. Based on the compression parameters corresponding to each data block, the corresponding data blocks are compressed to obtain compressed firmware. The self-extracting firmware is generated based on the compressed firmware.
[0008] In at least one embodiment, the compression parameters include a compression window, which represents the maximum range of data that the compression algorithm searches for.
[0009] In at least one embodiment, dividing the firmware to be compressed into multiple data blocks includes: The firmware to be compressed is divided continuously along the physical address of the firmware to be compressed according to the same data length to obtain the plurality of data blocks, wherein the plurality of data blocks are arranged continuously in the firmware to be compressed.
[0010] In at least one embodiment, generating compression parameters corresponding to each data block based on the entropy value corresponding to each data block includes: Based on the entropy value corresponding to each data block, the compilation information of the firmware to be compressed, and the user configuration, compression parameters corresponding to each data block are generated.
[0011] In at least one embodiment, in the preset correspondence, the compression window corresponding to the larger entropy value range is larger than the compression window corresponding to the smaller entropy value range.
[0012] In at least one embodiment, generating the self-extracting firmware based on the compressed firmware includes: A self-extracting header is added to the compressed firmware to generate the self-extracting firmware, and the self-extracting header is used to decompress the compressed firmware.
[0013] In at least one embodiment, the corresponding data blocks are compressed according to the compression parameters corresponding to each data block to obtain compressed firmware, including: According to the arrangement order of the multiple data blocks in the firmware to be compressed, one data block and the compression parameters corresponding to the data block are obtained sequentially. The compression algorithm is invoked, and the acquired data block is compressed according to the obtained compression parameters to obtain the compressed data unit corresponding to the data block; After compressing the current data block, the next data block and its corresponding compression parameters are obtained, and the next data block is compressed until all data blocks are compressed to obtain their respective compressed data units; and The compressed data units corresponding to the multiple data blocks are concatenated to obtain the compressed firmware.
[0014] According to an embodiment of the second aspect of this application, a self-extracting firmware generation apparatus is provided, the apparatus comprising: The partitioning unit divides the firmware to be compressed into multiple data blocks; A determining unit, which determines the entropy value corresponding to each data block, wherein the entropy value is used to characterize the disorder of the bit distribution in the corresponding data block; The parameter generation unit generates compression parameters corresponding to each data block based on the entropy range to which the entropy value of each data block belongs, and the preset correspondence between the entropy range and the compression parameters. A compression unit compresses the corresponding data blocks according to the compression parameters corresponding to each data block to obtain compressed firmware; A firmware generation unit generates the self-extracting firmware based on the compressed firmware.
[0015] One of the beneficial effects of this application embodiment is that: by determining the compression parameters corresponding to each data block according to the entropy value range of each data block in the compressed firmware, the optimal compression parameters are matched for each data block, thereby forming a variable compression parameter that dynamically changes with the entropy value range for the firmware to be compressed, and achieving a balance between compression ratio and decompression speed.
[0016] Referring to the following description and accompanying drawings, specific implementation methods of the embodiments of this application are disclosed in detail, indicating how the principles of the embodiments of this application can be adopted. It should be understood that the implementation methods of this application are not limited in scope. Within the spirit and scope of the appended claims, the implementation methods of this application include many changes, modifications, and equivalents. Attached Figure Description
[0017] The accompanying drawings, which form part of the specification, are used to provide a further understanding of the embodiments of this application and illustrate the implementation methods of this application, together with the textual description, to explain the principles of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other implementation methods based on these drawings without creative effort. In the drawings: Figure 1 This is a schematic diagram of a method for generating self-extracting firmware according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the compression of various data blocks according to an embodiment of this application; Figure 3 This is a schematic diagram of the self-extracting firmware generation process according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating the operation process of the self-extracting firmware according to an embodiment of this application; Figure 5 This is a schematic diagram of a self-extracting firmware generation device according to an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0018] Referring to the accompanying drawings, the foregoing and other features of the embodiments of this application will become apparent from the following description. Specific embodiments of this application are specifically disclosed in the description and drawings, illustrating partial implementations in which the principles of the embodiments of this application can be adopted. It should be understood that this application is not limited to the described embodiments; rather, the embodiments of this application include all modifications, variations, and equivalents falling within the scope of the appended claims.
[0019] In the embodiments of this application, the terms "first," "second," etc., are used to distinguish different elements by name, but do not indicate the spatial arrangement or chronological order of these elements, and these elements should not be limited by these terms. The term "and / or" includes any one or more of the terms listed in association and all combinations thereof. The terms "comprising," "including," "having," etc., refer to the presence of the stated features, elements, components, or assemblies, but do not exclude the presence or addition of one or more other features, elements, components, or assemblies.
[0020] In the embodiments of this application, the singular forms "a," "the," etc., including the plural forms, should be broadly understood as "a kind" or "a class" rather than limited to the meaning of "an." Furthermore, the term "the" should be understood to include both the singular and plural forms, unless the context explicitly indicates otherwise. Additionally, the term "according to" should be understood as "at least partially based on…," and the term "based on" should be understood as "at least partially based on…," unless the context explicitly indicates otherwise.
[0021] Features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, combined with features in other embodiments, or substituted for features in other embodiments. The term "comprising / including" as used herein means the presence of a feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components.
[0022] First aspect of the embodiments
[0023] This application provides a schematic diagram of a method for generating self-extracting firmware. For example... Figure 1 As shown, the generation method includes: 101. Divide the firmware to be compressed into multiple data blocks; 102. Determine the entropy value corresponding to each data block, wherein the entropy value is used to characterize the degree of disorder in the bit distribution in the corresponding data block; 103. Based on the entropy range to which each data block belongs and the preset correspondence between the entropy range and the compression parameters, generate the compression parameters corresponding to each data block; 104. Based on the compression parameters corresponding to each data block, compress the corresponding data blocks to obtain compressed firmware; 105. Generate the self-extracting firmware based on the compressed firmware.
[0024] It is worth noting that the above appendix Figure 1 The embodiments of this application have only been illustrated schematically, and the application is not limited thereto. For example, other operations may be added or some operations may be removed. Those skilled in the art can make appropriate modifications based on the above description, and are not limited to the above-described embodiments. Figure 1 The records.
[0025] According to the embodiments of this application, the compression parameters corresponding to each data block are determined based on the entropy range of each data block in the compressed firmware. Thus, the optimal compression parameters are matched for each data block, thereby forming variable compression parameters that dynamically change with the entropy range for the compressed firmware, achieving a balance between compression ratio and decompression speed.
[0026] In this embodiment, the firmware to be compressed can be a firmware file used to run on a target device or to upgrade the target device. The target device may include industrial control equipment, drive control equipment, communication control equipment, or other embedded devices. For example, the firmware to be compressed may include PLC controller firmware, motor driver firmware, bus communication module firmware, industrial control motherboard main firmware, etc. Taking PLC controller firmware as an example, the firmware to be compressed may include program code and data content. The program code may include low-level control code, hardware driver code, communication protocol code, device management code, etc.; the data content may include configuration files, text data, resource data, model information, function information, and padding data for address alignment, etc. It should be noted that the PLC controller firmware is only one example of the firmware to be compressed, and the firmware to be compressed in this embodiment is not limited to PLC controller firmware, nor is it limited to industrial equipment firmware. As long as the firmware can be used as a compression object and to generate self-decompressing firmware, it can be used as the firmware to be compressed in this embodiment.
[0027] In this embodiment, self-extracting firmware can be understood as a firmware file including a self-extracting header and compressed firmware. The self-extracting header may include program code for performing decompression processing, and the compressed firmware may include data obtained by compressing the firmware to be compressed. Therefore, when the target device starts up or performs a firmware upgrade, it can execute the self-extracting header to decompress the compressed firmware and run the decompressed firmware after decompression is complete.
[0028] In step 101, the firmware to be compressed can be divided into multiple data blocks according to the data arrangement order in the firmware. Here, "data arrangement order" can be understood as the order in which the data in the firmware is arranged according to file offset address, physical address, or storage address. That is, starting from the beginning of the firmware to be compressed, data can be extracted sequentially according to its original data order to form multiple data blocks. By dividing according to the data arrangement order, the correspondence between each data block and the original data position in the firmware to be compressed can be maintained, facilitating subsequent compression, splicing, and decompression recovery according to the corresponding order.
[0029] In some examples, the firmware to be compressed can be divided continuously along its physical addresses, with the same data length, resulting in multiple data blocks arranged consecutively within the firmware. In other words, the physical addresses or file offset addresses of two adjacent data blocks in the firmware can be consecutive, and the end position of the previous data block is adjacent to the start position of the next data block. For example, the firmware can be divided along its byte offset direction using a fixed-size block pattern, forming multiple consecutive and independent data blocks. The fixed size can be 4KB, 8KB, 16KB, or other data lengths. Taking a fixed size of 8KB as an example, the firmware can be divided into segments starting from the beginning, with each segment consisting of 8KB blocks. If the last part of the firmware is less than 8KB, it can be considered as a single data block.
[0030] Under the above partitioning method, the generated data blocks may correspond entirely to the program code region, or entirely to the configuration file region, padding data region, or other data regions; it is also possible that due to the fixed-length partitioning boundary not being completely consistent with the internal structure boundary of the firmware, a data block may simultaneously include program code and data files, or simultaneously include configuration files and padding data. None of the above situations will affect the subsequent determination of the data entropy value and generation of corresponding compression parameters for each data block.
[0031] In other examples, the data block partitioning method can also be adjusted according to the specific structure of the firmware to be compressed. For example, data of the same or similar types can be centrally partitioned into the same data block based on the partition structure, code segment location, data segment location, resource segment location, or configuration segment location of the firmware to be compressed. This makes the data types within each data block more consistent, which is beneficial for subsequently determining data distribution characteristics that better reflect the actual distribution of the data block. It should be noted that the specific partitioning method of the data blocks in this application embodiment is not limited, as long as the firmware to be compressed can be divided into multiple data blocks that can be analyzed and compressed separately.
[0032] In step 102, after obtaining multiple data blocks, each data block can be scanned and statistically analyzed to determine its corresponding data distribution characteristics. These characteristics describe the data distribution, regularity, or redundancy within the corresponding data block—that is, the predictability of the data block. Specifically, the more regular the data distribution and the larger the redundancy space, the higher the predictability of the data block. In this case, a relatively low compression ratio can be configured, sacrificing compression ratio to save memory and computational overhead. Conversely, the more disordered the data distribution and the smaller the redundancy space, the lower the predictability of the data. In this case, a relatively high compression ratio can be configured, sacrificing memory and computational overhead to save storage and transmission overhead.
[0033] In some examples, this data distribution characteristic includes the entropy value of the data block, which represents the degree of disorder in the bit distribution within the corresponding data block. The entropy value of a data block can be determined by analyzing the distribution of bit values, byte values, or symbol values within the data block. A smaller entropy value indicates a more regular distribution, higher predictability, and greater redundancy; conversely, a larger entropy value indicates a more disordered distribution, lower predictability, and less redundancy. For example, data blocks containing a large number of consecutive zeros, fixed padding values, or repeating byte sequences tend to have relatively concentrated bit or byte distributions, resulting in smaller entropy values. Conversely, data blocks containing a large amount of random data, encoded data, highly variable resource data, or unpredictable data tend to have relatively dispersed bit or byte distributions, resulting in larger entropy values. The entropy value quantifies the distribution of data blocks as input information for subsequent compression parameter generation.
[0034] In the example above, after calculating the entropy value of each data block, a data block address-entropy curve can be generated. This curve uses the arrangement order or physical address of the data blocks as the horizontal axis and the entropy value corresponding to the data block as the vertical axis. It can intuitively show the entropy value change trend, predictability distribution, and redundancy distribution of the firmware to be compressed in sequence, making it easier to identify low-entropy blocks and high-entropy blocks, and facilitating the configuration of subsequent compression parameters.
[0035] It should be noted that the embodiments of this application are not limited to generating a visual curve. The data block address-entropy curve can be in an easy-to-understand curve form, or it can be a data table, array, mapping relationship, parameter list, or other data structure that can represent the correspondence between data blocks and entropy values. As long as it can represent the correspondence between each data block and its entropy value, it can be used as the data block address-entropy curve in the embodiments of this application.
[0036] In step 103, compression parameters are generated for each data block based on its entropy range and the preset correspondence between the entropy range and compression parameters. Unlike setting compression parameters uniformly for the entire firmware to be compressed, this embodiment allows for configuring different compression parameters for different data blocks. This ensures that the compression parameters match the data distribution of the corresponding data blocks. These compression parameters may include: compression algorithm type, compression level parameters, compression window size, dictionary size, matching search range, maximum matching length, etc.
[0037] For example, a compression window represents the maximum range within which a compression algorithm can search for identical data. When compressing a data block, the algorithm can search for data that is the same as or similar to the data to be compressed within the range defined by this compression window, and then compress the data block based on the search results. When the compression parameters include a compression window, a larger compression window allows the algorithm to search a wider range of historical data, making it easier to find distant duplicate data or long repeating byte sequences; a smaller compression window results in a smaller range of historical data that the algorithm can search, typically only retrieving duplicate data within adjacent or relatively close ranges. Therefore, by configuring different compression windows for different data blocks, the search range for duplicate data by the compression algorithm can be adjusted according to the data distribution of different data blocks.
[0038] In some embodiments, multiple entropy ranges can be predefined, and a preset correspondence between entropy ranges and compression parameters can be established. For example, the entropy range can be divided into low entropy range, medium entropy range, and high entropy range, and corresponding compression parameters can be set for each entropy range. After calculating the entropy value of a data block, the target entropy range to which the entropy value belongs can be determined, and the compression parameters corresponding to the data block can be determined based on the compression parameters corresponding to the target entropy range.
[0039] In some examples, the predefined mapping can be stored in the form of a lookup table. For instance, this lookup table can include multiple entries, each containing an entropy range and the corresponding compression parameter. During the compression parameter generation process, the entropy value of each data block can be read sequentially, determining which entropy range it falls into, and retrieving the corresponding compression parameter from the lookup table. Thus, the compression parameter configuration for multiple data blocks can be completed block by block.
[0040] In some embodiments, within the preset correspondence between entropy ranges and compression windows, different compression window sizes correspond to different entropy ranges. For example, the compression window corresponding to a larger entropy range can be larger than the compression window corresponding to a smaller entropy range. That is, for data blocks with larger entropy values, because their data distribution is more disordered and their redundancy space is smaller, a larger compression window is used to improve the compression ratio and save storage space. For data blocks with smaller entropy values, because their data distribution is more regular and their redundancy space is larger, a smaller compression window can be configured, sacrificing some compression ratio to save memory and computing power.
[0041] In some embodiments, compression parameters corresponding to each data block are generated based on the data distribution characteristics of each data block, the compilation information of the firmware to be compressed, and user configuration. In some examples, the user configuration includes pre-set baseline parameters for the firmware to be compressed, such as data block size, compression algorithm type, maximum compression window, and minimum compression window. The compilation information provides the code segment and data segment range of the firmware to be compressed, and the attributes of the firmware itself awaiting decompression can be pre-set for the corresponding compression parameters for the code segment, data segment, or padding segment. When generating the compression parameters for each data block, for data ranges that the user configuration specifies must use a certain compression window, the user-specified compression window can be used first. For data ranges not specified by the user, the compilation information can be used to determine whether the data block belongs to a code segment, data segment, or padding segment, and then the final compression parameters can be determined by combining the entropy value of the data block. Therefore, based on the automatic analysis of data distribution characteristics, user configuration and firmware structure information can be introduced to achieve more flexible compression parameter configuration.
[0042] In the example above, after calculating the compression window size corresponding to each data block, a compression window curve can be generated. This curve uses the data block arrangement order or physical address as the horizontal axis and the corresponding compression window size as the vertical axis, visually displaying the changes in the compression window size of the firmware to be compressed arranged in sequence. In some examples, the compression window curve can be generated based on the data block address-entropy curve, compilation information, and user configuration. It should be noted that the compression window curve can also be a data structure such as a table, array, parameter sequence, or mapping relationship, as long as it can represent the correspondence between each data block and its corresponding compression window.
[0043] According to the above embodiment, the compression parameters corresponding to each data block are obtained. In step 104, each data block is compressed according to the compression parameters to obtain compressed firmware, which will be explained in detail below.
[0044] In some embodiments, according to the arrangement order of multiple data blocks in the firmware to be compressed, a data block and its corresponding compression parameters are obtained sequentially; after each data block and its corresponding compression parameters are obtained, a compression algorithm is invoked, and the corresponding data block is compressed according to the obtained compression parameters to obtain the compressed data unit corresponding to the data block; after the compression of the current data block is completed, the next data block and its corresponding compression parameters are obtained, and the next data block is compressed, and so on, until multiple data blocks in the firmware to be compressed have been compressed to obtain their respective compressed data units; the compressed data units corresponding to multiple data blocks are concatenated according to the arrangement order of the data blocks to obtain the compressed firmware.
[0045] Figure 2 This is a schematic diagram illustrating the compression of various data blocks according to an embodiment of this application.
[0046] by Figure 2 For example, the firmware to be compressed can be divided into data blocks B1, B2, B3, ..., Bn. Correspondingly, compression parameters P1, P2, P3, ..., Pn can be determined. During compression, data block B1 and compression parameter P1 are first scheduled, and the compression algorithm is called to compress data block B1, resulting in compressed data unit C1; then data block B2 and compression parameter P2 are scheduled, and the compression algorithm is called to compress data block B2, resulting in compressed data unit C2; and so on, until the compressed data unit Cn corresponding to data block Bn is obtained. C1, C2, ..., Cn are then concatenated in sequence to obtain the compressed firmware.
[0047] When compressing each data block, the compression algorithm called can be the DEFLATE compression algorithm or other existing compression algorithms; this application does not impose any restrictions.
[0048] According to the above embodiment, a compressed firmware is obtained. In step 105, the self-extracting firmware can be generated based on the compressed firmware. A self-extracting header is added to the compressed firmware to generate the self-extracting firmware. The self-extracting header is used to decompress the compressed firmware. The self-extracting header may include decompression program code, and may also include information required for decompression such as the location of the compressed firmware, the length of the compressed firmware, the decompression target address, the verification method, and the entry address.
[0049] When decompressing compressed firmware using a self-decompressing head, the compressed firmware is decompressed as a whole data unit, without the need to decompress it separately according to the divided data blocks. The specific decompression algorithm can refer to the existing technology, and will not be elaborated here.
[0050] When the target device boots up or performs a firmware upgrade, a self-extracting header can be run. This header reads and decompresses the compressed firmware to obtain the decompressed firmware data. It's important to note that although compressed firmware can be composed of multiple compressed data units, the self-extracting header treats it as a single object to be decompressed without requiring the target device to understand the entropy values, compression parameter generation processes, or compression window curves of each compressed data unit during the compression phase. In other words, the target device can perform decompression according to existing self-extracting procedures.
[0051] In some embodiments, the self-decompressing head can sequentially identify multiple compressed data units in the compressed firmware and decompress each of the compressed data units. For example, the self-decompressing head can determine the boundaries of each compressed data unit based on the data length information in the compressed data unit; verify the compressed data unit based on verification information; and call the corresponding decompression algorithm to decompress the compressed data unit. After decompressing one compressed data unit, the self-decompressing head can continue to identify the next compressed data unit and decompress the next compressed data unit until all compressed data units have been decompressed. The multiple data blocks obtained after decompression can be restored to complete firmware data according to their original arrangement order in the firmware to be compressed.
[0052] Therefore, without modifying the existing decompression process of the target device, compression parameters can be dynamically configured according to the data distribution of different data blocks in the firmware to be compressed, thereby improving compatibility with shipped devices or existing firmware upgrade processes.
[0053] The method for generating self-extracting firmware according to embodiments of this application has been described above. Hereinafter, the generation process of self-extracting firmware will be described using data distribution characteristics including entropy values and compression parameters including compression windows.
[0054] Figure 3 This is a schematic diagram illustrating the generation process of the self-extracting firmware according to an embodiment of this application. Figure 3 As shown, the process for generating self-extracting firmware includes: 301, divide the firmware to be compressed into multiple data blocks; 302, determine the entropy value corresponding to each data block respectively; 303, Generate a data block address-entropy curve based on the entropy value corresponding to each data block; 304. Generate a data block compression window curve based on the data block address-entropy curve, compilation information, and user configuration; the data block compression window curve can be used to represent the correspondence between each data block and the compression window.
[0055] 305. Invoke the compression algorithm and compress multiple data blocks sequentially according to the data block compression window curve to obtain multiple compressed data units; 306. Multiple compressed data units are spliced together to obtain compressed firmware; 307. Add a self-extracting header to the compressed firmware to generate self-extracting firmware.
[0056] The implementation methods of 301 to 307 above can refer to the foregoing embodiments, and the repeated parts will not be described again.
[0057] The above provides an exemplary description of the self-extracting firmware generation process. The following describes the operation process of the self-extracting firmware according to embodiments of this application.
[0058] Figure 4 This is a schematic diagram illustrating the operation process of the self-extracting firmware according to an embodiment of this application. Figure 4 As shown, the operation process of the self-extracting firmware in this application embodiment includes: 401, The microcontroller runs the boot ROM in memory; In some embodiments, the BOOTROM bootloader can be the bootloader that runs first after the target device is powered on. The BOOTROM bootloader can be used to perform hardware initialization, load boot code, or call a self-extracting header and other boot-related processes. In some examples, the BOOTROM bootloader can be loaded into DDR memory or run in other memory areas; this application embodiment does not limit this.
[0059] 402, Execute the self-extracting head to decompress the self-extracting firmware; In some embodiments, the self-decompressing head can read the compressed firmware and, according to the organization of compressed data units in the compressed firmware, sequentially identify and decompress multiple compressed data units to recover multiple data blocks. Subsequently, the complete firmware data can be recovered according to the arrangement order of the multiple data blocks in the firmware to be compressed. Since each compressed data unit in the compressed firmware can adopt a data format that can be recognized by existing decompression programs, this decompression process can follow existing decompression procedures.
[0060] 403, jump to firmware execution.
[0061] The implementation methods of 401 to 403 above can refer to the foregoing embodiments and related technologies, and the repeated parts will not be described again.
[0062] According to the above embodiments, the compression parameters corresponding to each data block are determined based on the entropy range of each data block in the compressed firmware. Thus, the optimal compression parameters are matched for each data block, thereby forming variable compression parameters that dynamically change with the entropy range for the compressed firmware, achieving a balance between compression ratio and decompression speed.
[0063] The above description only covers the steps or processes relevant to this application, but this application is not limited thereto. The method may also include other steps or processes; for details of these steps or processes, please refer to the prior art.
[0064] The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.
[0065] Second aspect of the embodiments
[0066] This application provides a device for generating self-extracting firmware. Since the principle of this device in solving the problem is similar to that of the method in the first aspect embodiment, its specific implementation can refer to the implementation of the method in the first aspect embodiment. The contents that are the same will not be repeated.
[0067] Figure 5 This is a schematic diagram of a self-extracting firmware generation apparatus according to an embodiment of this application. Figure 5 As shown, the self-extracting firmware generation apparatus of this application embodiment includes: The partitioning unit 501 divides the firmware to be compressed into multiple data blocks; The determining unit 502 determines the entropy value corresponding to each data block, and the entropy value is used to characterize the disorder of the bit distribution in the corresponding data block; The parameter generation unit 503 generates compression parameters corresponding to each data block based on the entropy range to which the entropy value of each data block belongs and the preset correspondence between the entropy range and the compression parameters. Compression unit 504 compresses the corresponding data blocks according to the compression parameters corresponding to each data block to obtain compressed firmware; Firmware generation unit 505 generates the self-extracting firmware based on the compressed firmware.
[0068] In some embodiments, the compression parameters include a compression window, which represents the maximum range of data that the compression algorithm searches for.
[0069] In some embodiments, the partitioning unit 501 continuously partitions the firmware to be compressed along the physical address of the firmware to be compressed according to the same data length to obtain the plurality of data blocks, wherein the plurality of data blocks are arranged continuously in the firmware to be compressed.
[0070] In some embodiments, the parameter generation unit 503 generates compression parameters corresponding to each data block based on the entropy value corresponding to each data block, the compilation information of the firmware to be compressed, and the user configuration.
[0071] In some embodiments, in the preset correspondence, the compression window corresponding to a larger entropy value range is larger than the compression window corresponding to a smaller entropy value range.
[0072] In some embodiments, the firmware generation unit 505 adds a self-extracting header to the compressed firmware to generate the self-extracting firmware, wherein the self-extracting header is used to decompress the compressed firmware.
[0073] In some embodiments, the compression unit 504 sequentially acquires a data block and the compression parameters corresponding to the data block according to the arrangement order of the plurality of data blocks in the firmware to be compressed. The compression algorithm is invoked, and the acquired data block is compressed according to the obtained compression parameters to obtain the compressed data unit corresponding to the data block; After compressing the current data block, the next data block and its corresponding compression parameters are obtained, and the next data block is compressed until all data blocks are compressed to obtain their respective compressed data units; and The compressed data units corresponding to the multiple data blocks are concatenated to obtain the compressed firmware.
[0074] It is worth noting that the above description only covers the components or modules relevant to this application, but this application is not limited thereto. The aforementioned device may also include other components or modules, and for details regarding these components or modules, please refer to related technologies.
[0075] For the sake of simplicity, Figure 5 The connections or signal paths between the various components or modules are merely illustrative examples; however, those skilled in the art should understand that various related technologies, such as bus connections, can be employed. The aforementioned components or modules can be implemented using hardware facilities such as processors and memory; this application does not limit the scope of the embodiments.
[0076] The above embodiments are merely illustrative examples of embodiments of this application, but this application is not limited thereto, and appropriate modifications can be made based on the above embodiments. For example, the above embodiments can be used alone, or one or more of the above embodiments can be combined.
[0077] Third aspect of the embodiments
[0078] This application provides an electronic device including a self-extracting firmware generation apparatus 500 as described in the second aspect of the embodiment, the contents of which are incorporated herein by reference. This electronic device may be, for example, a computer, server, workstation, laptop computer, smartphone, etc.; however, this application is not limited thereto.
[0079] Figure 6 This is a schematic diagram of an electronic device according to an embodiment of this application. For example... Figure 6 As shown, the electronic device 600 may include a processor (e.g., a central processing unit, CPU) 610 and a memory 620; the memory 620 is coupled to the central processing unit 610. The memory 620 can store various types of data; it also stores an information processing program 621, and executes the program 621 under the control of the processor 610.
[0080] In some embodiments, the self-extracting firmware generation apparatus 500 function is integrated into the processor 610. The processor 610 is configured to implement the self-extracting firmware generation method as described in the first aspect.
[0081] In some embodiments, the self-extracting firmware generation device 500 is configured separately from the processor 610. For example, the self-extracting firmware generation device 500 can be configured as a chip connected to the processor 610, and the function of the self-extracting firmware generation device 500 can be realized through the control of the processor 610.
[0082] In addition, such as Figure 6 As shown, the electronic device 600 may also include: an input / output (I / O) device 630 and a display 640, etc.; the functions of the above components are similar to those in the prior art, and will not be described in detail here. It is worth noting that the electronic device 600 is not necessarily required to include... Figure 6 All components shown; in addition, the electronic device 600 may also include Figure 6 For components not shown, please refer to relevant technologies.
[0083] This application also provides a computer-readable program, wherein when the program is executed in an electronic device, the program causes the computer in the electronic device to perform the self-extracting firmware generation method as described in the first aspect embodiment.
[0084] This application also provides a storage medium storing a computer-readable program, wherein the computer-readable program causes a computer in an electronic device to execute the self-extracting firmware generation method as described in the first aspect embodiment.
[0085] This application also provides a computer program product, wherein the computer program product causes a computer to execute the self-extracting firmware generation method as described in the first aspect embodiment in an electronic device.
[0086] The apparatus and methods described above in this application can be implemented in hardware or in combination with software. This application relates to a computer-readable program that, when executed by a logic component, enables the logic component to implement the apparatus or components described above, or to implement the various methods or steps described above. This application also relates to storage media for storing the above programs, such as hard disks, magnetic disks, optical disks, DVDs, flash memory, etc.
[0087] The methods / apparatus described in conjunction with the embodiments of this application can be directly embodied in hardware, software modules executed by a processor, or a combination of both. For example, one or more and / or combinations of one or more functional block diagrams shown in the figures can correspond to various software modules in a computer program flow, or to various hardware modules. These software modules can correspond to the various steps shown in the figures, respectively. These hardware modules can be implemented, for example, using a field-programmable gate array (FPGA) to embed these software modules.
[0088] The software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. A storage medium can be coupled to the processor, enabling the processor to read information from and write information to the storage medium; or the storage medium can be an integral part of the processor. The processor and storage medium can reside in an ASIC. The software module can be stored in the memory of a mobile terminal or in a memory card that can be inserted into the mobile terminal. For example, if the device (such as a mobile terminal) uses a high-capacity MEGA-SIM card or a high-capacity flash memory device, the software module can be stored in the MEGA-SIM card or the high-capacity flash memory device.
[0089] One or more and / or one or more combinations of functional blocks described in the accompanying drawings can be implemented as a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or any suitable combination thereof for performing the functions described herein. One or more and / or one or more combinations of functional blocks described in the accompanying drawings can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in communication with a DSP, or any other such configuration.
[0090] The present application has been described above with reference to specific embodiments. However, those skilled in the art should understand that these descriptions are exemplary and not intended to limit the scope of protection of the present application. Those skilled in the art can make various modifications and variations to the present application based on the principles thereof, and these modifications and variations are also within the scope of the present application.
Claims
1. A method for generating self-extracting firmware, wherein, The method includes: The firmware to be compressed is divided into multiple data blocks; The entropy value corresponding to each data block is determined, and the entropy value is used to characterize the degree of disorder in the bit distribution in the corresponding data block; Based on the entropy range to which the entropy value of each data block belongs, and the preset correspondence between the entropy range and the compression parameters, the compression parameters corresponding to each data block are generated. Based on the compression parameters corresponding to each data block, the corresponding data blocks are compressed to obtain compressed firmware. The self-extracting firmware is generated based on the compressed firmware.
2. The method according to claim 1, wherein, The compression parameters include a compression window, which represents the maximum range within which the compression algorithm searches for the same data.
3. The method according to claim 1, wherein, The firmware to be compressed is divided into multiple data blocks, including: The firmware to be compressed is divided continuously along the physical address of the firmware to be compressed according to the same data length to obtain the plurality of data blocks, wherein the plurality of data blocks are arranged continuously in the firmware to be compressed.
4. The method according to claim 1, wherein, Based on the entropy value corresponding to each data block, the compression parameters corresponding to each data block are generated, including: Based on the entropy value corresponding to each data block, the compilation information of the firmware to be compressed, and the user configuration, compression parameters corresponding to each data block are generated.
5. The method according to claim 1, wherein, In the preset correspondence, the compression window corresponding to the larger entropy value range is larger than the compression window corresponding to the smaller entropy value range.
6. The method according to claim 1, wherein, The self-extracting firmware is generated based on the compressed firmware, including: A self-extracting header is added to the compressed firmware to generate the self-extracting firmware, and the self-extracting header is used to decompress the compressed firmware.
7. The method according to claim 1, wherein, Based on the compression parameters corresponding to each data block, the corresponding data blocks are compressed to obtain compressed firmware, including: According to the arrangement order of the multiple data blocks in the firmware to be compressed, one data block and the compression parameters corresponding to the data block are obtained sequentially. The compression algorithm is invoked, and the acquired data block is compressed according to the obtained compression parameters to obtain the compressed data unit corresponding to the data block; After compressing the current data block, the next data block and its corresponding compression parameters are obtained, and the next data block is compressed until all data blocks are compressed to obtain their respective compressed data units; and The compressed data units corresponding to the multiple data blocks are concatenated to obtain the compressed firmware.
8. An apparatus for generating self-decompressing firmware, wherein, The device includes: The partitioning unit divides the firmware to be compressed into multiple data blocks; A determining unit, which determines the entropy value corresponding to each data block, wherein the entropy value is used to characterize the disorder of the bit distribution in the corresponding data block; The parameter generation unit generates compression parameters corresponding to each data block based on the entropy range to which the entropy value of each data block belongs, and the preset correspondence between the entropy range and the compression parameters. A compression unit compresses the corresponding data blocks according to the compression parameters corresponding to each data block to obtain compressed firmware; A firmware generation unit generates the self-extracting firmware based on the compressed firmware.