Embedded boot upgrading method and device, analyzer and readable storage medium

Abstract

The application relates to the embedded technology field and discloses an embedded Boot upgrade method and device, an analyzer and a readable storage medium. The method is applied to an embedded system, the embedded system comprises a first starting module and a second starting module, a descriptor of the second starting module is stored in a descriptor storage area in the second starting module, and the method comprises the following steps: upgrading the second starting module based on an upgrade firmware through the first starting module; reading state information of the embedded system through the first starting module, checking a descriptor in the descriptor storage area through the first starting module if it is determined that the upgrade state is upgrade completion according to the state information; and determining that the second starting module is upgraded if the checking is passed. The application solves the structural contradiction that the unupgradability of the first starting module is damaged when the second starting module is upgraded and the changed structure cannot be adapted if the first starting module is not modified.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to an embedded boot upgrade method, apparatus, analyzer, and readable storage medium. Background Technology

[0002] Embedded systems have long faced a core challenge: once a device is deployed, physical access costs are extremely high. IAP (In-Application Programming) technology emerged to address this issue. IAP technology allows devices to update their firmware while running via a network or local communication interface, without requiring disassembly, a programmer, or physical contact.

[0003] Existing embedded systems use a dual-bootloader architecture (also known as a two-level boot architecture). This architecture splits the bootloader into two levels: the Boot0 program is extremely small (1-4KB), only handling basic initialization and jump decisions; the Boot1 program is responsible for full IAP functionality. The Boot0 program is designed as a minimal boot manager that is "never upgraded," while the Boot1 program can be upgraded along with the application through the Boot0 program. However, in the traditional dual-boot architecture, the boot parameters of the Boot1 program must be hard-coded in the Boot0 program. There is a strong coupling between the Boot0 and Boot1 programs. When the Boot1 program is upgraded, the Boot0 program is passively modified. This leads to a structural contradiction: modifying the Boot0 program when upgrading the Boot1 program would break its non-upgradeability, while not modifying the Boot0 program would fail to adapt to changes. Summary of the Invention

[0004] In view of this, the purpose of this application is to overcome the shortcomings of the prior art and provide an embedded boot upgrade method. The method is applied to an embedded system, which includes a first boot module and a second boot module. The descriptor of the second boot module is stored in a descriptor storage area within the second boot module. The method includes: Upon receiving the upgrade firmware, the first boot module upgrades the second boot module based on the upgrade firmware, and then resets it after the upgrade is completed. The first startup module reads the status information of the embedded system and determines the upgrade status based on the status information. If the upgrade status is determined to be upgrade complete, the descriptor in the descriptor storage area is read through the first startup module, and the descriptor is verified. If the verification passes, the upgrade of the second startup module is confirmed to be complete.

[0005] In one embodiment, the step of upgrading the second boot module based on the upgrade firmware by the first boot module upon receiving the upgrade firmware includes: Upon receiving the upgrade firmware, the upgrade firmware is verified, and a soft reset is triggered after the verification passes. The first boot module reads the state bitmap encoding of the embedded system and performs erase, write, verification and comparison operations on the second boot module based on the state bitmap encoding to complete the upgrade of the second boot module based on the upgrade firmware.

[0006] In one embodiment, the step of reading descriptors from the descriptor storage area through the first startup module and verifying the descriptors includes: The first startup module reads the descriptor in the descriptor storage area and verifies the fields in the descriptor. The fields include at least two of the following: magic number field, cyclic redundancy check value field, and second startup module version number field. Based on the validation results of all the fields, the validation result of the descriptor is determined.

[0007] In one embodiment, the field includes a magic number field, a cyclic redundancy check field, and a second startup module version number field. The step of reading the descriptor in the descriptor storage area through the first startup module and validating the fields in the descriptor includes: The first startup module reads the magic number field of the descriptor in the descriptor storage area and performs magic number verification on the magic number field to obtain the magic number verification result. The first startup module reads the cyclic redundancy check value field of the descriptor in the descriptor storage area, calculates the first cyclic redundancy calculation value of the first preset byte before the descriptor, and performs cyclic redundancy check based on the first cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy check result. The first startup module reads the second startup module version number field of the descriptor in the descriptor storage area and performs a compatibility check on the second startup module version number field to obtain the compatibility check result.

[0008] In one embodiment, the step of performing a compatibility check on the second startup module version number field to obtain a compatibility check result includes: Compare the version number field of the second startup module with the version number of the first startup module; If the version number field of the second startup module is not greater than the version number of the first startup module, then the compatibility verification result is determined to be passed; If the version number field of the second startup module is greater than the version number of the first startup module, then the compatibility check result is determined based on the base field size field of the descriptor in the descriptor storage area and the bit-defined characteristic flag field.

[0009] In one embodiment, the step of determining the compatibility check result based on the basic field size field and the bitwise defined characteristic flag field of the descriptor in the descriptor storage area includes: The second cyclic redundancy calculation value of the second preset byte before the descriptor is calculated based on the basic field area size field, and cyclic redundancy verification is performed based on the second cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy check result; Flag bit analysis is performed based on the bit-defined characteristic flag bit field to obtain the flag bit analysis results; If the cyclic redundancy check result is passed and the flag analysis result meets the preset conditions, then the compatibility check result is determined to be passed. If the cyclic redundancy check result is unsuccessful or the flag analysis result does not meet the preset conditions, then the compatibility check result is determined to be unsuccessful.

[0010] In one embodiment, the step of reading the status information of the embedded system through the first startup module and determining the upgrade status based on the status information includes: If the status word in the status information matches a preset combination of completed status words, then the upgrade status is determined to be completed. If the status word in the status information matches a preset interruption status word combination, then the upgrade status is determined to be an upgrade interruption. If the status word in the status information matches a preset abnormal status word combination, then the upgrade status is determined to be an upgrade abnormality.

[0011] In one embodiment, the method further includes: When the upgrade of the second startup module is completed, the first startup module determines the entry address of the second startup module based on the descriptor, and transfers control of the embedded system to the second startup module based on the entry address.

[0012] In one embodiment, the method further includes: If the upgrade status is determined to be an upgrade anomaly or the verification result of the descriptor is a failure, then the preset security recovery interface is initialized through the first startup module, and the security recovery firmware file is received; The first boot module verifies the security recovery firmware file and writes it into the second boot module, so that the second boot module can return to normal.

[0013] In one embodiment, the method further includes: If the upgrade status is determined to be an upgrade interruption, the first startup module locates the interruption location based on the status information. Based on the interruption location and the upgraded firmware, the process of upgrading the second boot module continues.

[0014] This application also provides an embedded boot upgrade device, the embedded boot upgrade device comprising: The upgrade module is used to upgrade the second startup module based on the upgrade firmware through the first startup module when the upgrade firmware is received, and to reset it after the upgrade is completed; The judgment module is used to read the status information of the embedded system through the first startup module and judge the upgrade status based on the status information; The verification module is used to read the descriptors in the descriptor storage area through the first startup module and verify the descriptors if the upgrade status is determined to be upgrade complete. The determination module is used to determine that the upgrade of the second startup module is complete if the verification passes.

[0015] This application also provides an analyzer, which includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the above-described embedded boot upgrade method.

[0016] This application also provides a computer-readable storage medium storing a computer program that, when run on a processor, executes the aforementioned embedded boot upgrade method.

[0017] The embodiments of this application have the following beneficial effects: This application applies to an embedded system, which includes a first boot module and a second boot module. The descriptor of the second boot module is stored in a descriptor storage area within the second boot module. The method includes: upon receiving an upgrade firmware, upgrading the second boot module based on the upgrade firmware via the first boot module, and resetting it after the upgrade is complete; reading the status information of the embedded system via the first boot module and determining the upgrade status based on the status information; if the upgrade status is determined to be complete, reading the descriptor in the descriptor storage area via the first boot module and verifying the descriptor; if the verification passes, determining the entry address of the second boot module based on the descriptor via the first boot module, and transferring control of the embedded system to the second boot module based on the entry address. In this application, the boot parameters of the second boot module are stored as descriptors in the descriptor storage area within the second boot module. The first and second boot modules are decoupled, so that upgrading the second boot module does not cause passive modification of the first boot module; the first boot module only needs to read the descriptor from the descriptor storage area. This solves the structural contradiction that modifying the first boot module during a second boot module upgrade would compromise its non-upgradeability, while not modifying the first boot module would prevent adaptation to changes. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and therefore should not be considered as a limitation on the scope of protection of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first embodiment of the embedded boot upgrade method provided in this application; Figure 2 A schematic diagram of the partition layout of the embedded system on the Flash memory provided in this application; Figure 3 A flowchart illustrating a second embodiment of the embedded boot upgrade method provided in this application; Figure 4 A flowchart illustrating the upgrade process for the second startup module provided in this application; Figure 5 A schematic diagram of the state transition changes during the upgrade process provided in this application; Figure 6 A flowchart illustrating the third embodiment of the embedded boot upgrade method provided in this application; Figure 7 A flowchart illustrating the fourth embodiment of the embedded boot upgrade method provided in this application; Figure 8 A flowchart illustrating the fifth embodiment of the embedded boot upgrade method provided in this application; Figure 9 A flowchart illustrating the fifth embodiment of the embedded boot upgrade method provided in this application; Figure 10 A complete flowchart of the embedded boot upgrade process provided in this application is shown. Figure 11 This is a schematic diagram of the embedded boot upgrade device provided in this application. Detailed Implementation

[0020] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.

[0023] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0024] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0025] It is understood that the method of this application is applied to embedded systems, which can be installed in devices such as smart terminals, PC terminals, and mobile terminals. For ease of description, the following embodiments use an embedded system as the execution subject for illustration.

[0026] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0027] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a first embodiment of the embedded boot upgrade method provided in this application. The method is applied to an embedded system, which includes a first boot module and a second boot module. The descriptor of the second boot module is stored in a descriptor storage area within the second boot module. The first boot module contains a Boot0 program, and the second boot module contains a Boot1 program. The method includes: Step S101: Upon receiving the upgrade firmware, the first boot module upgrades the second boot module based on the upgrade firmware, and then resets it after the upgrade is completed.

[0028] In this embodiment, when the embedded system receives an upgrade firmware for the second boot module, it upgrades the second boot module based on the upgrade firmware through the first boot module and then resets it after the upgrade is complete. It should be noted that the first boot module contains a first-level bootloader (Boot0 program), a non-upgradeable bootloader responsible for basic initialization and jump determination in the dual-boot architecture; the second boot module contains a second-level bootloader (Boot1 program), an upgradeable bootloader responsible for full IAP functionality in the dual-boot architecture. IAP (In-Application Programming) is a technology that allows a device to update its own firmware and write it to its internal Flash memory via a network or local communication interface while in operation.

[0029] In this embodiment, the descriptors of the second startup module are stored in the descriptor storage area within the second startup module. When the embedded system upgrades the second startup module, the descriptors in the descriptor storage area of ​​the second startup module are updated. These descriptors are used to record the startup parameters of the second startup module (entry offset, stack pointer, code size, version information, compatibility requirements, etc.). Through the descriptor mechanism, the startup parameters of the second startup module are decoupled from the hard-coded constants of the first startup module. This avoids the situation where the startup parameters of the second startup module must be hard-coded in the first startup module, and avoids the situation where upgrading the second startup module necessarily requires updating the first startup module as well.

[0030] In one embodiment, such as Figure 2 As shown, Figure 2 The schematic diagram of the partition layout of the embedded system on the Flash memory provided in this application; wherein, the partition layout of the embedded system on the Flash memory includes a first boot module (Boot0), a second boot module (Boot1, with a descriptor storage area before and after Boot1), a status identifier area, a firmware backup area and an App area; wherein the starting address of the first boot module and the status identifier area is determined once and fixed in the first boot module when the project starts, and will not be changed; the size of the second boot module and the firmware backup area is dynamically specified by the Boot descriptor. The status identifier area consists of 2-4 equal-sized sectors, supporting multi-sector rotation wear leveling. The functional division of each module is as follows: (1) First boot module (MCU Boot0 code area): responsible for the most basic hardware initialization, the location and verification of the Boot1 descriptor (including multi-version negotiation), the status determination and recovery of the upgraded state machine (including the location of the active sector for wear leveling), and the UART-based secure recovery mode. The design goal of Boot0 is to never be upgraded, and the code size is controlled within 4-8KB. (2) Second boot module (MCU Boot1 code area): Responsible for complete IAP functions, including communication protocol stack, Flash read / write and erase driver, firmware verification, encryption / decryption engine, and upgrade process control. Standardized Boot descriptors are embedded at fixed offsets at the beginning and end of Boot1. (3) App module (MCU App code area): Runs application business logic, responsible for receiving upgrade instructions and new firmware data from the remote server, writing them to the firmware backup area, setting the "pending upgrade" flag in the status log area after verification, and triggering a soft reset. (4) Status identifier area (independent Flash sector x2-4): Records the status transition information of the upgrade process, including status words (bitmap encoding) and page completion bitmaps. Supports multi-sector rotation wear leveling, and locates the currently active sector through the generation counter at the sector header. (5) Firmware backup area (Flash area): Serves as the receiving buffer area for the new Boot1 firmware, and is the same size as the second boot module.

[0031] In one embodiment, the second startup module (with a descriptor storage area at both the front and back) reads the descriptors from the tail descriptor storage area of ​​the second startup module first when the first startup module starts. If the verification fails, it automatically backtracks to read the descriptors from the head descriptor storage area. When the first startup module detects that a descriptor in one descriptor storage area is valid while a descriptor in another descriptor storage area is corrupted, it automatically repairs the corrupted descriptor using the valid one. This achieves parameter decoupling between the first and second startup modules while ensuring the reliability of the descriptors themselves.

[0032] In one embodiment, the descriptor occupies a fixed 64 bytes and is stored in two descriptor storage areas within the second boot module. One descriptor storage area is located at the end of the second boot module (64 bytes below the end); the other descriptor storage area is located at the beginning of the second boot module (+0x40 bytes, i.e., after the interrupt vector table). The structure is defined as follows: typedef struct __attribute__((packed, aligned(4))) { / / === Basic Field Area (V1, 40 bytes) === uint32_t magic; / / +0x00 Magic number 0x424F4F54 uint32_t version; / / +0x04 Boot1 firmware version number (BCD) uint32_t desc_version; / / +0x08 Descriptor structure version number uint32_t entry_offset; / / +0x0C The offset of the entry point relative to the Boot1 base address uint32_t init_sp; / / +0x10 Boot1 expects an initial stack pointer uint32_t code_size; / / +0x14 Actual size of Boot1 code (including descriptors) uint32_t min_boot0_ver; / / +0x18 Minimum Boot0 version requirement uint32_t flags; / / +0x1C bit31=REQUIRED_EXTENSION uint32_t desc_checksum; / / +0x20 CRC32 base field uint32_t base_size; / / +0x24: Base field size (=40) uint32_t reserved[6]; / / +0x28: Reserved extended field (24 bytes) } boot1_descriptor_t; / / Total 64 bytes Explanation of the meaning of each field: (a) magic field: fixed value is 0x424F4F54 (corresponding to ASCII characters "B", "O", "O", "T"), used to quickly determine whether the descriptor is valid. When the Flash area is in erase state (all 0xFF), magic is not equal to the magic number, and Boot0 can directly determine that the Boot1 area is invalid.

[0033] (b) version field: The version number of the Boot1 firmware, using BCD encoding (e.g., 0x00010203 represents v1.2.3), used for version comparison to determine whether an upgrade is needed.

[0034] (c) The `desc_version` field: The version number of the descriptor structure itself. When it is necessary to extend the descriptor fields in the future, backward compatibility is achieved through this field: when the old version of Boot0 encounters an unrecognized `desc_version`, it only parses the known fields and ignores the newly added fields.

[0035] (d) entry_offset field: The offset of the Boot1 entry function address relative to the Boot1 base address. The default value in the traditional architecture is 4 (Reset_Handler is located at the vector table offset + 4), but this invention allows Boot1 to freely set the entry point location.

[0036] (e) init_sp field: The initial main stack pointer value expected by Boot1. In traditional architectures, it is read from the first word of the vector table by default. In this invention, after decoupling, it is explicitly specified by the descriptor.

[0037] (f) code_size field: The actual size of the Boot1 code (including the descriptor). Boot0 uses this value to determine the range of Flash that needs to be erased and written when performing an upgrade migration.

[0038] (g) min_boot0_ver field: The minimum Boot0 version number required by the current Boot1. If a new version of Boot1 uses certain new features (such as new flags bit definitions), and these features require Boot0 to resolve correctly, this field is used to declare compatibility. If Boot0's version is lower than this value when it starts up, it will refuse to jump and enter safe recovery mode.

[0039] (h) flags field: Characteristic flags defined bit by bit, such as Bit0=1 indicating that Boot1 supports encrypted upgrade packages, Bit1=1 indicating that it supports compressed upgrade packages, Bit2=1 indicating that it supports differential upgrades, etc. Boot0 adjusts its initialization behavior before jumping based on these flags.

[0040] (i) desc_checksum field: The CRC32 checksum of the first 56 bytes (magic to flags) of the descriptor, used to detect silent data corruption in the Flash.

[0041] Step S102: Read the status information of the embedded system through the first startup module, and determine the upgrade status based on the status information.

[0042] In this embodiment, after upgrading the second boot module, the embedded system will reset and power on again. After power-on, the first boot module will perform basic hardware initialization, including: system clock configuration (setting to main frequency operation), Flash controller configuration (setting wait period, enabling prefetch buffer), independent watchdog initialization (setting timeout to twice the maximum sector erase time of Flash), and necessary GPIO initialization. Next, the first boot module will read the embedded system's status information and determine the upgrade status based on this information. The status information is read from a fixed address in the status identifier area, either as a status word or the last valid information record.

[0043] In one embodiment, the step of reading the status information of the embedded system through the first startup module and determining the upgrade status based on the status information includes: Step S1021: If the status word in the status information matches the preset completion status word combination, then the upgrade status is determined to be upgrade complete.

[0044] Step S1022: If the status word in the status information matches the preset interruption status word combination, then the upgrade status is determined to be an upgrade interruption.

[0045] Step S1023: If the status word in the status information matches the preset abnormal status word combination, then the upgrade status is determined to be an upgrade abnormality.

[0046] In this embodiment, if the embedded system determines that the status word in the status information matches a preset combination of completed status words, then the upgrade status is determined to be "upgrade completed." If the system determines that the status word in the status information matches a preset combination of interrupted status words, then the upgrade status is determined to be "upgrade interrupted." If the system determines that the status word in the status information matches a preset combination of abnormal status words, then the upgrade status is determined to be "upgrade abnormal."

[0047] In one embodiment, if the embedded system determines that the status word in the status information is all 1s (0xFFFFFFFF, the initial value after sector erasure), or that the COMMIT bit has been cleared (upgrade successfully completed), it indicates that the system is in an idle or upgraded state. If the embedded system determines that the status word in the status information indicates that the upgrade is in progress (e.g., the ERASED bit, WRITING bit, VERIFYING bit, etc. have been cleared), it indicates that the last upgrade was interrupted due to a power outage or an abnormality, and the system is in an upgrade interruption state. If the embedded system determines that the status word in the status information is unrecognizable (neither all 1s nor a valid intermediate state), it indicates that the log data is corrupted, and the system is in an upgrade abnormal state.

[0048] Step S103: If the upgrade status is determined to be upgrade complete, the descriptor in the descriptor storage area is read through the first startup module, and the descriptor is verified.

[0049] In this embodiment, if the embedded system determines that the upgrade status is complete, it reads the descriptors in the descriptor storage area of ​​the second startup module through the first startup module and verifies the descriptors. Specifically, the descriptor verification includes magic number verification, cyclic redundancy check results, and compatibility check results. The embedded system determines the verification result of the descriptor based on the magic number verification result, cyclic redundancy check result, and compatibility check result.

[0050] Step S104: If the verification passes, the upgrade of the second startup module is confirmed to be complete.

[0051] In this embodiment, if the embedded system determines that the verification result of the descriptor is passed, it determines that the upgrade of the second startup module is complete.

[0052] In one embodiment, the method further includes: Step S105: When it is determined that the upgrade of the second startup module is completed, the entry address of the second startup module is determined by the first startup module based on the descriptor, and the control of the embedded system is transferred to the second startup module based on the entry address.

[0053] In this embodiment, when the embedded system determines that the second boot module upgrade is complete, it uses the first boot module to determine the entry address of the second boot module based on the descriptor, and then transfers control of the embedded system to the second boot module based on the entry address. In one embodiment, the embedded system reads the entry_offset and init_sp fields from the descriptor through the first boot module, sets the main stack pointer to the init_sp field, then calls the entry function of the second boot module through the function pointer to determine the entry address of the second boot module, and then performs a seamless jump based on the entry address through the function pointer, transferring control of the embedded system to the second boot module.

[0054] In this embodiment, the embedded system, upon receiving an upgrade firmware, upgrades the second boot module based on the upgrade firmware using the first boot module and resets it after the upgrade is complete. The first boot module reads the embedded system's status information and determines the upgrade status based on this information. If the upgrade status is determined to be complete, the first boot module reads the descriptors in the descriptor storage area and verifies them. If the verification passes, the first boot module determines the entry address of the second boot module based on the descriptors and transfers control of the embedded system to the second boot module based on the entry address. The boot parameters of the second boot module in this application are stored as descriptors in the descriptor storage area of ​​the second boot module. The first and second boot modules are decoupled, so that when Boot1 is upgraded, Boot0 is not passively modified; Boot0 only needs to read the descriptors from the descriptor storage area. This solves the structural contradiction that modifying the first boot module during the second boot module upgrade would compromise its non-upgradeability, while not modifying the first boot module would prevent adaptation to changes.

[0055] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating a second embodiment of the embedded boot upgrade method provided in this application. The difference between the second embodiment and the first embodiment is that, upon receiving the upgrade firmware, the step of upgrading the second boot module based on the upgrade firmware by the first boot module includes: Step S201: Upon receiving the upgrade firmware, verify the upgrade firmware and trigger a soft reset after the verification is successful.

[0056] Step S202: The first boot module reads the state bitmap encoding of the embedded system, and performs erase, write, verification and comparison operations on the second boot module based on the state bitmap encoding to complete the upgrade of the second boot module based on the upgrade firmware.

[0057] In this embodiment, when the embedded system receives the upgrade firmware, it verifies the upgrade firmware and triggers a soft reset after the verification is successful. After the soft reset, the first boot module reads the state bitmap encoding of the embedded system and performs erase, write, verification and comparison operations on the second boot module based on the state bitmap encoding to complete the upgrade of the second boot module based on the upgrade firmware.

[0058] In one embodiment, the data structure of the status identifier area includes a sector header structure, a status bitmap encoding, and a page completion bitmap data structure, wherein the sector header structure, the status bitmap encoding, and the page completion bitmap data structure are described as follows: (1) Sector header structure: In order to support multi-sector rotation wear leveling, the first 12 bytes of each log sector are a sector header structure: typedef struct __attribute__((packed)) { uint32_t sector_magic; / / Sector valid identifier 0x4C4F4700 uint32_t generation; / / Monotonically increasing generation counter uint32_t sector_crc; / / Header CRC32 checksum sector_header_t; / / 12 bytes The `sector_magic` field is used to quickly determine whether the sector contains valid information data. The `generation` field is a monotonically increasing counter starting from 1, incrementing by 1 after each complete upgrade process. The `sector_crc` field is used to verify the integrity of the sector header.

[0059] (2) Status bitmap encoding: The status record occupies one 32-bit word. Erasure-free status tracing is achieved by utilizing the single-bit clearing feature of Flash programming (Flash programming can only change a bit from 1 to 0; to change a bit back from 0 to 1, a sector erase must be performed). The status encoding is defined as follows: / / Status bit definition — each bit represents a state stage / / Initial value (after sector erase): 0xFFFFFFFF (all bits = 1) / / When a certain state is reached: Clear the corresponding bit (1 -> 0, no erasure required) #define STATE_IDLE(1u<<0) / / bit0=0: free #define STATE_RECEIVING(1u<<1) / / bit1=0: New firmware being received #define STATE_RECEIVED(1u<<2) / / bit2=0: Reception completed and verification passed #define STATE_ERASING(1u<<3) / / bit3=0: Boot1 old sector erasure in progress #define STATE_ERASED(1u<<4) / / bit4=0: Erase complete #define STATE_WRITING(1u<<5) / / bit5=0: writing page by page #define STATE_WRITTEN(1u<<6) / / bit6=0: Write complete #define STATE_VERIFYING(1u<<7) / / bit7=0: Readback verification in progress #define STATE_COMMIT(1u<<8) / / bit8=0: Upgrade submission complete (3) Page completion bitmap data structure: In order to achieve true fine-grained breakpoint resume, this invention maintains a page completion bitmap (page_bitmap) in the status log area in addition to the status word. This bitmap records the write completion status of each page of the second startup module, so that when power is lost and restored, it can continue from the first unwritten page instead of rewriting all pages.

[0060] typedef struct __attribute__((packed)) { uint32_t state_word; / / Upgrade state word uint32_t new_fw_size; / / Total size of the new firmware (bytes) uint32_t new_fw_checksum; / / CRC32 checksum of the new firmware uint32_t page_total; / / Total number of pages in Boot1 section uint32_t page_bitmap[8]; / / Maximum 256 pages (256 bits) uint32_t record_checksum; / / CRC32 checksum for this record } state_record_v2_t; / / Approximately 48 bytes in total In one embodiment, such as Figure 4 and Figure 5 As shown, Figure 4 A flowchart illustrating the upgrade process for the second startup module provided in this application; Figure 5 This is a schematic diagram illustrating the state transition during the upgrade process provided in this application. The embedded system receives the upgrade firmware. When STATE_IDLE=0 in the status bitmap encoding of the status identifier area, the RECEIVING bit is changed from 1 to 0 via Flash programming, causing the state to transition from IDLE to RECEIVING. After all firmware data has been received and the CRC32 full packet verification passes, the RECEIVED bit in the status bitmap encoding is cleared, and the upgrade firmware is written to the backup area. A soft reset is then triggered, causing the state to transition from RECEIVING to RECEIVED. After the soft reset, the first boot module detects that the RECEIVED bit is cleared and the ERASED bit is still 1, determining that an erasure operation needs to be started. The first boot module clears the ERASING bit and begins Flash sector erasure, causing the state to transition from RECEIVED to ERASING. After all relevant sectors have been erased by the first boot module, the ERASED bit is cleared, causing the state to transition from ERASING to ERASED. The first boot module clears the WRITING bit and begins... Data is read from the backup area and written page by page to the second boot module. After each page is written and verified, the corresponding bit in the page completion bitmap is updated (from 1 to 0), causing the state to transition from ERASED to WRITING. After all pages are written and verified by the first boot module, the WRITTEN bit and VERIFYING bit are cleared. Starting from the starting address of the second boot module, each page is read back and compared byte by byte with the corresponding page in the backup area, causing the state to transition from WRITTEN to VERIFYING. After all data comparisons are successful, the COMMIT bit is cleared by the first boot module, and all status bits are cleared (the status log area is restored to all 1s through sector erasure), indicating that the upgrade is successfully completed, causing the state to transition from VERIFYING to COMMITTING. The first boot module triggers a soft reset, re-enters the IDLE state (status word all 1s), and then jumps to the new second boot module according to the normal boot path, causing the state to transition from COMMITTING to IDLE.

[0061] In this embodiment, the embedded system verifies the upgraded firmware upon receiving it and triggers a soft reset upon successful verification. The first boot module reads the state bitmap encoding of the embedded system and performs erase, write, verification, and comparison operations on the second boot module based on this encoding. This completes the upgrade of the second boot module based on the upgraded firmware, updating the descriptors within it. The first and second boot modules are decoupled. When Boot1 is upgraded, Boot0 is not passively modified; only the descriptors in the second boot module need to be updated. Boot0 only needs to read the descriptors from the descriptor storage area. This resolves the structural contradiction where upgrading the second boot module would compromise the first boot module's non-upgradeability, while not modifying the first boot module would prevent adaptation to changes.

[0062] Please refer to Figure 6 , Figure 6 This is a flowchart illustrating a third embodiment of the embedded boot upgrade method provided in this application. The difference between the third embodiment and the first to second embodiments is that the step of reading the descriptor in the descriptor storage area through the first boot module and verifying the descriptor includes: Step S301: The first startup module reads the descriptor in the descriptor storage area and verifies the fields in the descriptor. The fields include at least two of the following: magic number field, cyclic redundancy check value field, and second startup module version number field.

[0063] In this embodiment, the embedded system reads the descriptor in the descriptor storage area through the first boot module and verifies the fields in the descriptor. The fields include at least two of the following: a magic number field, a cyclic redundancy check (CRC) value field, and a second boot module version number field. Optionally, the first boot module can verify the magic number field and the CRC value field separately, or verify the CRC value field and the second boot module version number field separately. Preferably, the first boot module magic number field, the CRC value field, and the second boot module version number field are verified separately.

[0064] In one embodiment, the field includes a magic number field, a cyclic redundancy check field, and a second startup module version number field. The step of reading the descriptor in the descriptor storage area through the first startup module and validating the fields in the descriptor includes: Step S3011: The first startup module reads the magic number segment of the descriptor in the descriptor storage area and performs magic number verification on the magic number segment to obtain the magic number verification result.

[0065] In this embodiment, the embedded system reads the magic number field of the descriptor in the descriptor storage area through the first boot module, and performs magic number verification on the magic number field to obtain the magic number verification result. Specifically, the magic number field is the magic field. As described above regarding the descriptor, the magic field has a fixed value of 0x424F4F54. If the magic field is equal to the fixed value 0x424F4F54, the magic number verification result is that the magic number verification passes; if the magic field is not equal to the fixed value 0x424F4F54, the magic number verification result is that the magic number verification fails.

[0066] Step S3012: The first startup module reads the cyclic redundancy check value field of the descriptor in the descriptor storage area, calculates the first cyclic redundancy calculation value of the first preset byte before the descriptor, and performs cyclic redundancy check based on the first cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy check result.

[0067] In this embodiment, the embedded system reads the cyclic redundancy check (CRC) value field of the descriptor in the descriptor storage area through the first startup module and calculates the first CRC calculation value of the first preset byte before the descriptor. The first CRC calculation value is compared with the CRC check value field. If the first CRC calculation value and the CRC check value field are the same, the CRC check result is determined to be successful; if the first CRC calculation value and the CRC check value field are different, the CRC check result is determined to be unsuccessful. Specifically, the first preset byte is the first 56 bytes, and the CRC check is a 32-bit CRC check. That is, the first startup module reads the first 56 bytes of the descriptor in the descriptor storage area to calculate the CRC32 calculation value, and the CRC check value field is the desc_checksum field. The CRC32 calculation value and the desc_checksum field are then compared.

[0068] Step S3013: The second startup module version number field of the descriptor in the descriptor storage area is read by the first startup module, and a compatibility check is performed on the second startup module version number field to obtain the compatibility check result.

[0069] In this embodiment, the embedded system reads the second startup module version number field of the descriptor in the descriptor storage area through the first startup module, and performs a compatibility check on the second startup module version number field to obtain a compatibility check result. The second startup module version number field is the `desc_version` field. The compatibility check enables the first startup module to securely negotiate with the second startup module based on its highest supported descriptor version number to determine if the conditions for control transfer are met. This check mechanism allows the first startup module to securely adapt to dozens of iterations of the second startup module without upgrades throughout the product lifecycle.

[0070] Step S302: Based on the verification results of all the fields, determine the verification result of the descriptor.

[0071] In this embodiment, the embedded system determines the descriptor's verification result based on the verification results of all fields through the first startup module. It can be understood that the first startup module verifies the magic number field and the cyclic redundancy check value field separately, and then determines the descriptor's verification result based on the verification results of the magic number field and the cyclic redundancy check value field; the first startup module verifies the cyclic redundancy check value field and the second startup module version number field separately, and then determines the descriptor's verification result based on the verification results of the cyclic redundancy check value field and the second startup module version number field; the first startup module verifies the magic number field and the second startup module version number field separately, and then determines the descriptor's verification result based on the verification results of the magic number field and the second startup module version number field.

[0072] Preferably, in one embodiment, the step of determining the verification result of the descriptor based on the verification results of all the fields includes: Step S3021: Based on the magic number verification result, the cyclic redundancy check result, and the compatibility check result, determine the verification result of the descriptor.

[0073] In this embodiment, the embedded system determines the descriptor's verification result based on the magic number check result, cyclic redundancy check result, and compatibility check result through the first startup module. Specifically, if the magic number check result, cyclic redundancy check result, and compatibility check result are all passed, the descriptor's verification result is determined to be passed; if any one of the magic number check result, cyclic redundancy check result, and compatibility check result is failed, the descriptor's verification result is determined to be failed.

[0074] In this embodiment, after the second startup module upgrade is completed, the embedded system performs magic number verification, cyclic redundancy check, and compatibility check on the descriptor updated by the second startup module to determine the verification result of the descriptor. By verifying the dimensions, the reliability of the second startup module upgrade is improved, and it also helps to improve the reliability of the subsequent control of the embedded system by the second startup module.

[0075] Please refer to Figure 7 , Figure 7 This is a flowchart illustrating the fourth embodiment of the embedded boot upgrade method provided in this application. The difference between the fourth embodiment and the first to third embodiments is that the step of performing compatibility verification on the second boot module version number field to obtain the compatibility verification result includes: Step S401: Compare the version number field of the second startup module with the version number of the first startup module.

[0076] Step S402: If the version number field of the second startup module is not greater than the version number of the first startup module, then the compatibility verification result is determined to be passed.

[0077] In this embodiment, the embedded system reads the version number field of the second startup module through the first startup module, compares the version number field of the second startup module with the version number of the first startup module, and if the version number field of the second startup module is not greater than the version number of the first startup module, the compatibility verification result can be directly determined to be passed. Specifically, the version number field of the second startup module is the desc_version field in the descriptor, and the version number of the first startup module is usually represented by the BOOT0_MAX_DESC_VERSION field, that is, the desc_version field is compared with the BOOT0_MAX_DESC_VERSION field.

[0078] Step S403: If the version number field of the second startup module is greater than the version number of the first startup module, then the compatibility verification result is determined based on the basic field size field of the descriptor in the descriptor storage area and the bit-defined characteristic flag field.

[0079] In this embodiment, the embedded system determines that the version number field of the second startup module is greater than the version number of the first startup module through the first startup module. Then, it reads the basic field size field and the bit-defined characteristic flag field of the descriptor in the descriptor storage area, and verifies the basic field size field and the bit-defined characteristic flag field respectively. Based on the verification results of the basic field size field and the bit-defined characteristic flag field, the compatibility verification result is determined.

[0080] In one embodiment, the step of determining the compatibility check result based on the basic field size field and the bitwise defined characteristic flag field of the descriptor in the descriptor storage area includes: Step S4031: Calculate the second cyclic redundancy calculation value of the second preset byte before the descriptor based on the basic field area size field, and perform cyclic redundancy verification based on the second cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy check result.

[0081] Step S4032: Perform flag bit analysis based on the bit-defined characteristic flag bit field to obtain the flag bit analysis result.

[0082] In this embodiment, the embedded system compares the version number field of the second startup module with the version number of the first startup module through the first startup module. If it is determined that the version number field of the second startup module is greater than the version number of the first startup module, then it reads the base field size field and the bit-defined characteristic flag field of the descriptor in the descriptor storage area. In one embodiment, the base field size field is the base_size field, and the bit-defined characteristic flag field is bit 31 of the flags field (REQUIRED_EXTENSION flag).

[0083] The embedded system calculates the second cyclic redundancy calculation value of the second preset byte before the descriptor based on the base field area size field through the first startup module, and performs cyclic redundancy verification based on the second cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy verification result. In one embodiment, the first startup module determines the size of the base field area (defined as 40 bytes) based on the base_size field, and then calculates the second cyclic redundancy calculation value of the first 40 bytes of the descriptor. CRC32 verification is performed only on the base fields within the base_size range (the verification range is precisely limited to base_size bytes), ignoring unknown extended fields. That is, the second cyclic redundancy calculation value and the cyclic redundancy check value field are compared. If the second cyclic redundancy calculation value and the cyclic redundancy check value field are the same, the cyclic redundancy verification result is passed; if the second cyclic redundancy calculation value and the cyclic redundancy check value field are different, the cyclic redundancy verification result is failed. It should be noted that the base_size field is determined by the second startup module during compilation, rather than being inferred by the first startup module. This avoids the risk of the first startup module "guessing" the boundaries of the base field. The base field area (the first 40 bytes) is a stable interface that remains unchanged across versions. The information contained therein, such as magic, entry_offset, init_sp, code_size, and min_boot0_ver, must be provided to the first startup module by the second startup module in any version, and its semantics never change.

[0084] The embedded system performs flag bit analysis based on bitwise defined characteristic flag fields through the first boot module to obtain the flag bit analysis results. In one embodiment, if the REQUIRED_EXTENSION flag is 0, it indicates that the newly added fields of the descriptor after the upgrade of the second boot module are all optional extensions (such as newly added encryption algorithm declarations, compression algorithm declarations, etc.). The first boot module safely ignores these fields and can jump normally to the second boot module according to the parsing results of the basic fields, obtaining a flag bit analysis result that meets the preset conditions. If the REQUIRED_EXTENSION flag is 1, it indicates that the newly added fields of the descriptor after the upgrade of the second boot module introduce mandatory new features (such as new secure boot protocols) that the first boot module does not understand and that are necessary for the operation of the second boot module. The first boot module refuses to jump, obtaining a flag bit analysis result that does not meet the preset conditions. It should be noted that the REQUIRED_EXTENSION flag is carefully set by the developers of the second boot module based on the security impact of the new features. It is only set when the new features are indeed "unsafe to operate without," avoiding unnecessary triggering of recovery modes due to excessive conservatism.

[0085] Step S4033: If the cyclic redundancy check result is passed and the flag analysis result meets the preset conditions, then the compatibility check result is determined to be passed.

[0086] Step S4034: If the cyclic redundancy check result is unsuccessful or the flag analysis result does not meet the preset conditions, then the compatibility check result is determined to be unsuccessful.

[0087] In this embodiment, if the embedded system determines that the cyclic redundancy check result is passed and the flag bit analysis result meets the preset conditions, then the compatibility check result is determined to be passed. If the cyclic redundancy check result is determined to be failed or the flag bit analysis result does not meet the preset conditions, then the compatibility check result is determined to be failed.

[0088] It should be noted that during the lifecycle of an embedded system, the second boot module will continuously iterate, and the following scenarios may occur: A new version of the second boot module adds new optional fields to the descriptor (such as declaring supported encryption algorithm types); a new version of the second boot module changes the internal Flash layout, requiring the addition of new parameters to the descriptor; a new version of the second boot module introduces a completely new secure boot protocol, and the old version of the first boot module may cause security vulnerabilities if it jumps to execute without knowing this. In traditional solutions, when the first boot module encounters an unfamiliar descriptor version, it can only handle it in two ways: 1. Directly and blindly jump (insecure); 2. Refuse to jump and enter recovery mode (too conservative, requiring a synchronous upgrade of the first boot module every time the second boot module adds optional fields). Therefore, the compatibility verification in this application, through a descriptor multi-version negotiation protocol, allows the first boot module to securely adapt to any future version of the second boot module without upgrading. By precisely defining the boundaries of the basic fields using the `base_size` field and providing a security decision basis using the `REQUIRED_EXTENSION` flag, the first boot module jumps normally when the second boot module adds optional new features, and only enters recovery mode when the second boot module introduces mandatory incompatible changes. This resolves the fundamental contradiction of the first startup module being fixed and the second startup module continuously evolving and upgrading throughout the entire lifecycle of an embedded system.

[0089] Please refer to Figure 8 , Figure 8 This is a flowchart illustrating the fifth embodiment of the embedded Boot upgrade method provided in this application. The difference between the fifth embodiment and the first to fourth embodiments is that the method further includes: Step S501: If it is determined that the upgrade status is an upgrade error or the verification result of the descriptor is a failure, then the preset security recovery interface is initialized through the first startup module, and the security recovery firmware file is received.

[0090] Step S502: The first boot module verifies the security recovery firmware file and writes it into the second boot module so that the second boot module returns to normal.

[0091] In this embodiment, if the embedded system determines through the first boot module that the upgrade status is an upgrade error or the descriptor verification result is a failure, it initializes a preset security recovery interface through the first boot module, receives a security recovery firmware file, verifies the security recovery firmware file through the first boot module, and writes it to the second boot module, so that the second boot module returns to normal. That is, the first boot module enters the security recovery mode, thus avoiding an infinite reboot or stuck state. The security recovery mode is the last line of defense for the anti-bricking mechanism of this application.

[0092] In one embodiment, Boot0 automatically enters secure recovery mode when any of the following conditions are triggered: (a) the magic field of the second boot module's descriptor is not equal to 0x424F4F54; (b) the CRC32 check of the second boot module's descriptor fails; (c) the version number of the first boot module is lower than min_boot0_ver; (d) the same stage of upgrading the state machine fails more than 3 times; (e) the value of the status word is not within the legal range (data corruption). The workflow of secure recovery mode is as follows: 1) After entering secure recovery mode, the first boot module indicates to the outside world that the device is in recovery mode through a specific signal (rapidly flashing LED). 2) The first boot module initializes specific interfaces, such as serial port and CAN, and waits for the host computer to send the secure recovery firmware file through a specific protocol. 3) The first boot module receives data frames and performs CRC check frame by frame. 4) The first boot module directly writes the received firmware data to the second boot module (skipping status log recording, because this is a manually intervened recovery operation). 5) After all data is received, the first boot module verifies the newly written descriptor of the second boot module. After successful verification, a specific signal indicates success, followed by a soft reset. 6) If transmission is interrupted or descriptor verification fails, wait for the host computer to resend. The key design principle of the secure recovery mode is that its code size is extremely small (a few hundred bytes), relying only on the most basic interface drivers and Flash page programming functions, sharing the same trust domain with the remaining functional code of the first boot module. Because it is located in the "never-upgraded" area of ​​the first boot module, the correctness of the code has been fully verified before leaving the factory. As long as the MCU's Flash controller and UART physical interface are not damaged, this recovery channel will always be available.

[0093] The embedded system in this embodiment incorporates a minimalist secure recovery mode within the first boot module. When the second boot module descriptor verification fails or multiple retries to upgrade the state machine fail, the first boot module automatically enters recovery mode, receiving the secure recovery firmware file via the hardware UART interface and directly writing it to the second boot module. Because the code for this secure recovery mode is extremely small and located in the "never-upgraded" Boot0, it provides the system with a final, indestructible recovery path, effectively preventing it from falling into an infinite reboot or stuck state.

[0094] Please refer to Figure 9 , Figure 9 This is a flowchart illustrating the fifth embodiment of the embedded Boot upgrade method provided in this application. The difference between the fifth embodiment and the first to fourth embodiments is that the method further includes: Step S601: If the upgrade status is determined to be an upgrade interruption, the first startup module locates the interruption location based on the status information.

[0095] Step S602: Based on the interruption location and the upgrade firmware, continue the process of upgrading the second boot module.

[0096] In this embodiment, if the embedded system determines that the upgrade status is an upgrade interruption, the first startup module locates the interruption location based on the status information. Based on the interruption location and the upgrade firmware, the upgrade process for the second startup module continues. Specifically, based on the status information, if the first startup module determines that ERASING=0 and ERASED=1, it determines that the upgrade interruption is in the ERASING state, and the first startup module re-executes the complete erase operation; if it determines that WRITING=0 and WRITTEN=1, it determines that the upgrade interruption is in the WRITING state, the first startup module traverses the page_bitmap, finds the first page number resume_page with bit=1, and continues writing from resume_page, without repeating the operation on already written pages; if it determines that VERIFYING=0 and COMMIT=1, it determines that the upgrade interruption is in the VERIFYING state, and the first startup module re-executes the full-area readback verification from the beginning; if it determines that COMMIT=0, it determines that the upgrade interruption is in the COMMITTING state, and the first startup module triggers a soft reset after completing the status word clearing operation.

[0097] It's important to note that Flash page programming operations are guaranteed to be atomic by hardware. A page programming command either executes completely or not at all; there is no "half-page write" state. Bitmap updates are performed after a page write is successful. Therefore, a page with bit=1 has definitely not been successfully written (or it has been written but the bitmap hasn't been updated; in this case, rewriting the page is idempotent). New firmware data in the backup area is retained unmodified throughout the entire upgrade process until the COMMITTING phase, at which point the status log is cleared. Therefore, data sources are not lost even if power is lost at any time. Based on these principles, interruption recovery is possible.

[0098] The embedded system in this embodiment locates the interruption position based on status information using a first startup module. Based on the interruption position and the upgrade firmware, the process of upgrading the second startup module continues. This improves the accuracy of locating the interruption position after an upgrade interruption, while also increasing the efficiency of the upgrade process.

[0099] Please refer to the following for specific implementation: Figure 10 , Figure 10This application provides a complete flowchart of the embedded boot upgrade process. After the first boot module powers on, it reads the status information of the embedded system and determines the upgrade status based on the status information. If the upgrade status is determined to be complete, the first boot module reads the descriptor in the descriptor storage area and verifies the descriptor. If the verification passes, the first boot module determines the entry address of the second boot module based on the descriptor and transfers control of the embedded system to the second boot module based on the entry address. If the upgrade status is determined to be interrupted, the first boot module locates the interruption location based on the status information. Based on the interruption location and the upgrade firmware, it continues to execute the upgrade process for the second boot module. If the upgrade status is determined to be abnormal or the descriptor verification result is unsuccessful, the first boot module initializes the preset security recovery interface and receives the security recovery firmware file. The first boot module verifies the security recovery firmware file and writes it to the second boot module to restore the second boot module to normal operation.

[0100] refer to Figure 11 , Figure 11 This is a schematic diagram of the embedded boot upgrade device provided in this application. The embedded boot upgrade device includes: The upgrade module 10 is used to upgrade the second startup module based on the upgrade firmware through the first startup module when the upgrade firmware is received, and to reset it after the upgrade is completed.

[0101] The judgment module 20 is used to read the status information of the embedded system through the first startup module and judge the upgrade status based on the status information.

[0102] The verification module 30 is used to read the descriptors in the descriptor storage area through the first startup module and verify the descriptors if the upgrade status is determined to be complete.

[0103] The determination module 40 is used to determine the entry address of the second startup module based on the descriptor through the first startup module if the verification passes, and to transfer control of the embedded system to the second startup module based on the entry address.

[0104] It is understood that the embedded boot upgrade device in this embodiment corresponds to the embedded boot upgrade method in the above embodiment. The options in the above embodiment are also applicable to this embodiment, so they will not be described again here.

[0105] This application also provides an analyzer, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the above-described embedded boot upgrade method by running the computer program.

[0106] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0107] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0108] This application also provides a computer storage medium for storing the computer program used in the aforementioned analyzer. The computer storage medium can be a readable storage medium, a non-volatile storage medium, or a volatile storage medium. For example, the computer storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0110] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0111] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an analyzer (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0112] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An embedded boot upgrade method, characterized in that, The method is applied to an embedded system, the embedded system including a first boot module and a second boot module, wherein the descriptor of the second boot module is stored in a descriptor storage area in the second boot module, and the method includes: Upon receiving the upgrade firmware, the first boot module upgrades the second boot module based on the upgrade firmware, and then resets it after the upgrade is completed. The first startup module reads the status information of the embedded system and determines the upgrade status based on the status information. If the upgrade status is determined to be upgrade complete, the descriptor in the descriptor storage area is read through the first startup module, and the descriptor is verified. If the verification passes, the upgrade of the second startup module is confirmed to be complete.

2. The embedded boot upgrade method according to claim 1, characterized in that, The step of upgrading the second boot module based on the upgraded firmware by the first boot module upon receiving the upgraded firmware includes: Upon receiving the upgrade firmware, the upgrade firmware is verified, and a soft reset is triggered after the verification passes. The first boot module reads the state bitmap encoding of the embedded system and performs erase, write, verification and comparison operations on the second boot module based on the state bitmap encoding to complete the upgrade of the second boot module based on the upgrade firmware.

3. The embedded boot upgrade method according to claim 1, characterized in that, The step of reading descriptors from the descriptor storage area through the first startup module and verifying the descriptors includes: The first startup module reads the descriptor in the descriptor storage area and verifies the fields in the descriptor. The fields include at least two of the following: magic number field, cyclic redundancy check value field, and second startup module version number field. Based on the validation results of all the fields, the validation result of the descriptor is determined.

4. The embedded boot upgrade method according to claim 3, characterized in that, The fields include a magic number field, a cyclic redundancy check field, and a second startup module version number field. The step of reading the descriptor in the descriptor storage area through the first startup module and validating the fields in the descriptor includes: The first startup module reads the magic number field of the descriptor in the descriptor storage area and performs magic number verification on the magic number field to obtain the magic number verification result. The first startup module reads the cyclic redundancy check value field of the descriptor in the descriptor storage area, calculates the first cyclic redundancy calculation value of the first preset byte before the descriptor, performs cyclic redundancy check based on the first cyclic redundancy calculation value and the cyclic redundancy check value field, and obtains the cyclic redundancy check result. The first startup module reads the second startup module version number field of the descriptor in the descriptor storage area and performs a compatibility check on the second startup module version number field to obtain the compatibility check result.

5. The embedded boot upgrade method according to claim 4, characterized in that, The step of performing compatibility verification on the second startup module version number field to obtain the compatibility verification result includes: Compare the version number field of the second startup module with the version number of the first startup module; If the version number field of the second startup module is not greater than the version number of the first startup module, then the compatibility verification result is determined to be passed; If the version number field of the second startup module is greater than the version number of the first startup module, then the compatibility check result is determined based on the base field size field of the descriptor in the descriptor storage area and the bit-defined characteristic flag field.

6. The embedded boot upgrade method according to claim 5, characterized in that, The step of determining the compatibility check result based on the basic field size field and the bit-defined characteristic flag field of the descriptor in the descriptor storage area includes: The second cyclic redundancy calculation value of the second preset byte before the descriptor is calculated based on the basic field area size field, and cyclic redundancy verification is performed based on the second cyclic redundancy calculation value and the cyclic redundancy check value field to obtain the cyclic redundancy check result; Flag bit analysis is performed based on the bit-defined characteristic flag bit field to obtain the flag bit analysis results; If the cyclic redundancy check result is passed and the flag analysis result meets the preset conditions, then the compatibility check result is determined to be passed. If the cyclic redundancy check result is unsuccessful or the flag analysis result does not meet the preset conditions, then the compatibility check result is determined to be unsuccessful.

7. The embedded boot upgrade method according to claim 1, characterized in that, The step of reading the status information of the embedded system through the first startup module and determining the upgrade status based on the status information includes: If the status word in the status information matches a preset combination of completed status words, then the upgrade status is determined to be completed. If the status word in the status information matches a preset interruption status word combination, then the upgrade status is determined to be an upgrade interruption. If the status word in the status information matches a preset abnormal status word combination, then the upgrade status is determined to be an upgrade abnormality.

8. The embedded boot upgrade method according to claim 1, characterized in that, The method further includes: When the upgrade of the second startup module is completed, the first startup module determines the entry address of the second startup module based on the descriptor, and transfers control of the embedded system to the second startup module based on the entry address.

9. The embedded boot upgrade method according to claim 1, characterized in that, The method further includes: If the upgrade status is determined to be an upgrade anomaly or the verification result of the descriptor is a failure, then the preset security recovery interface is initialized through the first startup module, and the security recovery firmware file is received; The first boot module verifies the security recovery firmware file and writes it into the second boot module, so that the second boot module can return to normal.

10. The embedded boot upgrade method according to claim 1, characterized in that, The method further includes: If the upgrade status is determined to be an upgrade interruption, the first startup module locates the interruption location based on the status information. Based on the interruption location and the upgraded firmware, the process of upgrading the second boot module continues.

11. An embedded boot upgrade device, characterized in that, The embedded boot upgrade device includes: The upgrade module is used to upgrade the second startup module based on the upgrade firmware through the first startup module when the upgrade firmware is received, and to reset it after the upgrade is completed; The judgment module is used to read the status information of the embedded system through the first startup module and judge the upgrade status based on the status information; The verification module is used to read the descriptors in the descriptor storage area through the first startup module and verify the descriptors if the upgrade status is determined to be upgrade complete. The determination module is used to determine that the upgrade of the second startup module is complete if the verification passes.

12. An analyzer, characterized in that, The analyzer includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the embedded boot upgrade method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a processor, executes the embedded boot upgrade method according to any one of claims 1-10.

Images