Firmware upgrade methods, devices, equipment and program products

Abstract

This application relates to the field of embedded devices, and more particularly to a firmware upgrade method, apparatus, device, and program product. The method includes: obtaining the compiled output of the firmware source code file; specifying the size of a first image file as the partition size of the firmware storage partition of the embedded device, and packaging the first image file into a first image file according to the partition size; obtaining the actual occupied space of the first file system of the first image file; determining the reserved space of a second image file based on the actual occupied space; generating the second image file based on the reserved space; encapsulating the second image file to obtain a firmware upgrade package; and upgrading the embedded device using the firmware upgrade package. Since the second image file can be much smaller than the size of the firmware storage partition, the transmission time of the firmware upgrade package can be effectively shortened, and the writing to Flash memory can be reduced, which is beneficial to improving firmware upgrade efficiency and extending Flash memory lifespan.

Description

Technical Field

[0001] This application relates to the field of embedded devices, and more particularly to a firmware upgrade method, apparatus, device, and program product. Background Technology

[0002] Currently, many embedded devices use storage media such as NOR FLASH (or non-flash memory) or eMMC (embedded multimedia card) to store firmware. In practical applications, the storage media is usually not directly manipulated. Instead, an EXT4 file system is first created on these storage media to manage the firmware.

[0003] When using the EXT4 file system to manage firmware, the EXT4 file system is typically mounted and the firmware is loaded during embedded device startup. When creating upgrade firmware, the image size is specified as the partition size, and the compiled output directory is packaged into an EXT4 format image file. Firmware generated according to the partition size will result in more network traffic and Flash writes during firmware upgrades, leading to longer upgrade times and potentially shortening the Flash lifespan. Summary of the Invention

[0004] In view of this, embodiments of this application provide a firmware upgrade method, apparatus, device, and program product to solve the problems in the prior art where firmware upgrades require a large amount of network transmission traffic and Flash writing, resulting in long upgrade times and potential impact on Flash lifespan.

[0005] A first aspect of this application provides a firmware upgrade method, the method being applied to a server, the method comprising:

[0006] Obtain the compilation artifacts of the firmware source code files, and compress the compilation artifacts to obtain the first image file; The size of the first image file is specified as the partition size of the firmware storage partition of the embedded device, and the compilation artifacts are packaged into the first image file according to the partition size; Obtain the actual space occupied by the first file system that generated the first image file; The reserved space for the second image file is determined based on the actual occupied space. The second image file is generated based on the reserved space. The second image file is then packaged to obtain a firmware upgrade package. The embedded device is then upgraded using the firmware upgrade package.

[0007] In conjunction with the first aspect, in the first possible implementation of the first aspect, obtaining the actual space occupied by the first file system that generated the first image file includes: Obtain the total number of blocks in the first image file, the number of free blocks in the first image file, and the size of a single block using a file system information management tool; Based on the total number of blocks included in the first image file and the number of free blocks in the first image file, the number of used blocks of the first file system that generated the first image file is determined. Based on the number of used blocks and the size of a single block of the file system, the actual space occupied by the first file system that generated the first image file is determined.

[0008] In conjunction with the first aspect, in a second possible implementation of the first aspect, before specifying the size of the first image file as the partition size of the firmware storage partition of the embedded device, the method further includes: The compilation output was compressed using a file system compression tool to generate a zeroth image file; The compiled artifacts are packaged into a first image file, including: Use the EXT4 file system tools to package the zeroth image file into a first image file in EXT4 format.

[0009] Secondly, embodiments of this application provide a firmware upgrade method, the firmware upgrade method being based on a firmware upgrade package determined by any one of the firmware upgrade methods of the first aspect, the method being applied to an embedded device, the method comprising: When the embedded device starts up, a firmware storage partition is mounted through a preset first mount point. The firmware storage partition includes the compilation artifacts stored in the second image file. Access the compilation artifacts stored in the second image file through the first mount point, and copy the compilation artifacts to the memory file system; The compiled artifacts in the memory file system are mounted through a preset second mount point, and the firmware storage partition is unmounted after the mounting is completed.

[0010] In conjunction with the second aspect, in a first possible implementation of the second aspect, the first image file includes a zero image file generated by compressing the compilation artifacts using a file system compression tool; Mount the compiled artifacts in the memory file system through a preset second mount point, and unmount the firmware storage partition after mounting, including: Designate a temporary directory as the second mount point; Mount the zeroth image file through the second mount point; The second mount point is switched to the firmware root directory via a system call; After the switch is completed, the mount relationship between the first mount point and the firmware storage partition is unmounted.

[0011] In conjunction with the second aspect, in a second possible implementation of the second aspect, after unmounting the firmware storage partition, the method further includes: In the operating environment based on the memory file system, receive new firmware upgrade packages; The new firmware upgrade package is overwritten to the firmware storage partition of the embedded device, and the process jumps to the step of mounting the firmware storage partition through a preset first mount point when the embedded device starts up. The firmware storage partition includes the compilation artifacts stored in the second image file.

[0012] In conjunction with the second aspect, in a third possible implementation of the second aspect, the first image file includes a zeroth image file generated by compressing the compilation artifacts using a file system compression tool; After mounting the compiled artifacts in the memory file system via a preset second mount point, the method further includes: In response to a request to read data from the zeroth image file, the corresponding compressed data block is read from the zeroth image file by the operating system kernel and transparently decompressed. The decompressed data is stored in the system cache for access, and the decompressed data is preferentially reclaimed when the system memory is insufficient.

[0013] A third aspect of this application provides a firmware upgrade apparatus, the apparatus being applied to a server, the apparatus comprising: The compilation product acquisition unit is used to acquire the compilation product of the firmware source code file and compress the compilation product to obtain a first image file. The image file packaging unit is used to specify the size of the first image file as the partition size of the firmware storage partition of the embedded device, and to package the compilation product into the first image file according to the partition size; The actual space occupied acquisition unit is used to acquire the actual space occupied by the first file system that generated the first image file. The firmware upgrade package determination unit is used to determine the reserved space of the second image file based on the actual occupied space, generate the second image file based on the reserved space, encapsulate the second image file to obtain a firmware upgrade package, and upgrade the embedded device through the firmware upgrade package.

[0014] A fourth aspect of this application provides a firmware upgrade device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the firmware upgrade device performs the method as described in any of the first aspects.

[0015] A fifth aspect of this application provides a computer program product that, when run on a computer, causes the computer to execute the methods described in the first aspect or its various implementations.

[0016] A sixth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects.

[0017] A seventh aspect of this application provides a chip for implementing the methods in the various implementations of the first aspect described above. Specifically, the chip includes a processor for calling and running a computer program from a memory, causing a device equipped with the chip to perform the methods as described in the first aspect or its various implementations.

[0018] The beneficial effects of this application embodiment compared with the prior art are as follows: In the firmware upgrade method of this application embodiment, after obtaining the compilation product of the firmware source code file, the compilation product is first packaged into a first image file according to the size of the firmware storage partition. The actual occupied space of the first file system that generated the first image file is obtained. Based on the actual occupied space, a reserved space for the second image file is determined. The compilation product is then repackaged into a second image file using this reserved space, and the second image file is encapsulated to obtain the firmware upgrade package. Because this firmware upgrade package obtains the actual occupied space of the first file system of the first image file by pre-packaging the compilation product, and repackages it using the reserved space determined by the actual occupied space of the first file system that generated the first image file, the second image file can be much smaller than the size of the firmware storage partition. This effectively shortens the transmission time of the firmware upgrade package and reduces the writing to Flash, which is beneficial to improving firmware upgrade efficiency and extending the lifespan of Flash. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram illustrating an implementation scenario of a firmware upgrade method provided in this application embodiment; Figure 2 This is a schematic diagram illustrating the implementation process of a server-side firmware upgrade method provided in an embodiment of this application. Figure 3This is a schematic diagram illustrating the implementation process of a firmware upgrade method based on an embedded device, as provided in an embodiment of this application. Figure 4 This is a schematic diagram illustrating the implementation process of a method for mounting a first image file through a second mount point, as provided in an embodiment of this application. Figure 5 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application; Figure 6 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0023] In the embedded systems field, when using NOR Flash or eMMC to store firmware, the EXT4 file system is typically relied upon for management. This EXT4 file system forms a standard operating procedure: the firmware is loaded by mounting the EXT4 file system during device startup, and during firmware upgrades, an EXT4 image file with the same full size as the physical partition is generated. The initial intention of this approach was to ensure reliable storage of the EXT4 image file, but it also brings significant drawbacks: because the partition size is fixed and often a large amount of free space is reserved, the generated upgrade image contains a large amount of invalid data, resulting in a large upgrade package size. This not only increases the network transmission burden and upgrade time, but also affects the lifespan of the Flash storage medium due to frequent writing of large amounts of data.

[0024] To address the aforementioned problems, this application proposes a firmware upgrade method. Figure 1This diagram illustrates an implementation scenario for the method, which includes server 1 and embedded device 2. Server 1 can package the firmware source code files into a firmware upgrade package. Specifically, the server can obtain the compiled output of the firmware source code files; specify the size of the first image file as the partition size of the firmware storage partition of the embedded device; package the first image file into a first image file according to the partition size; obtain the actual space occupied by the first image file; determine the reserved space for the second image file based on the actual space occupied; generate the second image file based on the reserved space; encapsulate the second image file to obtain the firmware upgrade package; and send the firmware upgrade package to the embedded device so that the embedded device can perform a firmware upgrade via the firmware upgrade package. It is understood that the device generating the firmware upgrade package is not limited to the server; other devices can generate the firmware upgrade package and send it to the server, which then distributes it to various embedded devices for firmware upgrades. This effectively reduces the transmission efficiency of the firmware upgrade package, reduces Flash writing, improves upgrade efficiency, and increases Flash lifespan.

[0025] After receiving the firmware upgrade package, embedded device 2 mounts the firmware storage partition through a preset first mount point during startup. The firmware storage partition includes the compilation artifacts stored in the second image file. It accesses the compilation artifacts stored in the second file system through the first mount point and copies the compilation artifacts to the memory file system. It then mounts the compilation artifacts in the memory file system through a preset second mount point. After mounting, the firmware storage partition is unmounted. This allows the firmware storage partition to be overwritten during firmware operation, effectively improving the security and reliability of firmware upgrades.

[0026] Figure 2 This is a schematic diagram illustrating the implementation process of a firmware upgrade method provided in an embodiment of this application. This method can be used in devices that generate firmware upgrade packages, including servers, etc. The method is described in detail below: In S201, the compiled output of the firmware source code file is obtained.

[0027] In this application's embodiments, the firmware source code file refers to the uncompiled firmware source code file, including firmware files written in languages ​​such as C, C++, and Python, with formats of .c, .h, and .py respectively. The firmware source code file includes executable files, library files, configuration files, resource files, and script files, etc.

[0028] In a server or other firmware upgrade package creation device, the source code files of the embedded device's firmware are compiled and linked to generate the final, executable compilation artifact directory.

[0029] To further reduce the size of the firmware upgrade package, shorten the transmission time of the firmware upgrade package, reduce writing to Flash, improve firmware upgrade efficiency, and extend Flash lifespan, this embodiment of the application can use the mksquashfs tool to package and compress the entire compilation artifact directory into a Squashfs format image file, which serves as the zeroth image file. Squashfs is a read-only, highly compressed file system that can significantly reduce image size.

[0030] For example, assuming the compilation output directory is the firmware root directory . / firmware_root / , you can use the command mksquashfs . / rootfs firmware.squashfs -comp xz to generate a first image file named firmware.squashfs.

[0031] In S202, the size of the first image file is specified as the partition size of the firmware storage partition of the embedded device, and the compilation product is packaged into the first image file according to the partition size.

[0032] The first image file can be an EXT4 format image file. EXT4 file system tools can be used to package the compilation artifacts or the zeroth image file into an EXT4 format first image file. The zeroth image file can be a Squashfs or cramfs format image file. File system compression tools, including Squashfs or cramfs file system tools, can be used to compress the compilation artifacts to generate the Squashfs format zeroth image file, which can significantly reduce the storage space occupied by the compilation artifacts.

[0033] To ensure compatibility, when packaging the zeroth image file, a blank file with the exact same size as the firmware storage partition on the target embedded device's Flash memory needs to be created first. Then, an EXT4 file system is created on this blank file, and the compressed zeroth image file (Squashfs or cramfs image file) is stored in this newly created EXT4 file system, generating the first image file. Generating a first image file that perfectly matches the firmware storage partition layout of the embedded device allows for accurate space analysis later.

[0034] For example, assuming the target device's partition size is 64MB, you can create a 64MB blank file named large.img, and then format it as an EXT4 file system using the command `mkfs.ext4 large.img`. Next, mount it to a temporary directory (such as / mnt / temp), copy firmware.squashfs to that directory, and finally unmount the temporary directory. This completes the creation of the first image file.

[0035] In S203, the actual space occupied by the first file system that generated the first image file is obtained.

[0036] Although the first image file is the same size as the firmware storage partition, it contains only a single Squashfs file, which may be only 6MB. Therefore, the EXT4 file system has a large amount of unused free space. This step can use a file system information management tool to obtain data such as the free blocks, total number of blocks, and single block size of the first image file, and calculate the actual space used to store data.

[0037] File system information management tools such as dumpe2fs can be used to obtain the total number of blocks in the first image file, the number of free blocks in the first image file, and the size of each block. Based on the total number of blocks in the first image file and the number of free blocks in the first image file, the difference between the two can be used to obtain the number of blocks used in the first image file. Based on the number of used blocks and the size of each block in the first image file, the actual space occupied in the first image file can be obtained.

[0038] The number of used blocks refers to the number of blocks occupied by the zeroth image file or compilation artifact in the firmware storage partition, that is, the number of blocks that have already stored the number of users and file system metadata. The number of free blocks refers to the number of blocks in the first file system of the first image file, such as the EXT4 file system, that have not yet been allocated and used, and are available for storing new files or expanding existing files in the future.

[0039] For example, the dumpe2fs tool can be used to read the superblock information of the first image file to obtain the Total blocks, Free blocks, and Block size (typically 4KB). The used blocks are calculated as: Used blocks = Total blocks - Free blocks. Then, the actual occupied space is calculated as: Used blocks = Total blocks - Free blocks. The block size provides a precise estimate of the actual space occupied by the first file system used to generate the first image file.

[0040] In S204, the reserved space for the second image file is determined based on the actual occupied space, the second image file is generated based on the reserved space, the second image file is packaged to obtain a firmware upgrade package, and the embedded device is upgraded through the firmware upgrade package.

[0041] After determining the actual space occupied by the first file system in the first image file, the reserved space for the second image file can be determined. This reserved space will be used as the size of the final image (second image file) to store the metadata of the first image file and the first file system. For example, an EXT4 image with the reserved space size can be created again, and the zeroth image file or compilation artifact can be stored in it. The resulting second image file will be much smaller than the first image file. Finally, header information (such as version number, checksum, etc.) is added to this small image file for encapsulation, generating the final firmware upgrade package.

[0042] For example, if the actual occupied space is 6MB, and the reserved space determined based on the actual occupied space is 7MB, then a 7MB EXT4 image will be created, and the first image file firmware.squashfs will be stored in it. The final generated package update_v1.2.bin is the firmware upgrade package, which is approximately 7MB in size, much smaller than the initial 64MB.

[0043] Since the actual generated firmware upgrade package is much smaller than the size of the first image file generated based on the firmware storage partition size, transmitting the firmware upgrade package to the embedded device can significantly reduce the transmission traffic and improve the upgrade efficiency. Furthermore, writing the firmware upgrade package to Flash memory greatly reduces the amount of data written, which helps reduce Flash writes and increase Flash memory lifespan.

[0044] After the firmware upgrade package is generated and transmitted to the embedded device, the embedded device can perform a firmware upgrade operation based on the firmware upgrade package, such as... Figure 3 As shown, the implementation process of the firmware upgrade method for embedded devices includes: In S301, when the embedded device starts up, the firmware storage partition is mounted through a preset first mount point.

[0045] The firmware storage partition includes the compiled artifacts or zeroth image file stored in the second image file, such as the EXT4 file system mentioned above. The second image file occupies significantly less storage space than the first image file, effectively reducing the amount of Flash memory written.

[0046] After the embedded device powers on, the bootloader (such as U-Boot) first loads the kernel. After the kernel starts, it executes the ` / init` initialization script. This script needs to mount the firmware storage partition on the Flash memory. Assuming the firmware storage partition is defined as ` / dev / mmcblk0p2` in the device tree, the command `mount -t ext4 / dev / mmcblk0p2 / mnt / flash` is used to mount the firmware storage partition to the first mount point ` / mnt / flash`. At this point, the system can access the contents of the firmware storage partition on the Flash memory through the first mount point.

[0047] Mounting the firmware storage partition through the first mount point allows the system to read firmware data from the Flash memory. The EXT4 file system is the standard Linux file system, supporting journaling to ensure data consistency. After mounting, the system can access all files in the firmware storage partition in the Flash memory through the first mount point, such as the / mnt / flash path, including all files in the second file system generated during the burning of the second image file, such as compilation artifacts or the zeroth image file included in the second file system.

[0048] In S302, the compilation artifact stored in the second image file is accessed through the first mount point, and the compilation artifact is copied to the memory file system.

[0049] After mounting the firmware storage partition in Flash, the system can access the compiled artifacts or zeroth image files compressed from the compiled artifacts, such as Squashfs image files. Assuming the zeroth image file is named firmware.squashfs and the first mount point is / mnt / flash, the complete access path for the first image file is: / mnt / flash / firmware.squashfs. The copy command `cp / mnt / flash / firmware.squashfs / tmp / firmware.squashfs` can be used to copy the zeroth image file from the firmware storage partition to the RAMFS (ramfs) filesystem. The RAMFS filesystem is a temporary filesystem in Linux, entirely based on memory for read and write operations, resulting in very fast read and write speeds.

[0050] Copying the zeroth image file (such as a Squashfs image file) from the firmware storage partition in Flash to the memory file system can achieve extremely fast read speeds (memory read / write speeds are far superior to Flash read / write speeds), and decouple the runtime environment from the physical storage medium, preparing for subsequent security upgrades. At this point, all files required for system operation are loaded into memory, no longer relying on real-time reading from Flash, effectively improving firmware operating efficiency.

[0051] In S303, the compilation artifacts in the memory file system are mounted through a preset second mount point, and the firmware storage partition is unmounted after the mounting is completed.

[0052] You can create a temporary directory as a second mount point, for example, create a temporary directory named `mkdir / new_root`. Then use the mount command `mount -t squashfs / tmp / firmware.squashfs / new_root -o loop` to mount the compiled artifacts in memory, or the zeroth image file obtained from the compiled artifacts (such as the Squashfs image file), to this temporary directory. The `-o loop` parameter indicates that the file is mounted as a block device. After mounting, the system can access the complete file system in the zeroth image file (Squashfs image file) through the temporary directory ` / new_root`. At this point, the system does not need to access the Flash memory. You can use the unmount command `umount / mnt / flash` to unmount the firmware storage partition of the Flash memory, releasing the Flash memory from its occupancy.

[0053] By moving the zeroth image file or compilation artifacts from Flash to memory, the system has two available file systems: an EXT4 file system on Flash and a Squashfs file system in memory. Since Squashfs is read-only and all files are loaded into memory, the system can run safely without needing to access Flash. Therefore, the firmware storage partition can be unmounted.

[0054] In this embodiment of the application, the process of mounting the first image file through the second mount point and unmounting the firmware storage partition after mounting can be as follows: Figure 4 As shown, it includes: In S401, a temporary directory is designated as the second mount point.

[0055] In the initialization script, a temporary directory can be created as a second mount point, which can then be used as the mount point for the new firmware root directory.

[0056] In S402, the zeroth image file is mounted through the second mount point.

[0057] Using the mount command, the first image file in memory is mounted to a temporary directory that serves as the second mount point. At this point, the temporary directory serving as the second mount point includes the complete root file system structure, including directories such as / bin, / etc, and / lib.

[0058] In S403, the second mount point is switched to the firmware root directory via a system call.

[0059] The temporary directory of the second mount point can be switched to the system's firmware root directory via system calls. For example, the root file system can be switched atomically using pivot_root.

[0060] In S404, after the switch is completed, the mount relationship between the first mount point and the firmware storage partition is unmounted.

[0061] After the root switch is complete, the old root file system is now mounted under the old firmware root directory. The old root file system can be unmounted using the command `umount / old_root`. At this point, the Flash firmware storage partition is completely unmounted, and the system no longer occupies that firmware storage partition. In the operating environment of the memory file system, a new firmware upgrade package can be received and overwritten to the embedded device's firmware storage partition, overwriting the old firmware upgrade package. When the embedded device boots, the first image file is copied to the memory file system by mounting the firmware storage partition containing the new firmware upgrade package. The first image file in the memory file system is then mounted through a second mount point. After mounting is complete, the firmware storage partition is unmounted.

[0062] In addition, after mounting the compiled artifacts in the memory file system through the preset second mount point in this embodiment, it can respond to the read request for data in the first image file (Squashfs image file), read the corresponding compressed data blocks from the first image file (Squashfs image file) through the operating system kernel and perform transparent decompression, store the decompressed data in the system cache for access, and preferentially reclaim the decompressed data when the system memory is insufficient, so that the Squashfs image file can run efficiently on memory-constrained embedded devices.

[0063] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0064] Figure 5This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. The firmware upgrade device includes: The compilation artifact acquisition unit 501 is used to acquire the compilation artifacts of the firmware source code file; The image file packaging unit 502 is used to specify the size of the first image file as the partition size of the firmware storage partition of the embedded device, and to package the compilation product into the first image file according to the partition size; The actual space occupied acquisition unit 503 is used to acquire the actual space occupied by the first file system that generated the first image file; Firmware upgrade package determination unit 504 is used to determine the reserved space of the second image file based on the actual occupied space, generate the second image file based on the reserved space, encapsulate the second image file to obtain a firmware upgrade package, and upgrade the embedded device through the firmware upgrade package.

[0065] The firmware upgrade device and Figure 2 The firmware upgrade method shown corresponds to this.

[0066] In addition, embodiments of this application also provide a firmware upgrade device based on an embedded device, comprising: The first mounting unit is used to mount the firmware storage partition through a preset first mounting point when the embedded device starts up. The firmware storage partition includes the compilation artifacts stored in the second image file.

[0067] The copy unit is used to access the compilation artifact stored in the second image file through the first mount point and copy the compilation artifact to the memory file system.

[0068] The second mounting unit is used to mount the compilation artifacts in the memory file system through a preset second mount point, and unmount the firmware storage partition after the mounting is completed.

[0069] Firmware upgrade device based on embedded device, and Figure 3 The firmware upgrade method shown corresponds to this.

[0070] Figure 6 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. Figure 6 As shown, the firmware upgrade device 6 of this embodiment includes: a processor 60, a memory 61, and a computer program 62, such as a firmware upgrade program, stored in the memory 61 and executable on the processor 60. When the processor 60 executes the computer program 62, it implements the steps in the various firmware upgrade method embodiments described above. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the various device embodiments described above.

[0071] For example, the computer program 62 may be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 62 in the firmware upgrade device 6.

[0072] The firmware upgrade device 6 can be a server, an embedded device, or a device for creating firmware upgrade packages. The firmware upgrade device may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that... Figure 6 This is merely an example of a firmware upgrade device 6 and does not constitute a limitation on the firmware upgrade device 6. It may include more or fewer components than shown, or combine certain components, or different components. For example, the firmware upgrade device may also include input / output devices, network access devices, buses, etc.

[0073] The processor 60 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0074] The memory 61 can be an internal storage unit of the firmware upgrade device 6, such as a hard drive or memory of the firmware upgrade device 6. The memory 61 can also be an external storage device of the firmware upgrade device 6, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the firmware upgrade device 6. Furthermore, the memory 61 can include both internal and external storage units of the firmware upgrade device 6. The memory 61 is used to store the computer program and other programs and data required by the firmware upgrade device. The memory 61 can also be used to temporarily store data that has been output or will be output.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0076] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0077] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0078] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0079] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0081] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0082] In addition, this application also provides a computer program product that, when run on a computer, causes the computer to execute the methods in the above-described implementations.

[0083] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A firmware upgrade method, characterized in that, The method is applied to a server, and the method includes: Obtain the compiled output of the firmware source code file; The size of the first image file is specified as the partition size of the firmware storage partition of the embedded device, and the compilation artifacts are packaged into the first image file according to the partition size; Obtain the actual space occupied by the first file system that generated the first image file; The reserved space for the second image file is determined based on the actual occupied space. The second image file is generated based on the reserved space. The second image file is packaged to obtain a firmware upgrade package. The embedded device is upgraded using the firmware upgrade package.

2. The method according to claim 1, characterized in that, Obtain the actual space occupied by the first file system that generated the first image file, including: Obtain the total number of blocks in the first image file, the number of free blocks in the first image file, and the size of a single block using a file system information management tool; Based on the total number of blocks included in the first image file and the number of free blocks in the first image file, the number of used blocks of the first file system that generated the first image file is determined. Based on the number of used blocks and the size of a single block of the file system, the actual space occupied by the first file system that generated the first image file is determined.

3. The method according to claim 1, characterized in that, Before specifying the size of the first image file as the partition size of the firmware storage partition of the embedded device, the method further includes: The compilation output was compressed using a file system compression tool to generate a zeroth image file; The compiled artifacts are packaged into a first image file, including: Use the EXT4 file system tools to package the zeroth image file into a first image file in EXT4 format.

4. A firmware upgrade method, characterized in that, The firmware upgrade method is based on the firmware upgrade package determined by the firmware upgrade method of claim 1, and the method is applied to an embedded device. The method includes: When the embedded device starts up, a firmware storage partition is mounted through a preset first mount point. The firmware storage partition includes the compilation artifacts stored in the second image file. Access the compilation artifacts stored in the second image file through the first mount point, and copy the compilation artifacts to the memory file system; The compiled artifacts in the memory file system are mounted through a preset second mount point, and the firmware storage partition is unmounted after the mounting is completed.

5. The method according to claim 4, characterized in that, The first image file includes a zero image file generated by compressing the compilation output using a file system compression tool; Mount the compiled artifacts in the memory file system through a preset second mount point, and unmount the firmware storage partition after mounting, including: Designate a temporary directory as the second mount point; Mount the zeroth image file through the second mount point; The second mount point is switched to the firmware root directory via a system call; After the switch is completed, the mount relationship between the first mount point and the firmware storage partition is unmounted.

6. The method according to claim 4, characterized in that, After mounting is completed and the firmware storage partition is unmounted, the method further includes: In the operating environment based on the memory file system, receive new firmware upgrade packages; The firmware upgrade package is overwritten to the firmware storage partition of the embedded device, and the process jumps to the step of mounting the firmware storage partition through a preset first mount point when the embedded device starts up.

7. The method according to claim 4, characterized in that, The first image file includes a zero image file generated by compressing the compilation output using a file system compression tool; After mounting the compiled artifacts in the memory file system via a preset second mount point, the method further includes: In response to a request to read data from the zeroth image file, the corresponding compressed data block is read from the zeroth image file by the operating system kernel and transparently decompressed. The decompressed data is stored in the system cache for access, and the decompressed data is preferentially reclaimed when the system memory is insufficient.

8. A firmware upgrade device, characterized in that, The device is used in a server, and the device includes: The compilation artifact acquisition unit is used to acquire the compilation artifacts of the firmware source code files; The image file packaging unit is used to specify the size of the first image file as the partition size of the firmware storage partition of the embedded device, and to package the compilation product into the first image file according to the partition size; The actual space occupied acquisition unit is used to acquire the actual space occupied by the first file system that generated the first image file. The firmware upgrade package determination unit is used to determine the reserved space of the second image file based on the actual occupied space, generate the second image file based on the reserved space, encapsulate the second image file to obtain a firmware upgrade package, and upgrade the embedded device through the firmware upgrade package.

9. A firmware upgrade device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the firmware upgrade device to implement the method as described in any one of claims 1-7.

10. A computer program product comprising computer program instructions, characterized in that, When the computer program is run, the method as described in any one of claims 1-7 is performed.

Images