Flash data exception recovery method and device, equipment, medium and product

Abstract

The invention relates to a Flash data exception recovery method and device, equipment, a medium and a product, and the method comprises the steps: determining a target exception partition with data exception in an immutable partition under the condition that the data of the immutable partition in a Flash partition of the equipment is detected to be exceptional in a Boot stage of power-on startup of the equipment; determining an abnormal data block with data exception in the target abnormal partition; recovering the stored data in the abnormal data block through the redundant code block stored in the target abnormal partition; wherein the redundant code block is obtained by coding original data in the target abnormal partition through an erasure code data algorithm. According to the method and the device, the problem that the equipment cannot be normally started due to the abnormal Flash data can be solved.

Description

Technical Field

[0001] This disclosure relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, device, medium, and product for recovering abnormal Flash data. Background Technology

[0002] The device's Flash data is generated by using a package packaging tool to create a firmware package from multiple binary files and some configuration files. Then, a dedicated chip download tool is used to burn the firmware package into the device's flash memory. Finally, the data is written to the factory production line using tools such as embedded device calibration and serial number writing tools, thus completing the writing of the device's Flash data.

[0003] When deploying and using devices, some devices are placed in harsh environments. Environmental factors such as electromagnetic interference and temperature changes can cause them to become "bricked" due to inadequate code write protection mechanisms or insufficient EMC protection. This can result in the device failing to boot and losing functionality due to Flash data corruption, incorrect erasure, or reset of the Flash memory. Current technology typically involves re-downloading and reprogramming the flash memory to restore functionality. However, given the wide deployment range of IoT devices and the extremely high on-site maintenance costs for manufacturers in locations such as underground mines and residential homes, there is an urgent need for a technology that can self-recover when the device fails to boot due to Flash data anomalies and can provide statistical data on the anomalies to improve device robustness. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, medium, and product for recovering abnormal Flash data.

[0005] According to a first aspect of this disclosure, a method for recovering abnormal Flash data is provided, the method comprising:

[0006] If an abnormality is detected in the immutable partition data of the Flash partition of the device during the Boot phase of the device power-on, the target abnormal partition in the immutable partition where the data abnormality occurred is determined.

[0007] Identify the abnormal data blocks that have experienced data anomalies within the target abnormal partition;

[0008] The stored data in the abnormal data block is recovered by using the redundant code blocks already stored in the target abnormal partition; wherein, the redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

[0009] Further, determining the target abnormal partition in the immutable partition where data anomalies have occurred includes:

[0010] Obtain the checksum and checksum code pre-stored in the immutable partition;

[0011] Perform integrity verification on the immutable partition to obtain the data verification result of the immutable partition;

[0012] The immutable partitions whose checksum and check code do not match the data verification result are identified as the target abnormal partitions.

[0013] Further, determining the abnormal data block in the target abnormal partition where the data abnormality has occurred includes:

[0014] The abnormal data block is located by using the checksum of the original data of each data block in the target abnormal partition.

[0015] Furthermore, after identifying the target anomalous partition in the immutable partition where data anomalies have occurred, the method further includes:

[0016] If the target abnormal partition contains Boot code, then the Boot code is used to perform an integrity check on the Boot code through a backup of the Boot code;

[0017] If the integrity check fails, the boot code is restored using the backup code, and the device is restarted after the boot code is successfully restored.

[0018] Furthermore, after identifying the abnormal data block in the target abnormal partition where the data abnormality occurred, the method further includes:

[0019] Determine the diagnostic information of the abnormal data block, wherein the diagnostic information includes at least one of the following: the code information of the abnormal data block, and the location information of the abnormal data block;

[0020] The diagnostic information is saved to a variable partition of the device.

[0021] Furthermore, after recovering the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition, the method further includes:

[0022] Restart the device and report the diagnostic information of the abnormal data block to the user.

[0023] Furthermore, before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, the method further includes:

[0024] Based on the total length of the immutable partition in the Flash partition of the device and the total length of the original data blocks stored in the immutable partition, a redundant code block is determined; wherein, the redundant code block stores the redundant code of the data block;

[0025] The redundant code block is saved to the immutable partition of the device, and the partition information of the immutable partition is determined; wherein the partition information includes at least one of the following: partition attribute information, data block attribute information, and redundant code block attribute information.

[0026] Further, determining redundant code blocks based on the total length of the immutable partitions in the Flash partition of the device and the total length of the originally stored data blocks in the immutable partitions includes:

[0027] The difference between the total length of the immutable partition in the Flash partition and the total length of the data block in the immutable partition is calculated to obtain the space address of the redundancy code virtual space;

[0028] The redundant code is saved to the redundant code virtual space according to the spatial address to obtain the redundant code block; wherein, the total length of the redundant code block is an integer multiple of the data block size.

[0029] Furthermore, before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, the method further includes:

[0030] If the data in the immutable partition of the Flash partition meets the update requirements, the source code of the data block to be updated in the immutable partition is compiled to obtain the original binary file, and the first partition information of the original binary file in the immutable partition is determined.

[0031] The first partition information is updated based on the length of the redundant code virtual space of the immutable partition to obtain the second partition information;

[0032] Based on the second partition information, the original binary file is converted into a target data block, and a redundant code block of the target data block is generated;

[0033] The target data block and the redundant code block are downloaded to the device, and the checksum and check code of the target data block are updated. During the boot phase of the device power-on, the device is checked for any abnormalities in the immutable partition.

[0034] According to a second aspect of this disclosure, a Flash data anomaly recovery apparatus is provided, the apparatus comprising:

[0035] The first determining module is used to determine the target abnormal partition in the immutable partition where the data abnormality occurred when an abnormality is detected in the immutable partition data of the Flash partition of the device during the Boot phase of the device power-on.

[0036] The second determining module is used to determine the abnormal data block in the target abnormal partition where data abnormality has occurred;

[0037] The first recovery module is used to recover the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition; wherein the redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

[0038] According to a third aspect of this disclosure, an electronic device is provided. The electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described above.

[0039] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the methods described above.

[0040] According to a fifth aspect of this disclosure, a computer program product is provided. The computer program product includes a computer program that, when executed by a processor, implements the methods described above in this disclosure.

[0041] This disclosure provides a method, apparatus, device, medium, and product for recovering abnormal Flash data. In this embodiment, firstly, if an anomaly is detected in the immutable partition data of the Flash partition during the device's power-on boot phase, a target abnormal partition in the immutable partition where the data anomaly occurred is identified. Then, the abnormal data block in the target abnormal partition is identified. Finally, the stored data in the abnormal data block is recovered using redundant code blocks already stored in the target abnormal partition. The redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

[0042] As described above, the technical solution of this disclosure detects whether there are any anomalies in the immutable partition data of the Flash partition during the Boot stage of device power-on. If an anomaly is detected, the abnormal data block causing the anomaly can be located, and the stored data in the abnormal data block can be recovered based on the corresponding redundant code block. This disclosure can automatically recover from the bricking problem caused by Flash data anomalies through forward erasure coding data recovery technology. Furthermore, the automatic detection and recovery of abnormal Flash data during the device power-on stage of this disclosure does not require intrusive modifications to the original functional design, achieving the purpose of self-repair upon startup. It has low maintenance costs, good applicability, and can be applied to various embedded devices. Attached Figure Description

[0043] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0044] Figure 1 A flowchart of a Flash data anomaly recovery method provided as an exemplary embodiment of this disclosure;

[0045] Figure 2 A schematic diagram of a Flash partition provided as an exemplary embodiment of this disclosure;

[0046] Figure 3 A flowchart of a Flash data anomaly recovery method provided as another exemplary embodiment of this disclosure;

[0047] Figure 4 A flowchart of a Flash data anomaly recovery method provided as another exemplary embodiment of this disclosure;

[0048] Figure 5 A flowchart of a Flash data anomaly recovery method provided as another exemplary embodiment of this disclosure;

[0049] Figure 6 A flowchart of a Flash data anomaly recovery method provided as another exemplary embodiment of this disclosure;

[0050] Figure 7 A schematic diagram of a Flash partition provided for another exemplary embodiment of this disclosure;

[0051] Figure 8 A flowchart of a Flash data anomaly recovery method provided as another exemplary embodiment of this disclosure;

[0052] Figure 9 This is a schematic diagram of Flash data updating provided as an exemplary embodiment of the present disclosure;

[0053] Figure 10 A schematic block diagram of the functional modules of a Flash data anomaly recovery device provided as an exemplary embodiment of this disclosure;

[0054] Figure 11 A structural block diagram of an electronic device provided as an exemplary embodiment of this disclosure;

[0055] Figure 12 A structural block diagram of a computer system provided as an exemplary embodiment of this disclosure;

[0056] Figure 13A structural block diagram of a computer program product provided for an exemplary embodiment of this disclosure. Detailed Implementation

[0057] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0058] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0059] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0060] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0061] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0062] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0063] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0064] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device. It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation of this disclosure; other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0065] In one embodiment, such as Figure 1 As shown, a method for recovering abnormal Flash data is provided, including the following steps:

[0066] Step 101: If an anomaly is detected in the immutable partition data of the device's Flash partition during the Boot phase of the device's power-on, determine the target abnormal partition in the immutable partition where the data anomaly occurred.

[0067] Generally, Flash partitions can be divided into two categories: variable partitions and immutable partitions. Variable partitions store user data and data that needs to be saved during operation. This part depends on the operating state and generally does not affect system startup. Immutable partitions are generally the code area and critical data area. This part does not change with the system's operating state and is the key data to ensure the system can start normally and maintain normal operation. Generally, this refers to the data area that cannot be changed after the device firmware is burned or after the device leaves the factory. This is also the data object area that this invention needs to process.

[0068] Here, during the boot phase of the device's power-on process, the executing entity can detect whether there are any anomalies in the immutable partition data within the device's Flash partition. If an anomaly is detected, the executing entity can identify the target abnormal partition within the immutable partition where the data anomaly occurred. It should be noted that this device can be an embedded device or other types of devices; the specific device type is not limited here.

[0069] During the boot phase, an integrity check of the immutable flash partition will be performed, using checksum verification algorithms such as SHA256 or MD5. If the checksum result of the immutable partition in the flash partition does not match the checksum stored in the flash, it proves that the protected data has been corrupted, that is, it is determined that there is an anomaly in the immutable partition data in the flash partition. At this point, a serious error will occur during device startup or operation, so the boot code will guide the subsequent data recovery process, which involves executing the steps described below.

[0070] In one possible embodiment, determining the target anomalous partition in an immutable partition where data anomalies have occurred includes the following steps:

[0071] Retrieve the checksum and checksum code pre-stored in the immutable partition;

[0072] Perform integrity verification on the immutable partition to obtain the data verification result of the immutable partition;

[0073] Immutable partitions whose checksums and check codes do not match the data verification results are identified as target anomalous partitions.

[0074] Specifically, if an anomaly is detected in the immutable partition data during the boot phase of the device's power-on, the execution entity first retrieves the checksum and checksum code pre-stored in the immutable partition. For example... Figure 2 As shown, Figure 2 An exemplary diagram of Flash partitioning is shown, wherein the Flash partitioning of the device is divided into variable partitions and immutable partitions. The immutable partitions include the Partitioninfo partition, Factory partition, BootLoader partition, Code1 partition, Code2 partition, and Code3 partition; the variable partitions include the Reserved partition, File System partition, User NV partition, System NV partition, and OTA partition.

[0075] For example, if the executing entity detects an anomaly in the immutable partition data in the Flash partition of the device during the Boot phase when the device is powered on, it can obtain the checksum, i.e., the checksum code, which is stored in the Partitioninfo partition in advance. This checksum code is used to indicate the integrity of the original data of each partition in the immutable partition.

[0076] Then, the executing entity can perform integrity checks on each partition in the immutable partition using an integrity verification algorithm to obtain the data verification results for each partition. For example, the integrity verification algorithm can be either the SHA256 algorithm or the MD algorithm. It should be noted that the specific type of integrity verification algorithm is not limited here, as long as it can effectively verify each partition in the immutable partition.

[0077] Finally, the executing entity identifies immutable partitions where the checksum and checksum code do not match the data verification result as target abnormal partitions. For example, when the checksum code corresponding to partition Code1 in the immutable partition does not match the data verification result of partition Code1 obtained by the SHA256 algorithm, the executing entity identifies partition Code1 as the target abnormal partition.

[0078] Step 102: Identify the abnormal data block in the target abnormal partition where the data abnormality occurred.

[0079] Here, after identifying the target abnormal partition in the immutable partition where the data anomaly has occurred, the executing entity can identify the abnormal data block in the target abnormal partition where the data anomaly has occurred.

[0080] In one possible embodiment, identifying the anomalous data block in the target anomalous partition includes the following steps:

[0081] The abnormal data block is located by using the checksum of the original data in each data block of the target abnormal partition.

[0082] Specifically, after identifying the target abnormal partition in the immutable partition where data anomalies have occurred, the executing entity can locate the data block where data anomalies have occurred by using the checksum of the original data of each data block in the target abnormal partition, and thus obtain the abnormal data block.

[0083] For example, suppose the target abnormal partition identified by the executing entity in an immutable partition is partition Code1, which includes data block 1, data block 2, and data block 3. In this case, the executing entity locates the abnormal data block by detecting the checksums of data block 1, data block 2, and data block 3; for example, the abnormal data block is data block 2. Furthermore, information such as the abnormal location and content of the abnormal data block can be stored in a mutable data partition, such as a file system, to aid in error diagnosis.

[0084] Step 103: Recover the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition.

[0085] Here, after the executing entity identifies the abnormal data block in the target abnormal partition where the data abnormality has occurred, it can recover the stored data in the abnormal data block through the redundant code block already stored in the target abnormal partition. The redundant code block is obtained by encoding the original data in the target abnormal partition through the erasure coding data algorithm.

[0086] In one possible embodiment, the executing entity recovers the stored data in the abnormal data block using redundant code blocks already stored in the target abnormal partition. These redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding algorithm. The erasure coding algorithm can be array erasure coding, such as RAID5 or RAID6, or it can be Reed-Solomon erasure coding, or low-density parity check erasure coding. It should be noted that the choice of erasure coding algorithm is not limited here, as long as it can encode the original data in the target abnormal partition to obtain redundant code blocks.

[0087] For example, the target abnormal partition identified by the executing entity in the immutable partition is partition Code1. Partition Code1 includes data block 1, data block 2, and data block 3. The executing entity locates the abnormal data block as data block 2 by detecting the checksums of data blocks 1, 2, and 3. Redundant code blocks for data block 2 have been stored in partition Code1. These redundant code blocks are obtained by encoding data block 2 using a Reed-Solomon erasure coding algorithm. The executing entity uses these redundant code blocks to recover the stored data in data block 2. It should be noted that the number of redundant code blocks must be greater than the number of abnormal data blocks. Assuming the Cauchy-Reed-Solomon data recovery algorithm is used here, and the original data in this partition is divided into n data blocks, with m redundant code blocks already stored, then data recovery is possible as long as the number of abnormal data blocks does not exceed m; otherwise, recovery fails.

[0088] This disclosure provides a method, apparatus, device, medium, and product for recovering abnormal Flash data. In this embodiment, firstly, if an anomaly is detected in the immutable partition data of the Flash partition during the device's power-on boot phase, a target abnormal partition in the immutable partition where the data anomaly occurred is identified. Then, the abnormal data block in the target abnormal partition is identified. Finally, the stored data in the abnormal data block is recovered using redundant code blocks already stored in the target abnormal partition. The redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

[0089] As described above, the technical solution of this disclosure detects whether there are any anomalies in the immutable partition data of the Flash partition during the Boot stage of device power-on. If anomalies are detected, the abnormal data block causing the anomaly can be located, and the stored data in the abnormal data block can be recovered based on the corresponding redundant code block. This disclosure can automatically recover from device bricking caused by Flash data anomalies through forward erasure coding data recovery technology. Furthermore, the automatic detection and recovery of abnormal Flash data during the device power-on stage of this disclosure requires no intrusive modification to the original functional design, achieving self-healing upon startup. It features low maintenance costs, good applicability, and can be applied to various embedded devices.

[0090] In one embodiment, such as Figure 3 As shown, after identifying the target abnormal partition in the immutable partition where data anomalies have occurred in step 101, the following steps are also included:

[0091] Step 301: If the target abnormal partition contains Boot code, then the integrity of the Boot code is verified by using the backup code of the Boot code.

[0092] Here, after the executing entity identifies the target abnormal partition in the immutable partition where the data anomaly has occurred, if the target abnormal partition contains Boot code, the executing entity will perform an integrity check on the Boot code using the backup code of the Boot code.

[0093] In one possible embodiment, the executing entity identifies the target aberration partition within the immutable partition. If the target aberration partition contains boot code, the executing entity performs integrity verification on the boot code using its backup. It should be noted that the bootloader partition is the first partition entered during system startup. In this embodiment, the backup boot code is preferably deployed in this partition, and this backup code must employ a full backup mechanism to prevent this critical code from being corrupted.

[0094] For example, the target abnormal partition determined by the execution entity in the immutable partition is the bootloader partition, and the bootloader partition contains the boot code and the backup code of the boot code. The execution entity verifies the integrity of the boot code through the backup code of the boot code.

[0095] Step 302: If the integrity verification fails, restore the Boot code using the backup code, and restart the device after the Boot code is successfully restored.

[0096] Here, the executing entity performs integrity verification on the Boot code using the backup code. If the integrity verification fails, it restores the Boot code using the backup code and restarts the device after the Boot code is successfully restored.

[0097] In one possible embodiment, the target abnormal partition determined by the execution subject in the immutable partition is the bootloader partition, and the bootloader partition contains the boot code and the backup code of the boot code. The execution subject performs integrity verification on the boot code through the backup code of the boot code. If the integrity verification fails, the execution subject restores the boot code through the backup code of the boot code stored in the bootloader partition, and restarts the device after the boot code is successfully restored.

[0098] In this embodiment, firstly, if the executing entity detects that the target abnormal partition contains Boot code, it performs an integrity check on the Boot code using the backup code of the Boot code. Then, if the integrity check fails, the executing entity restores the Boot code using the backup code and restarts the device after the Boot code is successfully restored.

[0099] As described above, in the event that the Boot code integrity verification fails, this embodiment restores the Boot code by backing up the code and restarts the device after the Boot code is successfully restored. This avoids the device being unable to enter the subsequent Flash data recovery process due to Boot code corruption, thus further improving the stability of the device.

[0100] In one embodiment, such as Figure 4 As shown, after identifying the abnormal data block in the target abnormal partition in step 102, the following steps are also included:

[0101] Step 401: Determine the diagnostic information for the abnormal data block.

[0102] Here, after the executing entity identifies the abnormal data block in the target abnormal partition where the data anomaly has occurred, it can determine the diagnostic information of the abnormal data block. This diagnostic information includes at least one of the following: the code information of the abnormal data block, or the location information of the abnormal data block.

[0103] In one possible embodiment, for example, the executing entity determines the abnormal data block in the target abnormal partition as data block 1 of the Code1 partition, and the executing entity determines the diagnostic information of data block 1, wherein the diagnostic information of data block 1 includes: code information of data block 1 and location information of data block 1.

[0104] Step 402: Save the diagnostic information to the device's variable partition.

[0105] Here, after determining the diagnostic information of the abnormal data block, the executing entity can save the diagnostic information to the device's variable partition.

[0106] Continuing the previous example, the executing entity identifies the abnormal data block in the target abnormal partition as data block 1 of the Code1 partition, and determines the diagnostic information for data block 1. The executing entity then saves the diagnostic information for data block 1 to the Reserved partition in the variable partition. It should be noted that the diagnostic information can also be saved to other partitions in the variable partition, such as the File System partition or the OTA partition; the specific save location is not restricted.

[0107] In this embodiment, firstly, the executing entity determines the diagnostic information of the abnormal data block, and then saves the diagnostic information to the device's variable partition. As described above, this embodiment, by saving the diagnostic information of the abnormal data block to the device's variable partition, helps developers to analyze the causes of device anomalies later by reading the diagnostic information saved in the variable partition, thereby improving the stability and reliability of the device.

[0108] In one embodiment, such as Figure 5 As shown, after recovering the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition, step 103 also includes the following steps:

[0109] Step 501: Restart the device and report the diagnostic information of the abnormal data blocks to the user.

[0110] After the executing entity recovers the stored data in the abnormal data block of the device through the redundant code blocks already stored in the target abnormal partition, if the device is a device with communication functions, the executing entity can report the diagnostic information of the abnormal data block to the user after the data recovery is successful and the device is restarted.

[0111] In this embodiment, after the data is successfully recovered and the device is restarted, the executing entity can report the diagnostic information of the abnormal data block to the user, which helps the developers analyze the cause of the device's abnormality and further improves the stability and reliability of the device.

[0112] In one embodiment, such as Figure 6 As shown, before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, step 101 further includes the following steps:

[0113] Step 601: Determine redundant code blocks based on the total length of the immutable partitions in the device's Flash partitions and the total length of the original data blocks stored in the immutable partitions.

[0114] Here, before determining the target abnormal partition in the immutable partition where the data anomaly occurs, the executing entity can determine the redundant code block based on the total length of the immutable partition in the device's Flash partition and the total length of the original data blocks stored in the immutable partition; wherein, the redundant code block stores the redundant code of the data block.

[0115] In one possible embodiment, redundancy blocks are determined based on the total length of immutable partitions in the device's Flash partition and the total length of data blocks originally stored in the immutable partitions, including the following steps:

[0116] First, calculate the difference between the total length of the immutable partition in the Flash partition and the total length of the data block in the immutable partition to obtain the space address of the redundancy code virtual space;

[0117] Secondly, the redundant code is saved to the redundant code virtual space according to the spatial address to obtain the redundant code block.

[0118] Specifically, before determining the target abnormal partition in the immutable partition where data anomalies occur, the executing entity first calculates the difference between the total length of the immutable partition in the Flash partition and the total length of the data blocks in the immutable partition to obtain the space address of the redundancy code virtual space, and then allocates the redundancy code virtual space to each partition in the immutable partition according to the space address.

[0119] Here, the size of the virtual space for redundant codes must be an integer multiple of the size of the data block to meet the requirement that erasure code data blocks have the same size. The combined virtual address spaces are contiguous to simplify partition table records. All remaining space in the immutable area can be fully utilized for redundant code storage, increasing redundancy and thus improving the probability of recovery.

[0120] For example, such as Figure 7 As shown, Figure 7 Another Flash partition diagram is shown as an example, in which each partition in the immutable partition corresponds to a redundant code virtual space.

[0121] It should be noted that when the bootloader partition is the first partition entered when the system starts, the backup code of the boot code in this embodiment can preferably be deployed in this partition, and this backup code needs to adopt a full backup mechanism. Therefore, the bootloader partition does not need to set up a redundant code virtual space. The factory partition is the data area written by the subsequent process after the firmware is downloaded. Therefore, the factory partition also does not need to set up a redundant code virtual space.

[0122] Then, the executing entity saves the redundant code to the redundant code virtual space according to the space address corresponding to each partition, obtaining redundant code blocks. The total length of the redundant code blocks is an integer multiple of the data block size; that is, each redundant code block completely stores the redundant code of the data block. It should be noted that there is no limit to the number of redundant code blocks generated. When there is a large amount of remaining space address in the redundant code virtual space, the number of redundant code blocks generated can be increased to enhance redundancy, thereby improving the recoverability probability of stored data in abnormal data blocks.

[0123] Step 602: Save the redundant code block to the immutable partition of the device and determine the partition information of the immutable partition.

[0124] Here, the executing entity determines redundant code blocks based on the total length of the immutable partitions in the device's Flash partitions and the total length of the originally stored data blocks in the immutable partitions. The redundant code blocks can then be saved to the device's immutable partitions, and the partition information for each immutable partition is determined. The partition information includes at least one of the following: partition attribute information, data block attribute information, or redundant code block attribute information.

[0125] like Figure 7 As shown, after identifying the redundant code block, the executing entity first saves the redundant code block to the redundant code virtual space in the immutable partition of the device. Then, it determines the partition information of the immutable partition and saves the partition information to the Partitioninfo partition. This partition information includes: partition attribute information, data block attribute information, and redundant code block attribute information. Among them, the partition attribute information includes the partition ID or partition name, partition start address, partition size, and checksum of each partition. The data block attribute information includes the length of each data block. The redundant code block attribute information includes the redundant code start address and redundant code length of each redundant code block. A redundant code length of 0 indicates that the region does not support data recovery.

[0126] In this embodiment, firstly, the execution entity determines redundant code blocks based on the total length of the immutable partition in the Flash partition of the device and the total length of the original data blocks stored in the immutable partition. Then, the execution entity saves the redundant code blocks to the immutable partition of the device and determines the partition information of the immutable partition.

[0127] As described above, the execution entity determines redundant code blocks by using the total length of the immutable partition and the total length of the original data blocks stored in the immutable partition, and saves the redundant code blocks to the immutable partition of the device, thereby optimizing the space of the immutable partition of the device; and the partition information of the immutable partition is saved to the Partitioninfo partition, which does not have an intrusive impact on the original partitioning scheme of the immutable partition of the device, further improving the stability of the device.

[0128] In one embodiment, such as Figure 8 As shown, before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, step 101 further includes the following steps:

[0129] Step 801: If the data in the immutable partition of the Flash partition meets the update requirements, compile the source code of the data block to be updated in the immutable partition to obtain the original binary file, and determine the first partition information of the original binary file in the immutable partition.

[0130] Here, if the data in the immutable partition of the Flash partition meets the update requirements, the execution entity can compile the source code of the data block to be updated in the immutable partition to obtain the original binary file and determine the first partition information of the original binary file in the immutable partition.

[0131] like Figure 9 As shown, Figure 9 An exemplary diagram of Flash data update is shown. When the data in the immutable partition of the Flash partition meets the update requirements, firstly, the executing entity can compile the source code and data of the data blocks to be updated in the Partitioninfo partition, User NV partition, SystemNV partition, File Sysem partition, BootLoader partition, and Code1-CodeN partitions to obtain the original binary files boot.bin, cp.bin, ap.bin, etc. Then, the executing entity determines the first partition information of the original binary file in the immutable partition of the device, wherein the first partition information is used to indicate the original storage location of the binary file in the immutable partition.

[0132] During the process of updating the data in the immutable partition of the Flash partition, since devices such as communication modules will update the factory partition during factory production, if it is necessary to update the Factory partition in the immutable partition of devices such as communication modules, the factory calibration and serial number data can be compiled at the same time as the source code of the data block to be updated in the immutable partition to obtain the original binary file, and the first partition information of the original binary file in the immutable partition can be determined.

[0133] Step 802: Update the first partition information based on the length of the redundancy code virtual space of the immutable partition to obtain the second partition information.

[0134] Here, after obtaining the original binary file and determining its first partition information within the immutable partition, the executing entity updates the first partition information based on the length of the redundancy code virtual space of the immutable partition, thus obtaining the second partition information. The second partition information indicates the updated storage location of the binary file within the immutable partition.

[0135] After determining the first partition information of the original binary file within the immutable partition, the executing entity updates the first partition information based on the length of the redundant code virtual space of the immutable partition and the position mapping relationship of the virtual space in the mapping table of the immutable partition, thus obtaining the second partition information. The second partition information indicates the updated storage location of the binary file within the immutable partition.

[0136] Step 803: Based on the second partition information, the original binary file is converted into a target data block, and a redundant code block of the target data block is generated.

[0137] Here, the execution entity updates the first partition information based on the length of the redundant code virtual space based on the immutable partition. After obtaining the second partition information, it can convert the original binary file into the target data block based on the second partition information and generate the redundant code block of the target data block.

[0138] After obtaining the second partition information, the executing entity can convert the original binary file into target data blocks based on the second partition information and generate redundant code blocks for the target data blocks. It should be noted that when there is a large amount of remaining space address in the redundant code virtual space, the number of redundant code blocks generated can be increased to increase redundancy, thereby improving the recoverability probability of stored data in abnormal data blocks and expanding the application scenarios of anomaly recovery. Therefore, the number of redundant code blocks generated is not limited here.

[0139] Step 804: Download the target data block and redundant code block to the device, update the checksum and check code of the target data block, and check for any abnormalities in the immutable partition of the device during the boot phase of the device power-on.

[0140] Here, after the execution entity converts the original binary file into a target data block based on the second partition information and generates a redundant code block for the target data block, it can download the target data block and the redundant code block to the device, update the checksum and check code of the target data block, and detect whether there are any abnormalities in the data in the immutable partition of the device during the boot phase of the device power-on.

[0141] like Figure 9 As shown, after the execution entity converts the original binary file into a target data block based on the second partition information and generates a redundant code block for the target data block, it first packages the target data block and the redundant code block into a firmware package according to the configuration file and downloads the firmware package to the device. During the download process, the execution entity updates the checksum and check code of the target data block. After the target data block is updated, it updates the checksum and check code of each partition in the immutable partition. After the checksum and check code of each partition is updated, it updates the total checksum and check code of the immutable partition and saves the checksum and check code of the target data block, the checksum and check code of each partition in the immutable partition, and the total checksum and check code of the immutable partition to the Partitioninfo partition of the immutable partition.

[0142] Then, during the boot phase of the device's power-on, the execution entity detects whether there are any anomalies in the data of the device's immutable partition. If an anomaly is found, the entity recovers the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition. The specific steps for recovering the stored data in the abnormal data block can be found in the embodiments of steps 101 to 103, and will not be repeated here.

[0143] In this embodiment, firstly, if the data in the immutable partition of the Flash partition meets the update requirements, the execution entity compiles the source code of the data block to be updated in the immutable partition to obtain the original binary file and determines the first partition information of the original binary file in the immutable partition. Then, the execution entity updates the first partition information based on the length of the redundant code virtual space of the immutable partition to obtain the second partition information. After that, the execution entity converts the original binary file into the target data block based on the second partition information and generates the redundant code block of the target data block. Finally, the execution entity downloads the target data block and the redundant code block to the device, updates the checksum and check code of the target data block, and checks whether there are any abnormalities in the data in the immutable partition of the device during the boot phase of the device power-on.

[0144] As described above, if the data in the immutable partition of the Flash partition meets the update requirements, the executing entity can update the data in the immutable partition of the Flash partition. At the same time as updating the data, it can also update the checksum and check code of the target data block, the checksum and check code of each partition in the immutable partition, and the total checksum and check code of the immutable partition, forming three levels of verification information. This allows for the rapid location of the abnormal data block that has caused the data anomaly during the Flash data anomaly recovery process, further improving the reliability of the Flash data anomaly recovery method.

[0145] As described above, the technical solution disclosed herein can fully utilize unused Flash memory space to store redundant data codes. The larger the remaining space, the more damaged data blocks can be repaired. Erasure coding technology has high space utilization and is also practical for devices sensitive to Flash memory space. The erasure coding generation and writing method of this technical solution can be performed after program compilation and before downloading, fully utilizing the toolchain of existing chip systems, resulting in low usage costs. This technical solution can record data anomalies and abnormal data blocks. Devices with communication capabilities can upload and centrally analyze the data to assist in analyzing the causes of device anomalies.

[0146] By dividing each functional module according to its corresponding function, this disclosure provides a Flash data anomaly recovery device, which can be a server or a chip applied to a server. Figure 10 This is a schematic block diagram of the functional modules of a Flash data anomaly recovery device provided as an exemplary embodiment of this disclosure. Figure 10 As shown, the Flash data anomaly recovery device includes:

[0147] The first determining module 1001 is used to determine the target abnormal partition in the immutable partition where the data abnormality occurred when an abnormality is detected in the immutable partition data of the Flash partition of the device during the Boot phase of the device power-on.

[0148] The second determining module 1002 is used to determine the abnormal data block in the target abnormal partition where data abnormality has occurred;

[0149] The first recovery module 1003 is used to recover the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition; wherein the redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

[0150] In one embodiment, the first determining module 1001 includes:

[0151] The first acquisition unit is used to acquire the checksum and check code pre-stored in the immutable partition;

[0152] The second acquisition unit is used to perform integrity verification on the immutable partition and obtain the data verification result of the immutable partition.

[0153] The first determining unit is used to determine the immutable partition where the checksum and check code do not match the data verification result as the target abnormal partition.

[0154] In one embodiment, the second determining module 1002 includes:

[0155] The third acquisition unit is used to locate the abnormal data block by using the checksum of the original data of each data block in the target abnormal partition.

[0156] In one embodiment, the apparatus further includes:

[0157] The verification module is used to perform integrity verification on the Boot code by using the backup code of the Boot code if the target abnormal partition contains Boot code;

[0158] The second recovery module is used to restore the Boot code using the backup code if the integrity verification fails, and to restart the device after the Boot code is successfully restored.

[0159] In one embodiment, the apparatus further includes:

[0160] The third determining module is used to determine the diagnostic information of the abnormal data block, wherein the diagnostic information includes at least one of the following: the code information of the abnormal data block, and the location information of the abnormal data block;

[0161] A storage module is used to save the diagnostic information to a variable partition of the device.

[0162] In one embodiment, the apparatus further includes:

[0163] The reporting module is used to restart the device and report the diagnostic information of the abnormal data block to the user.

[0164] In one embodiment, the apparatus further includes:

[0165] The fourth determining module is used to determine redundant code blocks based on the total length of the immutable partition in the Flash partition of the device and the total length of the data blocks originally stored in the immutable partition; wherein the redundant code block stores the redundant code of the data block;

[0166] The fifth determining module is used to save the redundant code block to the immutable partition of the device and determine the partition information of the immutable partition; wherein the partition information includes at least one of the following: partition attribute information, data block attribute information, and redundant code block attribute information.

[0167] In one embodiment, the fourth determining module includes:

[0168] The second determining unit is used to calculate the difference between the total length of the immutable partition in the Flash partition and the total length of the data block in the immutable partition, and obtain the space address of the redundancy code virtual space.

[0169] The third determining unit is used to save the redundant code to the redundant code virtual space according to the spatial address to obtain the redundant code block; wherein the total length of the redundant code block is an integer multiple of the data block size.

[0170] In one embodiment, the apparatus further includes:

[0171] The compilation module is used to compile the source code of the data block to be updated in the immutable partition in the Flash partition when the data in the immutable partition meets the update requirements, to obtain the original binary file, and to determine the first partition information of the original binary file in the immutable partition.

[0172] The sixth determining module is used to update the first partition information based on the length of the redundant code virtual space of the immutable partition to obtain the second partition information;

[0173] A generation module is used to convert the original binary file into a target data block based on the second partition information, and generate redundant code blocks for the target data block;

[0174] The download module is used to download the target data block and the redundant code block to the device, update the checksum and check code of the target data block, and detect whether there are any abnormalities in the data in the immutable partition of the device during the boot phase of the device power-on.

[0175] This disclosure also provides an electronic device, including: at least one processor; a memory for storing processor-executable instructions; wherein the at least one processor is configured to execute the instructions to implement the methods disclosed in this disclosure.

[0176] Figure 11 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this disclosure. For example... Figure 11 As shown, the electronic device 1100 includes at least one processor 1101 and a memory 1102 coupled to the processor 1101. The processor 1101 can perform the corresponding steps in the methods disclosed in the embodiments of this disclosure.

[0177] The processor 1101 described above can also be called a central processing unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this embodiment can be implemented by the integrated logic circuitry in the processor 1101 or by software instructions. The processor 1101 can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in the memory 1102, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor 1101 reads information from the memory 1102 and, in conjunction with its hardware, completes the steps of the method described above.

[0178] Furthermore, various operations / processes according to this disclosure, implemented via software and / or firmware, can be transmitted from a storage medium or network to a computer system with a dedicated hardware architecture, such as... Figure 12 The computer system 1200 shown is equipped with the programs that constitute the software. When various programs are installed, the computer system is able to perform various functions, including functions such as those described above. Figure 12 A block diagram of a computer system provided for an exemplary embodiment of this disclosure.

[0179] Computer system 1200 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0180] like Figure 12As shown, the computer system 1200 includes a computing unit 1201, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1202 or a computer program loaded from a storage unit 1208 into a random access memory (RAM) 1203. The RAM 1203 may also store various programs and data required for the operation of the computer system 1200. The computing unit 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0181] Multiple components in the computer system 1200 are connected to the I / O interface 1205, including: an input unit 1206, an output unit 1207, a storage unit 1208, and a communication unit 1209. The input unit 1206 can be any type of device capable of inputting information into the computer system 1200. The input unit 1206 can receive input numerical or character information and generate key signal inputs related to user settings and / or function control of the electronic device. The output unit 1207 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. The storage unit 1208 may include, but is not limited to, a hard disk and an optical disk. The communication unit 1209 allows the computer system 1200 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, a modem, network card, infrared communication device, wireless communication transceiver, and / or chipset, such as Bluetooth™ device, WiFi device, WiMax device, cellular communication device, and / or the like.

[0182] The computing unit 1201 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1201 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1201 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1208. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 1100 via ROM 1202 and / or communication unit 1209. In some embodiments, the computing unit 1201 can be configured to perform the methods disclosed in this disclosure by any other suitable means (e.g., by means of firmware).

[0183] This disclosure also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the methods disclosed in this disclosure.

[0184] The computer-readable storage medium in this disclosure can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0185] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0186] Figure 13 A computer program product 1300 is provided as an exemplary embodiment of the present disclosure. The computer program product 1300 includes a computer program 1301, wherein the computer program 1301, when executed by a processor, implements the methods disclosed in the embodiments of the present disclosure.

[0187] In embodiments of this disclosure, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0188] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0189] The modules, components, or units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0190] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0191] The above description is merely an embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0192] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A method for recovering abnormal Flash data, characterized in that, include: If an abnormality is detected in the immutable partition data of the Flash partition of the device during the Boot phase of the device power-on, the target abnormal partition in the immutable partition where the data abnormality occurred is determined. Identify the abnormal data blocks that have experienced data anomalies within the target abnormal partition; The stored data in the abnormal data block is recovered by using the redundant code blocks already stored in the target abnormal partition; wherein, the redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

2. The method according to claim 1, characterized in that, The process of determining the target abnormal partition in the immutable partition where data anomalies have occurred includes: Obtain the checksum and checksum code pre-stored in the immutable partition; Perform integrity verification on the immutable partition to obtain the data verification result of the immutable partition; The immutable partitions whose checksum and check code do not match the data verification result are identified as the target abnormal partitions.

3. The method according to claim 1, characterized in that, The step of identifying the abnormal data block in the target abnormal partition that has experienced data anomalies includes: The abnormal data block is located by using the checksum of the original data of each data block in the target abnormal partition.

4. The method according to claim 1, characterized in that, After identifying the target anomalous partition in the immutable partition where the data anomaly has occurred, the method further includes: If the target abnormal partition contains Boot code, then the Boot code is used to perform an integrity check on the Boot code through a backup of the Boot code; If the integrity check fails, the boot code is restored using the backup code, and the device is restarted after the boot code is successfully restored.

5. The method according to claim 1, characterized in that, After identifying the anomalous data block in the target anomalous partition where the data anomaly has occurred, the method further includes: Determine the diagnostic information of the abnormal data block, wherein the diagnostic information includes at least one of the following: the code information of the abnormal data block, and the location information of the abnormal data block; The diagnostic information is saved to a variable partition of the device.

6. The method according to claim 5, characterized in that, After recovering the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition, the method further includes: Restart the device and report the diagnostic information of the abnormal data block to the user.

7. The method according to claim 1, characterized in that, Before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, the method further includes: Based on the total length of the immutable partition in the Flash partition of the device and the total length of the original data blocks stored in the immutable partition, a redundant code block is determined; wherein, the redundant code block stores the redundant code of the data block; The redundant code block is saved to the immutable partition of the device, and the partition information of the immutable partition is determined; wherein the partition information includes at least one of the following: partition attribute information, data block attribute information, and redundant code block attribute information.

8. The method according to claim 7, characterized in that, The determination of redundant code blocks based on the total length of the immutable partitions in the Flash partition of the device and the total length of the originally stored data blocks in the immutable partitions includes: The difference between the total length of the immutable partition in the Flash partition and the total length of the data block in the immutable partition is calculated to obtain the space address of the redundancy code virtual space; The redundant code is saved to the redundant code virtual space according to the spatial address to obtain the redundant code block; wherein, the total length of the redundant code block is an integer multiple of the data block size.

9. The method according to claim 1, characterized in that, Before determining the target anomalous partition in the immutable partition where the data anomaly has occurred, the method further includes: If the data in the immutable partition of the Flash partition meets the update requirements, the source code of the data block to be updated in the immutable partition is compiled to obtain the original binary file, and the first partition information of the original binary file in the immutable partition is determined. The first partition information is updated based on the length of the redundant code virtual space of the immutable partition to obtain the second partition information; Based on the second partition information, the original binary file is converted into a target data block, and a redundant code block of the target data block is generated; The target data block and the redundant code block are downloaded to the device, and the checksum and check code of the target data block are updated. During the boot phase of the device power-on, the device is checked for any abnormalities in the immutable partition.

10. A Flash data anomaly recovery device, characterized in that, The device includes: The first determining module is used to determine the target abnormal partition in the immutable partition where the data abnormality occurred when an abnormality is detected in the immutable partition data of the Flash partition of the device during the Boot phase of the device power-on. The second determining module is used to determine the abnormal data block in the target abnormal partition where data abnormality has occurred; The first recovery module is used to recover the stored data in the abnormal data block using the redundant code blocks already stored in the target abnormal partition; wherein the redundant code blocks are obtained by encoding the original data in the target abnormal partition using an erasure coding data algorithm.

11. An electronic device, characterized in that, include: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1-9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images