Equipment upgrading method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention relates to the technical field of embedded linux, and discloses a device upgrading method, an electronic device, a storage medium and a program product. The method comprises the following steps: starting a boot loader; reading the target index value from a plurality of partition files of factory configuration of the equipment; one partition file only contains one index value; obtaining a target DTB file according to the target index value; and reading the target DTB file, loading data in the target DTB file into a device memory, and starting a system kernel. According to the method and the device, the target DTB file is directionally searched through the target index value after the boot loader is started, the DTB file is loaded into the memory to start the kernel, and the upgrading of the DTB compatible with multiple hardware versions is realized through software, so that the same firmware is compatible with different hardware versions, version upgrading does not need to be performed by relying on physical hardware resources, and the upgrading efficiency is improved. Different hardware platforms are compatible, and the flexibility of version upgrading is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of embedded Linux technology, and in particular to a device upgrade method, electronic device, storage medium and program product. Background Art

[0002] Embedded Linux systems are widely used in hardware products. In Linux systems, the layout and configuration of hardware devices in embedded systems are described by the device tree (DeviceTree). The device tree is a data structure, usually stored in binary format, namely Device Tree Blob, DTB. Embedded Linux products store a hardware version and a Linux kernel software version in the firmware. Since products need to be updated iteratively, the same product will have multiple hardware versions, which will also correspond to multiple Linux kernel software versions.

[0003] However, the inventors have found that in the current technology, for products with multiple software versions, they are all updated through hardware reading, there is a lack of compatible software upgrade methods, it is not easy to manage software versions, and the flexibility of device upgrades is low. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a device upgrade method, electronic device, storage medium and program product, which can perform compatible upgrade and version management on multiple DTB devices through software, thereby improving the flexibility of device upgrade.

[0005] To solve the above technical problems, an embodiment of the present invention provides a device upgrade method, including: starting a boot loader; reading a target index value from multiple partition files of the device's factory configuration; one of the partition files contains only one index value; obtaining a target DTB file according to the target index value; reading the target DTB file, loading the data in the target DTB file into the device memory, and starting the system kernel.

[0006] An embodiment of the present invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the steps in the above-mentioned device upgrade method.

[0007] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the steps in the above-mentioned device upgrading method when executed by a processor.

[0008] An embodiment of the present invention further provides a computer program product, including computer instructions, which implement the steps in the above-mentioned device upgrading method when executed by a processor.

[0009] In an embodiment of the present invention, after the boot loader is started, the target DTB file is directionally found through the target index value, and the DTB file is loaded into the memory to start the kernel. The upgrade of DTB compatible with multiple hardware versions is implemented through software, so that the same firmware is compatible with different hardware versions, and there is no need to rely on physical hardware resources for version upgrade, so that it is compatible with different hardware platforms, and the flexibility of version upgrade is improved; and in the process of updating and upgrading through software, a partition file only contains one index value, and different index values ​​are stored through hardware physical partitions, so that an independent index value is established for each partition, reducing the complexity of the hardware partition index and improving the efficiency of the index; in addition, because it implements the upgrade compatible with multiple DTBs through software, in subsequent upgrades and modifications, it can be directly updated and upgraded over the air through software, thereby improving the versatility of a firmware, reducing the number of times the firmware version needs to be released, and saving the cost of update and maintenance.

[0010] In addition, the boot loader includes a search logic for a target index value, and the search logic is used to search for the target index value; the reading of the target index value from multiple partition files configured at the factory of the device includes: searching for the target index value in the multiple partition files by the search logic until the target index value is found and the target partition where the target index value is located is determined. The embodiment of the present application adds a search logic for the target index value in the boot loader, so that the target DTB file can be searched according to the target index value, thereby realizing the determination of the target DTB file by software in the boot process while being compatible with multiple DTBs.

[0011] In addition, before the boot loader is started, multiple versions of DTB files are packaged together with the system kernel image file to generate a compressed image set; the target DTB file is obtained according to the target index value, including: according to the target index value, obtaining the target DTB file corresponding to the target index value in the compressed image set. The implementation method of the present application packages multiple DTB files with the kernel image file, which is beneficial to reducing the occupancy of storage space while improving the speed of searching for DTB files and the rate of loading DTB files and the kernel during the process of starting the device, thereby improving the startup speed of the device.

[0012] In addition, one DTB file corresponds to one index value; the packaging of multiple versions of DTB files together with the system kernel to generate a compressed image set includes: calling a first packaging tool to package the multiple versions of DTB files to generate a DTB image file; calling a second tool to merge the system kernel image file and the DTB image file to generate the compressed image set.

[0013] In addition, if the target index value cannot be read in the target partition file, the default DTB data is loaded into the memory and the system kernel is started. The implementation method of the present application avoids the situation where the system cannot be loaded and started normally due to the lack of the target index value by loading the default DTB data into the memory when the target index value cannot be read.

[0014] In addition, if the target DTB file cannot be obtained in the boot image set, the default DTB data is loaded into the memory and the system kernel is started. The implementation method of the present application avoids the situation where the system cannot be loaded and started normally due to the failure to find the target DTB file by loading the default DTB data into the memory when the target DTB file cannot be read.

[0015] In addition, the target index value is located in the hardware information description file of the factory configuration file. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0017] Figure 1 This is a flow chart of a device upgrading method provided in one embodiment of the present application;

[0018] Figure 2 It is a schematic diagram of the packaging content of the boot image set provided in one implementation mode of the present application;

[0019] Figure 3 This is a schematic diagram of the corresponding relationship between hardware and index values ​​provided in one implementation mode of the present application;

[0020] Figure 4 This is another flow chart of a device upgrading method provided in one embodiment of the present application;

[0021] Figure 5 It is a structural schematic diagram of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0022] Usually, for Linux system devices, there is at least one DTB file in the firmware so that the device can work normally on the current hardware. When a firmware needs to be compatible with multiple different hardware, it is necessary to package multiple DTBs and search, select, and use the correct DTB file during the device startup phase. The current solution is that different hardware versions need to set different ADC sampling resistance values, and different voltage values ​​are read by the ADC after power-on to determine the final DTB file to be used, which wastes certain hardware resources, and cannot be upgraded over the air (Over-The-Air, OTA) or modified for shipped devices. However, updating through hardware reading lacks a method compatible with software upgrades, and it is not easy to manage software versions. The flexibility of device upgrades is low. Therefore, a device upgrade method, electronic device, storage medium, and program product are needed, which can perform compatible upgrades and version management for multiple DTB devices through software to improve the flexibility of device upgrades.

[0023] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0024] An embodiment of the present invention relates to a device upgrade method, which can be applied to hardware devices of embedded Linux systems, and realizes that different hardware uses the DTB index value in the factory configuration file partition to select and load the corresponding DTB file by software compatibility with multiple DTBs. The method includes: starting the boot loader; reading the target index value from multiple partition files of the factory configuration of the device; one of the partition files contains only one index value; obtaining the target DTB file according to the target index value; reading the target DTB file, loading the data in the target DTB file into the device memory, and starting the system kernel. After the boot loader is started, the target DTB file is searched for by the target index value in a targeted manner, and the DTB file is loaded into the memory to start the kernel. The upgrade of compatible DTB of multiple hardware versions is realized by software, so that the same firmware is compatible with different hardware versions, and there is no need to rely on physical hardware resources for version upgrade, so that it is compatible with different hardware platforms, and the flexibility of version upgrade is improved; and in the process of updating and upgrading by software, a partition file only contains one index value, and different index values ​​are stored by hardware physical partitions, so that an independent index value is established for each partition, reducing the complexity of the hardware partition index and improving the efficiency of the index; in addition, because it realizes the upgrade of compatible multiple DTBs by software, in subsequent upgrades and modifications, it can directly realize the upgrade of air updates by software, thereby improving the versatility of a firmware, reducing the number of times the firmware version needs to be released, and saving the cost of update and maintenance. The following is a specific description of the implementation details of a device upgrade method of an embodiment of the present invention. The following content is only the implementation details provided for the convenience of understanding, and is not necessary for the implementation of this solution.

[0025] This application packages and compresses multiple DTB files with index value identifiers into the same firmware package in advance, and adds different DTB index value identifiers in the partition file. Different hardware burns the corresponding partition files into the device during the production stage. After starting the boot loader, the currently required DTB file is selected for system startup according to the target index value in the partition file.

[0026] like Figure 1 As shown, in step 101, the boot loader is started.

[0027] In some embodiments of the present application, before the boot loader is started, multiple versions of DTB files are packaged together with the system kernel image file to generate a compressed image set; the target DTB file is obtained according to the target index value, including: according to the target index value, obtaining the target DTB file corresponding to the target index value in the compressed image set. The embodiments of the present application are beneficial to reducing the occupancy of storage space while improving the search speed of DTB files and the rate of loading DTB files and kernels in the process of starting the device, thereby improving the startup speed of the device. Specifically, the boot loader is a Uboot program. It should be noted that those skilled in the art can understand that the specific program for boot loading can be adjusted according to actual production needs, and it is only necessary to enable the search for the target index value to be triggered while boot loading is started, and no limitation is made here.

[0028] In step 102, the target index value is read from multiple partition files configured by the factory of the device; one of the partition files contains only one index value. The implementation method of the present application stores different index values ​​through hardware physical partitions, thereby establishing an independent index value for each partition, reducing the complexity of the hardware partition index and improving the efficiency of the index; only one index value is set in a partition file, thereby realizing a one-to-one correspondence between the physical partition and the index value, avoiding the situation where multiple index values ​​are read at the same time and the target DTB file cannot be correctly obtained, making the DTB version management method more reasonable.

[0029] In some embodiments of the present application, the boot loader includes a search logic for a target index value, and the search logic is used to search for the target index value; the reading of the target index value from multiple partition files configured at the factory of the device includes: searching for the target index value in the multiple partition files by the search logic until the target index value is found and the target partition where the target index value is located is determined. The embodiments of the present application add a search logic for the target index value in the boot loader, so that the target DTB file can be searched according to the target index value, thereby achieving the determination of the target DTB file by software in the boot process while being compatible with multiple DTBs.

[0030] In some embodiments of the present application, one DTB file corresponds to one index value; the packaging of multiple versions of the DTB files together with the system kernel to generate a compressed image set includes: calling a first packaging tool to package the multiple versions of the DTB files to generate a DTB image file; calling a second tool to merge the system kernel image file and the DTB image file to generate the compressed image set.

[0031] Specifically, the first packaging tool is the resource_tool tool called by the mkmultidtb.py script; the second packaging tool is the mkbootimg tool. It should be noted that those skilled in the art can understand that the packaging tool or packaging method used can be adjusted according to actual production needs, and only the packaging of the above files needs to be realized, and no limitation is made here.

[0032] In some embodiments of the present application, if the target index value cannot be read in the target partition file, the default DTB data is loaded into the memory and the system kernel is started. The embodiments of the present application avoid the situation where the system cannot be loaded and started normally due to the lack of the target index value by loading the default DTB data into the memory when the target index value cannot be read.

[0033] In step 103, a target DTB file is obtained according to the target index value.

[0034] In some embodiments of the present application, if the target DTB file cannot be obtained in the boot image set, the default DTB data is loaded into the memory and the system kernel is started. The embodiments of the present application avoid the situation where the system cannot be loaded and started normally due to the failure to find the target DTB file by loading the default DTB data into the memory when the target DTB file cannot be read.

[0035] In step 104, the target DTB file is read, the data in the target DTB file is loaded into the device memory, and the system kernel is started.

[0036] In some embodiments of the present application, the target index value is located in the hardware information description file of the factory configuration file. Specifically, by adding an identification code as the target index value in the configuration file corresponding to the hardware. It should be noted that those skilled in the art can understand that the method of adding the identification can be adjusted according to actual production needs, and it is only necessary to achieve the correspondence between the target index value and the factory configuration file, and no limitation is made here.

[0037] For example, first, multiple DTB files and the index values ​​corresponding to the DTB files, i.e., index values, and kernel, i.e., the Linux system kernel, are packaged together to generate zboot.img, i.e., a boot image set, which includes a compressed kernel image file zImage, and a resource image file resource.img. The kernel is used to load peripheral drivers and file systems when the system starts.

[0038] Specifically, you can enter the kernel source code directory and compile the Linux kernel kernel image zImage file through the regular make command; and add the DTB file name to be packaged and the index value corresponding to the DTB file in the mkmultidtb.py script under the kernel source code directory. For example, the correspondence between the DTB file and the index is achieved through "hardware A.dtb = DTB_A", "hardware B.dtb = DTB_B", and "hardware C.dtb = DTB_C", where DTB_A corresponds to hardware version A, DTB_B corresponds to hardware version B, and DTB_C corresponds to hardware version C. After the correspondence is achieved, run the mkmultidtb.py script, and call the resource_tool tool through the mkmultidtb.py script to package the specified DTB file to generate the resource.img file. After generating the Linux kernel kernel image zImage and resource.img, run the mkbootimg tool in the kernel source code directory to merge the generated zImage and resource.img to generate zboot.img, that is, the boot image set, such as Figure 2 shown.

[0039] Since this example uses three DTBs as an example for explanation, when generating partitions, it is also necessary to generate three partition files, namely factory files, which contain DTB index values ​​that correspond to the partitions one by one. Specifically, fill in the corresponding index value in the configuration file that describes the hardware information. For example, taking hardware A as an example to set the corresponding index, in the configuration file "hardwareA.txt" of hardware A, add "*dtb_index:DTB_A#" as the index identifier, and hardware B and hardware C set the corresponding index value in the same way. It can be understood by those skilled in the art that the number of hardware, the number of partitions, and the number of index values ​​can be set according to actual needs. It is only necessary to ensure that the three correspond one to one. This example is only used for illustrative understanding, and the specific number is not limited here.

[0040] After setting the index value as the identifier in the hardware configuration file, run the factory_tool tool to generate a factory partition image file from the hardware configuration file. The factory_tool tool is used to write the correct index value into the partition file. Taking the process of writing the index value of hardware A as an example, first run the factory_tool tool to convert the "hardware A.txt" file into the "hardware A.cfg" file. The "hardware A.cfg" file obtained after the conversion is the partition file used for the production and burning of hardware version A. The same applies to hardware B and hardware C. Figure 3As shown. Secondly, in the hardware production stage, select the correct software to burn according to different hardware versions. For example, when producing hardware version A, select the factory partition version software corresponding to index DTB_A for burning.

[0041] Since the boot loader, i.e. Uboot, does not include the logic of DTB index judgment in the default program, the developer can modify the Uboot source code to add the search logic of the target index value according to actual needs. After compiling the Uboot source code with the search logic of the target index value to generate the Uboot program, burn the Uboot program to the device as the startup program. After the embedded system is powered on, Uboot is executed first. After Uboot initializes the memory (DDR) and the flash memory (Flash), it reads the operating system (OS) from the Flash into the DDR and then starts the OS.

[0042] like Figure 4 As shown, after the boot loader, i.e. Uboot, is started, it first reads the DTB index value corresponding to the current hardware from the factory partition.

[0043] If the DTB index value corresponding to the current hardware is not found, the default DTB is used to load the kernel; if a valid DTB index is found, then the corresponding DTB file is searched from zboot.img.

[0044] If no DTB file matching the DTB index is found, the default DTB file is used to load the kernel. If a matching DTB file is found, the complete DTB file data is read into memory to load the kernel.

[0045] Taking the DTB loading process corresponding to hardware A as an example, the current device is hardware version A. After Uboot is started, the target index value is obtained as "*dtb_index:DTB_A", and the hardware description "*dtb_index:DTB_A" is found from the factory partition. Then, according to index DTB_A, "hardware A.dtb = DTB_A" is found from zboot.img, and finally the DTB file "hardware A.dtb" is read into the memory to load the kernel.

[0046] In an embodiment of the present invention, after the boot loader is started, the target DTB file is directionally found through the target index value, and the DTB file is loaded into the memory to start the kernel. The upgrade of DTB compatible with multiple hardware versions is realized through software, so that the same firmware is compatible with different hardware versions, and there is no need to rely on physical hardware resources for version upgrade, so as to be compatible with different hardware platforms and improve the flexibility of version upgrade; and in the process of updating and upgrading through software, a partition file only contains one index value, and different index values ​​are stored through hardware physical partitions, so as to establish an independent index value for each partition, reduce the complexity of the hardware partition index, and improve the efficiency of the index; in addition, because it realizes the upgrade compatible with multiple DTBs through software, in the subsequent upgrade and modification, the over-the-air update and upgrade can be realized directly through software, thereby improving the versatility of a firmware, reducing the number of times the firmware version needs to be released, and saving the cost of update and maintenance.

[0047] The steps of the above method are divided only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0048] In addition, the examples mentioned in the above embodiments can be freely combined, and any combination can be understood as an embodiment. The "embodiment" or "example" appearing in various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It can be understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0049] Statement of combinations of steps after all method embodiments: In summary, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or sequential order to achieve the desired results.

[0050] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the term "plurality" means more than two (including two), unless otherwise clearly and specifically defined.

[0051] Another embodiment of the present invention relates to an electronic device, such as Figure 5 As shown, it includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the device upgrade method as described above.

[0052] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0053] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0054] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0055] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0056] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present invention, and that in actual applications, various changes may be made in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A device upgrading method, characterized in that: include: Start the bootloader; Read the target index value from multiple partition files of the factory configuration of the device; One of the partition files contains only one index value; Acquire a target DTB file according to the target index value; The target DTB file is read, the data in the target DTB file is loaded into the device memory, and the system kernel is started.

2. The device upgrade method according to claim 1, characterized in that: The bootloader includes a search logic for a target index value, the search logic being used to search for the target index value; The step of reading the target index value from multiple partition files of the factory configuration of the device includes: The target index value is searched in the multiple partition files by the search logic until the target index value is found and the target partition where the target index value is located is determined.

3. The device upgrading method according to claim 1, characterized in that: Before the boot loader is started, multiple versions of DTB files are packaged together with the system kernel image file to generate a compressed image set; The acquiring the target DTB file according to the target index value includes: According to the target index value, a target DTB file corresponding to the target index value is obtained in the compressed image set.

4. The device upgrade method according to claim 3, characterized in that: One DTB file corresponds to one index value; The method of packaging multiple versions of DTB files together with the system kernel to generate a compressed image set includes: Calling a first packaging tool to package the multiple versions of the DTB files to generate a DTB image file; The second tool is called to combine and package the system kernel image file with the DTB image file to generate the compressed image set.

5. The device upgrade method according to claim 2, characterized in that: If the target index value cannot be read in the target partition file, the default DTB data is loaded into the memory and the system kernel is started.

6. The device upgrade method according to claim 2, characterized in that: If the target DTB file cannot be obtained in the boot image set, the default DTB data is loaded into the memory and the system kernel is started.

7. The device upgrading method according to any one of claims 1 to 6, characterized in that: The target index value is located in the hardware information description file of the factory configuration file.

8. An electronic device, characterized in that: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps in the device upgrading method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps in the device upgrading method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, implement the steps in the device upgrading method according to any one of claims 1 to 7.

Images