Target software upgrade method and system, computer equipment and readable storage medium

Abstract

The present application provides a target software upgrade method and system, computer equipment, and readable storage medium, including: generating an unordered block mirror file system and a compressed root file system based on the page size and sector size of the storage medium, respectively, and packaging the unordered block mirror file system and the compressed root file system to generate a burnable image and encapsulate it to generate a software update firmware package; mirroring the software update firmware package to a pre- or real-time compiled upgrade service framework, and executing the upgrade service framework to upgrade the target software through the software update firmware package. The present application adopts a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of system files. Encapsulating the unordered block mirror file system and the compressed root file system in one partition can save storage space management overhead, greatly shortening the development cycle and improving robustness.

Description

Technical Field

[0001] The present application relates to the field of vehicle and software technology, and in particular to a target software upgrade method and system, a computer device, and a readable storage medium. Background Art

[0002] Over-the-Air (OTA) upgrade of in-vehicle software refers to the remote updating of the software or firmware on the car through wireless communication technology (such as 4G / 5G, Wi-Fi, etc.), without the need for the owner to go to the dealer or service center for manual upgrade.

[0003] Current in-vehicle software upgrade options are diverse and lack strict, specific standards, resulting in poor upgrade convenience and long software development cycles. Examples include: image transfer based on the lightweight MQTT (Message Queuing Telemetry Transport) protocol; image transfer based on the FTP (File Transfer Protocol); upgrade functionality implemented by directly reading and writing storage media in user mode, requiring the development of different interfaces for different storage media; and image flashing using the dd command. The dd command is a command-line utility for low-level copying and conversion in Unix and Unix-like operating systems (such as Linux). It is commonly used to copy files, convert file formats, and transfer data between devices. Due to its powerful functionality and flexibility, the dd command can also be used for operations such as backing up and restoring disk partitions and creating and restoring disk images.

[0004] Therefore, for in-vehicle software running the Linux operating system, how to choose a reasonable upgrade plan and file system type is an issue that needs to be urgently addressed. Summary of the Invention

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of this application is to provide a target software upgrade method and system, a computer device and a readable storage medium to solve the problems existing in the prior art.

[0006] To achieve the above-mentioned and other related purposes, the present application provides a target software upgrade method, comprising the following steps:

[0007] Determining the page size and sector size of the storage medium according to a data sheet of the storage medium corresponding to the target software; wherein the target software includes vehicle-mounted software;

[0008] Based on the page size and the sector size, respectively generate an unordered block mirror file system and a compressed root file system, and package the unordered block mirror file system and the compressed root file system to generate a burnable image;

[0009] Encapsulating the burnable image according to a pre-designed or real-time designed upgrade rule file to generate a software update firmware package;

[0010] The software update firmware package is mirrored into an upgrade service framework that is compiled in advance or in real time, and the upgrade service framework is executed to upgrade the target software through the software update firmware package.

[0011] In one embodiment of the present application, the process of generating a burnable image includes: generating an unordered block image file system based on the page size and the sector size through a first tool, and generating a compressed root file system through a second tool; and packaging the unordered block image file system and the compressed root file system through an image container writing tool to generate a burnable image.

[0012] In one embodiment of the present application, before packaging the unordered block mirror file system and the compressed root file system through the image container writing tool, the method further includes: calculating the normal operating space of the unordered block mirror file system based on the bad block reserved page, physical block size, page size and total number of bad blocks of the unordered block mirror file system; configuring the volume size of the image container writing tool based on the normal operating space, and packaging the unordered block mirror file system and the compressed root file system through the configured image container writing tool.

[0013] In one embodiment of the present application, the method further includes: dividing at least two partitions according to the total capacity of the storage medium corresponding to the target software, and using one of the partitions as the first partition and the remaining partitions as the second partition;

[0014] After the target software is upgraded through the software update firmware package, the environment variable synchronization tool is called to configure the partition affiliation identifier of the upgraded target software at the next startup, and in the boot loader stage, switching operation between the first partition and the second partition is performed according to the partition to which the unordered block mirror file system should be mounted; wherein the environment variable synchronization tool is used to modify and automatically save environment variables.

[0015] In one embodiment of the present application, according to the partition to be mounted by the unordered block mirror file system, before switching between the first partition and the second partition, the method further includes: in the boot loader stage, using environment variable adjustment commands and environment variable save commands to configure the environment variables in the partition; wherein, the environment variable adjustment command is used to set or modify the value of the environment variable, and the environment variable save command is used to save the modified environment variable; and, configuring the environment variables in the partition through the environment variable synchronization tool under a pre-determined or real-time operating system, wherein the starting position, data length, and erased sector size recorded in the storage medium of the configuration file environment variables of the environment variable synchronization tool are consistent with the boot loader stage configuration; if inconsistent, using the default environment variables without the partition switching flag.

[0016] In one embodiment of the present application, the compilation process of the upgrade service framework includes: compiling dependencies in sequence on a pre-determined or real-time determined operating system environment to generate the upgrade service framework; or, compiling a dependency library under a framework for building an embedded operating system to generate the upgrade service framework.

[0017] In one embodiment of the present application, after generating a software update firmware package, the method further includes: encrypting the software update firmware package so that the software update firmware package is mirrored to a pre- or real-time compiled upgrade service framework and then unpacked through the upgrade service framework; wherein the encryption method includes symmetric encryption.

[0018] The present application also provides a target software upgrade system, the system comprising:

[0019] a data configuration module, configured to determine a page size and a sector size of a storage medium according to a data sheet of a storage medium corresponding to target software; wherein the target software includes vehicle-mounted software;

[0020] a file system packaging module, configured to generate an unordered block mirror file system and a compressed root file system according to the page size and the sector size, and to package the unordered block mirror file system and the compressed root file system to generate a burnable image;

[0021] A software update firmware package module is used to encapsulate the burnable image according to a pre-designed or real-time upgrade rule file to generate a software update firmware package;

[0022] The software upgrade module is used to mirror the software update firmware package to a pre-compiled or real-time compiled upgrade service framework, and execute the upgrade service framework to upgrade the target software through the software update firmware package.

[0023] The present application also provides a computer device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any one of the target software upgrade methods described above.

[0024] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the target software upgrade method described in any one of the above claims.

[0025] As described above, the present application provides a target software upgrade method and system, computer equipment and readable storage medium, which have the following beneficial effects: the present application determines the page size and sector size of the storage medium according to the data manual of the storage medium corresponding to the target software (such as vehicle-mounted software); at the same time, based on the page size and sector size, generates an unordered block mirror file system and a compressed root file system respectively, and packages the unordered block mirror file system and the compressed root file system to generate a burnable image; and according to the upgrade rule file designed in advance or in real time, encapsulates the burnable image to generate a software update firmware package; finally, the software update firmware package is mirrored to the upgrade service framework compiled in advance or in real time, and the upgrade service framework is executed to upgrade the target software through the software update firmware package. It can be seen that the present application adopts a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of the system files. The unordered block mirror file system and the compressed root file system are encapsulated in one partition, which can save the management overhead of storage space, greatly shorten the development cycle and improve robustness, and meet the versatility of platformization. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A schematic diagram of an exemplary system architecture for applying the technical solutions in one or more embodiments of this application;

[0027] Figure 2 A flowchart of a target software upgrade method provided in one embodiment of the present application;

[0028] Figure 3 A schematic diagram of the topology of an unordered block mirror file system provided in one embodiment of the present application;

[0029] Figure 4 A schematic diagram of the hardware structure of a target software upgrade system provided in one embodiment of the present application;

[0030] Figure 5 The figure is a schematic diagram of the hardware structure of a computer device suitable for implementing one or more embodiments of the present application. DETAILED DESCRIPTION

[0031] The following describes the embodiments of the present application through specific examples. Those skilled in the art can easily understand the other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0032] It should be noted that the illustrations provided in this embodiment only illustrate the basic concept of the present application in a schematic manner. Therefore, the illustrations only show components related to the present application and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0033] Figure 1 FIG1 shows a schematic diagram of an exemplary system architecture to which the technical solutions in one or more embodiments of the present application can be applied. Figure 1 As shown, system architecture 100 may include terminal device 110, network 120, and server 130. Terminal device 110 may include various electronic devices such as smartphones, tablet computers, laptop computers, and desktop computers. Server 130 may be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0034] Depending on implementation needs, the system architecture in the embodiments of the present application can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group consisting of multiple server devices. In addition, the technical solutions provided in the embodiments of the present application can be applied to terminal device 110, server 130, or can be implemented by both terminal device 110 and server 130, and this application does not impose any special restrictions on this.

[0035] In one embodiment of the present application, the terminal device 110 or server 130 of the present application can determine the page size and sector size of the storage medium according to the data manual of the storage medium corresponding to the target software; at the same time, based on the page size and sector size, generate an unordered block mirror file system and a compressed root file system respectively, and package the unordered block mirror file system and the compressed root file system to generate a burnable image; and according to a pre-designed or real-time upgrade rule file, encapsulate the burnable image to generate a software update firmware package; finally, mirror the software update firmware package to a pre-compiled or real-time compiled upgrade service framework, and execute the upgrade service framework to upgrade the target software through the software update firmware package. Using the terminal device 110 or server 130 to execute the target software upgrade method, the software upgrade can be performed by combining the unordered block mirror file system and the compressed root file system. The read-only nature of the compressed root file system ensures the security of system files. Encapsulating the unordered block mirror file system and the compressed root file system in a partition can save storage space management overhead, greatly shorten the development cycle and improve robustness, and meet the universality of the platform.

[0036] The above section introduces the contents of an exemplary system architecture applying the technical solution of this application. Next, we will continue to introduce the target software upgrade method of this application.

[0037] Figure 2 FIG. 1 shows a flow chart of a target software upgrade method provided by an embodiment of the present application. Specifically, in an exemplary embodiment, as shown in FIG. Figure 2 As shown, this embodiment provides a target software upgrade method, which includes the following steps:

[0038] S210: Determine the page size and sector size of the storage medium according to the data sheet of the storage medium corresponding to the target software; wherein the target software includes vehicle-mounted software. As an example, the vehicle-mounted software in this embodiment may be software in a multi-function camera.

[0039] S220: Generate an unsorted block image file system and a compressed root file system based on the page size and sector size, respectively, and package the unsorted block image file system and the compressed root file system to generate a burnable image. By way of example, in this embodiment or other embodiments, the unsorted block image file system includes but is not limited to UBIFS (Unsorted Block Image File System), and the compressed root file system includes but is not limited to SquashFS (Squash File System).

[0040] S230, encapsulate the burnable image according to the pre- or real-time designed upgrade rule file to generate a software update firmware package. As an example, in this embodiment or other embodiments, the pre- or real-time designed upgrade rule file may be a sw-description rule file. Among them, sw-description follows the markup syntax rules described in the configuration file library libconfig manual, and users can write the required upgrade rules according to the needs of the project. The core point is to design the partition location where the firmware image is installed, such as device=" / dev / mtd7"; the name of the firmware to be upgraded, such as filename="rootfsA.ext4". Use the file archiving command cpio to generate the software update firmware package required for the upgrade.

[0041] S240, mirroring the software update firmware package to the pre- or real-time compiled upgrade service framework, and executing the upgrade service framework to upgrade the target software through the software update firmware package. As an example, in this embodiment or other embodiments, the upgrade service framework includes but is not limited to the swupdate framework. The upgrade solution of this embodiment adopts the swupdate protocol and framework, which can be applied to various occasions of embedded control systems, not only in smart driving, smart home, smart industry, smart agriculture, etc.; it is also applicable to various storage media, such as eMMC (Embedded Multi Media Card, abbreviated as eMMC), NAND Flash, NOR Flash, etc.

[0042] It can be seen from this that this embodiment uses a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of system files. Encapsulating the unordered block mirror file system and the compressed root file system in one partition can save storage space management overhead, greatly shorten the development cycle and improve robustness, and meet the platform's versatility.

[0043] In one exemplary embodiment, the process of generating a burnable image includes: generating an unsorted block image file system based on page size and sector size using a first tool, and generating a compressed root file system using a second tool; and packaging the unsorted block image file system and the compressed root file system using an image container writing tool to generate a burnable image. In this or other embodiments, the first tool includes, but is not limited to, a tool for creating a file system image containing only file system-related content, such as the mkfs.ubifs tool; the second tool includes, but is not limited to, a command tool for creating a SquashFS file system image, such as the mksquashfs tool; and the image container writing tool includes, but is not limited to, the ubinize tool. As an example, in this embodiment, UBIFS is a file system built on UBI (Unsorted Block Image). Therefore, the root file system image created using mkfs.ubifs cannot be directly used for burning using the nand write command in the boot loader or u-boot stages. Therefore, burning requires creating a UBI volume in the corresponding partition of the root file system using UBI commands in the boot loader or u-boot stages, which is a relatively cumbersome method. Therefore, this embodiment uses the ubinize command to pre-process the root file system image created by mkfs.ubifs. First, the mkfs.ubifs and mksquashfs tools are used to create the UBIFS and SquashFS file systems, respectively. Then, the ubinize tool is used to package the UBIFS and SquashFS file systems into a single, burnable image. This embodiment combines UBIFS and SquashFS into a single, burnable image. The read-only nature of SquashFS ensures the security of system files. The design of UBIFS and SquashFS in a single partition reduces storage space management overhead, particularly for cost-effective, low-capacity storage media.

[0044] In one exemplary embodiment, before packaging the unordered block mirror file system and the compressed root file system using an image container writing tool, the process also includes: calculating the normal operating space of the unordered block mirror file system based on the bad block reserved pages, physical block size, page size, and total number of bad blocks of the unordered block mirror file system; configuring the volume size of the image container writing tool based on the normal operating space; and packaging the unordered block mirror file system and the compressed root file system using the configured image container writing tool. As an example, in this embodiment or other embodiments, stable operation of UBIFS requires reasonable calculation of its management overhead and reservation of sufficient bad block handling pages. UBIFS management overhead = (bad block reserved pages + 4) * physical block size + 2 * page size * (total number of bad blocks - bad block reserved pages - 4). Bad block reserved pages are typically reserved for every 1024 pages, and 20 bad block handling pages are reserved. Therefore, in this embodiment, it is necessary to first ensure the necessary space for these two parts, and then reasonably design the volume size available to users in the ubinize tool configuration file.

[0045] In an exemplary embodiment, this embodiment may further include: dividing at least two partitions according to the total capacity of the storage medium corresponding to the target software, and using one of the partitions as the first partition and the remaining partitions as the second partition; after upgrading the target software through the software update firmware package, calling the environment variable synchronization tool to configure the partition affiliation identifier of the upgraded target software at the next startup, and switching between the first partition and the second partition according to the partition to be mounted by the unordered block mirror file system during the boot loader phase; wherein the environment variable synchronization tool is used to modify and automatically save environment variables. It can be seen from this that this embodiment divides at least two partitions according to the total capacity of the corresponding storage medium. Even if errors such as network instability and abnormal power outages occur, the stable operation of the target software can be guaranteed by supporting partition switching, thereby having higher fault tolerance.

[0046] In an exemplary embodiment, based on the partition to be mounted by the unordered block mirror file system, before switching between the first partition and the second partition, this embodiment may further include: configuring the environment variables in the partition using an environment variable adjustment command and an environment variable save command during the boot loader phase; wherein the environment variable adjustment command is used to set or modify the value of the environment variable, and the environment variable save command is used to save the modified environment variable; and configuring the environment variables in the partition using an environment variable synchronization tool under a pre-determined or real-time operating system, wherein the starting position, data length, and erased sector size of the environment variables in the configuration file of the environment variable synchronization tool recorded in the storage medium are consistent with the configuration during the boot loader phase; if inconsistent, using default environment variables without a partition switching flag. In this embodiment or other embodiments, the dual partition switching startup function is implemented based on environment variables, wherein the reading, writing, and saving of environment variables are divided into two different stages; first, during the boot loader phase or u-boot phase, the setenv command can be used as the environment variable adjustment command and the saveenv command can be used as the environment variable save command for configuration. Second, under pre-determined or real-time Linux systems, the fw_setenv tool can be used as an environment variable synchronization tool for configuration. The starting position, data length, and erased sector size of the environment variables in the fw_env tool's configuration file must be consistent with the configuration in the u-boot phase. Otherwise, the default environment variables without the partition switch flag will be used. After upgrading the target software via the software update firmware package, the fw_setenv tool can be called to configure the partition identifier to be booted next time. When the upgraded target software is restarted, the boot loader or u-boot phase will determine the partition where the root file system should be mounted and then switch to the corresponding partition for boot.

[0047] In one exemplary embodiment, the compilation process of the upgrade service framework includes: sequentially compiling dependencies within a pre-determined or real-time operating system environment to generate the upgrade service framework; or compiling dependency libraries within a framework for building an embedded operating system to generate the upgrade service framework. By way of example, in this or other embodiments, the pre-determined or real-time operating system includes, but is not limited to, the Linux system. As can be seen, this embodiment does not require development from scratch; options can be configured as needed and cross-compiled for immediate use, thereby saving labor costs.

[0048] In one exemplary embodiment, after generating the software update firmware package, this embodiment may further include: encrypting the software update firmware package so that after mirroring the software update firmware package to a pre- or real-time-compiled upgrade service framework, the upgrade service framework can then unpack it; wherein the encryption method includes symmetric encryption. Therefore, in terms of security, this embodiment supports symmetric encryption by configuring ENCRYPTED_IMAGES in the options. When swupdate unpacks the upgrade package, the -k parameter is used to point to the symmetric encrypted file for verification. Therefore, this embodiment supports encryption during target software upgrades, providing a high level of security.

[0049] According to the above records, UBIFS is a file system built on UBI, so the storage medium of UBI in any of the above embodiments can be based on MTD (Memory Technology Device, abbreviated as MTD) block device. The corresponding topology structure is shown in the figure below. Figure 3 As shown. Figure 3 In the example, MTD represents the memory technology device, ubi volume 0 and ubi volume 1 represent the two ubi volumes, block device represents the block type device, ubi block device represents the block type device of ubi, FileSystem represents the file system, ubifs represents the unordered block mirror file system, and squash_rootfs represents the compressed root file system. Regarding file system selection: Common file system types include Ext4, XFS, UBIFS, and SquashFS. UBIFS offers large capacity, fast I / O, millisecond-level mount speeds, online compression, loss balancing, and bad block management, making it suitable for the aforementioned conveniences provided by ubi.

[0050] In summary, the present application provides a target software upgrade method, which can determine the page size and sector size of the storage medium according to the data manual of the storage medium corresponding to the target software (such as vehicle-mounted software); at the same time, based on the page size and sector size, respectively generate an unordered block mirror file system and a compressed root file system, and package the unordered block mirror file system and the compressed root file system to generate a burnable image; and according to the upgrade rule file designed in advance or in real time, encapsulate the burnable image to generate a software update firmware package; finally, the software update firmware package is mirrored to the upgrade service framework compiled in advance or in real time, and the upgrade service framework is executed to upgrade the target software through the software update firmware package. It can be seen that the present method adopts a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of system files. Encapsulating the unordered block mirror file system and the compressed root file system in one partition can save the management overhead of storage space, greatly shorten the development cycle and improve robustness, and meet the versatility of platformization. Because the compressed root file system (SquashFS) is read-only, this method utilizes a UBIFS+SquashFS approach. The root file system and user operating space are managed using a UBI volume, dividing the two storage spaces into a single partition. Compared to isolating the two storage spaces into two partitions, this reduces partition disk management overhead while ensuring read-only security for the root file system. Furthermore, the user-writable space uses UBIFS, meeting application requirements. This upgrade solution utilizes the swupdate protocol and framework and can be applied to various embedded applications, including smart driving, smart home, smart industry, and smart agriculture. It is also compatible with various storage media, such as eMMC, NAND Flash, and NOR Flash. For security, symmetric encryption is enabled by configuring ENCRYPTED_IMAGES in the options. When swupdate unpacks the upgrade package, the -k parameter points to the symmetric encrypted file for verification. To address the stability requirements of the automotive industry, a dual-partition upgrade solution is designed to ensure a functioning partition system in the event of network instability or power outages.

[0051] In another exemplary embodiment of the present application, Figure 4 As shown, this embodiment also provides a target software upgrade system, including:

[0052] The data configuration module 410 is configured to determine the page size and sector size of the storage medium according to the data sheet of the target software corresponding to the storage medium. The target software includes vehicle-mounted software. As an example, the vehicle-mounted software in this embodiment may be software in a multi-function camera.

[0053] The file system packaging module 420 is configured to generate an unsorted block image file system and a compressed root file system based on the page size and sector size, respectively, and to package the unsorted block image file system and the compressed root file system to generate a burnable image. By way of example, in this or other embodiments, the unsorted block image file system includes, but is not limited to, UBIFS (Unsorted Block Image File System), and the compressed root file system includes, but is not limited to, SquashFS (Squash File System).

[0054] The software update firmware package module 430 is used to encapsulate the burnable image according to the upgrade rule file designed in advance or in real time, and generate a software update firmware package. As an example, in this embodiment or other embodiments, the upgrade rule file designed in advance or in real time can be a sw-description rule file. Among them, sw-description follows the markup syntax rules described in the configuration file library libconfig manual, and users can write the required upgrade rules according to the needs of the project. The core point is to design the partition location where the firmware image is installed, such as device=" / dev / mtd7"; the name of the firmware to be upgraded, such as filename="rootfsA.ext4". Use the file archiving command cpio to generate the software update firmware package required for the upgrade.

[0055] The software upgrade module 440 is used to mirror the software update firmware package to the pre-compiled or real-time compiled upgrade service framework, and execute the upgrade service framework to upgrade the target software through the software update firmware package. As an example, in this embodiment or other embodiments, the upgrade service framework includes but is not limited to the swupdate framework. The upgrade solution of this embodiment adopts the swupdate protocol and framework, which can be applied to various occasions of embedded control systems, not only in smart driving, smart home, smart industry, smart agriculture, etc.; it is also applicable to various storage media, such as eMMC (Embedded Multi Media Card, abbreviated as eMMC), NAND Flash, NOR Flash, etc.

[0056] It can be seen from this that this embodiment uses a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of system files. Encapsulating the unordered block mirror file system and the compressed root file system in one partition can save storage space management overhead, greatly shorten the development cycle and improve robustness, and meet the platform's versatility.

[0057] In one exemplary embodiment, the process of generating a burnable image includes: generating an unsorted block image file system based on page size and sector size using a first tool, and generating a compressed root file system using a second tool; and packaging the unsorted block image file system and the compressed root file system using an image container writing tool to generate a burnable image. In this or other embodiments, the first tool includes, but is not limited to, a tool for creating a file system image containing only file system-related content, such as the mkfs.ubifs tool; the second tool includes, but is not limited to, a command tool for creating a SquashFS file system image, such as the mksquashfs tool; and the image container writing tool includes, but is not limited to, the ubinize tool. As an example, in this embodiment, UBIFS is a file system built on UBI (Unsorted Block Image). Therefore, the root file system image created using mkfs.ubifs cannot be directly used for burning using the nand write command in the boot loader or u-boot stages. Therefore, burning requires creating a UBI volume in the corresponding partition of the root file system using UBI commands in the boot loader or u-boot stages, which is a relatively cumbersome method. Therefore, this embodiment uses the ubinize command to pre-process the root file system image created by mkfs.ubifs. First, the mkfs.ubifs and mksquashfs tools are used to create the UBIFS and SquashFS file systems, respectively. Then, the ubinize tool is used to package the UBIFS and SquashFS file systems into a single, burnable image. This embodiment combines UBIFS and SquashFS into a single, burnable image. The read-only nature of SquashFS ensures the security of system files. The design of UBIFS and SquashFS in a single partition reduces storage space management overhead, particularly for cost-effective, low-capacity storage media.

[0058] In one exemplary embodiment, before packaging the unordered block mirror file system and the compressed root file system using an image container writing tool, the process also includes: calculating the normal operating space of the unordered block mirror file system based on the bad block reserved pages, physical block size, page size, and total number of bad blocks of the unordered block mirror file system; configuring the volume size of the image container writing tool based on the normal operating space; and packaging the unordered block mirror file system and the compressed root file system using the configured image container writing tool. As an example, in this embodiment or other embodiments, stable operation of UBIFS requires reasonable calculation of its management overhead and reservation of sufficient bad block handling pages. UBIFS management overhead = (bad block reserved pages + 4) * physical block size + 2 * page size * (total number of bad blocks - bad block reserved pages - 4). Bad block reserved pages are typically reserved for every 1024 pages, and 20 bad block handling pages are reserved. Therefore, in this embodiment, it is necessary to first ensure the necessary space for these two parts, and then reasonably design the volume size available to users in the ubinize tool configuration file.

[0059] In an exemplary embodiment, this embodiment may further include: dividing at least two partitions according to the total capacity of the storage medium corresponding to the target software, and using one of the partitions as the first partition and the remaining partitions as the second partition; after upgrading the target software through the software update firmware package, calling the environment variable synchronization tool to configure the partition affiliation identifier of the upgraded target software at the next startup, and switching between the first partition and the second partition according to the partition to be mounted by the unordered block mirror file system during the boot loader phase; wherein the environment variable synchronization tool is used to modify and automatically save environment variables. It can be seen from this that this embodiment divides at least two partitions according to the total capacity of the corresponding storage medium. Even if errors such as network instability and abnormal power outages occur, the stable operation of the target software can be guaranteed by supporting partition switching, thereby having higher fault tolerance.

[0060] In an exemplary embodiment, based on the partition to be mounted by the unordered block mirror file system, before switching between the first partition and the second partition, this embodiment may further include: configuring the environment variables in the partition using an environment variable adjustment command and an environment variable save command during the boot loader phase; wherein the environment variable adjustment command is used to set or modify the value of the environment variable, and the environment variable save command is used to save the modified environment variable; and configuring the environment variables in the partition using an environment variable synchronization tool under a pre-determined or real-time operating system, wherein the starting position, data length, and erased sector size of the environment variables in the configuration file of the environment variable synchronization tool recorded in the storage medium are consistent with the configuration during the boot loader phase; if inconsistent, using default environment variables without a partition switching flag. In this embodiment or other embodiments, the dual partition switching startup function is implemented based on environment variables, wherein the reading, writing, and saving of environment variables are divided into two different stages; first, during the boot loader phase or u-boot phase, the setenv command can be used as the environment variable adjustment command and the saveenv command can be used as the environment variable save command for configuration. Second, under pre-determined or real-time Linux systems, the fw_setenv tool can be used as an environment variable synchronization tool for configuration. The starting position, data length, and erased sector size of the environment variables in the fw_env tool's configuration file must be consistent with those configured during the u-boot phase. Otherwise, the default environment variables without the partition switch flag will be used. After upgrading the target software via the software update firmware package, the fw_setenv tool can be called to configure the partition identifier for the next boot. When the upgraded target software is restarted, the boot loader or u-boot phase will determine the partition where the root file system should be mounted and then switch to the corresponding partition for boot.

[0061] In one exemplary embodiment, the compilation process of the upgrade service framework includes: sequentially compiling dependencies within a pre-determined or real-time operating system environment to generate the upgrade service framework; or compiling dependency libraries within a framework for building an embedded operating system to generate the upgrade service framework. By way of example, in this or other embodiments, the pre-determined or real-time operating system includes, but is not limited to, the Linux system. As can be seen, this embodiment does not require development from scratch; options can be configured as needed and cross-compiled for immediate use, thereby saving labor costs.

[0062] In one exemplary embodiment, after generating the software update firmware package, this embodiment may further include: encrypting the software update firmware package so that after mirroring the software update firmware package to a pre- or real-time-compiled upgrade service framework, the upgrade service framework can then unpack it; wherein the encryption method includes symmetric encryption. Therefore, in terms of security, this embodiment supports symmetric encryption by configuring ENCRYPTED_IMAGES in the options. When swupdate unpacks the upgrade package, the -k parameter is used to point to the symmetric encrypted file for verification. Therefore, this embodiment supports encryption during target software upgrades, providing a high level of security.

[0063] According to the above records, UBIFS is a file system built on UBI, so the storage medium of UBI in any of the above embodiments can be based on MTD (Memory Technology Device, abbreviated as MTD) block device. The corresponding topology structure is shown in the figure below. Figure 3 As shown. Figure 3 In the example, MTD represents the memory technology device, ubi volume 0 and ubi volume 1 represent the two ubi volumes, block device represents the block type device, ubi block device represents the block type device of ubi, FileSystem represents the file system, ubifs represents the unordered block mirror file system, and squash_rootfs represents the compressed root file system. Regarding file system selection: Common file system types include Ext4, XFS, UBIFS, and SquashFS. UBIFS offers large capacity, fast I / O, millisecond-level mount speeds, online compression, loss balancing, and bad block management, making it suitable for the aforementioned conveniences provided by ubi.

[0064] In summary, the present application provides a target software upgrade system, which can determine the page size and sector size of the storage medium according to the data manual of the storage medium corresponding to the target software (such as vehicle-mounted software); at the same time, based on the page size and sector size, generate an unordered block mirror file system and a compressed root file system respectively, and package the unordered block mirror file system and the compressed root file system to generate a burnable image; and according to the upgrade rule file designed in advance or in real time, encapsulate the burnable image to generate a software update firmware package; finally, the software update firmware package is mirrored to the upgrade service framework compiled in advance or in real time, and the upgrade service framework is executed to upgrade the target software through the software update firmware package. It can be seen that the system adopts a combination of an unordered block mirror file system and a compressed root file system to perform software upgrades. The read-only nature of the compressed root file system ensures the security of the system files. Encapsulating the unordered block mirror file system and the compressed root file system in one partition can save the management overhead of storage space, greatly shorten the development cycle and improve robustness, and meet the versatility of platformization. Because the compressed root file system (SquashFS) is read-only, this system uses a UBIFS+SquashFS approach. The root file system and user operating space are managed using a UBI volume, dividing the two storage spaces into a single partition. Compared to isolating the two storage spaces into two partitions, this reduces partition disk management overhead while ensuring read-only security for the root file system. Furthermore, the user-writable space uses UBIFS, meeting application requirements. The upgrade solution utilizes the swupdate protocol and framework and can be applied to various embedded applications, including smart driving, smart home, smart industry, and smart agriculture. It is also compatible with various storage media, such as eMMC, NAND Flash, and NOR Flash. For security, symmetric encryption can be enabled by configuring ENCRYPTED_IMAGES in the options. When swupdate unpacks the upgrade package, the -k parameter points to the symmetric encrypted file for verification. To meet the stability requirements of the automotive industry, a dual-partition upgrade solution is designed to ensure a functioning partition system in the event of network instability or power outages.

[0065] It should be noted that the target software upgrade system provided in the above-mentioned embodiment and the target software upgrade method provided in the above-mentioned embodiment are based on the same concept. The specific manner in which the target software upgrade method performs operations has been described in detail in the above-mentioned method embodiment and will not be repeated here. In actual applications, the target software upgrade system provided in the above-mentioned embodiment can, as needed, allocate the above-mentioned functions to different functional modules. That is, the internal structure of the target software upgrade system can be divided into different functional modules, and then all or part of the functions of the corresponding functional modules can be implemented through the target software upgrade method described in the above-mentioned embodiment. This is not specifically limited here.

[0066] The embodiment of the present application further provides a computer device, which may include a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program so that the computer device executes Figure 2 The steps of the target software upgrade method. Figure 5 FIG1 shows a schematic diagram of the structure of a computer device 1000. Figure 5 As shown, the computer device 1000 includes: a processor 1010 , a memory 1020 , a power supply 1030 , a display unit 1040 , and an input unit 1060 .

[0067] The processor 1010 is the control center of the computer device 1000. It connects various components using various interfaces and lines, and performs various functions of the computer device 1000 by running or executing computer programs / instructions stored in the memory 1020, thereby monitoring the computer device 1000 as a whole. In the embodiment of the present application, when the processor 1010 calls the computer program stored in the memory 1020, it executes the following Figure 2 The steps of the target software upgrade method are as follows. Optionally, the processor 1010 may include one or more processing units; preferably, the processor 1010 may integrate an application processor and a modem processor, wherein the application processor primarily processes the operating system, user interface, and applications, and the modem processor primarily processes wireless communications. In some embodiments, the processor and memory may be implemented on a single chip; in some embodiments, they may also be implemented on separate chips.

[0068] The memory 1020 may primarily include a program storage area and a data storage area. The program storage area may store an operating system, various applications, and the like; the data storage area may store instruction data and the like generated based on the use of the computer device 1000. Furthermore, the memory 1020 may include a high-speed random access memory and a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device.

[0069] The computer device 1000 also includes a power supply 1030 (such as a battery) for supplying power to various components. The power supply can be logically connected to the processor 1010 through a power management system, thereby managing functions such as charging, discharging, and power consumption through the power management system.

[0070] The display unit 1040 can be used to display information input by the user or information provided to the user, as well as various menus of the computer device 1000. In the embodiment of the present application, it is mainly used to display the display interface of each application in the computer device 1000 and objects such as text and pictures displayed on the display interface. The display unit 1040 may include a display panel 1050. The display panel 1050 can be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc.

[0071] The input unit 1060 can be used to receive information such as numbers or characters input by the user. The input unit 1060 may include a touch panel 1070 and other input devices 1080. The touch panel 1070, also known as a touch screen, can receive user touch operations on or near it (for example, operations performed by the user using a finger, a stylus, or any other suitable object or accessory on or near the touch panel 1070).

[0072] Specifically, the touch panel 1070 can detect user touch operations and the signals generated by the touch operations, convert these signals into touch point coordinates, and send them to the processor 1010. It can also receive and execute commands sent by the processor 1010. In addition, the touch panel 1070 can be implemented using various types, such as resistive, capacitive, infrared, and surface acoustic wave. Other input devices 1080 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, a joystick, and the like.

[0073] Of course, the touch panel 1070 can cover the display panel 1050. When the touch panel 1070 detects a touch operation on or near it, it transmits it to the processor 1010 to determine the type of touch event. Then the processor 1010 provides corresponding visual output on the display panel 1050 according to the type of touch event. Figure 5 In the embodiment, the touch panel 1070 and the display panel 1050 are two independent components to realize the input and output functions of the computer device 1000, but in some embodiments, the touch panel 1070 and the display panel 1050 can be integrated to realize the input and output functions of the computer device 1000.

[0074] The computer device 1000 may further include one or more sensors, such as a pressure sensor, a gravity acceleration sensor, a proximity light sensor, etc. Of course, according to the needs of specific applications, the computer device 1000 may also include other components such as a camera.

[0075] The embodiment of the present application further provides a computer-readable storage medium, in which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, the above-mentioned device can perform the above-mentioned Figure 2 The steps of the target software upgrade method.

[0076] It will be understood by those skilled in the art that Figure 5 This is merely an example of a computer device and does not constitute a limitation of the device. The device may include more or fewer components than shown, or a combination of certain components, or different components. For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0077] Those skilled in the art should understand that the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be applied to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the functions in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including the instruction device, which implements the function specified in the process. Figure 1 a process or multiple processes and / or boxes Figure 1These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0078] It should be understood that although the terms "first" and "second" may be used to describe partitions in the embodiments of the present application, these terms are only used to distinguish partitions from each other. For example, without departing from the scope of the embodiments of the present application, the first partition may also be referred to as the second partition, and similarly, the second partition may also be referred to as the first partition.

[0079] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical concepts disclosed in this application shall be covered by the claims of this application.

Claims

1. A target software upgrade method, characterized in that: The method comprises the following steps: Determining the page size and sector size of the storage medium according to a data sheet of the storage medium corresponding to the target software; wherein the target software includes vehicle-mounted software; Based on the page size and the sector size, an unordered block mirror file system and a compressed root file system are respectively generated, and a normal operating space of the unordered block mirror file system is calculated according to the bad block reserved page, physical block size, page size, and total number of bad blocks of the unordered block mirror file system; and based on the normal operating space, a volume size is configured for an image container writing tool, and the configured image container writing tool is used to package the unordered block mirror file system and the compressed root file system to generate a burnable image; Encapsulating the burnable image according to a pre-designed or real-time designed upgrade rule file to generate a software update firmware package; The software update firmware package is mirrored into an upgrade service framework that is compiled in advance or in real time, and the upgrade service framework is executed to upgrade the target software through the software update firmware package.

2. The target software upgrade method according to claim 1, characterized in that: The process of generating a burnable image can also include: A disordered block image file system is generated by a first tool, and a compressed root file system is generated by a second tool.

3. The target software upgrade method according to claim 1 or 2, characterized in that: The method further comprises: Divide the target software into at least two partitions according to the total capacity of the storage medium, and use one of the partitions as the first partition and the remaining partition as the second partition; After the target software is upgraded through the software update firmware package, the environment variable synchronization tool is called to configure the partition affiliation identifier of the upgraded target software at the next startup, and in the boot loader stage, switching operation between the first partition and the second partition is performed according to the partition to which the unordered block mirror file system should be mounted; wherein the environment variable synchronization tool is used to modify and automatically save environment variables.

4. The target software upgrade method according to claim 3, characterized in that: According to the partition to which the unordered block mirror file system should be mounted, before switching between the first partition and the second partition, the method further includes: During the boot loader phase, the environment variables in the partition are configured using an environment variable adjustment command and an environment variable save command; wherein the environment variable adjustment command is used to set or modify the value of the environment variable, and the environment variable save command is used to save the modified environment variable; and The environment variables in the partition are configured by the environment variable synchronization tool under a pre-determined or real-time determined operating system, wherein the starting position, data length, and erased sector size of the configuration file environment variables of the environment variable synchronization tool recorded in the storage medium are consistent with the boot loader stage configuration; if they are inconsistent, the default environment variables without the partition switching flag are used.

5. The target software upgrade method according to claim 1 or 4, characterized in that: The compilation process of the upgrade service framework includes: compiling dependencies in sequence on a pre-determined or real-time determined operating system environment to generate the upgrade service framework; or compiling dependency libraries under a framework for building an embedded operating system to generate the upgrade service framework.

6. The target software upgrade method according to claim 1, characterized in that: After generating the software update firmware package, the method further includes: encrypting the software update firmware package so that the software update firmware package is mirrored to a pre- or real-time compiled upgrade service framework and then unpacked through the upgrade service framework; wherein the encryption method includes symmetric encryption.

7. A target software upgrade system, characterized in that: The system includes: a data configuration module, configured to determine a page size and a sector size of a storage medium according to a data sheet of a storage medium corresponding to target software; wherein the target software includes vehicle-mounted software; a file system packaging module, configured to generate an unordered block mirror file system and a compressed root file system according to the page size and the sector size, respectively, and calculate a normal operating space of the unordered block mirror file system according to the bad block reserved page, physical block size, page size, and total number of bad blocks of the unordered block mirror file system; and configure a volume size for an image container writing tool based on the normal operating space, and package the unordered block mirror file system and the compressed root file system with the configured image container writing tool to generate a burnable image; A software update firmware package module is used to encapsulate the burnable image according to a pre-designed or real-time upgrade rule file to generate a software update firmware package; The software upgrade module is used to mirror the software update firmware package to a pre-compiled or real-time compiled upgrade service framework, and execute the upgrade service framework to upgrade the target software through the software update firmware package.

8. A computer device, characterized in that: The system comprises a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the target software upgrade method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the steps of the target software upgrade method described in any one of claims 1 to 6 are implemented.

Images