Multi-partition program flashing state control method, device and equipment

Abstract

The application discloses a multi-partition program flashing state control method, device and equipment, relates to the flashing control field, and the method comprises the following steps: setting an independent state item for each logical partition, creating a flashing transaction, and generating a transaction number and a transaction phase flag after a flashing request of a target logical partition is received; switching the independent state item corresponding to the target logical partition to a to-be-updated state or an invalid to-be-recovered state, recording the target logical partition identifier, generating a flashing transaction recovery record, and writing the flashing transaction recovery record into a nonvolatile storage area; performing a whole-sector erasing operation on a shared state sector, updating the transaction phase flag to the shared state sector having been erased or the non-target logical partition state being recovered, and restoring the non-target logical partition independent state item recorded in the flashing transaction recovery record and which should continue to be valid to the shared state sector. The application can effectively realize multi-partition flashing control.

Description

Technical Field

[0001] This application relates to the fields of automotive electronic controller program boot loading, vehicle controller partition flashing control, non-volatile memory transaction recovery and upgrade startup security control technology, specifically to a multi-partition program flashing status control method, device and equipment. Background Technology

[0002] In existing vehicle controller bootloaders, multiple logical partitions typically share the same DFlash (Data Flash) state sector to store metadata such as program fingerprints, validity status, and compatibility status. Since non-volatile memory like DFlash can usually only be erased sector by sector, when any target logical partition enters the flashing process, the system needs to perform a full sector erase on the shared state sector containing the state entries of multiple logical partitions. Without transactional protection, state erasure, write failure, session timeout, or abnormal power loss during the flashing process of a single target logical partition can easily escalate into the loss of state of multiple non-target logical partitions or misjudgment of their startup status.

[0003] Specifically, the existing processing methods have the following problems: (1) When a single target logical partition is written, the complete erasure of the shared state sector will also destroy the state information of other non-target logical partitions; (2) When the target logical partition is interrupted, loses power or fails to write, other logical partitions that have not participated in the update may be deemed invalid because their status information has been erased; (3) Existing solutions typically only temporarily cache the state in RAM (Random Access Memory), lacking a recovery basis that can be saved across power failures, and cannot guarantee that non-target states can be recovered in power failure scenarios after erasure; (4) The existing solution lacks a transaction phase expression, and it is difficult to determine whether the system is currently in the state of pre-erase, post-erase, recovery, writing to the target logical partition, or commit completed after power-on. (5) If the erased state default value is directly used to represent the valid state, there is a risk that the logical partition may be misjudged as valid after the shared state sector is erased; (6) If there are multiple download requests in the same upgrade session, repeatedly entering the shared state sector erase window will not only increase the number of erases and writes, but may also damage the restored non-target logical partition state again; (7) Existing startup determination is usually based on a single global valid flag or a simple block valid flag, which cannot express the dependencies, compatibility status and transaction completion status between the blocks that must be started.

[0004] Therefore, how to effectively achieve state isolation of the target logical partition program, deterministic recovery after abnormal power failure, and startup consistency determination has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, and device for controlling the status of multi-partition program writing, which can effectively realize multi-partition writing control.

[0006] In a first aspect, embodiments of this application provide a method for controlling the state of a multi-partition program flashing, the method comprising: An independent status item is set for each logical partition. After receiving the flush request for the target logical partition, a flush transaction is created and a transaction number and transaction stage flag are generated. Switch the independent status item corresponding to the target logical partition to the pending update state or invalid pending recovery state, record the target logical partition identifier, generate a flush transaction recovery record, and write the flush transaction recovery record to the non-volatile storage area. Perform a full sector erase operation on the shared state sector and update the transaction phase flag to indicate that the shared state sector has been erased or that the non-target logical partition is in recovery. Restore the independent state entries of the non-target logical partitions that should remain valid, recorded in the transaction recovery log, to the shared state sector.

[0007] In conjunction with the first aspect, in one implementation method, The independent status item includes a status value, a status inverse code, a logical partition identifier, a version count and a verification field, and a valid commit flag that can be unidirectionally programmed; The current logical partition is considered to be in a valid state if and only if the independent state entries of the current logical partition meet the preset consistency check conditions; Switching an independent state item to a pending update state or an invalid pending recovery state includes: programming the valid commit flag in the unidirectional programming direction allowed by non-volatile storage without erasing the shared state sector, so that the independent state item no longer meets the preset consistency check conditions.

[0008] In conjunction with the first aspect, in one implementation method, The transaction phase flag is used to indicate that the current flushing process is in the following stages: transaction creation, target pending update, flushing transaction recovery record generation, shared state sector erasure, non-target logical partition state recovery, target logical partition data writing, target logical partition verification pending commit, target logical partition state commit, or transaction completion. Before entering the shared state sector erase, non-target logical partition state recovery, target logical partition data writing, or target logical partition state commit stage, the transaction stage flag indicating that the corresponding operation is in progress is persistently written to the flush transaction recovery record or an independent non-volatile transaction stage storage area. After the corresponding operation is completed, the transaction stage flag indicating that the corresponding operation has been completed is persistently written, and the next transaction stage is entered after the verification is passed.

[0009] In conjunction with the first aspect, in one implementation, the step of switching the independent state item corresponding to the target logical partition to a pending update state or an invalid pending recovery state, recording the target logical partition identifier, generating a flush transaction recovery record, and writing the flush transaction recovery record to a non-volatile storage area specifically includes: Switch the independent status item corresponding to the target logical partition to the pending update status or invalid pending recovery status, and record the target logical partition identifier; When it is determined that the current write transaction has not yet entered the shared state sector erase-recovery window, a write transaction recovery record is generated and written to the non-volatile storage area; The transaction recovery record includes the target logical partition identifier, transaction number, transaction stage flag, independent status items currently in a valid state in non-target logical partitions, corresponding version information, compatibility status items, startup required block set information, and recovery record verification fields. The non-volatile storage area is the Bootloader reserved area, the target logical partition reserved header area, the spare DFlash area, or other storage areas that will not be immediately destroyed by the current target logical partition's write process.

[0010] In conjunction with the first aspect, in one implementation, restoring the independent state entries of the non-target logical partitions that should remain valid, recorded in the write transaction recovery record, to the shared state sector specifically includes: After the shared state sector is erased, the program fingerprint information and compatible state items corresponding to the current flush transaction are first written back based on the flush transaction recovery record. Then, the independent state items of the non-target logical partitions that should remain valid and recorded in the flush transaction recovery record are restored to the shared state sector.

[0011] In conjunction with the first aspect, in one embodiment, the multi-partition program write state control method further includes: When a download request for a new target logical partition is received again within the same write transaction, the current transaction number is used. If it is determined that the shared state sector has completed the erasure of the current transaction and the state recovery of the non-target logical partition, the independent state item corresponding to the new target logical partition is first switched to the pending update state or the invalid pending recovery state. Then, the repeated erasure of the shared state sector and the repeated recovery of the state of the non-target logical partition are skipped, and the data writing process of the new target logical partition is executed. After the data writing to the new target logical partition is completed and passes the integrity check and compatibility check, the transaction phase flag is updated to target logical partition verification pending commit, the new target logical partition independent status item is committed as valid, and the version count, compatibility status item and status item verification field are updated. After the new target logical partition state is committed, update the current target logical partition, the set of committed target logical partitions, and the set of remaining target logical partitions to be flushed in the flush transaction recovery record. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is not empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end instruction or a diagnostic flush session end instruction has not yet been received, keep the current transaction number, the flush transaction recovery record, and the session-level erase state valid, and wait for or process the next download request. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end instruction or a diagnostic flush session end instruction has been received, persist the transaction phase flag to transaction completion, write the recovery completion flag, and clean up or invalidate the flush transaction recovery record.

[0012] In conjunction with the first aspect, in one embodiment, the multi-partition program write state control method further includes: When a flush exception occurs, a recovery exception occurs, a session timeout occurs, or the system is re-initialized upon power-on, the flush transaction recovery record and its persistent transaction phase flags are read from the non-volatile storage area: If it is determined that the shared state sector has been erased but the non-target logical partition state has not been fully restored, then the non-target logical partition state will continue to be restored based on the flush transaction recovery record. If the data writing or verification of the target logical partition is not completed, the target logical partition remains invalid. If the transaction is not completed, normal application startup will be blocked or a re-entry into the flashing session will be required.

[0013] In conjunction with the first aspect, in one embodiment, the multi-partition program write state control method further includes: During startup determination, the system uses the set of dependencies of the startup required blocks, the independent status items of each startup required block, the version count, the compatibility status items, the recovery completion flag, and the transaction phase flag to jointly determine whether to allow application startup. If any startup required block does not meet the validity condition, compatibility condition, or transaction completion condition, normal application startup is blocked.

[0014] Secondly, embodiments of this application provide a multi-partition program flashing status control device, the multi-partition program flashing status control device comprising: The configuration module is used to set independent status items for each logical partition. After receiving the flush request of the target logical partition, it creates a flush transaction and generates a transaction number and transaction stage flag. The generation module is used to switch the independent status item corresponding to the target logical partition to the pending update state or the invalid pending recovery state, record the target logical partition identifier, generate a flush transaction recovery record, and write the flush transaction recovery record to the non-volatile storage area. The operation module is used to perform a full sector erase operation on the shared state sector and update the transaction phase flag to indicate that the shared state sector has been erased or that the non-target logical partition is in recovery. The execution module is used to restore the independent state entries of non-target logical partitions that should remain valid, recorded in the flush transaction recovery record, to the shared state sector.

[0015] Thirdly, embodiments of this application provide a multi-partition program writing status control device, the multi-partition program writing status control device including a processor, a memory, and a multi-partition program writing status control program stored in the memory and executable by the processor, wherein when the multi-partition program writing status control program is executed by the processor, it implements the steps of the multi-partition program writing status control method described above.

[0016] The beneficial effects of the technical solutions provided in this application include: (1) When the target logical partition fails to be flushed, only the target logical partition remains in an invalid or pending recovery state, while the non-target logical partition can be recovered based on the transaction recovery record, thereby achieving partition-level state isolation; (2) Under the condition that the shared state sector must be completely erased, the system can still restore the record across power failure by using non-volatile write transactions to save the recovery basis, thereby improving the recoverability in abnormal reset scenarios after erasure; (3) By using the transaction phase flag, the system can identify whether it is currently in the state of pre-erase, post-erase, recovery, writing, or post-commit after power-on, and execute a deterministic recovery path; (4) By combining the status value, inverse code, logical partition identifier, version count and verification field, the risk of misjudging the validity of logical partitions caused by the erased state default value is reduced; (5) By controlling the state of the session-level erase, the repeated erasure within the same write transaction is reduced, and the state of the recovered non-target logical partition is prevented from being erased again. (6) By jointly determining the startup must block dependency set, compatibility status and transaction completion status, the consistency between startup release results and actual logical partition availability and software version compatibility is improved. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the multi-partition program write status control method of this application; Figure 2 A schematic diagram illustrating the relationship between the transaction recovery record and the shared state sector. Figure 3 A diagram illustrating the mechanism for one erase and subsequent skipping within the same write transaction; Figure 4 This is a timing diagram for power-off recovery after erasure. Figure 5 This is a schematic diagram illustrating startup consistency judgment based on the set of startup required block dependencies; Figure 6 This is a schematic diagram of the functional modules of the multi-partition program writing status control device in this application. Figure 7 This is a schematic diagram of the hardware structure of the multi-partition program writing status control device in this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0020] Firstly, embodiments of this application provide a multi-partition program write state control method. Specifically, it provides a method for isolating the write state of a target logical partition, deterministic recovery after an abnormal power outage, and determining startup consistency by writing transaction recovery records, transaction stage flags, partition state combination verification, and a set of startup necessary blocks, under the condition that multiple logical partitions share the same state storage sector and that the state storage sector can only be erased as a whole sector. It should be noted that the multi-partition program write state control method of this application is applicable to program boot loading systems with at least two logical partitions sharing the same shared state sector. The shared state sector is used to store program fingerprints, compatibility status items, startup necessary block set information, and independent status items corresponding one-to-one with each logical partition. The write transaction recovery record refers to structured recovery data generated and written to a non-volatile storage area before the shared state sector is erased as a whole sector.

[0021] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the multi-partition program write status control method of this application. Figure 1 As shown, the multi-partition program flashing status control method includes: S1: Set an independent status item for each logical partition. After receiving the flush request for the target logical partition, create a flush transaction and generate a transaction number and transaction stage flag. The independent status items include a status value, a status inverse code, a logical partition identifier, a version count and a verification field, and a valid commit flag that can be programmed unidirectionally. The current logical partition is determined to be in a valid state if and only if the independent status items of the current logical partition meet the preset consistency verification conditions. The default value of the erased state does not constitute a valid state on its own. When it is necessary to switch the independent status items to the pending update state or the invalid pending recovery state, the following steps are taken: without erasing the shared state sector, at least one failure indicator bit in the valid commit flag that is still in the erased state is programmed according to the unidirectional programming direction allowed by the non-volatile memory, so that the independent status item no longer meets the preset consistency verification conditions. The unidirectional programming direction is the bit state transition from the erased state to the programming state, including 0→1 or 1→0, depending on the erased state and programming polarity of the non-volatile memory. Since the polarity of DFlash is different, some are all 0 after erasure and some are all 1 after erasure. Therefore, when switching to the pending update state or the invalid pending recovery state, this application changes the other reserved bits of the flag from the original initial state after full erasure to the opposite state. The transaction phase flag indicates whether the current flushing process is in one of the following phases: transaction creation, target pending update, flushing transaction recovery record generation, shared state sector erasure, non-target logical partition state recovery, target logical partition data writing, target logical partition verification pending commit, target logical partition state commit, or transaction completion. Before entering the shared state sector erasure, non-target logical partition state recovery, target logical partition data writing, or target logical partition state commit phases, the transaction phase flag indicating that the corresponding operation is in progress is persistently written to the flushing transaction recovery record or an independent non-volatile transaction phase storage area. After the corresponding operation is completed, the transaction phase flag indicating that the corresponding operation has been completed is persistently written, and the next transaction phase is entered after the verification is successful. This ensures that after power failure, the last confirmed non-volatile phase is read, rather than a phase that only exists in RAM. S2: Switch the independent status item corresponding to the target logical partition to the pending update state or invalid pending recovery state, record the target logical partition identifier, generate a flush transaction recovery record, and write the flush transaction recovery record to the non-volatile storage area. S3: Perform a full sector erase operation on the shared state sector (i.e., perform a full sector erase operation on the shared state sector) and update the transaction phase flag to show that the shared state sector has been erased or the non-target logical partition is in recovery. S4: Restore the independent state entries of the non-target logical partition that should remain valid in the flush transaction recovery record to the shared state sector.

[0022] Furthermore, in one embodiment, the independent state item corresponding to the target logical partition is switched to a pending update state or an invalid pending recovery state, and the target logical partition identifier is recorded. Simultaneously, a flush transaction recovery record is generated and written to a non-volatile storage area. Specifically, this includes: S201: Switch the independent status item corresponding to the target logical partition to the pending update status or invalid pending recovery status, and record the target logical partition identifier; S202: When it is determined that the current flush transaction has not yet entered the shared-state sector erase-recovery window, a flush transaction recovery record is generated and written to the non-volatile storage area; for the relationship between the flush transaction recovery record and the shared-state sector, see [link to relevant documentation]. Figure 2 As shown; The transaction recovery record includes the target logical partition identifier, transaction number, transaction stage flag, independent status items currently in a valid state in non-target logical partitions, corresponding version information, compatibility status items, startup required block set information, and recovery record verification fields. The non-volatile storage area is the Bootloader reserved area, the target partition reserved header area, the spare DFlash area, or other storage areas that will not be immediately destroyed by the current target logical partition flushing process.

[0023] Furthermore, in one embodiment, restoring the independent state entries of the non-target logical partition that should remain valid, recorded in the write transaction recovery record, to the shared state sector specifically includes: After the shared state sector is erased, the program fingerprint information and compatible state items corresponding to the current flush transaction are first written back based on the flush transaction recovery record. Then, the independent state items of the non-target logical partitions that should remain valid and recorded in the flush transaction recovery record are restored to the shared state sector.

[0024] Furthermore, in one embodiment, the multi-partition program write state control method of this application further includes: When a download request for a new target logical partition is received again within the same write transaction, the current transaction number is used. If it is determined that the shared state sector has already completed the erasure of the current transaction and the state recovery of the non-target logical partition, the independent state item corresponding to the new target logical partition is first switched to the pending update state or the invalid pending recovery state. Then, the repeated erasure of the shared state sector and the repeated recovery of the non-target logical partition state are skipped, and the data writing process for the new target logical partition is executed. See [link to relevant documentation]. Figure 3 As shown, this allows only erasure and restore to be skipped, without skipping the status invalidation flag of the new target logical partition, so that subsequent download requests continue to belong to the same transaction; After the data writing to the new target logical partition is completed and passes the integrity check and compatibility check, the transaction phase flag is updated to target logical partition verification pending commit, the new target logical partition independent status item is committed as valid, and the version count, compatibility status item and status item verification field are updated. After the new target logical partition state is committed, update the current target logical partition, the set of committed target logical partitions, and the set of remaining target logical partitions to be flushed in the flush transaction recovery record. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is not empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end command or diagnostic flush session end command has not yet been received, maintain the current transaction number, the flush transaction recovery record, and the session-level erase state, and wait for or process the next download request. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end command or diagnostic flush session end command has been received, persist the transaction phase flag to transaction completion, write the recovery completion flag, and clean up or invalidate the flush transaction recovery record. This avoids ending the transaction immediately after the first target logical partition is committed, which would prevent subsequent downloads from using the erase result from a single operation.

[0025] Furthermore, in one embodiment, the multi-partition program write state control method of this application further includes: When a flush exception occurs, a recovery exception occurs, a session timeout occurs, or the system is re-initialized upon power-on, the flush transaction recovery record and its persistent transaction phase flags are read from the non-volatile storage area: If it is determined that the shared state sector has been erased but the non-target logical partition state has not been fully restored, then the non-target logical partition state will continue to be restored based on the flush transaction recovery record. If the data writing or verification of the target logical partition is not completed, the target logical partition remains invalid. If the transaction is not completed, normal application startup will be blocked or a re-entry into the flashing session will be required.

[0026] For the power-off recovery timing after erasure, please refer to [link / reference]. Figure 4 As shown.

[0027] Furthermore, in one embodiment, the multi-partition program write state control method of this application further includes: During startup determination, the system uses the set of dependencies for required startup blocks, the independent status items of each required startup block, version count, compatibility status items, recovery completion flag, and transaction phase flag to jointly determine whether to allow application startup. If any required startup block fails to meet the validity condition, compatibility condition, or transaction completion condition, normal application startup is blocked. For startup consistency determination based on the set of dependencies for required startup blocks, see [link to relevant documentation]. Figure 5 As shown.

[0028] It should be noted that the verification fields for the flush transaction recovery record include at least one of CRC, inverse check, or counter check, used to determine whether the flush transaction recovery record is complete. The set of startup essential blocks depends on the dependencies between the application partition, routing table partition, calibration MAP partition, and calibration data partition; for non-startup essential blocks, downgraded startup or restricted startup of the corresponding function can be allowed depending on the compatibility status. Session-level erase state is used to ensure that shared state sectors within the same flush transaction enter the erase-recovery window only once, preventing the erased non-target state that has been recovered during continuous downloads of multiple logical partitions from being erased again.

[0029] This application introduces a transaction recovery record for flashing, which stores the valid state, compatible state, set of necessary start-up blocks, transaction stage, and verification information of the non-target logical partition in a structured manner before the shared state sector is erased. It also introduces transaction stage flags, dividing the flashing process into stages such as transaction creation, target pending update, recovery record generation, shared state sector erasure, non-target logical partition state recovery, target logical partition writing, target logical partition commit, and transaction completion. In the event of abnormal abort, session timeout, or power-on, a deterministic recovery path is entered based on the transaction stage flags and the transaction recovery record for flashing, rather than simply clearing the state or requiring a complete system re-flash. Independent status items are validated using a combination of status value, status inverse code, logical partition identifier, version count, and check fields to avoid the erased state default value being misjudged as valid. After the shared status sector is completely erased, the valid status of non-target logical partitions is selectively restored according to the flush transaction recovery record, instead of uniformly rebuilding all statuses or relying on RAM cache. Through session-level erase status control, the shared status sector erase-recovery window in the same flush transaction is entered only once, thereby maintaining the consistency of recovery results within the transaction. The start-up release conditions are based on the set of necessary start-up blocks, compatible status, and transaction completion status, rather than on a single general flag.

[0030] The following examples illustrate the multi-partition program write status control method of this application.

[0031] The successful flashing process for a normal single logical partition is illustrated using an onboard controller program booting and loading system as an example. The onboard controller includes at least an application partition, a routing table partition, a first calibration MAP partition, a second calibration MAP partition, and a calibration data partition. The calibration MAP partition stores lookup-based calibration data used for control algorithm calls, including one-dimensional, two-dimensional, or multi-dimensional feature tables. These multiple logical partitions share the same DFlash status sector (i.e., a shared status sector). The shared status sector stores program fingerprints, compatibility status items, bootable block set information, and independent status items corresponding to each logical partition. Independent status items include a status value, status inverse, logical partition identifier, version count, and CRC checksum field. A corresponding logical partition is considered valid only if the above fields meet the consistency check conditions; erased state default values ​​are not individually recognized as valid.

[0032] The specific process is as follows: 1. During system power-on initialization, the program bootloader module reads the independent status items corresponding to each logical partition one by one, and establishes a logical block status table based on the status item combination verification results; 2. When a download request for a target logical partition is received, a flush transaction is created, a transaction number is generated, and the transaction stage flag is set to the transaction creation stage; 3. The independent status items corresponding to the target logical partition are set to the pending update state, and the transaction stage flag is updated to the pending update stage of the target logical partition; 4. If the shared state sector erase has not been performed in the current flush transaction, the independent status items, version information, compatibility status items, and startup required block set information that are still in a valid state in the non-target logical partition are read, a flush transaction recovery record containing the current transaction stage flag is generated, the flush transaction recovery record is written to the non-volatile storage area, and the next step is entered after successful writing and verification; 5. Before performing the shared state sector erase, the transaction stage flag is updated to the shared state sector erase and persistently written to the non-volatile storage area. After confirming successful write and verification, a full sector erase is performed on the shared state sector. After erasure, the transaction phase flag is persistently updated to "shared state sector erased" or "non-target logical partition in recovery." 6. Based on the transaction recovery record, the program fingerprint, compatibility status item, and valid status item of the non-target logical partition are written back, and the transaction phase flag is persistently updated to "non-target logical partition in recovery completed." 7. The transaction phase flag is persistently updated to "target logical partition data writing in progress," and target logical partition data writing, integrity verification, and compatibility checks are performed. 8. When verification passes, the transaction phase flag is persistently updated to "target logical partition verification pending commit," the target logical partition's independent status item is committed to a valid status, the version count, compatibility status item, and status item CRC are updated synchronously, and the transaction phase flag is persistently updated to "target logical partition status committed completed." 9. The transaction phase flag is persistently updated to "transaction completed," the recovery completion flag is written, and the transaction recovery record is cleaned up or invalidated. Through the above process, the state changes of the target logical partition and the state of the non-target logical partition remain transactionally isolated.

[0033] The transaction phase flag is persistently updated using dual-slot, append-only records, independent phase words, or other power-loss-safe methods to avoid power loss during the transaction phase flag update process, which would damage the main body of the write transaction recovery record. If the shared state sector is read as being erased after the system is powered on again, it will be treated as if the shared state sector has been erased, and the non-target logical partition state recovery will be performed based on the write transaction recovery record.

[0034] In this example, the system has generated a write transaction recovery record and completed the full sector erasure of the shared state sector, but an abnormal power outage occurred before the recovery of the non-target logical partition state was completed.

[0035] After the system is powered on again, the following process is executed: 1. The bootloader reads the flash transaction recovery record and verifies the transaction number, transaction stage number, target logical partition identifier, and CRC in the flash transaction recovery record; 2. When the transaction stage number indicates that the shared state sector has been erased but the non-target logical partition state has not been fully restored, the system does not directly allow application startup; 3. The bootloader rewrites the shared state sector according to the valid state item, version information, and compatibility state item of the non-target logical partition recorded in the flash recovery record; 4. Performs consistency checks on the state value, inverse code, logical partition identifier, version count, and CRC of the restored non-target logical partition state item; 5. If the non-target logical partition state is successfully restored, the target logical partition is kept in an pending update or invalid state, and the system is required to re-enter the flash session to continue flashing the target logical partition; 6. If the flash transaction recovery record verification fails or the non-target logical partition state cannot be restored, normal application startup is blocked and the system enters recovery flash mode. This provides a deterministic recovery path for the non-target logical partition within the high-risk window of power loss after the shared state sector is erased.

[0036] For the single-wipe and transaction consistency maintenance process during continuous download of multiple logical partitions, the flush transaction in this example is bounded by a diagnostic flush session or a pre-determined set of target logical partitions. The initial download request establishes a transaction number and session-level erase status, and records the current target logical partition, the committed set of target logical partitions, and the remaining set of target logical partitions to be flushed in the flush transaction recovery record, or records an equivalent transaction termination condition. Within the same diagnostic flush session, if download requests for the application partition and the labeled data partition are received sequentially, the system generates a flush transaction recovery record during the first flush of the target logical partition and performs an erase of the shared state sectors and recovery of the non-target logical partition state. When subsequent download requests arrive, the Bootloader uses the current transaction number and reads the session-level erase status and transaction phase flag. If it determines that the shared state sector has completed the erase of this transaction and the recovery of the non-target logical partition status, it first performs a state invalidation operation that does not require erasing the shared state sector, switching the independent state item corresponding to the new target logical partition to a pending update state or an invalid pending recovery state. Then, it skips the repeated erase of the shared state sector and the repeated recovery of the non-target logical partition status, and performs data writing, verification, and status commit for the new target logical partition. The state invalidation operation that does not require erasing the shared state sector includes: programming the valid commit flag in the independent state item according to the unidirectional programming direction allowed by the memory, so that the independent state item no longer meets the consistency verification conditions for a valid state; or writing a pending update record with a higher version count to the dual-slot or append-only state area, so that the original valid record is no longer used as the current valid record. After each target logical partition state is committed, the current target logical partition, the set of committed target logical partitions, and the set of remaining target logical partitions to be flushed are updated in the flush transaction recovery record. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is not empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end command or diagnostic flush session end command has not yet been received, the current transaction number, the flush transaction recovery record, and the session-level erase state remain valid, and the system waits for or processes the next download request. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end command or diagnostic flush session end command has been received, the transaction phase flag is persistently updated to transaction completion, a recovery completion flag is written, and the flush transaction recovery record is cleaned up or invalidated. This avoids the erase of non-target logical partition states that have been recovered during continuous download of multiple logical partitions, ensuring consistency in the recovery results of logical partition states within the same flush transaction, while reducing the number of DFlash erase operations.

[0037] For the process of keeping the target logical partition's write operation valid even if a non-target logical partition's startup essential blocks remain valid, in this example, the target logical partition failed or failed verification during data writing. The system determines that the target logical partition has not yet committed to a valid state based on the transaction phase flag, thus keeping the target logical partition in an invalid state. For non-target logical partitions, if their status items have been recovered based on the write transaction recovery record and passed the combined verification, they continue to maintain their valid state. The startup determination module determines whether the failed target logical partition belongs to the startup essential blocks based on the startup essential block dependency set; if it belongs to the startup essential blocks, normal startup is blocked and the system enters write recovery mode; if it does not belong to the startup essential blocks and the compatibility status allows, relevant functions can be restricted before downgrading the startup. Through the above process, a single logical partition write failure will not unconditionally expand to the failure of all partitions.

[0038] For the dynamic update process of the dependency set after adding a new essential startup block, when the system adds a new essential startup block, it assigns an independent address range, logical block identifier, independent status item, and dependency description to the new block. The new block is written into the essential startup block dependency set and included in the transaction recovery record. When only the new essential startup block is flushed, if the flush fails, the system determines whether the failure affects application startup based on the dependency set; at the same time, the valid state of other unupdated logical partitions can still be maintained or restored based on the transaction recovery record. Therefore, this application is applicable not only to initially defined multiple logical partitions but also to subsequent additions of essential startup blocks and their dependency adjustments.

[0039] This application achieves the following objectives: 1. Generates a write transaction recovery record that can be saved across power outages before the shared state sector is erased, providing a definite basis for the recovery of non-target logical partition states; 2. Describes the stages such as target logical partition pending update, shared state sector erasure, non-target logical partition state recovery, target logical partition write, target logical partition state commit, and transaction completion through transaction stage flags; 3. Enables the system to enter a deterministic path based on the transaction stage number to continue recovery, keep the target invalid, block startup, or re-enter the write session when any stage experiences abnormal termination, session timeout, or power-on; 4. Prevents the erased state default value from being misjudged as a valid state through a combination of status value, status inverse code, logical partition identifier, version count, and verification fields; 5. Ensures that shared state sectors within the same write transaction only enter the erase-recovery window once through session-level erase state control, maintaining the consistency of recovery results; 6. Determines whether to allow application startup by jointly considering the startup required block dependency set, compatibility status, and transaction completion status.

[0040] Secondly, embodiments of this application also provide a multi-partition program writing status control device.

[0041] In one embodiment, reference is made to Figure 6, Figure 6 This is a schematic diagram of the functional modules of the multi-partition program write status control device of this application. Figure 6 As shown, the multi-partition program writing status control device includes: a setting module, a generation module, an operation module, and an execution module.

[0042] The configuration module sets an independent status item for each logical partition. Upon receiving a flush request for the target logical partition, it creates a flush transaction and generates a transaction number and a transaction stage flag. The generation module switches the independent status item corresponding to the target logical partition to the pending update state or the invalid pending recovery state, records the target logical partition identifier, generates a flush transaction recovery record, and writes the flush transaction recovery record to the non-volatile storage area. The operation module performs a full sector erase operation on the shared state sector and updates the transaction stage flag to "shared state sector erased" or "non-target logical partition in recovery state". The execution module restores the independent status items of the non-target logical partition that should remain valid, recorded in the flush transaction recovery record, to the shared state sector.

[0043] Thirdly, embodiments of this application provide a multi-partition program writing status control device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0044] Reference Figure 7 , Figure 7 This is a schematic diagram of the hardware structure of the multi-partition program flashing status control device involved in the embodiments of this application. In the embodiments of this application, the multi-partition program flashing status control device may include a processor, a memory, a communication interface, and a communication bus.

[0045] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0046] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the multi-partition program writing status control device, as well as interfaces used for interconnecting the multi-partition program writing status control device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0047] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0048] The processor can be a general-purpose processor, which can call the multi-partition program write state control program stored in memory and execute the multi-partition program write state control method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the multi-partition program write state control program is called can be referred to in the various embodiments of the multi-partition program write state control method of this application, and will not be repeated here.

[0049] Those skilled in the art will understand that Figure 7 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0050] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0051] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0052] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0053] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0054] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0055] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for controlling the state of multi-partition program write / fetch, characterized in that, The multi-partition program write status control method includes: An independent status item is set for each logical partition. After receiving the flush request for the target logical partition, a flush transaction is created and a transaction number and transaction stage flag are generated. Switch the independent status item corresponding to the target logical partition to the pending update state or invalid pending recovery state, record the target logical partition identifier, generate a flush transaction recovery record, and write the flush transaction recovery record to the non-volatile storage area. Perform a full sector erase operation on the shared state sector and update the transaction phase flag to indicate that the shared state sector has been erased or that the non-target logical partition is in recovery. Restore the independent state entries of the non-target logical partitions that should remain valid, recorded in the write transaction recovery log, to the shared state sector.

2. The multi-partition program write state control method as described in claim 1, characterized in that: The independent status item includes a status value, a status inverse code, a logical partition identifier, a version count and a verification field, and a valid commit flag that can be unidirectionally programmed; The current logical partition is considered to be in a valid state if and only if the independent state entries of the current logical partition meet the preset consistency check conditions; Switching an independent state item to a pending update state or an invalid pending recovery state includes: programming the valid commit flag in the unidirectional programming direction allowed by non-volatile storage without erasing the shared state sector, so that the independent state item no longer meets the preset consistency check conditions.

3. The multi-partition program write state control method as described in claim 1, characterized in that: The transaction phase flag is used to indicate that the current flushing process is in the following stages: transaction creation, target pending update, flushing transaction recovery record generation, shared state sector erasure, non-target logical partition state recovery, target logical partition data writing, target logical partition verification pending commit, target logical partition state commit, or transaction completion. Before entering the shared state sector erase, non-target logical partition state recovery, target logical partition data writing, or target logical partition state commit stage, the transaction stage flag indicating that the corresponding operation is in progress is persistently written to the flush transaction recovery record or an independent non-volatile transaction stage storage area. After the corresponding operation is completed, the transaction stage flag indicating that the corresponding operation has been completed is persistently written, and the next transaction stage is entered after the verification is passed.

4. The multi-partition program write state control method as described in claim 1, characterized in that, The step of switching the independent state item corresponding to the target logical partition to the pending update state or the invalid pending recovery state, recording the target logical partition identifier, generating a flush transaction recovery record, and writing the flush transaction recovery record to the non-volatile storage area specifically includes: Switch the independent status item corresponding to the target logical partition to the pending update status or invalid pending recovery status, and record the target logical partition identifier; When it is determined that the current write transaction has not yet entered the shared state sector erase-recovery window, a write transaction recovery record is generated and written to the non-volatile storage area; The transaction recovery record includes the target logical partition identifier, transaction number, transaction stage flag, independent status items currently in a valid state in non-target logical partitions, corresponding version information, compatibility status items, startup required block set information, and recovery record verification fields. The non-volatile storage area is the Bootloader reserved area, the target logical partition reserved header area, the spare DFlash area, or other storage areas that will not be immediately destroyed by the current target logical partition's write process.

5. The multi-partition program write state control method as described in claim 1, characterized in that, The process of restoring the independent state entries of non-target logical partitions that should remain valid, recorded in the transaction recovery record, to the shared state sector specifically includes: After the shared state sector is erased, the program fingerprint information and compatible state items corresponding to the current flush transaction are first written back based on the flush transaction recovery record. Then, the independent state items of the non-target logical partitions that should remain valid and recorded in the flush transaction recovery record are restored to the shared state sector.

6. The multi-partition program write state control method as described in claim 1, characterized in that, The multi-partition program write status control method also includes: When a download request for a new target logical partition is received again within the same write transaction, the current transaction number is used. If it is determined that the shared state sector has completed the erasure of the current transaction and the state recovery of the non-target logical partition, the independent state item corresponding to the new target logical partition is first switched to the pending update state or the invalid pending recovery state. Then, the repeated erasure of the shared state sector and the repeated recovery of the state of the non-target logical partition are skipped, and the data writing process of the new target logical partition is executed. After the data writing to the new target logical partition is completed and passes the integrity check and compatibility check, the transaction phase flag is updated to target logical partition verification pending commit, the new target logical partition independent status item is committed as valid, and the version count, compatibility status item and status item verification field are updated. After the new target logical partition state is committed, update the current target logical partition, the set of committed target logical partitions, and the set of remaining target logical partitions to be flushed in the flush transaction recovery record. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is not empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end instruction or a diagnostic flush session end instruction has not yet been received, keep the current transaction number, the flush transaction recovery record, and the session-level erase state valid, and wait for or process the next download request. When the flush transaction is bounded by a pre-determined set of target logical partitions and the set of remaining target logical partitions to be flushed is empty, or when the flush transaction is bounded by a diagnostic flush session and a flush transaction end instruction or a diagnostic flush session end instruction has been received, persist the transaction phase flag to transaction completion, write the recovery completion flag, and clean up or invalidate the flush transaction recovery record.

7. The multi-partition program write state control method as described in claim 1, characterized in that, The multi-partition program write status control method also includes: When a flush exception occurs, a recovery exception occurs, a session timeout occurs, or the system is re-initialized upon power-on, the flush transaction recovery record and its persistent transaction phase flags are read from the non-volatile storage area: If it is determined that the shared state sector has been erased but the non-target logical partition state has not been fully restored, then the non-target logical partition state will continue to be restored based on the flush transaction recovery record. If the data writing or verification of the target logical partition is not completed, the target logical partition remains invalid. If the transaction is not completed, normal application startup will be blocked or a re-entry into the flashing session will be required.

8. The multi-partition program write state control method as described in claim 1, characterized in that, The multi-partition program write status control method also includes: During startup determination, the system uses the set of dependencies of the startup required blocks, the independent status items of each startup required block, the version count, the compatibility status items, the recovery completion flag, and the transaction phase flag to jointly determine whether to allow application startup. If any startup required block does not meet the validity condition, compatibility condition, or transaction completion condition, normal application startup is blocked.

9. A multi-partition program writing status control device, characterized in that, The multi-partition program write status control device includes: The configuration module is used to set independent status items for each logical partition. After receiving the flush request of the target logical partition, it creates a flush transaction and generates a transaction number and transaction stage flag. The generation module is used to switch the independent status item corresponding to the target logical partition to the pending update state or the invalid pending recovery state, record the target logical partition identifier, generate a flush transaction recovery record, and write the flush transaction recovery record to the non-volatile storage area. The operation module is used to perform a full sector erase operation on the shared state sector and update the transaction phase flag to indicate that the shared state sector has been erased or that the non-target logical partition is in recovery. The execution module is used to restore the independent state entries of non-target logical partitions that should remain valid, recorded in the flush transaction recovery record, to the shared state sector.

10. A multi-partition program writing status control device, characterized in that, The multi-partition program write state control device includes a processor, a memory, and a multi-partition program write state control program stored in the memory and executable by the processor, wherein when the multi-partition program write state control program is executed by the processor, it implements the steps of the multi-partition program write state control method as described in any one of claims 1 to 8.

Images