Data migration method and device, vehicle, medium and program product

Abstract

This application provides a data migration method, apparatus, vehicle, medium, and program product. The method involves acquiring the lifespan data of the main memory in an in-vehicle system; if the lifespan data indicates that the remaining lifespan has reached a preset lifespan threshold, migrating data from at least one critical partition in the main memory to an external storage device connected to the in-vehicle system; and after detecting that the migration is complete, switching the boot source of the in-vehicle system to the external storage device and loading the kernel image and root file system from the external storage device. Applying this technical solution can avoid the interruption of vehicle functionality caused by the in-vehicle system failing to boot due to main memory failure, thereby eliminating the resulting driving safety hazards.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a data migration method, apparatus, vehicle, medium, and program product. Background Technology

[0002] In vehicle systems, the main memory is responsible for storing the system boot image, kernel, root file system, and user data. Its reliability directly affects the stability and safety of the vehicle control system.

[0003] Because in-vehicle systems need to operate for extended periods, the number of erase / write cycles for main memory is limited, and the health of the memory gradually deteriorates under complex environments such as frequent read / write operations and temperature fluctuations. Currently, the lifespan management of main memory in in-vehicle systems typically relies on passive monitoring at the hardware level or simple threshold alarms.

[0004] However, the above method only provides a simple alarm, but the vehicle system will not be able to start when the main memory fails, which may cause the entire vehicle to malfunction or even pose a safety hazard. Summary of the Invention

[0005] This application provides a data migration method, apparatus, vehicle, medium, and program product to achieve the technical effect that the vehicle system can seamlessly switch to normal operation when the main memory fails.

[0006] In a first aspect, embodiments of this application provide a data migration method, including:

[0007] Obtain the lifespan data of the main memory in the vehicle system;

[0008] If the lifespan data indicates that the remaining lifespan has reached a preset lifespan threshold, the data of at least one critical partition in the main memory will be migrated to an external storage device connected to the vehicle system.

[0009] After the migration is detected, the boot source of the vehicle system is switched to the external storage device, and the kernel image and root file system are loaded from the external storage device.

[0010] In one or more embodiments, migrating data from at least one critical partition in the main memory to an external storage device connected to the vehicle system includes:

[0011] A GPT partition table is constructed on the peripheral storage device, and target partitions corresponding to the at least one key partition are created respectively;

[0012] Data from at least one key partition is read sequentially according to a preset priority order, and written to the corresponding target partition in units of preset-sized data blocks.

[0013] After the data migration of any critical partition is detected, a verification operation is performed on the critical partition and the corresponding target partition.

[0014] In one or more embodiments, the method further includes:

[0015] During the data migration process, the offsets of the key partitions that have been migrated and the key partitions currently being migrated are recorded as breakpoint information at a preset frequency and saved to a preset partition of the peripheral storage device.

[0016] Upon detecting that the vehicle system has been powered back on, the data migration process continues based on the breakpoint information.

[0017] In one or more embodiments, switching the boot source of the vehicle system to the external storage device and loading the kernel image and root file system from the external storage device includes:

[0018] Write a first migration completion identifier into the main memory and a second migration completion identifier into the peripheral storage device;

[0019] When the vehicle system is powered on and both the first migration completion flag and the second migration completion flag are detected to be valid, the boot source is switched to the external storage device.

[0020] Load the kernel image from the boot partition of the target partition corresponding to each of the at least one key partition;

[0021] Configure the root field in the kernel boot parameters of the vehicle system to point to the root file system partition in the target partition corresponding to the at least one critical partition.

[0022] In one or more embodiments, performing the verification operation between the critical partition and the corresponding target partition includes:

[0023] Obtain the first hash value of the target partition corresponding to the key partition, wherein the first hash value is determined based on the checksum of the data block migrated from the key partition;

[0024] If the first hash value is found to be consistent with the second hash value of the key partition, then the verification result corresponding to the verification operation is determined to be passed;

[0025] If the first hash value is found to be inconsistent with the second hash value of the key partition, the verification result is determined to be unsuccessful, and a rollback and retry operation is triggered.

[0026] In one or more embodiments, prior to migrating data from at least one critical partition in the main memory to a peripheral storage device connected to the vehicle system, the method further includes:

[0027] Detect whether a connection is established between the peripheral storage device and the vehicle system;

[0028] If a connection is established, detect the storage capacity data of the peripheral storage device;

[0029] If the storage capacity data indicates the storage space required to satisfy the data of at least one critical partition, and the health check operation of the peripheral storage device passes, the data of at least one critical partition in the main memory is migrated to the peripheral storage device.

[0030] In one or more embodiments, obtaining the lifespan data of the main memory in the vehicle system includes:

[0031] If the main memory is an eMMC, the lifetime estimation field and the lifetime termination information field in the EXT_CSD register of the eMMC are determined as the lifetime data;

[0032] If the main memory is UFS, the lifetime estimation field and the lifetime termination information field in the health descriptor of the UFS are determined as the lifetime data;

[0033] If the main memory is NandFlash, the number of erase / write cycles and the number of bad blocks of each NandFlash storage block are determined as the service life data.

[0034] Secondly, embodiments of this application provide a data migration apparatus, comprising:

[0035] The acquisition module is used to acquire the lifespan data of the main memory in the vehicle system;

[0036] The migration module is used to migrate data from at least one critical partition in the main memory to an external storage device connected to the vehicle system when the remaining lifespan indicated by the lifespan data reaches a preset lifespan threshold.

[0037] The processing module is used to switch the boot source of the vehicle system to the external storage device after the migration is detected, and to load the kernel image and root file system from the external storage device.

[0038] In one or more embodiments, the migration module migrates data from at least one critical partition in the main memory to an external storage device connected to the vehicle system, specifically for:

[0039] A GPT partition table is constructed on the peripheral storage device, and target partitions corresponding to the at least one key partition are created respectively;

[0040] Data from at least one key partition is read sequentially according to a preset priority order, and written to the corresponding target partition in units of preset-sized data blocks.

[0041] After the data migration of any critical partition is detected, a verification operation is performed on the critical partition and the corresponding target partition.

[0042] In one or more embodiments, the migration module is further configured to:

[0043] During the data migration process, the offsets of the key partitions that have been migrated and the key partitions currently being migrated are recorded as breakpoint information at a preset frequency and saved to a preset partition of the peripheral storage device.

[0044] Upon detecting that the vehicle system has been powered back on, the data migration process continues based on the breakpoint information.

[0045] In one or more embodiments, the processing module switches the boot source of the vehicle system to the external storage device and loads the kernel image and root file system from the external storage device, specifically for:

[0046] Write a first migration completion identifier into the main memory and a second migration completion identifier into the peripheral storage device;

[0047] When the vehicle system is powered on and both the first migration completion flag and the second migration completion flag are detected to be valid, the boot source is switched to the external storage device.

[0048] Load the kernel image from the boot partition of the target partition corresponding to each of the at least one key partition;

[0049] Configure the root field in the kernel boot parameters of the vehicle system to point to the root file system partition in the target partition corresponding to the at least one critical partition.

[0050] In one or more embodiments, the migration module performs a verification operation between the critical partition and the corresponding target partition, specifically for:

[0051] Obtain the first hash value of the target partition corresponding to the key partition, wherein the first hash value is determined based on the checksum of the data block migrated from the key partition;

[0052] If the first hash value is found to be consistent with the second hash value of the key partition, then the verification result corresponding to the verification operation is determined to be passed;

[0053] If the first hash value is found to be inconsistent with the second hash value of the key partition, the verification result is determined to be unsuccessful, and a rollback and retry operation is triggered.

[0054] In one or more embodiments, prior to migrating data from at least one critical partition in the main memory to a peripheral storage device connected to the vehicle system, the migration module is further configured to:

[0055] Detect whether a connection is established between the peripheral storage device and the vehicle system;

[0056] If a connection is established, detect the storage capacity data of the peripheral storage device;

[0057] If the storage capacity data indicates the storage space required to satisfy the data of at least one critical partition, and the health check operation of the peripheral storage device passes, the data of at least one critical partition in the main memory is migrated to the peripheral storage device.

[0058] In one or more embodiments, the acquisition module acquires the lifespan data of the main memory in the vehicle system, specifically for:

[0059] If the main memory is an eMMC, the lifetime estimation field and the lifetime termination information field in the EXT_CSD register of the eMMC are determined as the lifetime data;

[0060] If the main memory is UFS, the lifetime estimation field and the lifetime termination information field in the health descriptor of the UFS are determined as the lifetime data;

[0061] If the main memory is NandFlash, the number of erase / write cycles and the number of bad blocks of each NandFlash storage block are determined as the service life data.

[0062] Thirdly, embodiments of this application provide a vehicle, including: a memory and a processor;

[0063] The memory stores computer-executed instructions;

[0064] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0065] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0066] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0067] The data migration method, apparatus, vehicle, medium, and program product provided in this application embodiment are as follows: The method obtains the lifespan data of the main memory in the vehicle system; if the lifespan data indicates that the remaining lifespan has reached a preset lifespan threshold, the data of at least one critical partition in the main memory is migrated to an external storage device connected to the vehicle system; after detecting that the migration is completed, the vehicle system boot source is switched to the external storage device, and the kernel image and root file system are loaded from the external storage device. This solution acquires main memory lifespan data in real time, enabling the vehicle system to proactively trigger data migration when the remaining lifespan reaches a preset threshold, rather than simply issuing a passive alarm. This provides a window of opportunity for handling the situation before the memory completely fails. Migrating data from at least one critical partition to an external storage device ensures the preservation of the kernel image, root file system, and core configuration necessary for startup, preventing the loss of critical data due to sudden main memory failure. After migration, the system automatically switches the boot source to the external storage device and loads the kernel and root file system from it, allowing the vehicle system to boot independently of the failed main memory. This maintains basic operational capabilities even after main memory failure, resolving the vehicle's functional interruption caused by the inability to boot the vehicle system due to main memory failure, and thus eliminating the resulting driving safety hazards. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0069] Figure 1 Flowchart of the data migration method provided in the embodiments of this application Figure 1 ;

[0070] Figure 2 Flowchart of the data migration method provided in the embodiments of this application Figure 2 ;

[0071] Figure 3 Flowchart of the data migration method provided in the embodiments of this application Figure 3 ;

[0072] Figure 4 Flowchart of the data migration method provided in the embodiments of this application Figure 4 ;

[0073] Figure 5 This is a schematic diagram of the structure of the data migration device provided in the embodiments of this application;

[0074] Figure 6 This is a structural schematic diagram of the vehicle provided in an embodiment of this application.

[0075] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0076] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0077] The system fault tolerance and data migration issues when the main memory (such as embedded multimedia card (eMMC), universal flash storage (UFS), NAND flash memory) in the vehicle system (e.g., vehicle embedded system) reaches the end of its lifespan due to long-term operation.

[0078] In a system-on-chip (SoC), the main memory is responsible for storing the system's boot image, kernel, root file system, and user data. Its reliability directly affects the stability and safety of the vehicle control system.

[0079] However, since in-vehicle systems need to operate for a long time (such as intelligent driving and in-vehicle entertainment systems), the number of erase and write cycles of the main memory is limited (e.g., the lifespan difference between single-level cell (SLC) / multi-level cell (MLC) / triple-level cell (TLC) of NandFlash), and the health of the memory will gradually deteriorate under complex environments such as frequent read and write operations and temperature fluctuations.

[0080] In existing technologies, the lifespan management of the main memory of vehicle systems usually relies on passive monitoring at the hardware level or simple threshold alarms. Existing solutions only stay at the data acquisition level and lack an active response mechanism for critical lifespan states. When the memory lifespan is nearing its end, the vehicle system usually cannot migrate critical data in time, resulting in the system failing to start after the main memory fails.

[0081] To address the technical problems existing in the prior art, the inventors of this application propose the following concept: If the lifespan data of the main memory can be actively acquired, and when its remaining lifespan reaches a preset lifespan threshold, the vehicle system can determine that the main memory has entered a high-risk state at the end of its lifespan. At this time, a seamless emergency migration process can be directly triggered: First, the data of the critical partitions of the main memory (such as the boot partition, kernel image, root file system, etc.) is copied to an external storage device. After confirming that the data migration is complete, the boot source is automatically switched to the external storage device, and the kernel and root file system are loaded from it. This ensures that the vehicle's core computing unit can restart and operate normally from the external storage device, maintaining the core functions of the vehicle system and the overall vehicle operation safety.

[0082] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. The subject of this technical solution is a vehicle, such as a control unit in a vehicle.

[0083] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0084] Figure 1 Flowchart of the data migration method provided in the embodiments of this application Figure 1 ,like Figure 1 As shown, the method includes:

[0085] Step 11: Obtain the lifespan data of the main memory in the vehicle system;

[0086] In this step, during the operation of the vehicle system, the internal status register or descriptor of the main memory is actively read according to the preset monitoring cycle to obtain its corresponding lifespan data.

[0087] Optionally, the implementation of step 11 may include any of the following:

[0088] Item 1: If the main memory is eMMC, the lifetime estimate field and the lifetime termination information field in the EXT_CSD register of the eMMC are determined as lifetime data.

[0089] In this implementation, the lifespan of the main memory is assessed by reading key parameters from the EXT_CSD (Extended CSD) register.

[0090] For example, the UBoot firmware reads the EXT_CSD register via MMC commands (CMD8 or vendor-specific commands) to obtain the following key fields:

[0091] (1) DEVICE_LIFE_TIME_EST_TYP_A: indicates the estimated lifetime consumption caused by writing data on the host side. The value range is 0-10, where 0 indicates unused, 1-10 indicates 10%-100% of the lifetime has been consumed, and the larger the value, the more severe the wear.

[0092] (2) DEVICE_LIFE_TIME_EST_TYP_B: indicates the estimated lifetime consumption caused by data written to the device side (such as the WearLeveling operation for garbage collection), and the value range is the same as above.

[0093] (3) PRE_EOL_INFO: End-of-Life information, specifically defined as follows: 0x01: Warning to enter read-only mode, indicating that the storage medium is about to reach its design life; 0x02: Exhausted, the storage medium has reached or exceeded its design life; 0x03: Normal state.

[0094] Item 2: If the main storage is UFS, the lifetime estimate field and the lifetime termination information field in the health descriptor of UFS shall be determined as lifetime data.

[0095] In this implementation, the device health descriptor is read through the UFS Host Controller interface to obtain the lifespan data of the main storage.

[0096] For example, the bDeviceHealth field can be read using a UFS command (such as UFS_QUERY_REQUEST) to obtain the following key parameters:

[0097] (1) Life Time Estimation A: Lifetime estimation caused by host-side writes, with a value range of 0-10, and the same meaning as eMMC.

[0098] (2) Life Time Estimation B: Life time estimation caused by device-side writing, with a value range of 0-10, and the same meaning as eMMC.

[0099] (3) PRE_EOL_INFO: Pre-life end information, specifically defined as follows: 0x00: Normal state; 0x01: Approaching lifespan, close monitoring is recommended; 0x02: Severe aging, replacement is recommended as soon as possible; 0x03: End of life has been reached.

[0100] Item 3: If the main memory is NandFlash, determine the number of erase / write cycles and the number of bad blocks of each NandFlash storage block as the service life data.

[0101] In this implementation, the lifespan of the main memory is evaluated by counting the number of write / erase cycles (P / E cycles) and the number of bad blocks. Specifically:

[0102] (1) P / E Cycle Statistics:

[0103] Each NandFlash block has a maximum number of erase / write cycles designed to be exceeded. After exceeding this number, the probability of bit flips increases sharply, leading to a decrease in data reliability. The erase / write lifespan of different types of NandFlash is as follows: SLC (Single-Level Cell): 50,000 to 100,000 cycles; MLC (Multi-Level Cell): 3,000 to 10,000 cycles; TLC (Triple-Level Cell): 1,000 to 3,000 cycles.

[0104] The erase / write count counter for each block is maintained at the UBoot layer. It communicates with the NandFlash controller via I2C or SPI interface and periodically reads the erase / write statistics of each block. When the erase / write count of any block reaches 90% of its design life, an early warning is triggered.

[0105] (2) Bad block management:

[0106] NandFlash flash memory contains a small number of bad blocks at the factory, and new bad blocks are constantly generated during use. Bad blocks are managed in the following ways:

[0107] Factory Bad Block Table (BBT) Read: The factory bad block table of NandFlash is read during the first system boot to record the original bad block locations; Runtime Bad Block Detection: Bad block detection (Read / Write / Verify operation) is performed before each data write, and the runtime bad block table is updated when new bad blocks are found; Bad Block Growth Rate Calculation: When the number of newly added bad blocks per unit time exceeds the threshold, the memory is determined to have entered the rapid aging period.

[0108] Optionally, the monitoring of the main memory's lifespan data can be implemented by: implementing it at a certain period and giving corresponding trigger conditions; as shown in Table 1, Table 1 is a schematic table of monitoring period and trigger conditions provided in the embodiments of this application.

[0109] Table 1

[0110]

[0111] Among them, DEVICE_LIFE_EST>=6 indicates that the estimated lifespan consumption of the main memory has reached 60% or more; DEVICE_LIFE_EST>=8 indicates that the estimated lifespan consumption of the main memory has reached 80% or more; PRE_EOL_INFO==0x02 indicates that the main memory has been exhausted, that is, it has reached or exceeded its designed lifespan.

[0112] Step 12: If the lifespan data indicates that the remaining lifespan has reached the preset lifespan threshold, migrate the data of at least one critical partition in the main memory to the peripheral storage device connected to the vehicle system.

[0113] In this step, the remaining lifespan indicated by the obtained lifespan data is compared with a preset lifespan threshold. When the preset lifespan threshold is reached (e.g., lifespan estimate field ≥ 8), the main memory is considered to be abnormal and needs to be migrated.

[0114] At this point, the data in critical partitions of the main memory (such as trustzone, lk, boot, recovery, system, vendor, and data) is migrated to an external storage device connected to the vehicle system.

[0115] For example, peripheral storage devices can be USB flash drives, SD cards, or other storage media.

[0116] Optionally, prior to step 12, "migrating data from at least one critical partition in the main memory to a peripheral storage device connected to the vehicle system," the data migration method further includes:

[0117] Step 1: Check whether a connection has been established between the external storage device and the vehicle system;

[0118] In this implementation, the physical connection status of peripheral storage devices is detected during the UBoot stage (i.e., the system bootloader stage). By initializing the USB Host controller and enumerating the connected USB devices, it is detected whether a USB flash drive is inserted. At the same time, by initializing the SD / MMC controller and reading the card information, it is detected whether an SD card is inserted.

[0119] If any of the above devices are detected, the connection is confirmed to be established.

[0120] Step 2: If a connection is established, check the storage capacity data of the external storage device;

[0121] In this implementation, once it is confirmed that the peripheral storage device is connected, the descriptor of the peripheral storage device is read to obtain its total storage capacity and available remaining space.

[0122] At this point, calculate the total storage space required for all critical partitions to be migrated, and compare this total size with the available remaining space, while also setting a 20% margin for additional space.

[0123] Step 3: If the storage capacity data indicates that the storage space required for at least one critical partition is sufficient, and the health check operation of the peripheral storage device passes, migrate the data of at least one critical partition in the main memory to the peripheral storage device.

[0124] In this implementation, if the available remaining space is greater than the total size of the data to be migrated (optional 100% or 120%), the capacity test passes. Then, a health check operation is performed on the peripheral storage device to obtain the device health status by reading SMART information or performing read / write tests.

[0125] Then, after both capacity and health checks pass, the data migration process from main memory to peripheral storage devices is initiated.

[0126] For example, for USB boot adaptation: initialize the USB Host controller (EHCI / xHCI); enumerate USB devices and identify the target flash drive (by matching VID / PID or serial number); load the USB Mass Storage class driver; identify the LUN (Logical Unit Number) of the target device; read the device's MBR / GPT partition table; locate the boot partition based on the partition table information.

[0127] For SD card boot adaptation: Initialize the SD / MMC controller; identify the SD card type (SDSC / SDHC / SDXC); read the CSD (Card Specific Data) register to obtain capacity information; load the SD card partition table; locate the target boot partition.

[0128] Optionally, after the migration is complete, a lightweight test program can be run to verify the compatibility of the peripheral storage device.

[0129] For example, simulating a main memory failure scenario, UBoot is forced to skip the main memory and attempt to boot from an external storage device. Critical files (such as kernel images and root file system partitions) are checked to ensure they exist and are readable. If compatibility issues are detected, the migration status is marked as needing repair.

[0130] Step 13: After the migration is detected, switch the vehicle system boot source to the external storage device and load the kernel image and root file system from the external storage device.

[0131] In this step, after detecting that all data in at least one critical partition in the main memory has been migrated to the external storage device, the boot source of the vehicle system is switched from the main memory to the external storage device.

[0132] After the switch is completed, during the subsequent power-on and startup process of the vehicle system, the vehicle system can bootloader read the kernel image from the external storage device, configure the root file system path in the kernel boot parameters to point to the root file system partition on the external storage device, and then start the kernel to complete the system boot process.

[0133] For example, 1) Boot image loading: The bootloader loads the kernel image and device tree (Device Tree Blob) from the boot partition of the external storage device: determines the kernel image path based on the boot configuration (boot.cfg or boot variables); reads the kernel image from the external storage device to the specified address in DDR; verifies the kernel image signature (optional, for secure boot scenarios); reads and parses the device tree DTB file; configures the storage controller node in the device tree to point to the external storage device; and passes kernel boot parameters (cmdline), including the rootfs location.

[0134] 2) Root filesystem redirection: To mount the root filesystem to an external storage medium, the correct kernel boot parameters need to be configured in U-Boot:

[0135] bootargs = "root= / dev / sda2 rootwait rw console=ttyHSL0,115200,200n8androidboot.bootdevice=musb-hdrc.1.auto single"

[0136] Key parameter descriptions: root= / dev / sda2: Specifies the second partition (the first partition is boot) as the root file system device and the external storage medium.

[0137] The data migration method provided in this application involves obtaining the lifespan data of the main memory in the vehicle system; if the lifespan data indicates that the remaining lifespan has reached a preset lifespan threshold, migrating the data of at least one critical partition in the main memory to an external storage device connected to the vehicle system; after detecting that the migration is complete, switching the vehicle system boot source to the external storage device, and loading the kernel image and root file system from the external storage device. This solution acquires main memory lifespan data in real time, enabling the vehicle system to proactively trigger data migration when the remaining lifespan reaches a preset threshold, rather than simply issuing a passive alarm. This provides a window of opportunity for handling the situation before the memory completely fails. Migrating data from at least one critical partition to an external storage device ensures the preservation of the kernel image, root file system, and core configuration necessary for startup, preventing the loss of critical data due to sudden main memory failure. After migration, the system automatically switches the boot source to the external storage device and loads the kernel and root file system from it, allowing the vehicle system to boot independently of the failed main memory. This maintains basic operational capabilities even after main memory failure. The solution resolves the vehicle's functional interruption caused by the inability to boot the vehicle system due to main memory failure, thereby eliminating the resulting driving safety hazards.

[0138] Based on the above embodiments, Figure 2 Flowchart of the data migration method provided in the embodiments of this application Figure 2 ,like Figure 2 As shown, step 12 above, "migrating data from at least one critical partition in the main memory to a peripheral storage device connected to the vehicle system," may include:

[0139] Step 21: Construct a Globally Unique Identifier Partition Table (GPT) on the peripheral storage device and create target partitions corresponding to at least one critical partition.

[0140] In this step, a partition structure is created on the external storage device according to the GPT partition table format, including the EFISystem partition, boot partition, system partition, vendor partition, data partition, and recovery partition.

[0141] Furthermore, the aforementioned partitions can correspond to key partitions in the main memory such as trustzone / lk, boot, system, vendor, data, and recovery.

[0142] For example, Table 2 is a schematic table of the construction of storage partitions provided in the embodiments of this application, as shown in Table 2:

[0143] Table 2

[0144]

[0145] Step 22: Read the data of at least one key partition one by one according to the preset priority order, and write it to the corresponding target partition in units of preset size data blocks;

[0146] In this step, critical partitions are processed one by one according to a preset priority order. For each critical partition, data blocks are read from the corresponding critical partition in units of fixed size (for example, a 4MB batch read method can be used to read data blocks from the critical partition). A CRC32 checksum is calculated for each data block, and then the data block is written to the corresponding target partition on the external storage device.

[0147] For example, Table 3 is a schematic table illustrating the migration priority of key partitions provided in the embodiments of this application, as shown in Table 3:

[0148] Table 3

[0149]

[0150] Furthermore, the data migration method may also include:

[0151] Step 1: During the data migration process, the offsets of the critical partitions that have been migrated and the critical partitions currently being migrated are recorded as breakpoint information at a preset frequency and saved to the preset partition of the external storage device.

[0152] In this implementation, during the data migration process, breakpoint information is written to the GPT reserved sector of the peripheral storage device at a preset frequency after each data block is migrated or after each fixed amount of data is transferred.

[0153] The breakpoint information includes: a list of partitions that have been migrated, the starting offset of the partition currently being migrated, the migration progress percentage, and the total amount of data transferred (which can be recorded as an option). After each write, a synchronization operation (fsync) is performed on the external storage device.

[0154] In addition, to prevent breakpoint information from being tampered with or misread, the breakpoint information can be encrypted and stored using hardware security modules (such as TPM) or encryption algorithms (such as AES-256), and the encrypted breakpoint information can be stored in blocks in multiple locations (such as GPT reserved sectors and dedicated partitions of peripheral storage devices) to avoid the loss of breakpoints due to damage to a single location.

[0155] Step 2: When the vehicle system is detected to be powered on again, the data migration process continues based on the breakpoint information.

[0156] In this implementation, when the vehicle system is powered on again and the migration is detected to be incomplete, the migration recovery program in the loading stage can be guided to read the breakpoint records in the preset area of ​​the peripheral storage device, compare the completed partitions in the breakpoint records with the actual partition status of the main memory, and calculate the SHA256 hash value of the migrated partitions for integrity verification.

[0157] After successful verification, continue reading main memory data from the offset position of the current partition of the breakpoint information and write it to the peripheral storage device.

[0158] Then, after the migration is complete, update the migration log.

[0159] Step 23: After the data migration of any critical partition is detected, perform a verification operation on the critical partition and the corresponding target partition.

[0160] In this step, after all the data in a critical partition has been written, a data consistency check is performed on the source critical partition and the corresponding target partition to verify whether the data in the critical partition has been completely and accurately migrated to the corresponding target partition on the external storage device.

[0161] Optionally, step 23, "performing a verification operation between the critical partition and the corresponding target partition," can be:

[0162] Step 1: Obtain the first hash value of the target partition corresponding to the critical partition. This first hash value is determined based on the checksum of the data blocks migrated from the critical partition.

[0163] In this implementation, during the process of writing each data block of the critical partition to the target partition, the SHA256 hash value of all data blocks that have been written is calculated in real time and used as the first hash value of the target partition. This calculation covers all data from the starting position of the critical partition to the current writing completion position.

[0164] For example, for every 1MB of data block transferred, the CRC32 checksum of that data block is calculated and recorded; after the entire critical partition migration is completed, the SHA256 hash value of the corresponding target partition is calculated.

[0165] Step 2: If the first hash value is found to match the second hash value of the key partition, then the verification result corresponding to the verification operation is determined to be passed;

[0166] In this implementation, the second hash value of the pre-stored source key partition is obtained, and the first hash value and the second hash value are compared byte by byte. If the two hash values ​​are exactly the same, the verification result is determined to be successful.

[0167] Step 3: If the first hash value is found to be inconsistent with the second hash value of the critical partition, the verification result is determined to be unsuccessful, and a rollback and retry operation is triggered.

[0168] In this implementation, if the comparison results between the first hash value and the second hash value are not completely consistent, the verification result is determined to be unsuccessful.

[0169] Furthermore, the data already written to the target partition on the peripheral storage device can be cleared, and the migration status of the critical partition can be marked as pending retry. In subsequent processes, all data can be read from the critical partition in the main memory again and the migration can be performed again.

[0170] Optionally, an automatic rollback mechanism is implemented: retain the data that has been successfully migrated in the peripheral storage device; mark the main memory migration status as failed and pending retry; continue to boot from main memory; retry the migration on the next boot; and record the reason for failure for subsequent diagnostic analysis.

[0171] The data migration method provided in this application involves constructing a GPT partition table on an external storage device and creating target partitions corresponding to at least one critical partition. Data from at least one critical partition is read sequentially according to a preset priority order and written to the corresponding target partition in data blocks of a preset size. After the data migration of any critical partition is detected to be complete, a verification operation is performed between the critical partition and its corresponding target partition. This technical solution, by constructing a GPT partition table on the external storage device and creating target partitions corresponding to the critical partitions, and then performing migration and partition-by-partition verification in data blocks according to priority, ensures that the core data required for system startup is transferred completely and accurately to external storage. This avoids data loss or startup failure due to the exhaustion of the main memory, thereby effectively improving the availability and data security of the vehicle system in scenarios where the storage medium is aging.

[0172] Based on the above embodiments, Figure 3 Flowchart of the data migration method provided in the embodiments of this application Figure 3 ,like Figure 3 As shown, step 23 may include:

[0173] Step 31: Write the first migration completion identifier into the main memory and the second migration completion identifier into the peripheral storage device;

[0174] In this step, after all the data in the critical partitions of the main memory has been migrated and verified, a first migration completion identifier is written to a specific physical area of ​​the main memory.

[0175] At the same time, a second migration completion identifier is written into the GPT header protective MBR or the first sector of the peripheral storage device.

[0176] For example, the main memory flag location is a specific area of ​​eMMC / UFS / NandFlash, where the "MGigration_Completed" identifier is written; the peripheral memory flag location is the Protective MBR in the GPT header or the first sector, where the same identifier is written.

[0177] Step 32: When the vehicle system is powered on and the first migration completion flag and the second migration completion flag are both valid, switch the boot source to the external storage device.

[0178] In this step, during the system boot loading phase each time the vehicle system is powered on, the first migration completion flag in a specific area of ​​the main memory and the second migration completion flag in a specific area of ​​the peripheral storage device are read respectively.

[0179] If both read identifiers are valid, the migration completion identifier is determined to be valid, and the boot priority configuration of the system bootloader is modified to prioritize booting from the external storage device.

[0180] Step 33: Load the kernel image from the boot partition of the target partition corresponding to at least one critical partition;

[0181] In this step, the system bootloader initializes the controller of the corresponding peripheral storage device according to the modified boot priority configuration, identifies the GPT partition table on the peripheral storage device, locates the boot partition, and reads the kernel image file from the boot partition to a specified address in the system memory.

[0182] If the system secure boot feature is enabled, the system bootloader performs signature verification on the read kernel image, and loads it after successful verification.

[0183] Step 34: Configure the root field in the kernel boot parameters of the vehicle system to point to the root file system partition of the target partition corresponding to at least one critical partition.

[0184] In this step, the system bootloader constructs a kernel boot parameter string before starting the kernel, setting the value of the root parameter to the device node corresponding to the target partition on the external storage device that hosts the root file system.

[0185] If the external storage device is a USB flash drive, the root parameter is set to the corresponding device node; if the external storage device is an SD card, the root parameter is set to the corresponding device node.

[0186] The system bootloader adds the rootwait parameter and then passes the complete boot parameter string to the kernel.

[0187] The data migration method provided in this application involves writing a first migration completion identifier in the main memory and a second migration completion identifier in the peripheral storage device; when the vehicle system is powered on and the first and second migration completion identifiers are detected to be valid, the boot source is switched to the peripheral storage device; the kernel image is loaded from the boot partitions of the target partitions corresponding to at least one key partition; and the root field in the kernel boot parameters of the vehicle system is configured to point to the root file system partition of the target partitions corresponding to at least one key partition. This technical solution writes dual migration completion identifiers to both the main memory and the peripheral storage device, requiring both to be valid simultaneously when the vehicle system is powered on before switching the boot source. This effectively prevents erroneous switching caused by miswriting of one identifier or abnormal storage media, significantly enhancing the reliability and anti-interference capability of boot decisions. After the identifier verification is successful, the vehicle system loads the kernel image from the boot partition of the peripheral storage device and points the root field in the kernel boot parameters to the root file system partition on the peripheral storage device. This ensures that the kernel can correctly mount the root file system after booting, achieving a complete and seamless boot from external storage. Thus, it avoids the risks of premature switching and ensures that the system can stably continue running from external storage in the event of main memory failure, effectively improving the disaster recovery capability and boot security of the vehicle system.

[0188] Based on the above embodiments, Figure 4 Flowchart of the data migration method provided in the embodiments of this application Figure 4 ,like Figure 4 As shown, this data migration method is illustrated using an interactive process. The interactive components include: UBoot / Trustzone, the monitoring module, the data migration module, the startup switching module, and the external storage device.

[0189] One possible implementation process could be:

[0190] On the UBoot / Trustzone side: The vehicle system powers on, and UBoot initializes;

[0191] Step 401: UBoot / Trustzone sends a message to the monitoring module to check the health status of the main memory;

[0192] Step 402: The monitoring module returns a healthy status.

[0193] If the main memory is normal, proceed to step 403; otherwise, proceed to step 404.

[0194] Step 403: Boot from main memory;

[0195] Step 404: UBoot / Trustzone issues a check migration flag to the data migration module;

[0196] Step 405: The data migration module returns that the migration to UBoot / Trustzone is complete;

[0197] Step 406: UBoot / Trustzone issues a check for peripheral storage devices;

[0198] Step 407: The peripheral storage device returns that the device is ready.

[0199] Step 408: UBoot / Trustzone issues a trigger to switch the boot process to the boot switching module;

[0200] Step 409: Start the switching module to load the kernel image from the external storage device;

[0201] Step 410: Start the switching module to mount the partition to the external storage device;

[0202] Step 411: Start the switching module to send startup parameters to UBoot / Trustzone;

[0203] Step 412: UBoot / Trustzone jumps to execute the kernel.

[0204] In this process, the partition mount path remains unchanged, and only the physical device is switched (i.e., from main memory to peripheral storage device). That is, all switching logic is completed in the UBoot stage. The mount path ( / system, / vendor, / data) remains unchanged for the user. Only the mounted physical device is switched from main memory (eMMC / UFS / NandFlash) to peripheral storage device (USB / SD card), ensuring reliable system startup and continuous operation in the event of main memory failure.

[0205] In addition, the data migration method can be designed with a multi-level startup priority arbitration mechanism. After the vehicle system is powered on, it first detects the startup flag bit on each storage medium and attempts to start according to the preset priority order, rather than being limited to the operation after executing step 403 or step 404, as shown in Table 4. Table 4 is a schematic table of multi-level startup priority arbitration provided in the embodiments of this application.

[0206] Table 4:

[0207]

[0208] The above technical solution achieves the following technical effects:

[0209] 1) Significantly extends the actual service life of the vehicle system, avoiding the scrapping of the entire unit due to the aging of eMMC hardware;

[0210] 2) Achieve a seamless transition of the vehicle system before eMMC failure, ensuring vehicle start-up success rate and operational continuity;

[0211] 3) Reduce after-sales maintenance costs and user downtime losses; improve the vehicle system's proactive management capabilities and fault prevention capabilities for storage hardware lifespan;

[0212] 4) Compatible with existing SOC platforms, deployment can be carried out without replacing the main control chip.

[0213] In fact, the lifespan of eMMC, as a primary embedded memory in automotive electronic systems, is already somewhat recognized. However, the conventional approach is to repair and replace it after a failure, lacking a predictive data migration mechanism. Therefore, it can be considered that there is no technical solution in the current technology that directly addresses eMMC lifespan warning and seamless system migration to peripheral startup; the closest existing technology is a blank.

[0214] The core difference of this solution lies in: (1) monitoring the lifespan of the EMMC and triggering data migration in advance before reaching the threshold; (2) migrating the complete system data from the EMMC to a USB flash drive / SD card; and (3) configuring the vehicle system to support booting from the USB flash drive / SD card and running continuously. This combination solves the technical problem of the vehicle system failing to boot and losing data due to the end of the EMMC's lifespan, thus achieving the continuation of system availability and the protection of user data.

[0215] Based on the above embodiments, Figure 5 This is a schematic diagram of the structure of the data migration device provided in the embodiments of this application, as shown below. Figure 5 As shown, the device includes:

[0216] The acquisition module 51 is used to acquire the lifespan data of the main memory in the vehicle system;

[0217] The migration module 52 is used to migrate data from at least one critical partition in the main memory to an external storage device connected to the vehicle system when the remaining lifespan indicated by the lifespan data reaches a preset lifespan threshold.

[0218] Processing module 53 is used to switch the vehicle system boot source to the external storage device after the migration is detected, and to load the kernel image and root file system from the external storage device.

[0219] In one or more embodiments, the migration module 52 migrates data from at least one critical partition in the main memory to an external storage device connected to the vehicle system, specifically for:

[0220] Build a GPT partition table on the peripheral storage device and create target partitions corresponding to at least one critical partition.

[0221] Read data from at least one key partition in a preset priority order and write it to the corresponding target partition in units of preset size data blocks;

[0222] Once the data migration of any critical partition is detected, a verification operation is performed on the critical partition and its corresponding target partition.

[0223] In one or more embodiments, the migration module 52 is further configured to:

[0224] During the data migration process, the offsets of the critical partitions that have been migrated and the critical partitions currently being migrated are recorded as breakpoint information at a preset frequency and saved to a preset partition of the external storage device.

[0225] When the vehicle system is detected to be powered on again, the data migration process continues based on the breakpoint information.

[0226] In one or more embodiments, the processing module 53 switches the vehicle system boot source to an external storage device and loads the kernel image and root file system from the external storage device, specifically for:

[0227] Write a first migration completion flag to the main memory and a second migration completion flag to the peripheral storage device;

[0228] When the vehicle system is powered on and both the first migration completion flag and the second migration completion flag are detected as valid, the boot source will be switched to the external storage device.

[0229] Load the kernel image from the boot partition of the target partition corresponding to at least one critical partition;

[0230] Configure the root field in the kernel boot parameters of the vehicle system to point to the root file system partition of the target partition corresponding to at least one critical partition.

[0231] In one or more embodiments, the migration module 52 performs a verification operation between the critical partition and the corresponding target partition, specifically for:

[0232] Obtain the first hash value of the target partition corresponding to the critical partition. The first hash value is determined based on the checksum of the data blocks migrated from the critical partition.

[0233] If the first hash value is found to match the second hash value of the critical partition, the verification result corresponding to the verification operation is determined to be passed.

[0234] If the first hash value is found to be inconsistent with the second hash value of the critical partition, the verification result is determined to be unsuccessful, and a rollback and retry operation is triggered.

[0235] In one or more embodiments, before migrating data from at least one critical partition in the main memory to a peripheral storage device connected to the vehicle system, the migration module 52 is further configured to:

[0236] Check whether a connection is established between the peripheral storage device and the vehicle system;

[0237] If a connection is established, check the storage capacity data of the peripheral storage device;

[0238] If the storage capacity data indicates that the storage space required to satisfy the data of at least one critical partition is sufficient, and the health check operation of the peripheral storage device passes, the data of at least one critical partition in the main memory will be migrated to the peripheral storage device.

[0239] In one or more embodiments, the acquisition module 51 acquires the lifespan data of the main memory in the vehicle system, specifically for:

[0240] If the main memory is eMMC, the lifetime estimate field and the lifetime termination information field in the EXT_CSD register of the eMMC are determined as the lifetime data.

[0241] If the main storage is UFS, the lifetime estimate field and the lifetime end information field in the health descriptor of UFS are determined as the lifetime data;

[0242] If the main memory is NandFlash, the number of erase / write cycles and the number of bad blocks for each NandFlash storage block are determined as the lifespan data.

[0243] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical element, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls, or entirely in hardware. Alternatively, some modules can be implemented through processing element calls in software, while others can be implemented in hardware. Moreover, these modules can be integrated together or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0244] As can be seen from the above, the data migration device provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.

[0245] Figure 6 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Figure 6As shown, the vehicle provided in this embodiment includes at least one processor 61 and a memory 62.

[0246] Optionally, the vehicle also includes a communication component 63.

[0247] The processor 61, memory 62, and communication component 63 are connected via bus 64.

[0248] In a specific implementation, at least one processor 61 executes computer execution instructions stored in memory 62, causing at least one processor 61 to perform the above-described method.

[0249] The specific implementation process of processor 61 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0250] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0251] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0252] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0253] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0254] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0255] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0256] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0257] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0258] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0259] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0260] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0261] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0262] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data migration method, characterized in that, include: Obtain the lifespan data of the main memory in the vehicle system; If the lifespan data indicates that the remaining lifespan has reached a preset lifespan threshold, the data of at least one critical partition in the main memory will be migrated to an external storage device connected to the vehicle system. After the migration is detected, the boot source of the vehicle system is switched to the external storage device, and the kernel image and root file system are loaded from the external storage device.

2. The method according to claim 1, characterized in that, The step of migrating data from at least one critical partition in the main memory to an external storage device connected to the vehicle system includes: A GPT partition table is constructed on the peripheral storage device, and target partitions corresponding to the at least one key partition are created respectively; Data from at least one key partition is read sequentially according to a preset priority order, and written to the corresponding target partition in units of preset-sized data blocks. After the data migration of any critical partition is detected, a verification operation is performed on the critical partition and the corresponding target partition.

3. The method according to claim 2, characterized in that, The method further includes: During the data migration process, the offsets of the key partitions that have been migrated and the key partitions currently being migrated are recorded as breakpoint information at a preset frequency and saved to a preset partition of the peripheral storage device. Upon detecting that the vehicle system has been powered back on, the data migration process continues based on the breakpoint information.

4. The method according to claim 2 or 3, characterized in that, The step of switching the boot source of the vehicle system to the external storage device and loading the kernel image and root file system from the external storage device includes: Write a first migration completion identifier into the main memory and a second migration completion identifier into the peripheral storage device; When the vehicle system is powered on and both the first migration completion flag and the second migration completion flag are detected to be valid, the boot source is switched to the external storage device. Load the kernel image from the boot partition of the target partition corresponding to each of the at least one key partition; Configure the root field in the kernel boot parameters of the vehicle system to point to the root file system partition in the target partition corresponding to the at least one critical partition.

5. The method according to claim 2 or 3, characterized in that, The step of performing the verification operation between the critical partition and the corresponding target partition includes: Obtain the first hash value of the target partition corresponding to the key partition, wherein the first hash value is determined based on the checksum of the data block migrated from the key partition; If the first hash value is found to be consistent with the second hash value of the key partition, then the verification result corresponding to the verification operation is determined to be passed; If the first hash value is found to be inconsistent with the second hash value of the key partition, the verification result is determined to be unsuccessful, and a rollback and retry operation is triggered.

6. The method according to any one of claims 1-3, characterized in that, Prior to migrating data from at least one critical partition in the main memory to an external storage device connected to the vehicle system, the method further includes: Detect whether a connection is established between the peripheral storage device and the vehicle system; If a connection is established, detect the storage capacity data of the peripheral storage device; If the storage capacity data indicates the storage space required to satisfy the data of at least one critical partition, and the health check operation of the peripheral storage device passes, the data of at least one critical partition in the main memory is migrated to the peripheral storage device.

7. The method according to any one of claims 1-3, characterized in that, The acquisition of the lifespan data of the main memory in the vehicle system includes: If the main memory is an eMMC, the lifetime estimation field and the lifetime termination information field in the EXT_CSD register of the eMMC are determined as the lifetime data; If the main memory is UFS, the lifetime estimation field and the lifetime termination information field in the health descriptor of the UFS are determined as the lifetime data; If the main memory is NandFlash, the number of erase / write cycles and the number of bad blocks of each NandFlash storage block are determined as the service life data.

8. A data migration device, characterized in that, include: The acquisition module is used to acquire the lifespan data of the main memory in the vehicle system; The migration module is used to migrate data from at least one critical partition in the main memory to an external storage device connected to the vehicle system when the remaining lifespan indicated by the lifespan data reaches a preset lifespan threshold. The processing module is used to switch the boot source of the vehicle system to the external storage device after the migration is detected, and to load the kernel image and root file system from the external storage device.

9. A vehicle, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium / computer program product, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7; The computer program product includes a computer program that, when executed by a processor, is used to implement the method as described in any one of claims 1-7.

Images