Method and electronic device for upgrading firmware

By placing non-AB firmware into a sub-firmware upgrade package and utilizing a dual-partition upgrade method, the problem of non-AB firmware being unable to be upgraded in the Android AB system is solved, enabling effective upgrades of non-AB firmware in the AB system, applicable to various electronic devices.

CN114706608BActive Publication Date: 2025-11-25FUZHOU ROCKCHIP SEMICON
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202210311267.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-03-28
Publication Date
2025-11-25
Estimated Expiration
2042-03-28

AI Technical Summary

Technical Problem

In the Android AB system, existing technology cannot upgrade non-AB firmware with only one partition, especially non-AB firmware such as the primary bootloader and resource partition that are directly associated with the chip ROM, which cannot be effectively upgraded.

Method used

Non-AB firmware is placed in a separate sub-firmware upgrade package and upgraded to the reserved firmware package partition in the device partition table. The upgrade is performed using a dual-partition upgrade method, which includes steps such as creating an image file, signing, and verification, to ensure that non-AB firmware can be successfully upgraded in the AB system.

Benefits of technology

It enables efficient upgrades of non-AB firmware within the AB system, ensuring the integrity and security of the upgrade process, and is applicable to various electronic devices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114706608B_ABST
    Figure CN114706608B_ABST
Patent Text Reader

Abstract

The application relates to the technical field of firmware upgrading, in particular to a firmware upgrading method and electronic equipment. The firmware upgrading method comprises the following steps: upgrading a sub-firmware upgrading package containing non-AB firmware to a reserved firmware package partition through AB upgrading; and upgrading the sub-firmware upgrading package of the non-AB firmware stored in the reserved firmware package partition through a preset sub-firmware upgrading package instruction. For the non-AB firmware without two AB partitions in an AB system, the firmware upgrading of the non-AB firmware can be realized in the AB system through the above method.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, and in particular to methods and electronic devices for upgrading firmware. Background Technology

[0002] In the existing Android AB system, when performing an Android AB upgrade, all firmware to be upgraded must have two partitions, A and B, existing in the form of suffixes _a or _b (such as boot_a and boot_b). During a dual-partition (AB) upgrade, if the currently running system is in slot a, the firmware will be upgraded to slot b, and vice versa.

[0003] In real-world scenarios, even in AB systems, some firmware is not AB (i.e., it only has one actual partition). For example, the primary boot loader directly associated with the chip ROM is usually not AB because the ROM typically does not implement AB logic, so it only has one partition.

[0004] Meanwhile, in some scenarios, to save space, critical partitions in the system are partitioned using A / B partitioning, while non-critical partitions are partitioned in a non-A / B manner (such as resource partitions like logo / resource). In these scenarios, existing A / B system upgrade methods cannot be used when upgrading non-A / B firmware is required. Summary of the Invention

[0005] This application provides a method and electronic device for upgrading firmware, which enables the upgrading of non-AB firmware with only one partition in an AB system.

[0006] In a first aspect, a method for upgrading firmware is provided. The method includes: placing firmware having a non-dual-partition format into a separate sub-firmware upgrade package; upgrading the sub-firmware upgrade package containing the firmware to a reserved firmware package partition in a pair of reserved firmware package partitions in a device partition table; and upgrading the sub-firmware upgrade package stored in the reserved firmware package partition in response to a sub-firmware upgrade package instruction.

[0007] In some embodiments, upgrading the sub-firmware upgrade package containing the firmware to a reserved firmware package partition in a pair of reserved firmware package partitions in a device partition table includes: creating a first image file containing the sub-firmware upgrade package and storing the first image file in the main upgrade package of the system firmware; storing the main upgrade package on a server with a new system firmware version number; and upgrading the first image file to the reserved firmware package partition in response to a dual-partition upgrade command.

[0008] In some embodiments, upgrading the first image file to the reserved firmware package partition includes: in response to a dual-partition upgrade instruction, determining whether there is a sub-firmware upgrade package named according to a preset rule in the current reserved firmware package partition; if so, deleting the sub-firmware upgrade package; and upgrading the first image file to the reserved firmware package partition through dual-partition upgrade according to the main upgrade package.

[0009] In some embodiments, upgrading the sub-firmware upgrade package stored in the reserved firmware package partition in response to the sub-firmware upgrade package instruction includes: determining whether there is a sub-firmware upgrade package named according to a preset rule in the reserved firmware package partition; if not, exiting the non-dual-partition firmware upgrade; if there is, determining whether there is a non-dual-partition firmware upgrade result marker file under a predetermined path; if there is, determining the upgrade result based on the upgrade result marker file; if the upgrade is successful, performing a first operation, the first operation including: deleting the sub-firmware upgrade package with a predetermined name in the reserved firmware package partition, deleting the sub-firmware upgrade package in the sub-firmware upgrade package path of the marker file, deleting the non-AB firmware upgrade result marker file under the predetermined path, and then exiting the non-AB firmware upgrade service.

[0010] In some embodiments, if the upgrade fails, it checks whether to continue. If not, it performs the first operation. If it continues, it checks whether the current dual-partition system has been successfully upgraded. If the upgrade fails, it sleeps for a predetermined time and then continues to query. If the upgrade is successful, it verifies the sub-firmware upgrade package. If the verification passes, it sets the path of the sub-firmware upgrade package to be upgraded to the path of the sub-firmware upgrade package named according to preset rules in the reserved firmware package partition. It writes the preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded for upgrading non-dual-partition firmware to a predetermined position in the device's boot communication partition.

[0011] In some embodiments, upgrading the sub-firmware upgrade package stored in the reserved firmware package partition in response to the sub-firmware upgrade package instruction further includes: if there is no non-dual-partition firmware upgrade result marker file, checking whether the current dual-partition system has been successfully upgraded; if the upgrade is unsuccessful, continuing to query after a predetermined sleep time; if the upgrade is successful, verifying the sub-firmware upgrade package; if the verification passes, setting the path of the sub-firmware upgrade package to be upgraded to the path of the sub-firmware upgrade package named according to a preset rule in the reserved firmware package partition, and writing a preset sub-firmware upgrade package instruction for upgrading non-dual-partition firmware and the path of the sub-firmware upgrade package to be upgraded to a predetermined position in the device's boot communication partition.

[0012] In some embodiments, the method further includes: Step S1: Parsing the predetermined location of the boot communication partition to obtain a preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded for upgrading non-dual-partition firmware; Step S2: Searching for the physical block device node corresponding to the mount point in the upgrade mode according to the first-level path name in the path of the sub-firmware upgrade package to be upgraded, checking whether the physical block device node exists, if it exists, setting the physical block device node to be mounted to the corresponding physical block device node found, and executing step S3; if the physical block device node does not exist, obtaining the current location from the command line parameters, adding the location as a suffix to the physical block device node, checking again whether the physical block device node with the added suffix exists, if it exists, setting the physical block device node to be mounted to the corresponding physical block device node with the added suffix, and executing step S3; 3. Otherwise, an error occurs, the upgrade result is set to failure, and step S4 is executed; Step S3: Create a mount point specified by the first-level path name, and mount the physical block device node to be mounted to the newly created mount point. Obtain the corresponding sub-firmware upgrade package according to the sub-firmware upgrade package path to be upgraded, and verify the sub-firmware upgrade package. If the verification fails, prompt that the sub-firmware upgrade package verification is wrong and set the upgrade result to failure; otherwise, upgrade the firmware in the sub-firmware upgrade package. After the upgrade is completed, set the upgrade result to success or failure; Step S4: Create a non-dual-partition firmware upgrade result marker file under the predetermined path, and write the upgrade result and the sub-firmware upgrade package path to be upgraded into the marker file. Clear the special upgrade instruction for upgrading non-dual-partition firmware and the sub-firmware upgrade package path to be upgraded in the predetermined position of the boot communication partition. The device restarts and enters the system.

[0013] In some embodiments, upgrading the sub-firmware upgrade package containing the firmware to a reserved firmware package partition in a pair of reserved firmware package partitions in the device partition table includes: generating a public-private key pair using a predetermined algorithm, signing the sub-firmware upgrade package using the private key, and storing the public key in a specific path of the dual-partition system firmware and a specific path of the firmware containing the upgrade mode in the dual-partition system; verifying the sub-firmware upgrade package if the upgrade is successful includes: verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package in the specific path of the dual-partition system firmware if the upgrade is successful; verifying the sub-firmware upgrade package in step S3 includes: verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package in the specific path of the firmware in the upgrade mode.

[0014] In some embodiments, the method further includes: adding the pair of reserved firmware package partitions to the device partition table; creating a second binary image file corresponding to the reserved firmware package partition in the pair of reserved firmware package partitions; and burning the second binary image file to the reserved firmware package partition.

[0015] In a second aspect, an electronic device is provided. The electronic device includes a memory configured to store an instruction set; and a processor configured to perform the aforementioned firmware upgrade method.

[0016] For non-AB firmware in the AB system that does not have two partitions, AB, the firmware upgrade method shown in this application can also be used to upgrade non-AB firmware in the AB system.

[0017] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0018] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of this application and other related content, and should not be considered as limitations on this application. In the accompanying drawings:

[0019] Figure 1 This is a flowchart illustrating a firmware upgrade method according to embodiments of the present disclosure. Figure 1 ;

[0020] Figure 2 This is a flowchart illustrating the execution of different operations based on different upgrade results according to embodiments of the present disclosure;

[0021] Figure 3 This is a flowchart illustrating a device entering firmware upgrade mode according to an embodiment of the present disclosure;

[0022] Figure 4 This is a schematic diagram illustrating the overall flow of a firmware upgrade method according to an embodiment of the present disclosure;

[0023] Figure 5 This is a schematic diagram of a module of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0024] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended to limit the scope of protection of this application.

[0025] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this application, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0026] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit this application.

[0027] In the description of this application, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " in this document generally indicates that the preceding and following objects have an "or" logical relationship.

[0028] In this application, terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy or order relationship between these entities or operations.

[0029] Unless otherwise specified, the use of terms such as “comprising,” “including,” “having,” or other similar expressions in this application is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0030] In this application, expressions such as "greater than", "less than", and "exceeding" are understood to exclude the stated number; expressions such as "above", "below", and "within" are understood to include the stated number. Furthermore, in the description of the embodiments of this application, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times", unless otherwise explicitly specified.

[0031] As mentioned in the background section above, non-AB firmware (i.e., firmware with only one partition) cannot be upgraded in AB systems. Therefore, a method to solve this problem is urgently needed. This application addresses this technical problem through a self-designed firmware upgrade method. It should be noted that the firmware upgrade method of this application is for upgrading non-AB firmware within an AB system that is not dependently coupled with the AB firmware. In this document, non-AB firmware can be referred to as non-dual-partition firmware, AB upgrade can be referred to as dual-partition upgrade, and the AB system can be referred to as a dual-partition system.

[0032] Figure 1 This is a flowchart illustrating a firmware upgrade method 100 according to an embodiment of the present disclosure. Figure 1 As shown, the method 100 includes steps S101 to S103.

[0033] In step S101, firmware with a non-dual partition format is placed into a separate sub-firmware upgrade package.

[0034] In step S102, the sub-firmware upgrade package containing the firmware is upgraded to the reserved firmware package partition in a pair of reserved firmware package partitions in the device partition table.

[0035] In some embodiments, prior to this step, the pair of reserved firmware package partitions can be added to the device partition table, such as adding an AB partition, referred to as reserved firmware package partition A and reserved firmware package partition B (e.g., reserved_loader_a and reserved_loader_b). The reserved firmware package partitions are used to store independent firmware upgrade packages that are not in the AB partitions. A second binary image file corresponding to the reserved firmware package partition in the pair of reserved firmware package partitions is created, and the second binary image file is burned to the reserved firmware package partition when the device is shipped from the factory.

[0036] After the above operations are completed, in the above steps, a first image file containing the sub-firmware upgrade package is created and stored in the main upgrade package of the system firmware; the main upgrade package is stored on the server with a new system firmware version number; and in response to the dual-partition upgrade command, the first image file is upgraded to the reserved firmware package partition.

[0037] In this embodiment, the firmware to be upgraded (not in AB partition format) is placed into a separate sub-firmware upgrade package. This sub-firmware upgrade package is named according to preset rules, such as naming it with a predetermined name (e.g., update_loader.zip). The non-AB firmware in the sub-firmware upgrade package must not have any dependency coupling relationship with the AB firmware in the system (e.g., the first-level boot loader firmware and resource firmware such as logo / resource). Then, a binary image file (i.e., the first image file) with a file system is created for the reserved firmware package partition, containing the above-mentioned sub-firmware upgrade package file (e.g., update_loader.zip).

[0038] The system firmware version number is modified. When creating the main upgrade package containing the system firmware, the first image file for the reserved firmware package partition, created above, is included in the same main upgrade package. This allows the AB upgrade engine to upgrade the corresponding first image file to the corresponding reserved firmware package partition. The upgrade image for the reserved firmware package partition in the main upgrade package is always complete, and the upgrade image for the reserved firmware package partition does not use differences. The main upgrade package is named with the new system firmware version number and placed on the FOTA server.

[0039] In response to the dual-partition upgrade command, it determines whether a sub-firmware upgrade package named according to a preset rule exists in the current reserved firmware package partition. If it exists, the sub-firmware upgrade package is deleted. Then, based on the main upgrade package, the first image file is upgraded to the reserved firmware package partition via dual-partition upgrade. For example, when the FOTA AB client is running, it queries the FOTA server based on the current system firmware version number to see if there is new firmware to upgrade. When new firmware needs to be upgraded:

[0040] a. First, check if there is a sub-firmware upgrade package named according to the preset rules in the current reserved firmware package partition. If it exists, delete the sub-firmware upgrade package with the preset name in the reserved firmware package partition.

[0041] b. Then, based on the main upgrade package, use the AB upgrade engine to perform the AB firmware upgrade. During this process, the binary image file created above for the reserved firmware package partition is upgraded to the corresponding reserved firmware package partition.

[0042] After upgrading the sub-firmware upgrade package containing non-AB firmware to the reserved firmware package partition, the device restarts, boots into the upgraded system, and mounts the reserved firmware package partition. Next, the firmware upgrade service for non-AB partitions (such as non_ab_update_service) is started, and the specific process is explained in step S103.

[0043] In step S103, the sub-firmware upgrade package stored in the reserved firmware package partition is upgraded in response to the sub-firmware upgrade package instruction. First, it is determined whether a sub-firmware upgrade package named according to a preset rule exists in the reserved firmware package partition. If it does not exist, the non-dual-partition firmware upgrade is exited.

[0044] If it exists, determine whether a non-dual-partition firmware upgrade result flag file (such as / cache / non_ab_update_flag) exists in the predetermined path. If it exists, determine the upgrade result based on the upgrade result flag file. If the upgrade is successful, perform the first operation, which includes: deleting the sub-firmware upgrade package with the predetermined name in the reserved firmware package partition, deleting the sub-firmware upgrade package in the sub-firmware upgrade package path in the flag file, deleting the non-AB firmware upgrade result flag file in the predetermined path, and then exiting the non-AB firmware upgrade service.

[0045] If no non-dual-partition firmware upgrade result marker file exists, the current dual-partition system is checked to see if the upgrade was successful. Specifically, in some embodiments, the current slot is obtained through the boot_ctrl HAL of AB (e.g., getCurrentSlot), and then the current slot is queried to see if it is marked as successfully upgraded by AB (e.g., isSlotMarkedSuccessful). If the query result indicates that the AB upgrade has not yet succeeded (e.g., isSlotMarkedSuccessful is not true), the system sleeps for a predetermined time (e.g., sleep(5)) and then continues to query. If the query result indicates that the AB upgrade has succeeded, the sub-firmware upgrade package is verified. If the verification passes, the path of the sub-firmware upgrade package to be upgraded is set to the path of the sub-firmware upgrade package named according to the preset rules in the reserved firmware package partition (e.g., / reserved_loader / update_loader.zip). The preset sub-firmware upgrade package instruction for upgrading non-AB firmware and the path of the sub-firmware upgrade package to be upgraded are written in the predetermined position of the device's boot communication partition.

[0046] The device then restarts and boots into firmware upgrade mode (such as recovery).

[0047] Figure 2 The flowchart illustrates a process for determining if an upgrade is unsuccessful based on the upgrade result tag file, according to an embodiment of this disclosure.

[0048] In step S201, if the upgrade fails, it is checked whether to continue. If not, the first operation is performed.

[0049] In step S202, if the process continues, it checks whether the current dual-partition system has been successfully upgraded. If the upgrade is unsuccessful, it sleeps for a predetermined time and then continues to query. Specifically, it obtains the current slot (e.g., getCurrentSlot) through the AB's boot_ctrl HAL, and then queries whether the current slot is marked as successfully upgraded by AB (e.g., isSlotMarkedSuccessful). If the query result indicates that the AB upgrade has not yet been successful (e.g., isSlotMarkedSuccessful is not true), it sleeps for a predetermined time (e.g., sleep(5)) and then continues to query.

[0050] In step S203, if the upgrade is successful, the sub-firmware upgrade package is verified. If the verification passes, the path of the sub-firmware upgrade package to be upgraded is set to the path of the sub-firmware upgrade package named according to the preset rules in the reserved firmware package partition. The preset sub-firmware upgrade package instruction for upgrading non-dual-partition firmware and the path of the sub-firmware upgrade package to be upgraded (such as recovery) are written in the predetermined position of the device's boot communication partition.

[0051] In the device's bootloader, add the current slot flag (e.g., androidboot.slot_suffix=_b) to the command-line parameters to boot the device into firmware upgrade mode (e.g., recovery mode).

[0052] Figure 3 This is a flowchart illustrating a device entering firmware upgrade mode according to an embodiment of the present disclosure.

[0053] In step S301, the predetermined location of the boot communication partition is parsed to obtain the preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded for upgrading non-dual-partition firmware.

[0054] In step S302, based on the first-level path name in the sub-firmware upgrade package path to be upgraded, the physical block device node (e.g., / dev / block / by-name / reserved_loader) corresponding to the mount point is searched in the upgrade mode (e.g., recovery). The existence of the physical block device node is checked. If it exists, the physical block device node to be mounted is set to the found corresponding physical block device node, and step S303 is executed. If the physical block device node does not exist, the current position (slot) is obtained from the command line parameters, and the position (slot) is added as a suffix to the physical block device node (e.g., / dev / block / by-name / reserved_loader_b). The existence of the physical block device node with the added suffix is ​​checked again. If it exists, the physical block device node to be mounted is set to the corresponding physical block device node with the added suffix (e.g., / dev / block / by-name / reserved_loader_b), and step S303 is executed. Otherwise, an error occurs, the upgrade result is set to failure, and step S304 is executed.

[0055] In step S303, a mount point specified by the first-level path name is created, and the physical block device node to be mounted is mounted to the newly created mount point. The corresponding sub-firmware upgrade package is obtained according to the path of the sub-firmware upgrade package to be upgraded. The sub-firmware upgrade package is verified. If the verification fails, a message is displayed indicating that the sub-firmware upgrade package verification has failed, and the upgrade result is set to failure. Otherwise, the firmware in the sub-firmware upgrade package is upgraded. After the upgrade is completed, the upgrade result is set to success or failure.

[0056] In step S304, a non-dual-partition firmware upgrade result flag file (e.g., / cache / non_ab_update_flag) is created in a predetermined path, and the upgrade result and the path of the sub-firmware upgrade package to be upgraded are written into the flag file. The special upgrade instructions for upgrading non-dual-partition firmware and the path of the sub-firmware upgrade package to be upgraded are cleared from the predetermined location of the boot communication partition. The device restarts and enters the system.

[0057] In this embodiment, upgrading the sub-firmware upgrade package containing the firmware to a reserved firmware package partition in a pair of reserved firmware package partitions in the device partition table includes: generating a public-private key pair using a predetermined algorithm, signing the sub-firmware upgrade package using the private key, and storing the public key in a specific path of the dual-partition system firmware and a specific path of the firmware containing the upgrade mode in the dual-partition system.

[0058] The step S203, which involves verifying the sub-firmware upgrade package if the upgrade is successful, includes: verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package under a specific path of the dual-partition system firmware if the upgrade is successful.

[0059] The verification of the sub-firmware upgrade package in step S303 includes: verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package in a specific path of the firmware in the upgrade mode.

[0060] For non-AB firmware in the AB system that does not have two partitions, AB, the firmware upgrade method shown in this application can also be used to upgrade non-AB firmware in the AB system.

[0061] The above flowchart illustrates the overall firmware upgrade process. Figure 4 . Figure 4 This is a schematic diagram illustrating the overall flow of a firmware upgrade method according to an embodiment of the present disclosure.

[0062] exist Figure 4 In the device partition table, an A / B partition is added, which is two physical partitions called reserved firmware package partition A and reserved firmware package partition B.

[0063] Create a binary image file with a file system that contains no content for the "Reserved Firmware Package Partition" and burn the created binary image to the A and B physical partitions of the "Reserved Firmware Package Partition" when the device is shipped from the factory.

[0064] The firmware to be upgraded (excluding A / B partition format) is placed into a separate sub-firmware upgrade package, which is named according to a predetermined name. A public / private key pair is generated using a predetermined digital signature algorithm. The sub-firmware upgrade package is signed using the private key, and the corresponding public key is placed in a specific path of the A / B system firmware and a specific path of the firmware containing the upgrade mode in the A / B system.

[0065] Create a binary image file with a file system that includes sub-firmware upgrade package files for the "Preserve Firmware Package Partition".

[0066] Modify the system firmware version number. When creating the main upgrade package containing the system firmware, include the binary image file for the "preserve firmware package partition" within the same main upgrade package. Name the main upgrade package with the new system firmware version number and upload it to the FOTA server.

[0067] When the FOTA A / B client is running, it queries the FOTA server based on the current system firmware version number to see if there is any new firmware to upgrade. When a new firmware upgrade is needed, it first checks if a sub-firmware upgrade package with a predetermined name exists in the current reserved firmware package partition. If it exists, it deletes the sub-firmware upgrade package with the predetermined name from the reserved firmware package partition. Then, based on the main upgrade package, it uses the A / B upgrade engine to perform an A / B firmware upgrade. During this process, the binary image file created for the "reserved firmware package partition" is upgraded to the corresponding reserved firmware package partition.

[0068] After the A / B upgrade is completed, the device restarts, boots into the upgraded system, and mounts the corresponding reserved firmware package partition.

[0069] Enable firmware upgrade service for non-A / B partition formats.

[0070] The process involves several steps: First, determining if a sub-firmware upgrade package with a predetermined name exists in the reserved firmware package partition. If it does, then checking if a non-AB firmware upgrade result marker file exists in the predetermined path. If the sub-firmware upgrade package does not exist, the non-AB firmware upgrade service exits. If a non-AB firmware upgrade result marker file exists in the predetermined path, it checks if the upgrade result in the marker file is successful. If the upgrade result in the marker file is successful, the sub-firmware upgrade package with the predetermined name in the reserved firmware package partition is deleted, along with the sub-firmware upgrade packages in the path of the sub-firmware upgrade package in the marker file, and the non-AB firmware upgrade result marker file in the predetermined path. Then, the non-AB firmware upgrade service exits. If a non-AB firmware upgrade result marker file does not exist in the predetermined path, the current slot is obtained through the A / B boot_ctrl HAL, and it is then determined whether the current slot is marked as a successful A / B upgrade. If the upgrade result in the marker file is unsuccessful, it is determined whether to continue. If to continue, the A / B boot_ctrl... HAL acquires the current slot and then determines whether the current slot is marked as a successful A / B upgrade. If not, it exits the non-AB firmware upgrade service. If the current slot is not marked as a successful A / B upgrade, it sleeps for a predetermined time and then continues to determine whether the current slot is marked as a successful A / B upgrade. If the current slot is marked as a successful A / B upgrade, it uses the public key of the sub-firmware upgrade package under a specific path in the A / B system firmware to verify the sub-firmware upgrade package. It determines whether the verification is successful. If it fails, it exits the non-AB firmware upgrade service; if it succeeds, it sets the path of the sub-firmware upgrade package to be upgraded to the path of the sub-firmware upgrade package with a predetermined name in the reserved firmware package partition. A special upgrade command for upgrading non-AB firmware and the path of the sub-firmware upgrade package to be upgraded are written to a predetermined location in the device's boot communication partition.

[0071] The device restarts, and in the device's bootloader, the current slot flag is added to the command-line parameters to guide the device into firmware upgrade mode. In firmware upgrade mode, the predetermined location of the boot communication partition is parsed to obtain the special upgrade instructions for non-AB firmware and the path to the sub-firmware upgrade package to be upgraded. Based on the first-level path name in the sub-firmware upgrade package path, the physical block device node corresponding to the mount point is found in the upgrade mode's fstab. The system checks if the physical block device node exists. If it does, it sets the physical block device node to be mounted to the found physical block device node, creates a mount point specified by the first-level path name, and mounts the physical block device node to be mounted to this newly created mount point. It retrieves the corresponding sub-firmware upgrade package based on the path of the sub-firmware upgrade package to be upgraded, verifies the sub-firmware upgrade package using the public key of the sub-firmware upgrade package under the specific path of the upgrade mode, and determines whether the verification is successful. If successful, it upgrades the firmware in the sub-firmware upgrade package. After the upgrade is complete, it sets the upgrade result to success or failure, creates a non-AB firmware upgrade result marker file in the predetermined path, and writes the upgrade result and the path of the sub-firmware upgrade package to be upgraded into this marker file. It clears the special upgrade instructions for upgrading non-AB firmware and the path of the sub-firmware upgrade package to be upgraded from the predetermined location in the boot communication partition, and restarts the device. If unsuccessful, it sets the upgrade result to failure.

[0072] If the physical block device node does not exist, the current slot is obtained from the command-line parameters, and the slot is added as a suffix to the physical block device node. It is then checked whether the physical block device node with the added suffix exists. If it does, the physical block device node to be mounted is set to the found corresponding physical block device node. A mount point specified by the first-level path name is created, and the physical block device node to be mounted is mounted to this newly created mount point. The corresponding sub-firmware upgrade package is obtained according to the path of the sub-firmware upgrade package to be upgraded. The sub-firmware upgrade package public key under the specific path of the upgrade mode is used to verify the sub-firmware upgrade package. If the verification is successful, the firmware in the sub-firmware upgrade package is upgraded. After the upgrade is completed, the upgrade result is set to success or failure. A non-AB firmware upgrade result marker file is created in the predetermined path, and the upgrade result and the path of the sub-firmware upgrade package to be upgraded are written to this marker file. The special upgrade instructions for upgrading non-AB firmware and the path of the sub-firmware upgrade package to be upgraded are cleared from the predetermined location of the boot communication partition, and the device is restarted. If the physical block device node with the added suffix does not exist, the upgrade result is set to failure. A non-AB firmware upgrade result marker file is created in the predetermined path, and the upgrade result and the path of the sub-firmware upgrade package to be upgraded are written to the marker file. The special upgrade instructions for non-AB firmware upgrades and the path of the sub-firmware upgrade package to be upgraded are cleared from the predetermined location of the boot communication partition, and the device is restarted.

[0073] Figure 5 This is a schematic diagram illustrating a module of an electronic device 500 according to an embodiment of the present disclosure. The electronic device 500 includes, but is not limited to, network devices, embedded devices, programmable devices, and smart mobile terminals. Figure 5 As shown, the electronic device 500 includes a memory 501 and a processor 502. The memory 502 is configured to store an instruction set. The processor 502 is configured to perform any step in the firmware upgrade method mentioned above.

[0074] In the case of the AB system, the above electronic devices 500 can still be upgraded even if there is only one partition of firmware.

[0075] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A method for upgrading firmware, characterized in that, include: Firmware with non-dual partitioning format is placed into a separate sub-firmware upgrade package; Add a pair of reserved firmware package partitions to the device partition table, create a binary image file corresponding to the reserved firmware package partition in the pair of reserved firmware package partitions, and burn the binary image file to the reserved firmware package partition; Upgrading the sub-firmware upgrade package containing the firmware to the reserved firmware package partition in the pair of reserved firmware package partitions includes creating a first image file containing the sub-firmware upgrade package, storing the first image file in the main upgrade package of the system firmware, storing the main upgrade package on the server with a new system firmware version number, and upgrading the first image file to the reserved firmware package partition in response to the dual-partition upgrade command. as well as The sub-firmware upgrade package stored in the reserved firmware package partition is upgraded in response to the sub-firmware upgrade package instruction.

2. The method according to claim 1, characterized in that, Upgrading the first image file to the reserved firmware package partition includes: In response to the dual-partition upgrade command, determine whether a sub-firmware upgrade package named according to a preset rule exists in the current reserved firmware package partition; if it exists, delete the sub-firmware upgrade package; and According to the main upgrade package, the first image file is upgraded to the reserved firmware package partition through a dual-partition upgrade.

3. The method according to claim 1, characterized in that, Upgrading the sub-firmware upgrade package stored in the reserved firmware package partition in response to the sub-firmware upgrade package instruction includes: Determine whether there is a sub-firmware upgrade package named according to a preset rule in the reserved firmware package partition. If not, exit the non-dual partition firmware upgrade. If it exists, determine whether there is a non-dual-partition firmware upgrade result marker file under the predetermined path. If it exists, determine the upgrade result based on the upgrade result marker file. If the upgrade is successful, execute the first operation, which includes: deleting the sub-firmware upgrade package with a predetermined name in the reserved firmware package partition, deleting the sub-firmware upgrade package in the sub-firmware upgrade package path of the marker file, deleting the non-AB firmware upgrade result marker file under the predetermined path, and then exiting the non-AB firmware upgrade service.

4. The method according to claim 3, characterized in that, Also includes: If the upgrade fails, check whether to continue; if not, perform the first operation. If to continue, check if the current dual-partition system has been successfully upgraded. If the upgrade is unsuccessful, hibernate for a scheduled time and then continue to query. If the upgrade is successful, the sub-firmware upgrade package is verified. If the verification passes, the path of the sub-firmware upgrade package to be upgraded is set to the path of the sub-firmware upgrade package named according to the preset rules in the reserved firmware package partition. The preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded are written in the predetermined position of the device's boot communication partition for upgrading non-dual-partition firmware.

5. The method according to claim 3, characterized in that, Upgrading the sub-firmware upgrade package stored in the reserved firmware package partition in response to the sub-firmware upgrade package instruction further includes: If no non-dual-partition firmware upgrade result marker file exists, check whether the current dual-partition system has been successfully upgraded. If the upgrade is unsuccessful, continue querying after a scheduled hibernation time. If the upgrade is successful, the sub-firmware upgrade package is verified. If the verification passes, the path of the sub-firmware upgrade package to be upgraded is set to the path of the sub-firmware upgrade package named according to the preset rules in the reserved firmware package partition. The preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded are written in the predetermined position of the device's boot communication partition for upgrading non-dual-partition firmware.

6. The method according to claim 4 or 5, characterized in that, Also includes: Step S1: Parse the predetermined location of the boot communication partition to obtain the preset sub-firmware upgrade package instruction and the path of the sub-firmware upgrade package to be upgraded for non-dual-partition firmware. Step S2: Based on the first-level path name in the sub-firmware upgrade package path to be upgraded, search for the physical block device node corresponding to the mount point in the upgrade mode. Check if the physical block device node exists. If it exists, set the physical block device node to be mounted to the corresponding physical block device node found, and execute step S3. If the physical block device node does not exist, obtain the current position from the command line parameters, add the position as a suffix to the physical block device node, and check again if the physical block device node with the added suffix exists. If it exists, set the physical block device node to be mounted to the corresponding physical block device node with the added suffix, and execute step S3. Otherwise, an error occurs, the upgrade result is set to failure, and step S4 is executed. Step S3: Create a mount point specified by the first-level path name, and mount the physical block device node to be mounted to the newly created mount point. Obtain the corresponding sub-firmware upgrade package according to the path of the sub-firmware upgrade package to be upgraded, and verify the sub-firmware upgrade package. If the verification fails, prompt that the sub-firmware upgrade package verification is incorrect and set the upgrade result to failure; otherwise, upgrade the firmware in the sub-firmware upgrade package. After the upgrade is completed, set the upgrade result to success or failure. Step S4: Create a non-dual-partition firmware upgrade result marker file in the predetermined path, and write the upgrade result and the path of the sub-firmware upgrade package to be upgraded into the marker file. Clear the special upgrade instructions for upgrading non-dual-partition firmware and the path of the sub-firmware upgrade package to be upgraded in the predetermined location of the boot communication partition. Reboot the device and enter the system.

7. The method according to claim 6, characterized in that, Upgrading the sub-firmware upgrade package containing the firmware to the reserved firmware package partition of the pair of reserved firmware package partitions includes: A public-private key pair is generated using a predetermined algorithm. The private key is used to sign the sub-firmware upgrade package. The public key is then stored in a specific path of the dual-partition system firmware and a specific path of the firmware containing the upgrade mode in the dual-partition system. The step of verifying the sub-firmware upgrade package if the upgrade is successful includes: if the upgrade is successful, verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package under a specific path of the dual-partition system firmware; The verification of the sub-firmware upgrade package in step S3 includes: verifying the sub-firmware upgrade package using the public key of the sub-firmware upgrade package in a specific path of the firmware in the upgrade mode.

8. An electronic device, characterized in that, include: The memory is configured to store instruction sets; as well as A processor is configured to execute the instruction set to perform the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • FOTA firmware upgrading method and device based on Android system

    CN113238771A