A method and system for recovering from long-term storage failure in mobile terminals

Abstract

This application relates to the field of digital storage technology, providing a method and system for recovering from long-term storage failures in mobile terminals. Through a built-in independent power supply design, the boot disk can continue to supply power even when the mobile terminal is powered off, overcoming the limitations of traditional OTG devices. The storage controller automatically monitors the read / write status of flash memory chip data blocks and generates real-time health reports; when a warning data block is detected, a bidirectional communication protocol is triggered. During the data backup phase, the boot disk employs a layered verification mechanism to generate CRC codes for each data block and stores them centrally, while simultaneously calculating the overall SHA-256 code and synchronizing it across both ends. In the recovery phase, SHA-256 code comparison ensures backup integrity, and CRC code verification verifies data accuracy block by block. Finally, the backup files are automatically migrated to a non-volatile partition. This achieves a seamless closed loop from fault detection to data recovery, addressing the system booting challenges after long-term device storage.

Description

Technical Field

[0001] This application relates to the field of digital storage technology, and more specifically, to a method and system for recovering from long-term storage failure in mobile terminals. Background Technology

[0002] The content in this section provides only background information related to this application and may not constitute prior art.

[0003] In current mobile phone usage scenarios, when devices are stored in warehouses or user drawers for extended periods (≥2 years), the areas within their internal UFS / eMMC storage components that store firmware, configurations, security keys, and other critical information become crucial for businesses and individuals.

[0004] Issues such as charge leakage, bit flipping, and bad block propagation can easily occur, directly preventing the phone system from booting properly and causing significant obstacles for users. Currently, after-sales repair typically only involves disassembling the device to replace the motherboard or using a dedicated downloader like Firehose / EDL to flash the firmware. This approach is not only costly and time-consuming, but also results in a poor user experience. More importantly, ordinary users lack the skills to disassemble the device or short-circuit test points, and they cannot anticipate storage component failures, making it difficult to quickly restore the device to normal operation.

[0005] In the prior art, Chinese Patent Publication No. CN119622458A discloses a data recovery method, apparatus, storage device, and computer-readable storage medium. The method includes backing up parity data of a redundant disk array (BDA) in the storage device to a backup block via snapshots according to preset backup conditions, and establishing a positional correspondence between the snapshot information of the parity data in the backup block and the location of user data in the BDA. After the storage device experiences an abnormal power outage and subsequent power-on or abnormal restart, the latest parity data snapshot information is obtained from the backup block. Based on the positional correspondence and the latest parity data snapshot information, data recovery is performed on all parity data in the BDA that follows the latest parity data. This method enables rapid recovery of parity data, resulting in shorter boot times for the storage device in the event of an abnormal power outage or restart, thus improving the user experience.

[0006] The aforementioned patents only improve data recovery speed and are only applicable to storage devices using Nand Flash as the storage medium. Furthermore, the BOOT ROM on mobile phones only supports USB or SD card Download Mode. Starting in this mode requires not only manual operation of specific button combinations but also connecting the phone to a computer, installing the corresponding driver on the computer, and authorizing a specific account. This has a high operational threshold, making it difficult for ordinary users to complete independently. Existing Type-C USB flash drives are limited to functioning as OTG expansion devices and cannot be recognized as a "trusted boot source" by the BOOT ROM when the phone is without a system running, thus failing to provide support for device startup and recovery. In addition, the existing technology system lacks a dedicated automatic recovery process for the special scenario of "first power-on after long-term storage," resulting in a lack of convenient and efficient technical means to solve system boot failure problems in this scenario. Summary of the Invention

[0007] To address the aforementioned technical problems, the purpose of this application is to provide a method and system for recovering from long-term storage failure in mobile terminals. This method establishes a connection between the mobile terminal and a boot disk with a built-in independent power supply. During startup, it automatically detects the health status of flash memory chip data blocks and generates a report. When a warning data block is detected, it automatically establishes communication and transmits a backup file containing the CRC codes of each data block and the overall SHA-256 code. Data recovery is completed through multi-layer verification and comparison, and the system is automatically restarted and booted. This eliminates the need for manual operation of specific key combinations, computer connection, and driver installation, thus solving the problem of system boot difficulties upon first power-on after long-term storage.

[0008] The objective of this application is achieved through the following technical solution:

[0009] In a first aspect, the present invention provides a method for recovering from long-term storage failure of a mobile terminal, comprising a mobile terminal and a boot disk, wherein the mobile terminal establishes a connection with the boot disk via a Type-C interface, the boot disk has a built-in independent power supply, and the power supply provides power to the boot disk or the mobile terminal, the method comprising:

[0010] When the mobile terminal starts up, the storage controller performs read and write operations on each data block of the flash memory chip, records the number of errors and response time of each data block, and generates an initial health report containing the corresponding health status.

[0011] When a warning data block higher than the first preset level appears in the initial health report, the mobile terminal initiates two-way communication and sends a connection request containing the warning data block identifier to the boot disk; the boot disk responds to the connection request through the corresponding protocol of the Type-C interface and establishes a data transmission channel.

[0012] After receiving the identifier of the warning data block through the data transmission channel, the boot disk stores all data blocks as backup files in the form of files; generates a CRC code for each data block separately, and stores the CRC codes corresponding to all warning data blocks in the verification area of ​​the boot disk; generates an overall SHA-256 code for all data blocks, and stores the overall SHA-256 code in the root directory of the boot disk and the local cache area of ​​the mobile terminal respectively.

[0013] The mobile terminal retrieves the locally cached SHA-256 code and sends a verification request to the boot disk. The boot disk returns the backup file and the CRC code of the verification area. The mobile terminal extracts the overall SHA-256 code of the root directory and performs a first comparison with the overall SHA-256 code in the locally cached directory. If they do not match, the mobile terminal re-requests the transmission of the backup file and the overall SHA-256 code from the boot disk, repeating the comparison until they match or a transmission failure is determined. If they match, the backup file is restored to the non-volatile spare partition, and each CRC code in the verification area is extracted and compared with the CRC code generated by the corresponding data block in the non-volatile spare partition. If they match, the corresponding data block in the health report is updated to normal. If they do not match, they are marked as abnormal, and the corresponding data block is re-requested from the boot disk, repeating the verification until they match or data corruption is determined. After all operations are completed, the mobile terminal restarts the boot system.

[0014] Furthermore, the number of errors for each data block is counted in real time by the ECC error correction module built into the flash memory chip, and the response time of each data block is obtained by the timing module of the storage controller.

[0015] Furthermore, before a warning data block exceeding the first preset level appears in the initial health report, the following is also included:

[0016] Record the access frequency of each data block. For data blocks whose access frequency exceeds the preset frequency, the mobile terminal shortens the detection interval to the preset interval.

[0017] Furthermore, the step of storing all data blocks as backup files also includes:

[0018] Data blocks accessed more frequently than a preset frequency should be backed up first.

[0019] Furthermore, after storing the complete SHA-256 code in the root directory of the boot disk and the local cache of the mobile terminal, it also includes:

[0020] During the data block transmission process, the mobile terminal creates a temporary copy of each data block to be transmitted, so that the original data block can be accessed normally during the migration; after all data blocks are transmitted and the data block backup files and corresponding CRC codes are stored, the mobile terminal automatically deletes the temporary copies corresponding to all data blocks.

[0021] Furthermore, after updating the corresponding data block in the health report to normal, it also includes:

[0022] Encrypted communication is initiated, and the mobile terminal sends the SHA-256 code and the updated health report to the distributed cloud storage node allocated by the enterprise for individual users via mobile network or WiFi; after receiving the data, the cloud storage node associates and stores the SHA-256 code with the initial health report.

[0023] Furthermore, the mobile terminal also includes the following before restarting the boot system:

[0024] A recovery log is generated to record the key data and corresponding timestamps of this operation, and uploaded to the cloud storage node through an encrypted channel. The key data includes: the number of warning data blocks, transmission time, CRC code comparison results, and SHA-256 code comparison results.

[0025] Secondly, this invention provides a recovery system for long-term storage failure of a mobile terminal, comprising a mobile terminal and a boot disk. The mobile terminal establishes a connection with the boot disk via a Type-C interface. The boot disk has a built-in independent power supply that powers either the boot disk or the mobile terminal. The system includes:

[0026] The startup module is used when the mobile terminal starts up. The storage controller performs read and write operations on each data block of the flash memory chip, records the number of errors and response time of each data block, and generates an initial health report containing the corresponding health status.

[0027] The data transmission channel establishment module is used to initiate bidirectional communication when a warning data block higher than the first preset level appears in the initial health report. The mobile terminal sends a connection request containing the warning data block identifier to the startup disk; the startup disk responds to the connection request through the corresponding protocol of the Type-C interface to establish a data transmission channel.

[0028] The backup module is used to store all data blocks as backup files after the boot disk receives the identifier of the warning data block through the data transmission channel; it generates a CRC code for each data block separately and stores the CRC codes corresponding to all warning data blocks in the verification area of ​​the boot disk; it generates a unified SHA-256 code for all data blocks as a whole, and stores the unified SHA-256 code in the root directory of the boot disk and the local cache area of ​​the mobile terminal respectively.

[0029] The recovery and verification module is used by the mobile terminal to call the locally cached SHA-256 code and send a verification request to the boot disk. The boot disk returns the backup file and the CRC code of the verification area. The mobile terminal extracts the overall SHA-256 code of the root directory and performs a first comparison with the overall SHA-256 code in the local cache. If they do not match, the mobile terminal re-requests the transmission of the backup file and the overall SHA-256 code from the boot disk, repeating the comparison until they match or a transmission failure is determined. If they match, the backup file is restored to the non-volatile spare partition, and each CRC code in the verification area is extracted and compared with the CRC code generated by the corresponding data block in the non-volatile spare partition. If they match, the corresponding data block in the health report is updated to normal. If they do not match, they are marked as abnormal and the corresponding data block is re-requested from the boot disk, repeating the verification until they match or data corruption is determined. After all operations are completed, the mobile terminal restarts the boot system.

[0030] Thirdly, the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the steps corresponding to the method in the first aspect.

[0031] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps corresponding to the method in the first aspect.

[0032] In summary, the technical solutions of this application have at least the following advantages and beneficial effects:

[0033] This invention employs a boot disk with a built-in independent power supply, connected to a mobile terminal via a Type-C interface. This independent power supply can simultaneously power both the boot disk and the mobile terminal, overcoming the limitation of existing Type-C USB drives that can only function as OTG expansion devices. This allows the boot disk to function normally even when the mobile terminal is not running a system, without relying on a computer for power or driver installation. Secondly, upon mobile terminal startup, the storage controller automatically performs read and write operations on each data block of the flash memory chip, recording the number of errors and response times, and generating an initial health report containing health status levels. This eliminates the need for manual operation of specific key combinations to trigger DownloadMode, lowering the operational threshold. When a warning data block exceeding a first preset level is detected, the mobile terminal automatically initiates bidirectional communication, sending a connection request containing the warning data block identifier to the boot disk via the corresponding protocol of the Type-C interface, establishing a data transmission channel, and enabling the boot disk to be booted. The ROM is identified as a "trusted boot source." Subsequently, after receiving the warning data block identifier, the boot disk automatically stores all data blocks as backup files. A CRC code is generated for each data block and stored centrally in the verification area. Simultaneously, an SHA-256 code is generated for all data blocks and stored in the boot disk's root directory and the mobile terminal's local cache. Next, the mobile terminal automatically sends a verification request to the boot disk using the locally cached SHA-256 code. The boot disk returns the backup file and the CRC code in the verification area. The mobile terminal first compares the overall SHA-256 code in the root directory with the locally cached code. If they do not match, it re-requests transmission and repeats the comparison. If they match, the backup file is restored to the non-volatile spare partition. Then, each CRC code in the verification area is compared with the CRC code generated for the corresponding data block in the spare partition. If they do not match, an anomaly is marked and the corresponding data block is re-requested for verification. No manual intervention is required throughout the entire process. After all operations are completed, the mobile terminal automatically restarts the boot system. This complete automatic recovery process is specifically designed for the first power-on scenario after long-term storage of the device, effectively solving the problem of system boot failure in this scenario. It achieves convenient and efficient recovery without the need for computer assistance or complex manual operations. Attached Figure Description

[0034] Figure 1 A flowchart of a method for recovering from long-term storage failure in a mobile terminal, provided by the present invention;

[0035] Figure 2 A schematic diagram of the structure of a recovery system for long-term storage failure of a mobile terminal provided by the present invention;

[0036] Figure 3 This is a schematic diagram of the structure of an electronic device provided by the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0038] like Figure 1 As shown in the embodiment of this application, a method for recovering from long-term storage failure of a mobile terminal includes a mobile terminal and a boot disk. The mobile terminal establishes a connection with the boot disk via a Type-C interface. The boot disk has a built-in independent power supply, which supplies power to the boot disk or the mobile terminal. The method includes:

[0039] S101, When the mobile terminal starts up, the storage controller performs read and write operations on each data block of the flash memory chip, records the number of errors and response time of each data block, and generates an initial health report containing the corresponding health status.

[0040] When a mobile terminal starts up, its storage system is not yet burdened with a large number of runtime tasks and is in a relatively independent and stable initial working state. This minimizes interference from other applications or processes during the storage detection process. Therefore, choosing this stage for the storage controller to perform the detection operation ensures the objectivity and accuracy of the detection results. The storage controller, as the core control unit of the mobile terminal's storage system, is responsible for initiating data read / write commands and coordinating data interaction between the storage medium and other components of the terminal. When it performs read / write operations on each data block of the flash memory chip, the data blocks covered include not only the user's daily stored file data but also firmware (such as the mobile terminal's boot firmware and hardware driver firmware, which directly determine whether the mobile terminal can complete the process normally). The startup process involves essential data such as configuration data (e.g., network parameters, hardware parameters, account authentication settings; missing or incorrect data can cause malfunctions, such as inability to connect to the network or hardware failure). This data needs to be covered because its health directly impacts the mobile terminal's basic operational capabilities. Missing such data may result in the terminal remaining unusable even after data recovery. The principle behind this read / write operation is to simulate data access scenarios during daily mobile terminal use (i.e., real read / write I / O behavior), rather than simply performing static existence checks on data blocks, thus better reflecting the data block status under actual usage conditions.

[0041] While the storage controller performs read and write operations, it simultaneously records the number of errors and response time for each data block. Based on these two quantitative indicators, an initial health report is generated, including the corresponding health status level. The number of errors, as a core indicator reflecting data block reliability, directly reflects whether there are problems such as data bit flipping or physical media damage during the read / write process. Response time, as a key indicator reflecting data block access performance, indirectly reflects the aging degree of the storage area where the data block resides and the stability of the communication link between the storage controller and the flash memory chip. The health level formed by the combination of these two indicators is not based on subjective judgment of a single indicator, but rather on a preset quantitative threshold system (e.g., setting 0 errors and a response time less than 10ms as Level 1 (normal state), 1-3 errors or a response time of 10-20ms as Level 2 (mild warning state), and more than 3 errors or a response time greater than 20ms as Level 3 (severe warning state)). Each data block is then classified, and the classification results of all data blocks are finally summarized to form the initial health report.

[0042] The number of errors for each data block is counted in real time by the ECC (Error Correcting Code) error correction module built into the flash memory chip, and the response time of each data block is obtained by the storage controller timing module.

[0043] S102, when a warning data block higher than the first preset level appears in the initial health report, the mobile terminal initiates bidirectional communication and sends a connection request containing the warning data block identifier to the startup disk; the startup disk responds to the connection request through the corresponding protocol of the Type-C interface and establishes a data transmission channel;

[0044] Specifically, the first preset level is a critical health level pre-set based on the reliability requirements of the mobile terminal storage system. This level indicates that the health status of the data block has posed a potential risk to the basic operation of the mobile terminal (such as system startup and core function implementation). For example, the third level (severe warning state) of "more than 3 errors or response time greater than 20ms" mentioned above can be set as the first preset level. When such warning data blocks appear in the initial health report, it means that there may be areas in the flash memory chip (UFS / Emmc, i.e., general flash memory storage / embedded multimedia card) that have undergone obvious bit flips, bad block spread or charge leakage. Therefore, the mobile terminal initiates bidirectional communication and sends a connection request containing the warning data block identifier to the boot disk. The communication mechanism is based on the extended Type-C interface CC logic detection capability of the mobile terminal's BOOT ROM and a composite communication architecture of USBHID (Human Interface Device) protocol and USB Mass Storage Class. This architecture can separate command interaction and data transmission to ensure communication stability. The warning data block identifier specifically includes the physical address of the warning data block in the flash memory chip (such as the LUN number, block start address and length of UFS), the error count of the corresponding data block and health level information. The principle behind this is to enable the boot disk to accurately obtain the range of warning data blocks that need to be processed before responding to the connection, avoiding redundant reading and transmission of fault-free data blocks during subsequent data transmission, thereby significantly improving the overall efficiency of the subsequent recovery process.

[0045] The boot disk responds to connection requests and establishes a data transmission channel via the corresponding protocol of the Type-C interface. This corresponding protocol is a custom communication protocol based on the boot disk's USB 3.2 DRD (Dual-Role Device) controller, which is strictly compatible with the Dongle Boot Mode communication specification of the mobile terminal's BOOT ROM. Upon receiving a connection request, the boot disk's USB controller first verifies the legitimacy of the warning data block identifier in the connection request using its own hardware security module (integrated TRNG+HAB / TPM 2.0 compatible module). Specifically, the verification includes whether the data block's physical address is within the valid address range of the mobile terminal's flash memory chip and whether the health level information conforms to preset encoding rules. After successful verification, the boot disk returns a response frame to the mobile terminal containing its own VID (Vendor ID), PID (Product ID), and firmware version number. Upon receiving the response frame, the mobile terminal's BOOT ROM matches the VID / PID with the preset RecoveryDongle (external boot disk) identifier. Once a match is confirmed, both parties negotiate and establish a dedicated data transmission channel based on the USB protocol.

[0046] Before the trigger condition of "when a warning data block with a higher than the first preset level appears in the initial health report" is met, it is also necessary to record the access frequency of each data block and shorten the detection interval to the preset interval for data blocks whose access frequency exceeds the preset frequency. The principle of recording the access frequency of each data block is that the mobile terminal's storage controller has a built-in access frequency statistics module. This module accumulates the number of read and write operations of each data block in real time within a preset statistical period, and generates an access frequency record table containing the physical address of the data block and the corresponding number of accesses. The statistical objects cover the file data blocks, firmware data blocks (such as the boot firmware data blocks corresponding to the BOOTIMG and RECOVERY partitions) and configuration data blocks (such as network parameters and hardware device parameter configuration data blocks) stored by the user on a daily basis. Since frequently accessed data blocks are usually critical data blocks that are essential for the operation of core functions of mobile terminals, such as firmware data blocks that need to be read frequently during system startup and network configuration data blocks that need to be called repeatedly in daily communication, if such data blocks fail to be stored, it will directly cause the mobile terminal to fail to start normally or core functions (such as communication and display) to malfunction. Therefore, recording the frequency of access to such data is the basis for achieving "key data key monitoring".

[0047] S103, after receiving the identifier of the warning data block through the data transmission channel, the boot disk stores all data blocks as backup files in the form of files; generates a CRC code for each data block separately, and stores the CRC codes corresponding to all warning data blocks in the verification area of ​​the boot disk; generates an overall SHA-256 code for all data blocks, and stores the overall SHA-256 code in the root directory of the boot disk and the local cache area of ​​the mobile terminal respectively;

[0048] Specifically, after receiving the identifiers of the warning data blocks via the USB 3.2 DRD communication protocol (which is compatible with the Dongle Boot Mode communication specification of the mobile terminal's BOOT ROM), the boot disk stores all data blocks in the mobile terminal's flash memory chip (UFS / eMMC) as files in its own non-volatile memory (high-endurance SLC / 3D XPoint NAND), forming a backup file. Here, "all data blocks" not only includes the warning data blocks identified in the initial health report, but also covers the file data blocks, firmware data blocks, and configuration data blocks stored by the user on a daily basis. The principle is that the initial health report may only detect warning data blocks that have shown failure characteristics, while there may be potential failure data blocks in the flash memory chip that have not yet been detected. Fully backing up all data blocks can build a "safe baseline" for data recovery, preventing the inability to roll back due to damage or loss of the original data during the recovery process. The beneficial effect is to avoid the mobile terminal from experiencing functional abnormalities due to the omission of hidden failure data blocks after recovery, ensuring the integrity and availability of the system after recovery.

[0049] After all data block backup files are stored, the boot disk's USB controller calls the built-in verification module to generate a CRC (Cyclic Redundancy Check) code for each data block individually. The CRC codes corresponding to all warning data blocks are then stored centrally in the boot disk's verification area. The CRC code generation principle involves calculating a fixed-length check value for each data block's binary data stream using a preset polynomial algorithm. This value uniquely corresponds to the data block content. If a data block experiences bit flipping or data loss during storage or subsequent transmission, its CRC code will change significantly, thus achieving accurate detection of the integrity of a single data block. The boot disk's verification area is a dedicated, independent region within its non-volatile memory, protected by a security module (integrated TRNG+HAB / TPM 2.0 compatible module). This prevents unauthorized tampering or accidental overwriting of the CRC code. The beneficial effect is that subsequent verification stages do not require overall verification of all backup data; only CRC code comparison is needed to quickly locate abnormal warning data blocks, significantly improving verification efficiency. Simultaneously, the security module's protection ensures the reliability of the verification benchmark, preventing malicious tampering that could lead to verification failure.

[0050] Subsequently, the boot disk's security module (integrating an AES256 encryption engine and SHA-256 signature verification function) generates a unified SHA-256 code for all backup files, storing this code in both the boot disk's root directory and the mobile terminal's local cache. The SHA-256 code generation principle involves using a secure hash algorithm to calculate a unique 256-bit hash value from the overall binary data stream of all backup files. This algorithm has strong collision resistance; even a 1-bit change in the backup data will result in a completely different SHA-256 code, effectively verifying the overall integrity and tamper-proof nature of the backup data. Storing it in the boot disk's root directory facilitates direct reading by the mobile terminal during subsequent verification, eliminating the need to delve into the boot disk's complex partition structure (such as CERT and LOG partitions), thus reducing the complexity of the verification process. Storing it in the mobile terminal's local cache (such as a temporary cache partition in UFS / eMMC or BOOT) further enhances the verification process. The principle of the ROM's built-in cache is to avoid the transmission delay caused by reading the hash value from the boot disk twice during verification. The beneficial effect is that the dual storage mechanism ensures that the hash value itself will not be unable to be obtained due to the failure of a single storage location (such as the boot disk root directory file being corrupted or the mobile terminal's local cache being lost), thus ensuring the feasibility of the verification process. At the same time, the high security of SHA-256 meets the "high security" design goal of this system and effectively prevents malicious firmware or tampered data from being injected into the backup process.

[0051] In addition, the step of storing all data blocks as backup files also includes prioritizing the backup of data blocks that are accessed more frequently than a preset frequency; during recovery, critical data can be restored first, shortening the recovery time of the core functions of the mobile terminal and optimizing the user experience.

[0052] Furthermore, during data block transmission, the mobile terminal creates a temporary copy for each data block to be transmitted, ensuring normal access to the original data blocks during migration. Once all data blocks have been transmitted and the backup files and corresponding CRC codes have been stored, the mobile terminal automatically deletes all temporary copies corresponding to the data blocks. The principle behind the creation of temporary copies is that the mobile terminal's storage controller, while initiating data block transmission to the boot disk, performs a block-level copy operation on a preset free partition (temporary backup partition) of the local flash memory chip (UFS / eMMC) for each data block to be transmitted, ensuring that the temporary copy is completely consistent with the binary content of the original data block. The principle behind data access during migration is the storage controller's built-in access routing mechanism. When other processes (such as background services) request access to the original data blocks being transmitted, this mechanism automatically redirects the access request to the temporary copy, preventing transmission interruption or data inconsistency due to access to the original data blocks. The principle behind the deletion of temporary copies is that once all data blocks have been transmitted and the boot disk sends a confirmation message through the data transmission channel that "the data block backup file and corresponding CRC code have been successfully stored," the mobile terminal's BOOT... The ROM sends a secure erase command (compliant with JEDEC flash memory specifications) to the storage controller to perform batch deletion of all temporary copies in the temporary backup partition, preventing temporary copy remnants. This resolves the conflict between data block transmission and local data access, ensuring the continuity and consistency of data transmission. Furthermore, the automatic secure erasure of temporary copies avoids consuming additional storage resources, prevents storage fragmentation, and mitigates the risk of data leakage due to unauthorized access to temporary copies.

[0053] S104, the mobile terminal retrieves the locally cached SHA-256 code and sends a verification request to the boot disk; the boot disk returns the backup file and the CRC code of the verification area; the mobile terminal extracts the overall SHA-256 code of the root directory and performs a first comparison with the overall SHA-256 code in the locally cached directory; if they do not match, the mobile terminal re-requests the boot disk to transmit the backup file and the overall SHA-256 code, repeating the comparison until they match or a transmission failure is determined; if they match, the backup file is restored to the non-volatile spare partition, and each CRC code in the verification area is extracted and compared with the CRC code generated by the corresponding data block in the non-volatile spare partition; if they match, the corresponding data block in the health report is updated to normal; if they do not match, it is marked as abnormal and the corresponding data block is re-requested from the boot disk, repeating the verification until they match or data corruption is determined; after all operations are completed, the mobile terminal restarts the boot system.

[0054] Specifically, the "locally cached SHA-256 code" is stored in the temporary cache partition of the mobile terminal's UFS / eMMC or the built-in cache of the BOOT ROM (access permissions are controlled by the BOOT ROM to prevent unauthorized tampering). The local cache is only accessed twice during the verification phase, which avoids the USB transmission delay caused by reading the hash value from the boot disk, thus aligning with the system's "efficient recovery" design goal. The communication process of sending the verification request to the boot disk is implemented based on the USB HID protocol, which is consistent with the communication architecture of the connection request in S102. It can leverage mature protocols to ensure low latency and high reliability of command transmission, avoiding compatibility issues caused by protocol switching.

[0055] After receiving the verification request, the boot disk returns the backup file and the CRC code of the verification area. The USB3.2 DRD controller of the boot disk first triggers the security module (integrated TRNG+HAB / TPM 2.0 compatible module) to verify the legality of the request. Specifically, it verifies whether the mobile terminal SoC ID (System on a Chip ID) carried in the request is consistent with the negotiation result of S102 and whether the instruction format conforms to the custom communication protocol specification. Only after the verification is passed will the boot data be returned. The backup file is stored in the high-endurance SLC / 3D XPoint non-volatile memory of the boot disk; the "CRC code of the verification area" is stored in the independent verification area of ​​the boot disk. The mobile terminal extracts the overall SHA-256 code of the root directory of the boot disk and performs a first comparison with the overall SHA-256 code cached locally. The principle of "extracting the root directory SHA-256 code" is that S103 has already stored the hash value in the root directory of the boot disk, and can directly read it without accessing complex partitions such as CERT and LOG, reducing the complexity of reading BOOT ROM. The first comparison relies on the strong anti-collision property of the SHA-256 algorithm - even if there is a 1-bit tampering or transmission error in the backup file, the hash value will be completely different, which can quickly verify the overall integrity of the backup file and determine whether it was damaged or tampered with during the transmission of S103. If the first comparison does not match, the mobile terminal requests the boot disk to retransmit the backup file and the complete SHA-256 code, repeating the comparison until a match is found or a transmission failure is determined. The technical principle is as follows: the mismatch is mostly due to USB transmission signal interference and packet loss, or occasional errors in the boot disk's temporary storage. At this time, the mobile terminal sends a retransmission command through the USB HID channel. The command carries the identifier of the file segment to be retransmitted (instead of retransmitting the whole file). The boot disk reads the corresponding segment according to the identifier and retransmits it through the USB Bulk channel. The "transmission failure determination" is based on a preset retransmission threshold (such as 3 consecutive times). After the threshold is triggered, the RGB LED of the boot disk switches to red (in accordance with the document's definition of "red = failure"). The mobile terminal's BOOT ROM records the failure information to the local temporary log.If the first comparison matches, the mobile terminal restores the backup file to the non-volatile spare partition, then extracts each CRC code from the check area and compares it one by one with the CRC codes generated for the corresponding data blocks in the spare partition. The "non-volatile spare partition" is a pre-divided independent partition in UFS / eMMC (with a capacity no smaller than the backup file, isolated from the system partition to avoid overwriting normal data). During the restoration process, the storage controller performs block-level writing according to the JEDEC (Joint Electron Device Engineering Council) flash memory specification to ensure that the storage structure of the spare partition is consistent with the original partition. The core of "comparing CRC codes one by one" is that the CRC code (Cyclic Redundancy Check code) is generated by a polynomial algorithm and can uniquely represent the content of a single data block. A successful overall SHA-256 comparison only confirms that there are no errors overall, while a block-level CRC comparison can locate single-block errors when restoring to the spare partition (such as occasional problems with the spare partition media), realizing "overall-partial" layered verification.

[0056] If each CRC code matches, the corresponding data block in the updated health report is considered normal. The technical principle is as follows: The mobile terminal's BOOT ROM modifies the initial S101 health report, updating the error count for the corresponding data block to 0 (confirmed by ECC module re-statistics), updating the response time to the actual access time of the spare partition (e.g., <10ms), and adjusting the health level to Level 1 (normal). Simultaneously, a "data block normal" flag and timestamp are written to the UFS RPMB area (read / write protected partition) to prevent duplicate evaluations. The beneficial effects of this step are: real-time updates to the health status provide accurate information for system booting; and the RPMB flag avoids redundant operations, reducing the computational load on the mobile terminal. If the CRC codes do not match when compared one by one, an anomaly is marked and the corresponding data block is re-requested. This process is repeated until a match is found or the data is deemed corrupted. The principle is as follows: The mobile terminal adds an "Abnormal and Pending Retransmission" flag to the health report and records the inconsistent CRC values. The physical address of the abnormal block is specified via the USB HID channel (only this block is retransmitted), reducing the amount of retransmitted data. "Data Corruption Determined" uses two consecutive failed retransmissions as a threshold, triggering the boot disk redundancy image mechanism to read the backup image from redundant storage and retransmit it. After all operations are completed, the mobile terminal restarts and boots the system.

[0057] After updating the health report, encrypted communication is initiated, sending the SHA-256 code and the updated health report to the distributed cloud storage node. Specifically, the encrypted communication uses the mobile terminal's AES256 encryption engine to encrypt the data end-to-end, and transmission relies on mobile networks or WiFi using the TLS protocol. The distributed cloud storage node is a user-specific node allocated by the enterprise, associated with the user's identity through IMEI (International Mobile Equipment Identity) to ensure unique data ownership. Upon receiving the data, the cloud storage node associates and stores the SHA-256 code with the initial health report. The principle is to construct a structured record based on "Device IMEI - Initial Health Report - Post-Recovery SHA-256 Code," with a storage format conforming to industry standards and supporting rapid retrieval via IMEI. The beneficial effects of this step are: enabling end-to-end traceability of recovery; after-sales service can analyze the causes of failure through records, providing data support for product optimization; and establishing health records for users, facilitating long-term tracking of storage status.

[0058] In addition, before the mobile terminal restarts, a recovery log is generated and encrypted and uploaded to the cloud storage node. The key data in the recovery log (number of warning blocks, transmission time, CRC / SHA comparison results) are all collected in real time from the preceding process. The number of warning blocks is taken from the initial health report, the transmission time is taken from the storage controller timing module, and the comparison results are taken from the verification module. All data is accompanied by millisecond-level timestamps. The encryption channel is consistent with the previous one, using AES256+TLS to ensure security.

[0059] Based on the same inventive concept, such as Figure 2 As shown, this invention provides a recovery system for long-term storage failure of a mobile terminal, comprising: a mobile terminal and a boot disk. The mobile terminal establishes a connection with the boot disk via a Type-C interface. The boot disk has a built-in independent power supply, which supplies power to either the boot disk or the mobile terminal. The system includes:

[0060] The startup module 201 is used to perform read and write operations on each data block of the flash memory chip by the storage controller when the mobile terminal starts up, record the number of errors and response time of each data block, and generate an initial health report containing the corresponding health status.

[0061] The data transmission channel establishment module 202 is used to initiate bidirectional communication when a warning data block with a level greater than the first preset level appears in the initial health report. The mobile terminal sends a connection request containing the warning data block identifier to the startup disk; the startup disk responds to the connection request through the corresponding protocol of the Type-C interface to establish a data transmission channel.

[0062] The backup module 203 is used to store all data blocks as backup files after the boot disk receives the identifier of the warning data block through the data transmission channel; generate a CRC code for each data block separately, and store the CRC codes corresponding to all warning data blocks in the verification area of ​​the boot disk; generate an overall SHA-256 code for all data blocks, and store the overall SHA-256 code in the root directory of the boot disk and the local cache area of ​​the mobile terminal respectively.

[0063] The recovery and verification module 204 is used by the mobile terminal to call the locally cached SHA-256 code and send a verification request to the boot disk; the boot disk returns the backup file and the CRC code of the verification area; the mobile terminal extracts the overall SHA-256 code of the root directory and performs a first comparison with the overall SHA-256 code of the locally cached directory; if they do not match, the mobile terminal re-requests the transmission of the backup file and the overall SHA-256 code from the boot disk, repeating the comparison until they match or a transmission failure is determined; if they match, the backup file is restored to the non-volatile spare partition, and each CRC code of the verification area is extracted and compared with the CRC code generated by the corresponding data block of the non-volatile spare partition one by one; if they match, the corresponding data block in the health report is updated to normal; if they do not match, they are marked as abnormal and the corresponding data block is re-requested from the boot disk, repeating the verification until they match or data corruption is determined; after all operations are completed, the mobile terminal restarts the boot system.

[0064] Based on the same inventive concept, such as Figure 3 As shown, the present invention provides an electronic device, including: a memory 302, a processor 301, and a computer program stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program, it implements a method for recovering from long-term storage failure of a mobile terminal.

[0065] Based on the same inventive concept, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for recovering long-term storage failure of a mobile terminal.

[0066] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method of recovering from long-term storage failure of a mobile terminal, characterized by, The application relates to a mobile terminal and a start disk, the mobile terminal is connected with the start disk through a Type-C interface, the start disk is internally provided with an independent power supply, the power supply supplies power for the start disk or the mobile terminal, and the method comprises the following steps: When the mobile terminal is started, a storage controller performs read-write operations on each data block of a flash memory chip, records the error times and response time lengths of the data blocks, and generates an initial health report containing corresponding health states; When a warning data block greater than a first preset level appears in the initial health report, the mobile terminal starts two-way communication, sends a connection request containing the identification of the warning data block to the start disk, and the start disk responds to the connection request through a corresponding protocol of the Type-C interface to establish a data transmission channel; After the start disk receives the identification of the warning data block through the data transmission channel, all the data blocks are stored in the form of files as backup files, CRC codes of each data block are generated, and the CRC codes of all the warning data blocks are stored in a check area of the start disk; an overall SHA-256 code of all the data blocks is generated, and the overall SHA-256 code is stored in a root directory of the start disk and a local cache area of the mobile terminal; The mobile terminal calls the SHA-256 code stored in the local cache, sends a check request to the start disk, the start disk returns the backup files and the CRC codes of the check area, the mobile terminal extracts the overall SHA-256 code of the root directory and compares the overall SHA-256 code with the overall SHA-256 code stored in the local cache; if the overall SHA-256 codes are inconsistent, the mobile terminal re-requests the start disk to transmit the backup files and the overall SHA-256 code, and the comparison is repeated until the overall SHA-256 codes are consistent or a transmission fault is determined; if the overall SHA-256 codes are consistent, the backup files are restored to a non-volatile backup partition, and the CRC codes of the check area are compared with the CRC codes of the corresponding data blocks of the non-volatile backup partition; if the comparison is consistent, the corresponding data blocks in the health report are updated to be normal; if the comparison is inconsistent, the corresponding data blocks are marked as abnormal and re-requested from the start disk, and the check is repeated until the comparison is consistent or the data is damaged; after all the operations are completed, the mobile terminal restarts the boot system. The error times of each data block are counted in real time through an ECC error correction module built in the flash memory chip, and the response time lengths of each data block are obtained through a timing module of the storage controller.

2. The method of claim 1, wherein the long-term storage failure of the mobile terminal is recovered by, Before the step of when the initial health report contains a warning data block greater than a first preset level, the following steps are further included:

3. The method of claim 1, wherein the long-term storage failure of the mobile terminal is recovered by, The access frequencies of the data blocks are recorded, and the detection interval of the data blocks with an access frequency greater than a preset frequency is shortened to a preset interval. The step of storing all the data blocks in the form of files as backup files further comprises the following step:

4. The method of claim 3, wherein the long-term storage failure of the mobile terminal is recovered by, The data blocks with an access frequency greater than a preset frequency are preferentially backed up. After the overall SHA-256 code is stored in the root directory of the start disk and the local cache area of the mobile terminal, the following steps are further included:

5. The method of claim 1, wherein the long-term storage failure of the mobile terminal is recovered by, ​ In the data block transmission process, the mobile terminal creates a temporary copy for each data block to be transmitted, so that the original data block can be normally accessed during migration; after all data blocks are transmitted, the data block backup file and the corresponding CRC code are stored, the mobile terminal automatically deletes all temporary copies corresponding to the data blocks.

6. The method of claim 1, wherein the long-term storage failure of the mobile terminal is recovered by, After the corresponding data block in the health report is updated to normal, it further includes: Start encrypted communication, the mobile terminal sends the SHA-256 code and the updated health report to the distributed cloud storage node allocated by the enterprise for the personal user through the mobile network or WiFi; after receiving, the cloud storage node stores the SHA-256 code and the initial health report in association.

7. The method of claim 6, wherein the long-term storage failure of the mobile terminal is recovered by, Before the mobile terminal restarts the boot system, it further includes: Generate a recovery log to record the key data of this operation and the corresponding timestamp, and upload it to the cloud storage node through the encrypted channel. The key data includes: the number of warning data blocks, the transmission time, the CRC code comparison result, and the SHA-256 code comparison result.

8. A mobile terminal long-term storage failure recovery system, characterized by, It includes: A mobile terminal and a boot disk, the mobile terminal establishes a connection with the boot disk through a Type-C interface, the boot disk is built-in with an independent power supply, and the power supply supplies power to the boot disk or the mobile terminal, the system includes: A start module, when the mobile terminal starts, the storage controller performs read and write operations on each data block of the flash memory chip, records the error times and response time of each data block, and generates an initial health report containing the corresponding level health status; A data transmission channel establishment module, when the initial health report contains more than a first preset level of warning data blocks, the mobile terminal starts two-way communication and sends a connection request containing the identification of the warning data block to the boot disk; the boot disk responds to the connection request through the corresponding protocol of the Type-C interface to establish a data transmission channel; A backup module, after the boot disk receives the identification of the warning data block through the data transmission channel, it stores all data blocks in the form of a file as a backup file; generate a CRC code for each data block and store all CRC codes corresponding to the warning data blocks in the verification area of the boot disk; generate a whole SHA-256 code for all data blocks, and store the whole SHA-256 code in the root directory of the boot disk and the local cache area of the mobile terminal respectively; The recovery and verification module is configured to call the locally cached SHA-256 code by the mobile terminal, send a verification request to the start disk, return the backup file and the CRC code of the verification area by the start disk, extract the overall SHA-256 code of the root directory by the mobile terminal, and perform a first comparison with the locally cached overall SHA-256 code; if the comparison is not consistent, the mobile terminal re-requests the start disk to transmit the backup file and the overall SHA-256 code, and repeats the comparison until the comparison is consistent or a transmission failure is determined; if the comparison is consistent, the backup file is restored to the non-volatile backup partition, each CRC code of the verification area is extracted, and the CRC codes are compared with the CRC codes generated by the corresponding data blocks of the non-volatile backup partition one by one; if the comparison is consistent, the corresponding data blocks in the health report are updated to be normal; if the comparison is not consistent, the corresponding data blocks are marked as abnormal and re-requested from the start disk, and the verification is repeated until the comparison is consistent or the data is determined to be damaged; and after all operations are completed, the mobile terminal restarts the boot system.

9. An electronic device, comprising: The electronic device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the recovery method of the long-term storage failure of the mobile terminal according to any one of claims 1-7 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the recovery method of the long-term storage failure of the mobile terminal according to any one of claims 1-7.

Images