Method for upgrading operating system based on bluetooth of RISC-V architecture chip

Abstract

The application discloses a method for upgrading an operating system based on a Bluetooth of a RISC-V architecture chip, and relates to the technical field of system upgrading. An upgrading context is formed through a Bluetooth upgrading session, the upgrading context forms a component compatibility graph, a compatible upgrading object set and a target write mapping, the target write mapping forms a block source description, a rollback consistent transaction unit and a rollback consistent update directed graph, the rollback consistent update directed graph and a Bluetooth link state form an encoding transmission group and a Bluetooth encoding fragment stream, the Bluetooth encoding fragment stream forms an inactive operating system region write result, an upgrading transaction log and a recoverable progress mapping, the recoverable progress mapping forms a mirror integrity flag, the mirror integrity flag forms a trial start description and trial start evidence, the trial start evidence forms an upgrading decision, the upgrading decision forms a start selection record, and the start selection record forms a current operating system list and an operating system upgrading result.

Description

Technical Field

[0001] This invention relates to the field of crack detection technology, and in particular to a method for upgrading the operating system of a RISC-V architecture chip based on Bluetooth. Background Technology

[0002] The RISC-V architecture allows chips to combine processor word length, basic instruction set, standard extensions, custom extensions, privileged modes, and physical memory protection capabilities according to application requirements. Chips in the same product family may correspond to different instruction set extensions, storage capacities, and peripheral configurations. The operating system kernel, device tree, drivers, and root file system need to be consistent with the actual chip capabilities.

[0003] Existing Bluetooth upgrade solutions typically involve the upgrade terminal sending either a full image or a differential image. After receiving the upgrade data, the device writes it to a spare partition, completes the image hash verification, modifies the startup partition, and restarts. Resuming interrupted transmissions usually only records the offset of the received data, and Bluetooth retransmissions usually only resend the same segment based on packet loss.

[0004] The above processing does not establish a continuous relationship between RISC-V capability differences, object dependencies, local block reuse, Bluetooth redundant transmission, transaction-level recovery, and new system trial startup. The whole packet signature cannot prove that the target object is compatible with the current chip, the receive offset cannot prove that the written content and the preceding object have been completed, and directly switching the boot partition may make it difficult to automatically return to the original operating system after the upgrade fails. There are also issues such as the target operating system upgrade object not matching the capabilities of the RISC-V architecture chip, Bluetooth link fluctuations causing repeated transmission of upgrade segments, inconsistent receive progress and actual write status after upgrade interruption, and the target operating system modifying the boot selection record before completing a valid trial startup. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] Therefore, this invention provides a method for upgrading the operating system of a RISC-V architecture chip based on Bluetooth, which solves the problems of mismatch between the target operating system upgrade object and the capabilities of the RISC-V architecture chip, repeated transmission of upgrade segments due to Bluetooth link fluctuations, inconsistency between the receiving progress and the actual writing status after the upgrade is interrupted, and modification of the boot selection record before the target operating system has completed a valid trial boot.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a method for Bluetooth-based upgrade operations of a RISC-V architecture chip, comprising, S1. Establish a Bluetooth upgrade session between the RISC-V architecture chip and the upgrade terminal, obtain the RISC-V architecture chip capability description, current operating system list, storage partition status, Bluetooth link status and target operating system upgrade list, and form an upgrade context. S2. Based on the upgrade context, the target operating system upgrade package is parsed into target upgrade objects. A component compatibility graph is constructed based on the instruction set extension requirements, word length requirements, privileged mode requirements, storage requirements, and object dependencies of each target upgrade object. A set of compatible upgrade objects is formed based on the component compatibility graph. A target write mapping is formed based on the set of compatible upgrade objects and the storage partition status. S3. Based on the target write mapping, compare the compatible upgrade object with the corresponding object in the current operating system in blocks, and form a block source description with a value of either local copy type or Bluetooth download type based on the block comparison result; Based on the block source description, target partition boundary, and startup dependency, rollback consistent transaction units are formed, and each rollback consistent transaction unit can be written and verified independently; a rollback consistent update directed graph is formed based on the preceding relationships between each rollback consistent transaction unit. S4. Based on the topological order of the rollback consistent update directed graph and the Bluetooth link state, form coded transmission groups. Determine the payload length and number of coded segments for each coded transmission group based on the Bluetooth link state. Perform systematic erasure coding on the source segments in the coded transmission groups to form a Bluetooth coded segment stream. S5. Reconstruct the corresponding rollback consistent transaction unit according to the Bluetooth encoded fragment stream. After the target hash verification of the reconstructed content passes, write the rollback consistent transaction unit to the inactive operating system area and write the write verification result to the upgrade transaction log in sequence. Form a recoverable progress mapping according to the upgrade transaction log. S6. After confirming that all rollback consistent transaction units in the directed graph of the rollback consistent update are completed according to the recoverable progress mapping, a mirror root hash is formed based on the inactive operating system region, and a mirror integrity flag is formed based on the comparison result between the mirror root hash and the target operating system upgrade list. Based on the image integrity flag, a trial boot description is generated, and an inactive operating system region is launched within the physical memory protection range configured by the machine mode startup monitoring program, thus forming evidence of a trial boot. S7. Based on the trial boot evidence, determine an upgrade decision from the upgrade submission decision and the upgrade rollback decision. When determining the upgrade submission decision, atomically update the boot selection record to select the inactive operating system region. When determining the upgrade rollback decision, maintain the original operating system region and the original boot selection record. S8. Update the current operating system list based on the boot selection record, and form the operating system upgrade result based on the upgrade context, component compatibility graph, rollback consistent update directed graph, recoverable progress mapping, trial boot evidence, and the determined upgrade decision.

[0008] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip described in this invention, wherein: The machine mode startup monitoring program generates a RISC-V architecture chip capability description and a current operating system list based on the chip's implementation capabilities and startup metadata. The Bluetooth controller determines the Bluetooth link status based on connection parameters and segment reception statistics; An upgrade context is formed only when the protected root public key verifies the validity of the target operating system upgrade manifest digital signature.

[0009] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: The target operating system upgrade package is parsed into a target upgrade object that has capability requirements, target hash, and prerequisite upgrade objects; Based on capability requirements, a single-object compatibility result is generated; based on the preceding upgrade objects, a component compatibility diagram is generated. Only target upgrade objects that are compatible with both single objects and their predecessor upgrade objects are added to the compatible upgrade object set, forming a target write mapping that satisfies the partition type, target size, and alignment length.

[0010] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: The same content is used to define the block segmentation rules to process the compatibility upgrade object and the object corresponding to the current operating system, forming a block source description with a value of either local copy type or Bluetooth download type; A rollback consistent transaction unit is formed that saves the target address, target hash, and set of preceding transaction units without crossing the target partition boundary and startup dependency boundary. A rollback consistent update directed graph and topological order are formed based on the relationships between preceding transaction units.

[0011] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: The segment loss estimate is formed based on the segment reception statistics, and the effective payload length of the encoded segment is formed based on the maximum transmission unit, protocol overhead, and single write length. The encoded transmission groups are formed according to the topological order. The number of encoded segments is determined based on the number of source segments, the estimated number of lost segments, and the number of secure segments. Systematic erasure coding is then used to form a Bluetooth encoded segment stream.

[0012] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: When the coding coefficient matrix is ​​at full rank, the coding transmission group is reconstructed, and the content to be written is formed into a transaction unit based on the block source description. Write to the target address and perform post-write verification when the target hash is valid and the preceding transaction unit is completed; An upgrade transaction log is formed based on the hash of the previous log record, the transaction unit identifier, the target hash, and the write verification status. After power failure and recovery, the upgrade continues from the last record with continuous hash and valid write verification.

[0013] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: A trial startup description is generated when the recoverable progress map covers all transaction units, the image root hash is consistent, and the digital signature of the target operating system upgrade manifest is valid. The machine mode startup monitoring program configures the physical memory protection range according to the trial startup description and starts the inactive operating system region, forming trial startup evidence based on the startup entry point, kernel initialization, system services, device initialization, and watchdog monitoring points.

[0014] As a preferred embodiment of the method for Bluetooth-based upgrade operation of a RISC-V architecture chip according to the present invention, wherein: If the image integrity flag and all trial startup flags are valid, an upgrade submission decision is made; otherwise, an upgrade rollback decision is made. The startup selection record uses a master record and a backup record with a monotonically increasing counter and a record check value; after confirming the upgrade submission decision, the backup record is written to and verified first, and then the master record is written to. Once the upgrade rollback decision is confirmed, the original boot selection record will be retained. Upon restart, select the record with valid verification and the highest count.

[0015] Secondly, this invention provides a RISC-V architecture chip with an operating system that can be upgraded via Bluetooth, including: The upgrade context formation module is used to establish a Bluetooth upgrade session and form an upgrade context; The compatibility mapping module is used to generate component compatibility graphs, sets of compatible upgrade objects, and target write mappings. The transaction graph construction module is used to form a block source description, rollback consistent transaction unit, and rollback consistent update directed graph; The Bluetooth encoding and transmission module is used to form encoding and transmission groups and Bluetooth encoding fragment streams based on the rollback consistent update directed graph and Bluetooth link state. The recoverable write module is used to reconstruct and rollback consistent transaction units, write to inactive operating system regions, and form upgrade transaction logs and recoverable progress maps. The isolated test boot module is used to generate image integrity flags and test boot descriptions, and to generate test boot evidence within the scope of physical memory protection. The atomic switching module is used to determine an upgrade decision from the upgrade commit decision and the upgrade rollback decision based on the trial start evidence and to process the start selection record; The upgrade result generation module is used to update the current operating system list and generate the operating system upgrade result.

[0016] The beneficial effects of this invention are as follows: the target operating system upgrade package is decomposed into target upgrade objects with chip capability requirements and prerequisite relationships. Then, a set of compatible upgrade objects is formed based on the compatibility results of a single object and the compatibility results of all prerequisite upgrade objects. The number of Bluetooth segments changes with the estimated value of segment loss. The receiving end reconstructs the source segment after the coding coefficient matrix reaches full rank. The transaction log forms a recoverable progress mapping. After the recoverable progress mapping is completed, a trial start under physical memory protection constraints is entered. The trial start evidence determines the atomic processing of the start selection record, thereby achieving the goal of simultaneously constraining chip capabilities and object prerequisite relationships in the component compatibility graph. Incompatible target upgrade objects are excluded before writing. Local copy blocks and systematic erasure coding reduce Bluetooth transmission volume and the number of repeated transmissions per chip. The hash-continuous upgrade transaction log ensures that the power-off recovery position is consistent with the actual write state. The trial start under physical memory protection constraints retains the original operating system area and startup metadata. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of the overall process for a Bluetooth-based upgrade operation method for a RISC-V architecture chip in Example 1.

[0019] Figure 2 This is a system flowchart of a RISC-V architecture chip for upgrading the operating system based on Bluetooth, as shown in Example 1.

[0020] Figure 3 The flowchart for the component compatibility processing and rollback consistent update directed graph formation in Example 1 is shown.

[0021] Figure 4 This is a flowchart of Bluetooth encoding transmission, transaction writing, and breakpoint recovery in Example 1.

[0022] Figure 5 This is a flowchart of the isolation trial startup and startup selection recording atomic processing in Example 1. Detailed Implementation

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0024] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0025] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0026] The upgrade terminal stores the target operating system upgrade package and the target operating system upgrade list signed by the publisher. The upgrade package includes the kernel, device tree, drivers and root file system. The upgrade list stores the object identifier, target hash, capability requirements, target size, partition type and preceding upgrade objects. The machine mode startup monitoring program stores the publisher's root public key, startup selection record and upgrade log start area.

[0027] Example 1, referring to Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 5 This is the first embodiment of the present invention, which provides a method for upgrading a RISC-V architecture chip based on Bluetooth, including the following steps: S1. Establish a Bluetooth upgrade session between the RISC-V architecture chip and the upgrade terminal, obtain the RISC-V architecture chip capability description, current operating system list, storage partition status, Bluetooth link status and target operating system upgrade list, and form an upgrade context. Specifically, the data processor encapsulates the signed and valid target operating system upgrade list, RISC-V architecture chip capability description, current operating system list, storage partition status, and Bluetooth link status according to the upgrade session identifier. The upgrade context is a custom technical term in this invention, representing the versioned input object used in a single Bluetooth upgrade session. The expression for the upgrade context denoted by a Bluetooth upgrade session is:

[0028] In the formula, Upgrade the Bluetooth session index. This data was read from the monitoring program that started in machine mode. Architecture chip capability description, The list of current operating systems derived from the currently active operating system region. The storage partition status is derived from the startup metadata. The Bluetooth link status originates from the Bluetooth controller. A list of target operating system upgrades that have passed digital signature verification. This indicates that the session is encapsulated according to a fixed field order and the upgrade session version.

[0029] Each item in the upgrade context stores the data source, read time, and validity flag. The upgrade is terminated when any of the following conditions occur: invalid signature, missing chip capability description, or inconsistent partition status. A valid upgrade context then enters component compatibility processing.

[0030] S2. Based on the upgrade context, the target operating system upgrade package is parsed into target upgrade objects. A component compatibility graph is constructed based on the instruction set extension requirements, word length requirements, privileged mode requirements, storage requirements, and object dependencies of each target upgrade object. A set of compatible upgrade objects is formed based on the component compatibility graph. A target write mapping is formed based on the set of compatible upgrade objects and the storage partition status. The data processor parses the target operating system upgrade package according to the target operating system upgrade list, forming kernel objects, device tree objects, driver objects, and root file system objects. The target upgrade object represents the operating system upgrade content with an independent object identifier, target hash, capability requirements, and object prerequisite relationships. The target upgrade object is formed by parsing the target operating system upgrade package sent by the upgrade terminal and is not directly output by the RISC-V architecture chip hardware interface. When the data processor satisfies the requirements for instruction set extension, processor word length, privileged mode, and memory space, it generates a valid single-object compatibility result. Then, it retrieves all preceding upgrade objects along the component compatibility graph. The target upgrade object that is compatible with both the single object and all preceding upgrade objects is added to the compatible upgrade object set. The expression for the compatible upgrade object set is:

[0031] In the formula, Upgrade the target object index. For the target upgrade object, To combine the chip capability requirements of each target upgrade object with The resulting single-object compatible set after comparison This is a component compatibility diagram based on the prerequisite upgrade objects in the target operating system upgrade list. for exist All prerequisite upgrade objects in the set, the set filtering conditions make All pre-upgrade targets belong to ; The component compatibility graph is a directed graph representing the target upgrade object and its predecessor relationships. The single-object compatibility set stores the comparison results of each target upgrade object in terms of instruction set extension, processor word length, privilege mode, and storage space. The dependency closure check traces the predecessor upgrade objects layer by layer along the component compatibility graph until there are no predecessor upgrade objects that have not been checked. When the predecessor device tree object is incompatible, the corresponding kernel object does not enter the compatibility upgrade object set. The upgrade is terminated when a directed cycle exists in the component compatibility graph. The data processor, following the order of the compatibility upgrade object set, retrieves the corresponding writable range of the inactive partition from the storage partition status. Based on the target size and alignment length, it forms the target write address and binds the target upgrade object, the target write address, and the target hash into a target write record. The target write mapping represents a definite correspondence between the compatibility upgrade object and the target address of the inactive operating system region. The aforementioned target write mapping expression is:

[0032] In the formula, according to The writable range is obtained from the partition type and the remaining range. , and These are derived sequentially from the object type, target size, and alignment length in the target operating system's upgrade manifest. Within the writable range, form the target write address that meets the alignment length. The target hash of the target upgrade object. Each element in the target write record consists of the target upgrade object, the target write address, and the target hash.

[0033] The target write address must not fall into the protected start area. If a writable interval that meets the size and alignment length cannot be obtained, the target write mapping is invalid, and the valid target write mapping enters the block comparison.

[0034] S3. Based on the target write mapping, compare the compatible upgrade object with the corresponding object in the current operating system in blocks, and form a block source description with a value of either local copy type or Bluetooth download type based on the block comparison result; Based on the block source description, target partition boundary, and startup dependency, rollback consistent transaction units are formed, and each rollback consistent transaction unit can be written and verified independently; a rollback consistent update directed graph is formed based on the preceding relationships between each rollback consistent transaction unit. The specific data processor performs content definition chunking for each compatible upgrade object in the target write map. The target object and the corresponding object in the current operating system are chunked using the same versioned rolling fingerprint rules to identify chunks with the same content.

[0035] The data processor calculates the target block hash and queries the current block hash index. If the hashes match, a local copy type block source description is generated, storing the current block's read address. If the hashes differ, a Bluetooth download type block source description is generated, storing the target block's content. The block source description indicates the definite content source of the target block in this upgrade round. Each target block corresponds to only one source type. (Target upgrade object) The Middle The block source description expression for the target blocks is:

[0036] In the formula, and These are the target block index and the current block index, respectively. Content definition blocks derived from the target upgrade object The content definition blocks are derived from the corresponding objects in the current operating system. A version-locked hash function. The read address of the same current block in the active operating system region. This indicates that the local copy address will be saved instead of being downloaded via Bluetooth.

[0037] Both source types use the same target block order, and subsequent combinations do not change the order of the target object content.

[0038] The data processor connects the block source descriptions sequentially according to the target block order, ending the combination at the target partition boundary, target upgrade object boundary, predecessor relationship boundary, and maximum length of a single transaction. The combination result is then encapsulated with the transaction unit identifier, target write address, pre-write hash, post-write target hash, and predecessor transaction unit set. "Rollback consistent transaction unit" is a custom technical term in this invention, referring to an upgrade data object that can be independently prepared, written, read, verified, and confirmed as complete without modifying the startup selection record. The expression for a rollback-consistent transaction unit is:

[0039] In the formula, To roll back the consistent transaction unit index, To upgrade the unique transaction unit identifier within the session, Use the target write address from the target write map. Description of contiguous block sources that do not cross target partition boundaries and startup dependency boundaries. Derived from the result of reading the target range before writing. Sourced from the target operating system upgrade list. This is the set of preceding transaction units obtained based on startup dependencies.

[0040] The pre-write hash is formed from the original content of the target address, and the post-write target hash is formed from the target block hash. The set of pre-transaction units contains object dependencies and address order dependencies.

[0041] The data processor uses rollback-consistent transaction units as nodes, connecting preceding transaction units to their corresponding subsequent transaction units, forming a set of directed edges and a rollback-consistent update directed graph. The rollback-consistent update directed graph is a custom technical term in this invention, representing the preceding relationships that must be followed for a transaction unit to be written and confirmed. The data processor performs topological sorting when the rollback-consistent update directed graph is acyclic, forming the transaction execution order. The expression for the rollback-consistent update directed graph is:

[0042] In the formula, , and To roll back the consistent transaction unit index, Form a set of nodes, for The saved set of preceding transaction units, with directed edges from point to ,and Must belong to , Only When there are no cycles, a topological order is formed that prioritizes the preceding transaction units.

[0043] If any of the following conditions occur, such as directed ring, overlapping target addresses, duplicate identifiers, or missing prerequisites, a transaction execution order will not be formed, and the valid order will enter the encoded transmission group for processing.

[0044] S4. Based on the topological order of the rollback consistent update directed graph and the Bluetooth link state, form coded transmission groups. Determine the payload length and number of coded segments for each coded transmission group based on the Bluetooth link state. Perform systematic erasure coding on the source segments in the coded transmission groups to form a Bluetooth coded segment stream. Specifically, the upgraded terminal obtains the Bluetooth download type block according to the transaction execution order and retains the position of the local copy type block. The data processor forms the measured segment loss ratio based on the number of transmissions and acknowledgments recorded by the Bluetooth controller.

[0045] The data processor calculates the current segment loss estimate based on the measured segment loss ratio and the previous segment loss estimate. It then calculates the payload length based on the maximum transmission unit (MTB), protocol overhead, buffer space, and single write length. Next, it divides the data into encoded transmission groups according to the transaction execution order. Finally, it calculates the number of encoded segments based on the number of source segments, the segment loss estimate, and the number of secure segments. An encoded transmission group represents a set of consecutive source segments encoded and reconstructed using the same coding coefficient matrix. The expression for each encoded transport group is:

[0046] In the formula, For the encoded transport group index, For Bluetooth link statistics time points, Provides the number of messages sent, the number of acknowledgments received, and the remaining buffer space. The maximum transmission unit for Bluetooth session negotiation. The length of a single write operation. For version-locked coding plan functions, according to Obtain the transaction order, form the redundancy amount using the smoothed fragment loss estimate, and use the length after deducting protocol overhead from the maximum transmission unit, the allowed buffer length, and... The minimum value in the range forms the effective load length. Number of source fragments saved and the number of encoded segments .

[0047] When the estimated fragment loss reaches the upper limit, transmission is paused. After the connection parameters are renegotiated, the untransmitted encoded transmission group continues. The upgrade transaction log of the completed transaction unit is not changed. The parameter version of the encoding plan function is saved with the upgrade context. After disconnection and reconnection, the same encoded transmission group continues to use the original source fragment order, payload length and generator matrix version, so that the encoded fragments received before and after reconnection can enter the same encoding coefficient matrix.

[0048] The upgraded terminal uses the encoded transmission group as the input for systematic erasure coding. The first encoded segment carries the source segment, and the second encoded segment combines the source segment according to the version-locked generator matrix coefficients. Each encoded segment is appended with a session identifier, transaction unit identifier, transmission group identifier, segment sequence number, matrix row index, and checksum, and forms a Bluetooth encoded segment stream in the order of the encoded transmission group. In the coded transmission group, the _ The Bluetooth encoded fragment is denoted as .

[0049]

[0050] In the formula, For the index of the encoded fragment, For encoding transmission group The first in One source fragment, Generate matrix coefficients for version-locked systematic erasure coding; coefficient operations are performed in... Execution within a finite domain, before Each coded segment uses identity matrix coefficients to preserve the untransformed source segment.

[0051] The Bluetooth encoded fragment stream enters the recoverable write process in the order of transaction execution.

[0052] S5. Reconstruct the corresponding rollback consistent transaction unit according to the Bluetooth encoded fragment stream. After the target hash verification of the reconstructed content passes, write the rollback consistent transaction unit to the inactive operating system area and write the write verification result to the upgrade transaction log in sequence. Form a recoverable progress mapping according to the upgrade transaction log. Specifically, the RISC-V architecture chip stores the verified encoded segments according to the session identifier and the transmission group identifier. Duplicate segments do not occupy the buffer repeatedly. The data processor forms the received encoding coefficient matrix according to the matrix row index and updates the rank of the finite field matrix.

[0053] When the received coding coefficient matrix is ​​full rank, the data processor reconstructs and concatenates the source segments in order. Then, it compares the reconstructed content hash with the target hash of the coded transport group. If reconstructed content exists and the target hash matches, a valid coded transport group check state is formed. The reconstructed content expression for each coded transport group is:

[0054] In the formula, This is the set of received encoded segments that have passed segment verification. For the corresponding coding coefficient matrix, To encode the target hash of the transmission group, Only when the rank of the coding coefficient matrix reaches Saved And the reconstructed content hash equals Outputs the reconstructed content concatenated in the order of the source fragments when in use; otherwise, outputs an empty set.

[0055] After all the encoded transmission groups of the corresponding transaction unit are verified to be valid, the machine mode starts the monitoring program to restore the target block sequence according to the block source description. Bluetooth download type blocks are taken from the reconstructed content, and local copy type blocks are taken from the active operating system area. The data processor combines the content to be written according to the target block order. When the target hash is consistent and the previous transaction unit is completed, the target address is written and post-write verification is performed.

[0056] After a transaction unit completes post-write verification, the machine mode starts a monitoring program that connects the previous log record hash, transaction unit identifier, target hash, write verification status, and upgrade version to form the current record. It checks log continuity starting from the session start hash and adds transaction unit identifiers with valid write verification and continuous log chains to the recoverable progress map. The recoverable progress map represents the set of transaction units that have completed content verification, target write, and post-write read verification. The recoverable progress mapping expression for a Bluetooth upgrade session is:

[0057] In the formula, To start the monitoring program in machine mode, connect to the upgrade transaction log formed by the previous record hash, transaction unit identifier, target hash, write verification status, and target version. To write the refactored content set for each transaction unit, according to Check the preceding relationships and only add transaction unit identifiers that have continuous log chains, consistent target content, and valid post-write verification. .

[0058] The first record in the upgrade transaction log is connected to the session's initial hash, and subsequent records are connected to the hash of the previous record. The write verification status is formed by the write-after-read content of the target address. After power failure recovery, the continuous log chain is located in reverse from the end record, and the preceding transaction unit is verified according to the rollback consistency update directed graph. When the target address content is inconsistent with the log target hash, the corresponding transaction unit and subsequent transaction units are removed and retransmitted.

[0059] S6. After confirming that all rollback consistent transaction units in the directed graph of the rollback consistent update are completed according to the recoverable progress mapping, a mirror root hash is formed based on the inactive operating system region, and a mirror integrity flag is formed based on the comparison result between the mirror root hash and the target operating system upgrade list. Based on the image integrity flag, a trial boot description is generated, and an inactive operating system region is launched within the physical memory protection range configured by the machine mode startup monitoring program, thus forming evidence of a trial boot. Specifically, when the recoverable progress mapping covers all transaction units, the machine mode starts the monitoring program to form the root hash of the inactive operating system region image in the list order, and verifies the list digital signature and the target image root hash.

[0060] The mirror root hash and mirror integrity flag are generated. The data processor generates a Merkle root based on the target hash of the transaction unit in the recoverable schedule map. A valid mirror integrity flag is generated when three conditions are met simultaneously: the recoverable schedule map is complete, the Merkle root matches the target mirror root hash of the manifest, and the manifest digital signature is valid. The expression for the mirror integrity result is:

[0061] In the formula, This is the result of an image of the inactive operating system region. Includes mirror root hash and mirror integrity flag , according to The determined leaf node order is determined by Transaction unit target hash formation and in Covering all transaction units equal Saved target image root hash and When the signature is valid Set it to 1.

[0062] If the image integrity flag is invalid, the original boot selection record is preserved; if the image integrity flag is valid, a trial boot description is generated.

[0063] The system generates a test boot description, test boot evidence, and test boot pass flag. The machine mode boot monitoring program configures physical memory protection entries based on the inactive region, active region, and protected boot metadata, prohibiting the test boot operating system from writing to the active region and boot metadata. The inactive region entry point, image root hash, target version, watchdog timeout, and physical memory protection configuration form the test boot description. Based on the test boot description, the system obtains the boot entry point, kernel initialization, target system services, device initialization, and watchdog monitoring points, generating test boot evidence and a test boot pass flag. The test boot evidence expression is:

[0064] In the formula, This is the entry point for the inactive operating system region. For the target version, The watchdog timeout specified for the target operating system upgrade list. The machine mode startup monitoring program is configured with physical memory protection based on inactive regions and protected startup metadata. Only In If valid, the target operating system is started, and the boot entry point, kernel initialization, target system services, device initialization, and watchdog monitoring points are encapsulated as evidence of a trial boot. .

[0065] The test boot evidence represents the combination of boot events obtained by the machine mode boot monitoring program at fixed monitoring points during a controlled test boot. The five flags come from entry jump, kernel callback, service manager, device specified in the list, and watchdog record in sequence. Each monitoring point also saves the event identifier, occurrence time, and target version. The machine mode boot monitoring program only accepts monitoring points within the time range specified in the test boot description and with the same target version, thereby avoiding writing ready events generated by the operating system before the upgrade into the current test boot evidence.

[0066] S7. Based on the trial boot evidence, determine an upgrade decision from the upgrade submission decision and the upgrade rollback decision. When determining the upgrade submission decision, atomically update the boot selection record to select the inactive operating system region. When determining the upgrade rollback decision, maintain the original operating system region and the original boot selection record. Specifically, the data processor determines an upgrade decision from the upgrade commit decision and the upgrade rollback decision based on the trial start pass flag. The upgrade decision only processes the start selection record and does not change the upgrade transaction log.

[0067] The upgrade submission decision causes the machine mode startup monitoring program to generate a new startup selection record based on the inactive zone entry, target version, mirror root hash, and an incrementing counter. This record is first written to and verified against the backup record, then written to the master record. The upgrade rollback decision causes the machine mode startup monitoring program to retain the startup selection record before the upgrade. The expressions for the upgrade decision and the updated startup selection record are as follows:

[0068]

[0069] In the formula, according to The five monitoring points in the test start-up have passed the test. The two values ​​represent the allowed switching to the target operating system. and continue to maintain the original operating system , Select a record for the currently active startup. The monotonically increasing count of the currently selected record is used for startup. This indicates the formation of a new boot selection record containing the inactive operating system region entry, the target operating system version, the image root hash, and an updated monotonically increasing count. The new boot selection record is first written to the backup record and read and verified, and then written to the main record.

[0070] The boot selection record is protected boot metadata, including the operating system region entry, version, image root hash, monotonically increasing count, and checksum. During reboot, it selects the record with valid checksum and the largest count from the primary and backup records.

[0071] S8. Update the current operating system list based on the boot selection record, and form the operating system upgrade result based on the upgrade context, component compatibility graph, rollback consistent update directed graph, recoverable progress mapping, trial boot evidence, and the determined upgrade decision; Specifically, the data processor determines the currently active operating system region based on the updated boot selection record. When the updated boot selection record points to the target operating system, the target operating system upgrade list that has passed digital signature verification is determined as the updated current operating system list. When the updated boot selection record continues to point to the original operating system, the current operating system list before the upgrade is retained.

[0072] The data processor determines the updated current operating system list according to the upgrade decision, and then encapsulates the upgrade context, transaction graph processing results, recoverable write results, trial boot evidence, upgrade decision, and updated current operating system list in the order they were formed, thus forming the operating system upgrade result. The expression for the operating system upgrade result of a Bluetooth upgrade session is:

[0073] In the formula, The upgrade context is encapsulated according to a fixed field order. Compatibility and upgrade object collection Target write mapping Rollback to consistent updates of directed graphs Recoverable progress mapping Trial initiation evidence Upgrade decision and the startup selection record after the update and according to The operating system upgrade result is generated after updating the current operating system list. .

[0074] The operating system upgrade results include session identifier, versions before and after the upgrade, set of compatible upgrade objects, number of transaction units, transmission statistics, trial start evidence, and final start selection record. The results corresponding to the upgrade commit decision clean up temporary fragments after normal startup, while the results corresponding to the upgrade rollback decision retain transaction logs and failure phases.

[0075] This embodiment also provides a RISC-V architecture chip with an operating system that can be upgraded via Bluetooth, including: The upgrade context formation module is used to establish a Bluetooth upgrade session and form an upgrade context; The compatibility mapping module is used to generate component compatibility graphs, sets of compatible upgrade objects, and target write mappings. The transaction graph construction module is used to form a block source description, rollback consistent transaction unit, and rollback consistent update directed graph; The Bluetooth encoding and transmission module is used to form encoding and transmission groups and Bluetooth encoding fragment streams based on the rollback consistent update directed graph and Bluetooth link state. The recoverable write module is used to reconstruct and rollback consistent transaction units, write to inactive operating system regions, and form upgrade transaction logs and recoverable progress maps. The isolated test boot module is used to generate image integrity flags and test boot descriptions, and to generate test boot evidence within the scope of physical memory protection. The atomic switching module is used to determine an upgrade decision from the upgrade commit decision and the upgrade rollback decision based on the trial start evidence and to process the start selection record; The upgrade result generation module is used to update the current operating system list and generate the operating system upgrade result.

[0076] In summary, the Bluetooth upgrade session forms an upgrade context, which in turn forms a component compatibility graph, a set of compatible upgrade objects, and a target write map. The target write map forms a block source description, a rollback consistent transaction unit, and a rollback consistent update directed graph. The rollback consistent update directed graph and the Bluetooth link state form an encoded transmission group and a Bluetooth encoded fragment stream. The Bluetooth encoded fragment stream forms the inactive operating system region write results, the upgrade transaction log, and a recoverable progress map. The recoverable progress map forms an image integrity flag, the image integrity flag forms a trial start description and trial start evidence, the trial start evidence forms an upgrade decision, the upgrade decision forms a startup selection record, and the startup selection record forms the current operating system list and the operating system upgrade results.

[0077] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for upgrading a RISC-V architecture chip based on Bluetooth, characterized in that: include, S1. Establish a Bluetooth upgrade session between the RISC-V architecture chip and the upgrade terminal, obtain the RISC-V architecture chip capability description, current operating system list, storage partition status, Bluetooth link status and target operating system upgrade list, and form an upgrade context. S2. Based on the upgrade context, the target operating system upgrade package is parsed into target upgrade objects. A component compatibility graph is constructed based on the instruction set extension requirements, word length requirements, privileged mode requirements, storage requirements, and object dependencies of each target upgrade object. A set of compatible upgrade objects is formed based on the component compatibility graph. A target write mapping is formed based on the set of compatible upgrade objects and the storage partition status. S3. Based on the target write mapping, compare the compatible upgrade object with the corresponding object in the current operating system in blocks, and form a block source description with a value of either local copy type or Bluetooth download type based on the block comparison result; Based on the block source description, target partition boundary, and startup dependencies, rollback consistent transaction units are formed, and each rollback consistent transaction unit can be written and verified independently. A directed graph of rollback consistent updates is formed based on the prior relationships between each rollback consistent transaction unit; S4. Based on the topological order of the rollback consistent update directed graph and the Bluetooth link state, form coded transmission groups. Determine the payload length and number of coded segments for each coded transmission group based on the Bluetooth link state. Perform systematic erasure coding on the source segments in the coded transmission groups to form a Bluetooth coded segment stream. S5. Reconstruct the corresponding rollback consistent transaction unit according to the Bluetooth encoded fragment stream. After the target hash verification of the reconstructed content passes, write the rollback consistent transaction unit to the inactive operating system area and write the write verification result to the upgrade transaction log in sequence. Form a recoverable progress mapping according to the upgrade transaction log. S6. After confirming that all rollback consistent transaction units in the directed graph of the rollback consistent update are completed according to the recoverable progress mapping, a mirror root hash is formed based on the inactive operating system region, and a mirror integrity flag is formed based on the comparison result between the mirror root hash and the target operating system upgrade list. Based on the image integrity flag, a trial boot description is generated, and an inactive operating system region is launched within the physical memory protection range configured by the machine mode startup monitoring program, thus forming evidence of a trial boot. S7. Based on the trial boot evidence, determine an upgrade decision from the upgrade submission decision and the upgrade rollback decision. When determining the upgrade submission decision, atomically update the boot selection record to select the inactive operating system region. When determining the upgrade rollback decision, maintain the original operating system region and the original boot selection record. S8. Update the current operating system list based on the boot selection record, and form the operating system upgrade result based on the upgrade context, component compatibility graph, rollback consistent update directed graph, recoverable progress mapping, trial boot evidence, and the determined upgrade decision.

2. The method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: The machine mode startup monitoring program generates a RISC-V architecture chip capability description and a list of current operating systems based on the chip's implementation capabilities and startup metadata. The Bluetooth controller determines the Bluetooth link status based on connection parameters and segment reception statistics; An upgrade context is formed only when the protected root public key verifies the validity of the target operating system upgrade manifest digital signature.

3. The method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: The target operating system upgrade package is parsed into a target upgrade object that has capability requirements, target hash, and prerequisite upgrade objects; Based on capability requirements, a single-object compatibility result is generated; based on the preceding upgrade objects, a component compatibility diagram is generated. Only target upgrade objects that are compatible with both single objects and their predecessor upgrade objects are added to the compatible upgrade object set, forming a target write mapping that satisfies the partition type, target size, and alignment length.

4. The method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: The same content is used to define the block segmentation rules to process the compatibility upgrade object and the object corresponding to the current operating system, forming a block source description with a value of either local copy type or Bluetooth download type; A rollback consistent transaction unit is formed that saves the target address, target hash, and set of preceding transaction units without crossing the target partition boundary and startup dependency boundary. A rollback consistent update directed graph and topological order are formed based on the relationships between preceding transaction units.

5. A method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: The segment loss estimate is formed based on the segment reception statistics, and the effective payload length of the encoded segment is formed based on the maximum transmission unit, protocol overhead, and single write length. The encoded transmission groups are formed according to the topological order. The number of encoded segments is determined based on the number of source segments, the estimated number of lost segments, and the number of secure segments. Systematic erasure coding is then used to form a Bluetooth encoded segment stream.

6. The method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: When the coding coefficient matrix is ​​at full rank, the coding transmission group is reconstructed, and the content to be written is formed into a transaction unit based on the block source description. Write to the target address and perform post-write verification when the target hash is valid and the preceding transaction unit is completed; An upgrade transaction log is formed based on the hash of the previous log record, the transaction unit identifier, the target hash, and the write verification status. After power failure and recovery, the upgrade continues from the last record with continuous hash and valid write verification.

7. A method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: A trial startup description is generated when the recoverable progress map covers all transaction units, the image root hash is consistent, and the digital signature of the target operating system upgrade manifest is valid. The machine mode startup monitoring program configures the physical memory protection range according to the trial startup description and starts the inactive operating system region, forming trial startup evidence based on the startup entry point, kernel initialization, system services, device initialization, and watchdog monitoring points.

8. A method for upgrading a RISC-V architecture chip based on Bluetooth as described in claim 1, characterized in that: If the image integrity flag and all trial startup flags are valid, an upgrade submission decision is made; otherwise, an upgrade rollback decision is made. The startup selection record uses the master record and backup record, which have monotonically increasing counters and record check values. After confirming the upgrade submission decision, first write to and verify the backup record, then write to the master record; Once the upgrade rollback decision is confirmed, the original boot selection record will be retained. Upon restart, select the record with valid verification and the highest count.

9. A method for upgrading the operating system of a RISC-V architecture chip based on Bluetooth, based on any one of claims 1 to 8, characterized in that: include, The upgrade context formation module is used to establish a Bluetooth upgrade session and form an upgrade context; The compatibility mapping module is used to generate component compatibility graphs, sets of compatible upgrade objects, and target write mappings. The transaction graph construction module is used to form a block source description, rollback consistent transaction unit, and rollback consistent update directed graph; The Bluetooth encoding and transmission module is used to form encoding and transmission groups and Bluetooth encoding fragment streams based on the rollback consistent update directed graph and Bluetooth link state. The recoverable write module is used to reconstruct and rollback consistent transaction units, write to inactive operating system regions, and form upgrade transaction logs and recoverable progress maps. The isolated test boot module is used to generate image integrity flags and test boot descriptions, and to generate test boot evidence within the scope of physical memory protection. The atomic switching module is used to determine an upgrade decision from the upgrade commit decision and the upgrade rollback decision based on the trial start evidence and to process the start selection record; The upgrade result generation module is used to update the current operating system list and generate the operating system upgrade result.

Images