Data updating method and storage device

Abstract

The invention discloses a data updating method and a storage device. The data updating method comprises the following steps: constructing a mapping table from a logic address to a physical address in a starting area of the storage device; writing an initial version corresponding to the boot loader into the first physical address, and mapping a preset starting logic address to the first physical address in a logic address-to-physical address mapping table; when a version update instruction for the boot loader is received, writing an update version corresponding to the boot loader into a second physical address; and updating the logical address-to-physical address mapping table to map the boot logical address from the first physical address to the second physical address. According to the data updating scheme, the physical address can be dynamically allocated, the version number rigid limitation caused by a fixed partition is avoided, and the utilization efficiency of the storage space is greatly improved.

Description

Technical Field

[0001] This application relates to the field of storage control, specifically to a data update method and a storage device. Background Technology

[0002] The bootloader, as the initial program that runs after a device is powered on, undertakes the core functions of hardware initialization and loading the main operating system. Its storage and management reliability is crucial for the booting of non-volatile storage devices such as SD cards, TF cards, USB flash drives, eMMC, UFS, and SSDs.

[0003] In existing technologies, the bootloader management mechanisms of different storage devices have their own characteristics: the bootloaders of SD cards, TF cards and USB flash drives are stored in a fixed initial sector and have no hardware-level backup; eMMC has a dedicated Boot Area partition, which can realize an A / B backup mechanism; UFS achieves secure storage and management through an independent Boot LU in conjunction with RPMB; and SSD places the bootloader within a specific LBA range and loads it by the firmware.

[0004] However, the above management mechanisms all have common technical defects: First, the recovery depth is insufficient, and the single / dual backup mechanism cannot cope with the scenario of continuous upgrade failure, which can easily lead to the device becoming "bricked"; second, the version management is rigid and lacks traceability, making it impossible to roll back to the historical version at a specific point; third, there is a risk of "ghost backup". Under the FTL mechanism, if the physical address corresponding to the old version does not retain a valid logical address mapping, it will be marked as invalid data and then erased by garbage collection, resulting in backup failure; fourth, the space utilization efficiency is low. The traditional fixed partition backup scheme can easily cause storage space waste, and the number of versions is rigidly limited.

[0005] The aforementioned problems are particularly prominent in scenarios such as IoT devices that require frequent OTA upgrades, seriously affecting the operational flexibility and reliability of the devices. Summary of the Invention

[0006] To address the aforementioned technical issues, this application provides a data update method and a storage device that can dynamically allocate physical addresses, avoiding the rigid limitation on the number of versions caused by fixed partitions, and significantly improving the utilization efficiency of storage space.

[0007] To address the aforementioned technical problems, this application provides a data update method applied to a storage device. The storage device includes a memory controller and a non-volatile storage medium. The non-volatile storage medium has a boot area for storing a bootloader, comprising: A logical address to physical address mapping table is constructed in the boot area of ​​the storage device. The logical address to physical address mapping table is used to manage the boot logical address and reserve the mapping relationship between the logical address range and the physical address. Write the initial version corresponding to the bootloader to the first physical address, and map the preset boot logical address to the first physical address in the logical address to physical address mapping table; When a version update instruction for the bootloader is received, the updated version corresponding to the bootloader is written to the second physical address; Update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address.

[0008] Optionally, in some embodiments of this application, it further includes: The mapping relationship of the first physical address in the logical address to physical address mapping table is modified from the startup logical address to a reserved logical address in the reserved logical address range, so as to archive the initial version to the reserved logical address range.

[0009] Optionally, in some embodiments of this application, the mapping relationship of the first physical address in the logical address to physical address mapping table is modified from the startup logical address to a reserved logical address within the reserved logical address range, so as to archive the initial version to the reserved logical address range, including: Determine the unallocated free reserved logical addresses within the reserved logical address range in the logical address to physical address mapping table; Modify the mapping entry corresponding to the first physical address from the startup logical address to a reserved logical address.

[0010] Optionally, in some embodiments of this application, it further includes: Detect the number of allocated reserved logical addresses within the reserved logical address range; When the number of allocated resources reaches a preset threshold, the status information of the bootloader version corresponding to each reserved logical address in the preset version management table is queried. In the version management table, the reserved logical address of the version with an invalid status is marked as an idle reserved logical address; If no invalid version is found, the historical versions are sorted according to the version identifier in the version management table. Based on the sorting results, the mapping relationship between the earliest valid historical version and the reserved logical address is removed, and the reserved logical address whose mapping relationship is removed is marked as an idle reserved logical address.

[0011] Optionally, in some embodiments of this application, it further includes: A version management table is constructed in the non-volatile secure storage area of ​​the storage device. The version management table is a dedicated management table independent of the logical address to physical address mapping table. The association information of each version of the bootloader is written into the version management table according to a preset format, so that the version management table records the mapping relationship, status information and security verification information of each version.

[0012] Optionally, in some embodiments of this application, after modifying the mapping relationship of the first physical address in the logical address to physical address mapping table from the startup logical address to a reserved logical address within the reserved logical address range, the method further includes: Update the version management table of the storage device with the association information of the initial version and the association information of the updated version of the bootloader.

[0013] Optionally, in some embodiments of this application, the logical reserved address corresponding to the initial version of the bootloader is updated in the version management table of the storage device, and the status information corresponding to the initial version is updated to a first status; Add a mapping entry corresponding to the updated version to the version management table of the storage device, and update the status information of the updated version to the second status; The update results of the version management table are stored in the non-volatile storage area.

[0014] Optionally, in some embodiments of this application, it further includes: If the current version of the bootloader fails to start, then the version management table is queried; The historical version with a valid status is determined as the target recovery version in the version management table, and the logical address to physical address mapping table is updated according to the target recovery version to remap the boot logical address to the physical address corresponding to the selected target recovery version.

[0015] Optionally, in some embodiments of this application, determining the historical version with a valid status in the version management table as the target recovery version includes: The bootloader versions are sorted according to their version identifiers, and the first valid historical version is selected as the target recovery version.

[0016] Optionally, in some embodiments of this application, it further includes: In response to a version rollback command sent by the host, the target historical version is located in the version management table according to the version identifier corresponding to the version rollback command; Update the logical address to physical address mapping table to map the startup logical address to the physical address corresponding to the target historical version.

[0017] Optionally, in some embodiments of this application, the version management table is also used to record the digital signature information of each version of the bootloader, and the digital signature information is used for start chain security verification.

[0018] Optionally, in some embodiments of this application, the version management table is also used to record at least one of the following: version identifier, integrity check code, and status information of each version of the bootloader.

[0019] Optionally, in some embodiments of this application, the version management table is stored in the non-volatile secure storage area of ​​the storage device, which is an RPMB replay protected memory block or a dedicated system area of ​​the storage device.

[0020] Optionally, in some embodiments of this application, the logical address to physical address mapping table is a mapping table independently maintained by the boot area, and the logical address to physical address mapping table is isolated from the address mapping table of the user data area in the storage device.

[0021] Optionally, in some embodiments of this application, the reserved logical address range is located in the target address segment of the boot zone logical address space and does not respond to read / write requests initiated by the host through standard storage access commands.

[0022] Optionally, in some embodiments of this application, it further includes: When a version update instruction for the bootloader is received again, the new update version is written to the third physical address allocated by the memory controller; Update the logical address to physical address mapping table, and map the startup logical address from the physical address corresponding to the current active version to the third physical address; Modify the mapping relationship between the physical address corresponding to the current active version and the logical address to physical address mapping table to a free reserved logical address within the reserved logical address range; Update the association information of each version of the bootloader in the version management table.

[0023] Optionally, in some embodiments of this application, after updating the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address, the method further includes: Trigger a reboot of the device containing the storage device so that the updated version of the bootloader can take effect.

[0024] Optionally, in some embodiments of this application, before updating the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address, the method further includes: Verify the updated digital signature information; If the digital signature information is verified, the logical address to physical address mapping table is updated to map the startup logical address from the first physical address to the second physical address.

[0025] Accordingly, this application also provides a data update apparatus applied to a storage device, the storage device including a memory controller and a non-volatile storage medium, the non-volatile storage medium having a boot area for storing a bootloader, including: The construction module is used to construct a logical address to physical address mapping table in the boot area of ​​the storage device. The logical address to physical address mapping table is used to manage the boot logical address and reserve the mapping relationship between the logical address range and the physical address. The mapping module is used to write the initial version corresponding to the bootloader to the first physical address, and to map the preset boot logical address to the first physical address in the logical address to physical address mapping table; The writing module is used to write the updated version of the bootloader to a second physical address when a version update instruction for the bootloader is received. An update module is used to update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address.

[0026] This application also provides a storage device, including: A connection interface for electrically connecting to a host system; Memory module and; The memory controller includes a processor, a data management circuit, a memory interface control circuit, and a buffer memory, and is electrically connected to the connection interface and the memory module. The memory controller is configured to perform the data update method as described above.

[0027] As described above, this application provides a data update method and a storage device, applied to a storage device. The storage device includes a memory controller and a non-volatile storage medium. The non-volatile storage medium has a boot area for storing a bootloader. After constructing a logical address to physical address mapping table in the boot area of ​​the storage device, the logical address to physical address mapping table is used to manage boot logical addresses and retain the mapping relationship between logical address ranges and physical addresses. The initial version corresponding to the bootloader is written to a first physical address, and a preset boot logical address is mapped to the first physical address in the logical address to physical address mapping table. When a version update instruction for the bootloader is received, the updated version corresponding to the bootloader is written to a second physical address. Finally, the logical address to physical address mapping table is updated to map the boot logical address from the first physical address to the second physical address. In the data update scheme provided in this application, an independent logical address to physical address mapping table is constructed in the boot area. The updated version is written to the second physical block instead of overwriting the old block. It supports multiple iterative updates and maps the old version to the reserved logical address range, realizing the safe retention of multiple versions. This not only solves the problems of insufficient recovery depth and inability to cope with continuous upgrade failures, but also supports the fixed-point rollback of historical versions. At the same time, it can dynamically allocate physical addresses according to the actual version size of the bootloader, getting rid of the hard limit on the number of versions and greatly improving the utilization efficiency of storage space. Attached Figure Description

[0028] 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. To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0029] Figure 1 This is a schematic diagram of the structure of the data update system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the data update method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the overall process of the data update method provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the Bootloader upgrade and secure archiving scenario provided in the embodiments of this application; Figure 5 This is a schematic diagram of the autonomous deep recovery process after startup failure provided in the embodiments of this application.

[0030] The realization of the objectives, functional features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. The accompanying drawings have illustrated 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 concepts of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0031] 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.

[0032] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0033] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0034] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0035] The following describes the embodiments involved in this application in detail. It should be noted that the order of description of the embodiments in this application is not intended to limit the priority of the embodiments.

[0036] Please see Figure 1The host system 10 is, for example, a personal computer, a laptop computer, or a server. The host system 10 includes a processor 110 (also referred to as a second processor), host memory 120, and a data transfer interface circuit 130. In this embodiment, the processor 110 is coupled (also referred to as electrically connected) to the host memory 120 and the data transfer interface circuit 130. In another embodiment, the processor 110, host memory 120, and data transfer interface circuit 130 are electrically connected to each other via a system bus. In this embodiment, the processor 110, host memory 120, and data transfer interface circuit 130 may be disposed on the motherboard of the host system 10.

[0037] The storage device 20 includes a storage controller 210, a rewritable non-volatile memory module 220, and a connection interface circuit 230. The storage controller 210 includes a processor 211 (also referred to as a first processor), a data management circuit 212, and a memory interface control circuit 213.

[0038] In this embodiment, the host system 10 is electrically connected to the storage device 20 via a data transmission interface circuit 130 and a connection interface circuit 230 to perform data access operations. For example, the host system 10 can store data to or read data from the storage device 20 via the data transmission interface circuit 130.

[0039] In this embodiment, the number of data transmission interface circuits 130 can be one or more. Through the data transmission interface circuits 130, the motherboard can be electrically connected to the storage device 20 via wired or wireless means. The storage device 20 can be, for example, a USB flash drive, memory card, solid-state drive (SSD), or wireless storage device. Wireless storage devices can be, for example, Near Field Communication (NFC) storage devices, Wi-Fi storage devices, Bluetooth storage devices, or Bluetooth Low Energy (BLE) storage devices (e.g., iBeacon), or other storage devices based on various wireless communication technologies. Furthermore, the motherboard can also be electrically connected via the system bus to various I / O devices such as a Global Positioning System (GPS) module, network interface card, wireless transmission device, keyboard, screen, and speaker.

[0040] In this embodiment, the data transmission interface circuit 130 and the connection interface circuit 230 are interface circuits compatible with the Peripheral Component Interconnect Express (PCI Express) standard. Furthermore, data transmission between the data transmission interface circuit 130 and the connection interface circuit 230 utilizes the Non-Volatile Memory Express (NVMe) communication protocol.

[0041] In another embodiment, the connection interface circuit 230 may be packaged in a chip with the memory controller 210, or the connection interface circuit 230 may be disposed outside a chip containing the memory controller 210.

[0042] In this embodiment, the host memory 120 is used to temporarily store commands or data executed by the processor 110. For example, in this embodiment, the host memory 120 may be Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), etc. However, it should be understood that this disclosure is not limited thereto, and the host memory 120 may also be other suitable memories.

[0043] The memory controller 210 is used to execute multiple logic gates or control commands implemented in hardware or firmware, and to perform operations such as writing, reading and erasing data in the rewritable non-volatile memory module 220 according to the commands of the host system 10.

[0044] More specifically, the processor 211 in the memory controller 210 is hardware with computing capabilities, used to control the overall operation of the memory controller 210. Specifically, the processor 211 is programmed with multiple control commands / program codes, and these control commands / program codes are executed when the storage device 20 is operating to perform operations such as writing, reading, and erasing data. Furthermore, in this embodiment, the control commands / program codes can also be executed to implement the memory management method provided in this disclosure. The control commands / program codes corresponding to memory management can also be implemented as hardware circuit units to implement the memory management method provided in this disclosure.

[0045] It is worth mentioning that, in this embodiment, the processor 110 and the processor 211 are, for example, a central processing unit (CPU), a microprocessor, or other programmable processing units (microprocessor), digital signal processor (DSP), programmable memory controller, application specific integrated circuits (ASIC), programmable logic device (PLD), or other similar circuit components, and this disclosure is not limited thereto.

[0046] In this embodiment, as described above, the memory controller 210 further includes a data management circuit 212 and a memory interface control circuit 213. It should be noted that the operations performed by each component of the memory controller 210 can also be considered as operations performed by the memory controller 210 itself.

[0047] The data management circuit 212 is electrically connected to the processor 211, the memory interface control circuit 213, and the connection interface circuit 230. The data management circuit 212 receives instructions from the processor 211 to perform data transfer. For example, it reads data from the host system 10 (e.g., host memory 120) via the connection interface circuit 230 and writes the read data to the rewritable non-volatile memory module 220 via the memory interface control circuit 213 (e.g., performing a write operation according to a write command from the host system 10). Another example is reading data from one or more physical units of the rewritable non-volatile memory module 220 (data can be read from one or more memory cells in one or more physical units) via the memory interface control circuit 213 and writing the read data to the host system 10 (e.g., host memory 120) via the connection interface circuit 230 (e.g., performing a read operation according to a read command from the host system 10). In another embodiment, the data management circuit 212 may also be integrated into the processor 211.

[0048] The memory interface control circuit 213 is used to receive instructions from the processor 211 and, in conjunction with the data management circuit 212, perform write (also known as programming), read, or erase operations on the rewritable non-volatile memory module 220.

[0049] Furthermore, data to be written to the rewritable non-volatile memory module 220 is converted into a format acceptable to the rewritable non-volatile memory module 220 via the memory interface control circuit 213. Specifically, if the processor 211 needs to access the rewritable non-volatile memory module 220, the processor 211 transmits a corresponding command sequence to the memory interface control circuit 213 to instruct the memory interface control circuit 213 to perform the corresponding operation. For example, these command sequences may include a write command sequence indicating the writing of data, a read command sequence indicating the reading of data, an erase command sequence indicating the erasure of data, and corresponding command sequences for indicating various memory operations. These command sequences may include one or more signals, or data on the bus. These signals or data may include command codes or program codes. For example, a read command sequence may include information such as the read identification code, memory address, and physical address.

[0050] In this disclosure, the memory controller 210 establishes a logical-to-physical address mapping table and a physical-to-logical address mapping table to record the mapping relationship between the logical addresses of logical units (e.g., logical blocks, logical pages, or logical columns) and the physical addresses (physical addresses) of physical units (e.g., physical erase units / physical blocks, physical pages, physical columns) configured for the rewritable non-volatile memory module 220. In other words, the memory controller 210 can use the logical-to-physical address mapping table (also called the logical-to-physical mapping table) to look up the physical unit mapped to a logical unit (e.g., look up the physical page mapped to a logical page; look up the physical address mapped to a logical address), and the memory controller 210 can use the physical-to-logical address mapping table (also called the physical-to-logical mapping table) to look up the logical unit mapped to a physical unit (e.g., look up the logical page mapped to a physical page; look up the logical address mapped to a physical address).

[0051] The memory controller 210 also establishes data structures to record various mapping relationships: including a list of adjusted blocks corresponding to different storage modes for adjusted blocks, a list of spare page groups for spare page groups, a mapping table for virtual spare blocks to record their correspondence with adjusted blocks, and an image table for virtual spare blocks to record their correspondence with spare page groups. When data access operations are required on a specified virtual spare block, the memory controller 210 can obtain the actual physical address by querying these mapping tables, and then perform the corresponding data read / write operations.

[0052] In one embodiment, the memory controller 210 further includes a buffer memory 214. The buffer memory is electrically connected to the processor 211 and is used to temporarily store data and commands from the host system 10, data from the rewritable non-volatile memory module 220, or other system data used to manage the storage device 20 (e.g., various image tables, index tables, address lists, adjusted block lists, spare page group lists, virtual spare block mapping tables, and other system data related to this disclosure) so that the processor 211 can quickly access the data, commands, or system data from the buffer memory 214.

[0053] The rewritable non-volatile memory module 220 is electrically connected to the memory controller 210 (memory interface control circuit 213) and is used to store data written by the host system 10.

[0054] In this embodiment, the rewritable non-volatile memory module 220 has multiple word lines, each of which is electrically connected to multiple memory cells, also called columns (or physical columns). Multiple columns on the same word line form a physical programming unit (also called a physical page or physical page). Each physical page corresponds to a physical address to record the location of the data stored in the physical page. Furthermore, multiple physical pages can form a physical block (also called a physical erase unit or physical block). Each memory die (chip) in the multiple memory dies of the rewritable non-volatile memory module has multiple planes, and each plane has multiple physical blocks. It should be noted that this disclosure is not limited to the size of each physical page and logical page.

[0055] The storage cell type (also known as the storage mode) represents the number of bits that each storage cell (Memory Cell) can store. Common types include SLC (Single-Level Cell, each storage cell stores 1 bit), MLC (Multi-Level Cell, each storage cell stores 2 bits), and TLC (Triple-Level Cell, each storage cell stores 3 bits). Different storage modes differ in storage density, read / write speed, and endurance, affecting the overall performance and characteristics of flash memory. Furthermore, in this embodiment, each physical block can be configured with different operating modes, assigning different storage modes to its storage cells. For example, when a physical block is configured with TLC storage mode, each of its storage cells can store 3 bits. When this physical block is switched from TLC storage mode to SLC or MLC storage mode, the number of bits that each storage cell can store will be adjusted to 1 bit or 2 bits.

[0056] The data update scheme provided in this application constructs an independent logical address to physical address mapping table in the boot sector, writes the updated version to the second physical block instead of overwriting the old block, and supports multiple iterative updates and mapping the old version to the reserved logical address range, thus achieving secure retention of multiple versions. This not only solves the problems of insufficient recovery depth and inability to cope with continuous upgrade failures, but also supports point rollback of historical versions. At the same time, it can dynamically allocate physical addresses according to the actual version size of the bootloader, getting rid of the hard limit on the number of versions and greatly improving the utilization efficiency of storage space.

[0057] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0058] A data update method includes: constructing a logical address to physical address mapping table in the boot area of ​​a storage device; writing the initial version corresponding to a bootloader to a first physical address; mapping a preset boot logical address to the first physical address in the mapping table; and when receiving a version update instruction for the bootloader, writing the updated version corresponding to the bootloader to a second physical address; and updating the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address.

[0059] Please continue reading. Figure 1 and in conjunction with reference Figure 2 , Figure 2 This is a schematic flowchart illustrating a data update method provided in an embodiment of this application. The data update method is applied to a storage device, which includes a memory controller and a non-volatile storage medium. The non-volatile storage medium has a boot area for storing a bootloader. The specific flow of the data update method is as follows: 101. Construct a logical address to physical address mapping table in the boot sector of the storage device.

[0060] The boot area, also known as the boot region, is a dedicated, independent storage area within the non-volatile storage medium of a storage device. Its sole purpose is to store the core code required for device startup, such as the bootloader. The form of the boot area varies depending on the type of storage device: for example, the dedicated boot area of ​​eMMC, the independent boot LU of UFS, the fixed starting sector of SD / TF cards / USB flash drives, and the specific LBA range of SSDs. It is the core area that the host firmware accesses first after the device is powered on.

[0061] The logical address to physical address mapping table is used to manage the mapping relationship between the boot logical address and the reserved logical address range and the physical address. In this scheme, the logical address to physical address mapping table of the boot area is the core management table of the logical address to physical address independently / strongly isolated by the storage device's memory controller for the boot area. It is specifically used to manage the one-to-one mapping relationship between the boot logical address (the logical address that the host always accesses to the bootloader), the reserved logical address range (a dedicated address range that the host cannot access), and the boot area physical address (the actual physical storage unit that stores the bootloader version). Moreover, this logical address to physical address mapping table is completely isolated from the address mapping table of the storage device's user data area to avoid user data operations affecting the boot area mapping relationship.

[0062] Specifically, the memory controller establishes an independent address mapping layer for the boot sector (also known as creating a separate logical address to physical address mapping table body), completely isolating it from the mapping table in the user data area. This ensures that the address mapping management of the boot sector is not interfered with by user data operations, while defining the storage location of the mapping table (either a dedicated storage area of ​​the memory controller or a physical address specified by the boot sector), guaranteeing the non-volatility of the mapping table itself.

[0063] In one embodiment, a data structure design scheme is proposed for the memory controller to establish an independent mapping table for the aforementioned boot sector. Specifically, this mapping table is essentially an array or hash table, with each entry corresponding to a logical address (sector / page) of the boot sector. Each entry contains at least the following fields: Logical Address (Index): The address in the boot sector's logical address space, for example, from 0x00000000 to 0x000FFFFF (the specific size depends on the boot sector capacity). Physical Address: The corresponding physical block address (PBA), typically including the block number and page offset. Attribute Flags: Used to indicate whether the mapping is valid, whether it is a reserved logical address, whether it is locked, etc. Checksum: CRC protection for the entry itself to prevent data corruption. This mapping table itself is stored in the memory controller's buffer memory for fast access, while a persistent copy is stored in non-volatile media (such as a reserved block in the boot sector or a dedicated system block). After each update, the memory controller writes the mapping table back to non-volatile memory to ensure recovery after power failure.

[0064] In one embodiment, a scheme for dividing the boot logical address and reserved logical address ranges by the memory controller is proposed. Specifically, the memory controller 210 divides the logical address of the boot area as follows: the boot logical address (L_boot) is fixed as a single logical address, such as 0x00000000, which serves as the hard-coded access entry point of the host Boot ROM. The memory controller 210 ensures that this address is always mapped to the physical address of the currently active Bootloader.

[0065] The reserved logical address range (L_reserved_range) defines a contiguous address range within the boot sector's logical address space, for example, 0x00100000 to 0x00FFFFFF. These addresses are not accessed by the host system via standard commands because the memory controller 210 filters them when parsing host system commands: if an accessed address falls within this range, an "invalid LBA" error is returned. Thus, the reserved logical addresses are only visible internally to the memory controller 210 and are used to mark physical addresses for historical versions.

[0066] In one embodiment, the memory controller 210 creates a separate logical-physical address mapping table for the logical address of the boot area. This mapping table is completely isolated from the address mapping table of the user data area of ​​the storage device through hardware configuration. At the same time, the memory controller 210 divides the logical address. The boot logical address is a single fixed logical address (such as 0x0000), which serves as the fixed entry point for the host boot firmware (such as SoC ROM, BIOS / UEFI) to access the bootloader. Secondly, the range of reserved logical addresses is divided. Specifically, a continuous logical address segment can be defined, such as the high address segment above 0xFFF00000, which is set as a dedicated address segment that is not accessible to the host and is used to map the historical versions of the bootloader that need to be retained.

[0067] In one embodiment, to prevent power outages from corrupting the mapping table during the update process, an atomic update mechanism for the mapping table is proposed, meaning that modifications to the mapping table must support atomicity. A dual backup mechanism and a logging mechanism can be used to ensure that modifications to the mapping table can achieve atomicity.

[0068] Specifically, a dual backup mechanism is used: the mapping table is stored in two copies (Primary and Backup) in non-volatile storage. During updates, the Backup copy is modified first, and the Active flag is switched upon successful write. If a power outage occurs during the update process, the memory controller detects an inconsistency in the flags upon the next startup and rolls back using the Backup copy. A logging mechanism is also used: a log area is reserved before the mapping table area. During each update, the "mapping entry before modification" and the "mapping entry after modification" are written to the log first, and then the primary mapping table is updated. Upon restart, the log is checked, and if the primary table update is incomplete, a rollback is performed. In this scheme, a dual backup + checksum approach is preferred because the startup mapping table is typically small, and the overhead is controllable.

[0069] In one embodiment, basic management fields and mapping rules are defined in the mapping table. The fields need to include information such as logical address identifier, corresponding physical address, and address status. At the same time, mapping rules are set, including enabling the unique mapping of logical addresses, reserving the allocation rules for logical address ranges, and the binding method between physical addresses and logical addresses, to ensure that the mapping table can realize the dynamic association and modification of logical addresses and physical addresses.

[0070] Finally, after writing the initial version of the bootloader to the first physical address of the boot sector, a corresponding mapping relationship between the preset boot logical address and the initial physical address is established in the constructed logical address to physical address mapping table. This mapping relationship is written into the table body and saved, completing the initialization and activation of the mapping table. This ensures that the host can access the initial version of the bootloader through the fixed boot logical address. At this point, the logical address to physical address mapping table of the boot sector is completed.

[0071] 102. Write the initial version of the bootloader to the first physical address, and map the preset boot logical address to the first physical address in the logical address to physical address mapping table.

[0072] The bootloader is the first program to run after the storage device is powered on. Its core function is to complete hardware initialization and load the device's main operating system. It is the fundamental program for the device to start normally and must be stored in a dedicated boot area of ​​non-volatile storage media. The first executable bootloader version written to the boot area during factory configuration or initial initialization is the initial version. The first physical address is the first physical storage unit specifically allocated by the memory controller in the boot area of ​​the non-volatile storage media for the initial version of the bootloader. It is the actual physical storage carrier of the initial version program data and is the smallest manageable physical address of the flash memory medium.

[0073] In detail, the memory controller maintains a pool of free physical blocks in the boot sector. During initial version writing, an erased physical block (denoted as the first physical address) is allocated from the pool. To ensure boot reliability, blocks located at the beginning of the boot sector with lower wear are typically selected first. The writing process includes sending erase commands, programming commands, and reading the checksum (ECC / CRC) to ensure data integrity before considering the write successful.

[0074] Within the boot area of ​​the rewritable non-volatile memory module 220, the memory controller 210 allocates a free physical address for the initial version of the bootloader, defining it as the first physical address. The memory controller writes the complete data of the initial version of the bootloader into the allocated first physical address, completing the physical storage of the program data. The writing process ensures data integrity, preventing data loss or corruption. Specifically, the memory controller retrieves the preset boot logical address from the boot area logical address to physical address mapping table. This address is the fixed logical entry point for the host boot firmware to access the bootloader and is a dedicated address pre-planned in the boot area logical address space (exemplarily 0x0000 in the disclosure document). In the boot area logical address to physical address mapping table, a one-to-one mapping relationship between the preset boot logical address and the first physical address is created, and this mapping relationship is entered into the designated management field of the mapping table.

[0075] After writing the first physical address, the memory controller creates an entry for the logical address, physical address, and attribute flags in the mapping table. For example, logical address: L_boot; physical address: first physical address; attribute flag: ACTIVE (indicating the current active version); this entry is also written to a persistent copy of the mapping table. The memory controller non-volatilely saves the updated logical address to physical address mapping table to ensure that the mapping relationship is not lost after power failure, completing the initialization and activation of the mapping table. The memory controller performs basic access verification to confirm that the host boot firmware can normally read the initial version data of the bootloader in the first physical address through the preset boot logical address.

[0076] 103. When a version update instruction for the bootloader is received, the updated version of the bootloader is written to the second physical address.

[0077] A version update command is a control command that triggers the storage device to execute a bootloader version update. It is initiated by the host, a remote maintenance terminal, or the device's own management system (such as an OTA upgrade command for IoT devices). The second physical address is a newly allocated free physical storage unit within the boot area of ​​the non-volatile storage medium for the updated bootloader version after the memory controller receives the version update command. It is the actual physical storage carrier for the updated version's program data and is independent of the first physical address storing the initial version. This second physical address is the smallest manageable unit of the flash memory medium, and the allocation process ensures that it contains no other valid data. Writing the updated version will not overwrite any physical addresses of previous versions.

[0078] For example, the memory controller 210 receives an externally initiated bootloader version update instruction through the storage device's connection interface circuit 230. It searches and filters within the boot area to select a free physical address without valid data or address conflicts as the second physical address. Simultaneously, it records the physical address of this physical block internally to ensure it does not conflict with the first physical address of the initial version. Next, the memory controller receives the complete program data of the externally sent bootloader update version, temporarily caches the data in the memory controller's cache, performs integrity verification on the cached data, and then writes the verified update version data from the cache, block by block, into the allocated second physical address according to the physical storage rules of the flash memory medium.

[0079] After all the updated version data is written to the second physical address, the memory controller performs read and write verification on the data in the physical block. By comparing the actual data stored in the physical block with the original data in the cache, it verifies whether the write was successful and whether the data is consistent. If the verification passes, the memory controller confirms that the second physical address has successfully stored a valid updated version of the bootloader.

[0080] In one implementation, after writing the updated version corresponding to the bootloader to the second physical address and before updating the logical address to physical address mapping table, the process includes: constructing a temporary boot mapping table in the memory controller's buffer memory; configuring this temporary boot mapping table to map only the second physical address; attempting to boot the updated version from the second physical address pointed to by the temporary boot mapping table in the buffer memory; if the boot is successful, updating the logical address to physical address mapping table in the non-volatile storage medium with the contents of the temporary boot mapping table; if the boot fails, discarding the temporary boot mapping table and keeping the logical address to physical address mapping table unchanged. This introduces a "trial boot" mechanism, that is, before officially writing the mapping table to the non-volatile storage medium, loading the new version into the buffer memory and running it to confirm its basic usability before solidifying the mapping relationship. This prevents unbootable, corrupted versions from being "welded" to the boot path, greatly improving the security of the update.

[0081] In one implementation, writing the updated version of the bootloader to the second physical address involves: obtaining the data size of the updated version; allocating one or more complete physical blocks for the updated version based on the data size and the physical block size of the non-volatile storage medium; and writing the data of the updated version into the allocated physical blocks in a sequential stream, ensuring that the write order within each physical block is continuous. This reduces cross-block addressing and fragmentation, improves read performance, and has a positive impact on boot speed.

[0082] In one implementation, a specific version of the bootloader and its corresponding first physical address are stored in the read-only memory of the storage device. During the initialization of the logical address to physical address mapping table, if an invalid boot logical address mapping or a boot failure from the boot logical address is detected, the memory controller forcibly remaps the boot logical address to the first physical address where the specific version of the bootloader resides. This provides an ultimate "brick recovery" solution. A fundamental and stable bootloader is retained in the ROM code stored within the memory controller. Even when all manageable bootloader versions are corrupted, there is still a "rescue" entry point, greatly enhancing the product's robustness.

[0083] In one embodiment, the memory controller receives an updated version of the binary image. The image undergoes integrity verification: a hash (e.g., SHA256) is calculated and compared with the hash value attached to the instruction. Digital signature verification: the digital signature of the image is verified using a pre-configured public key to ensure the image's origin is trustworthy and has not been tampered with. Version rollback prevention check: the version number in the image is checked to see if it is higher than the version number of the currently active version (this check is optional if rollback support is required). Typically, to prevent malicious downgrades, the version number is forced to monotonically increase.

[0084] Allocate a new physical block (denoted as the second physical address) from the pool of free physical blocks. If the remaining space in the startup area is insufficient, execute a reclamation strategy that reserves logical address ranges (see below) to release at least one free block.

[0085] Erase the physical block corresponding to the second physical address, and then programmatically write the updated version image page by page. After writing is complete, immediately read and verify to ensure data reliability.

[0086] Before modifying the mapping table, first add a temporary record to the version management table, recording "Update version is about to be activated", with a status of "Pending". This way, even if there is a subsequent power outage, it can be restored based on this record.

[0087] 104. Update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address.

[0088] The memory controller 210 extracts and verifies the digital signature information of the updated version of the bootloader. Only after the digital signature verification is successful will the mapping table update operation be performed. The memory controller 210 enables atomic update mode for the logical physical address mapping table to avoid data corruption in the mapping table due to power failure or abnormal interruption during the update process. In atomic update mode, the first physical address originally corresponding to the boot logical address in the mapping table is modified to the second physical address to complete the mapping switch of the boot logical address.

[0089] After the mapping relationship is modified, the memory controller 210 stores the updated logical address to physical address mapping table in a non-volatile manner to ensure that the latest state of the mapping table will not be lost after the device is powered off, and to provide a valid mapping basis for subsequent host access and device startup.

[0090] Optionally, in some embodiments of this application, the memory controller disables the atomic update mode and then verifies the mapping table update result. By simulating host access to the boot logic address, it is confirmed that the address can correctly point to the second physical address and read the updated version of the bootloader data, thus verifying that the mapping update operation has been successfully implemented.

[0091] Optionally, in some embodiments of this application, it may further include: The mapping relationship of the first physical address in the logical address to physical address mapping table is changed from the startup logical address to a reserved logical address in the reserved logical address range, so that the initial version is archived to the reserved logical address range.

[0092] Within the reserved logical address range of the boot area, the memory controller 210 searches and filters out unoccupied, unmapped free reserved logical addresses, identifies them as new associated logical addresses of the first physical address, and temporarily records this address information to avoid address conflicts that could lead to version management chaos. Then, the memory controller modifies the boot logical address originally associated with the first physical address to the selected free reserved logical address, debinding the first physical address from the boot logical address and establishing a mapping relationship between it and the reserved logical address. Next, the memory controller non-volatilely stores the modified logical address to physical address mapping table. Finally, the memory controller performs dual verification on the mapping modification result: first, confirming that the mapping relationship between the first physical address and the selected reserved logical address is successfully effective and that the boot logical address still stably points to the second physical address; second, verifying that the reserved logical address is invisible to the host and that the first physical address will not be marked as "invalid data" by the FTL (Flash Translation Layer), ensuring that the initial version is securely archived.

[0093] Optionally, in some embodiments of this application, the step "modifying the mapping relationship of the first physical address in the logical address to physical address mapping table from the startup logical address to a reserved logical address within the reserved logical address range, so as to archive the initial version to the reserved logical address range" may specifically include: Identify unallocated free reserved logical addresses within the reserved logical address range in the logical address to physical address mapping table; Change the mapping entry corresponding to the first physical address from the boot logical address to the reserved logical address.

[0094] The memory controller 210 reads a pre-configured reserved logical address range from the logical address to physical address mapping table, such as a starting address of 0xFFF00000 and an ending address of 0xFFFFFFFF. At the same time, it loads the address allocation status fields corresponding to all reserved logical addresses within this range. Then, the memory controller traverses the address allocation status fields corresponding to the reserved logical addresses and filters out reserved logical addresses with an address allocation status of "free". Next, the memory controller performs validity verification on these free reserved logical addresses to confirm that the address is not bound to other physical addresses, has no address conflicts, and belongs to a legal address segment within the reserved logical address range of the boot area. Furthermore, the memory controller selects the first free reserved logical address from the candidate list that has passed the verification, temporarily records the identification information of the address, and uses it as the new associated logical address of the first physical address. Then, the memory controller enables atomic update mode for the logical address to physical address mapping table. In the logical address to physical address mapping table, it searches for the mapping entry whose physical address field matches the first physical address. The current logical address identifier field of this entry is the boot logical address. Then, it changes the logical address identifier field in the mapping entry from the boot logical address to the selected target free reserved logical address, changes the status of the reserved logical address from free to allocated, and restores the status corresponding to the boot logical address to pending mapping.

[0095] Optionally, in some embodiments of this application, it further includes: Detect the number of allocated reserved logical addresses within the reserved logical address range; When the number of allocated resources reaches a preset threshold, the status information of the bootloader version corresponding to each reserved logical address in the preset version management table is queried. In the version management table, mark the reserved logical address of the version whose status is invalid as an idle reserved logical address; If no invalid version is found, the historical versions are sorted according to the version identifier in the version management table. Based on the sorting results, the mapping relationship between the earliest valid historical version and the reserved logical address is removed, and the reserved logical address whose mapping relationship is removed is marked as an idle reserved logical address.

[0096] The memory controller 210 reads the complete address list of the pre-configured reserved logical address range from the logical address to physical address mapping table, and at the same time loads the address allocation status fields corresponding to each reserved logical address in the list, filters out the reserved logical addresses with the address allocation status of "allocated", and the memory controller 210 counts the total number as N; the memory controller compares the allocated quantity N with the preset threshold M. If N < M, the reserved addresses are sufficient and no processing is required; if N ≥ M, the memory controller 210 reads the version management table from the non-volatile secure storage area (RPMB / special system area), extracts all the bootloader version records associated with the reserved logical addresses in the table, and filters out the versions with the status of "invalid" (the basis for the invalid status determination: version data corruption, integrity check failure, marked as discarded by the operation and maintenance side, etc.); For each version with an invalid status, the memory controller 210 extracts the reserved logical address associated with it, and changes the address allocation status of the reserved logical address from "allocated" to "idle". At the same time, the reserved logical address field of the invalid version is emptied and marked as an unbound address; finally, the memory controller writes the modified logical address to physical address mapping table and version management table into the non-volatile storage area and exits the atomic update mode; if at least 1 invalid version is filtered, the process ends and the reserved addresses have been released; if no invalid status version is queried, the memory controller filters out all the historical versions with the status of "valid" and associated with the reserved logical addresses from the version management table, arranges them in ascending order according to the serial number or value of the version identifier (such as V1 - V2 - V3), generates an ordered list of valid historical versions, and the first in the list is the earliest valid historical version.紧接着,存储器控制器从列表中选取首个版本,提取其关联的保留逻辑地址,记为待释放地址L;在映射表中定位待释放地址L对应的映射条目,将其地址分配状态从“已分配”修改为空闲,同时清空该条目与对应物理地址的绑定关系。 Immediately afterwards, the memory controller selects the first version from the list, extracts the reserved logical address associated with it, and records it as the address L to be released; locates the mapping entry corresponding to the address L to be released in the mapping table, changes its address allocation status from "allocated" to "idle", and at the same time clears the binding relationship between this entry and the corresponding physical address.

[0097] In some embodiments of the present application, the memory controller writes the modified mapping table and version management table into the non-volatile storage area, exits the atomic update mode, and completes the release of the reserved logical address.

[0098] Optionally, in some embodiments of the present application, it further includes: Construct a version management table in the non-volatile secure storage area of the storage device. The version management table is a dedicated management table independent of the logical address to physical address mapping table; Write the association information of each version of the bootloader into the version management table according to a preset format, so that the version management table records the mapping relationship, status information and security check information of each version.

[0099] The memory controller locates the non-volatile secure storage area of ​​the storage device. In some embodiments of this application, the non-volatile secure storage area is preferentially selected from the RPMB. If there is no RPMB, the dedicated system area is selected. The free contiguous storage space in the area without valid data and address conflicts is selected to divide the version management table into independent storage areas.

[0100] The storage controller creates an empty table body for the version management table in the allocated independent storage space, writes the table's basic metadata (such as table version number, field definition rules, and creation time), and configures the table's access permissions: only the storage controller has read and write permissions, and the host cannot read / modify the table through standard storage access commands, ensuring the security of the table data; it marks the table's attributes as a Bootloader-specific management table to distinguish it from other management tables in the user data area, completing the initialization and activation of the table body.

[0101] Then, the memory controller collects complete association information for each version of the bootloader, including the initial version or subsequent updated versions. For example, the initial version corresponds to the version identifier (e.g., V1), the first physical address, the associated boot logical address (e.g., 0x0000), the initial state (active), the integrity check code, and the digital signature information; the subsequent updated versions correspond to the version identifier (e.g., V2 or V3), the corresponding physical address (second or third physical block), the initial associated logical address (boot logical address), the initial state (active), the integrity check code, and the digital signature information.

[0102] Optionally, in some embodiments of this application, the information storage controller standardizes the collected raw information according to a preset format and converts it into standardized data that can be recognized by the table body, such as uniformly converting physical addresses into fixed-length hexadecimal strings, uniformly converting status information into enumeration values, etc.

[0103] After the memory controller writes the completed version entry into the physical storage area of ​​the version management table, it reads the newly written entry and compares the consistency between the original collected information and the information stored in the table. If the verification passes, the writing is confirmed to be successful; if the verification fails, it is rewritten and the anomaly is investigated.

[0104] Optionally, in some embodiments of this application, after the step "modifying the mapping relationship of the first physical address in the logical address to physical address mapping table from the startup logical address to a reserved logical address in the reserved logical address range, so as to archive the initial version to the reserved logical address range", it may further include: Update the version management table of the storage device to include the association information of the initial version and the association information of the updated version of the bootloader.

[0105] The associated information is the core metadata stored in the version management table, used to uniquely identify, manage, and trace each version of the bootloader. It is the key basis for the memory controller to realize bootloader version recovery, accurate rollback, and status identification, and is also a core component of the version management table. The associated information includes basic identification information, storage address information, version status information, and security verification information. The basic identification information includes information such as the version ID. The storage address information is the physical address corresponding to the version and the associated reserved logical address. The version status information can be represented as: active (the currently running version), valid (historical versions can be used normally), and invalid (damaged / verification failed version). The security verification information may contain digital signature information, which is used for boot chain security verification.

[0106] Optionally, in some embodiments of this application, after the step "update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address", it may further include: Trigger a reboot of the device containing the storage device so that the updated bootloader can take effect.

[0107] Optionally, in some embodiments of this application, before the step "update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address", the following may be included: Verify the updated digital signature information; If the digital signature information is verified, the logical address to physical address mapping table is updated to map the startup logical address from the first physical address to the second physical address.

[0108] Furthermore, the memory controller reads the version management table from the non-volatile secure storage area of ​​the storage device, then retrieves the original record of the initial version from the version management table, modifies and supplements its associated information, without changing the original valid information, and changes the version status from active to valid, and supplements the reserved logical address corresponding to the version, that is, supplements the free reserved logical address newly mapped to the first physical address, while the original associated information such as version ID, physical address, and integrity check code / digital signature remains unchanged.

[0109] Furthermore, the memory controller creates a separate record for the updated version in the version management table and fills in complete associated information according to specifications, such as entering a unique version ID, entering the corresponding physical address (i.e., the actual address of the second physical address), and entering the integrity check code for the updated version. After completing the information modification of the initial version and the addition of information for the updated version, the memory controller rewrites the updated version management table into the non-volatile secure storage area.

[0110] Optionally, in some embodiments of this application, it may further include: If the current version of the bootloader fails to start, the version management table is queried. The version management table identifies a valid historical version as the target recovery version, and the logical address to physical address mapping table is updated according to the target recovery version to remap the startup logical address to the physical address corresponding to the target recovery version.

[0111] For example, after the device is powered on, the BootROM loads the currently active version of the bootloader and performs integrity / execution checks. If a boot failure is detected, a recovery trigger signal is sent to the memory controller. Upon receiving the signal, the memory controller suspends the current boot operation and initiates an autonomous recovery process, as follows: If the host system 10 detects that the bootloader of the currently active version has failed to start and sends a recovery trigger signal to the memory controller 210, the memory controller 210 will pause the current boot operation and initiate an autonomous recovery process upon receiving the signal. The memory controller 210 will read the version management table from the non-volatile secure storage area, filter out historical bootloader versions that are valid in the table, and form a list of valid candidate versions. Subsequently, the memory controller 210 will sort the valid historical versions in the candidate list according to their version identifiers, in descending order of version number, and select the version at the top of the list as the target recovery version. Extract the physical address corresponding to the target recovery version and verify its validity. After successful verification, the memory controller 210 enables atomic update mode for the logical physical address mapping table, modifies the physical address of the faulty version originally pointed to by the startup logical address to the physical address corresponding to the target recovery version, saves the mapping table non-volatilely after completing the mapping modification, and verifies the remapping result. After confirming that the remapping is effective, the memory controller 210 sends a restart command to the device. After the device is powered on again, it loads the bootloader of the target recovery version. If the recovery still fails, the memory controller 210 recursively executes the above process and selects the next valid version from the candidate list to continue trying.

[0112] It should be noted that before recovery, the memory controller retrieves the boot logical address that the host consistently accesses from the logical address to physical address mapping table. Simultaneously, it verifies the validity of the physical address of the target recovery version. After successful validity verification, the memory controller initiates an atomic update mode for the logical address to physical address mapping table. Then, it modifies the physical address of the faulty version, which was originally pointed to by the boot logical address, to the physical address corresponding to the target recovery version, completing the remapping of the boot logical address. Subsequently, the update result of the mapping table is verified by simulating host access to the boot logical address. If it is confirmed that the address correctly points to the physical address of the target recovery version and can normally read the bootloader data of that version, then the remapping operation is verified as successful.

[0113] After the memory controller completes the remapping validity verification, it sends a reboot command to the device. The device is then powered on again, and the BootROM loads the bootloader of the target recovery version via the boot logical address to achieve autonomous recovery. If this recovery still fails, the memory controller will recursively execute the above steps, selecting the next valid version from the candidate list to continue trying.

[0114] Optionally, in some embodiments of this application, the step "determining the historical version with a valid status in the version management table as the target recovery version" may specifically include: The bootloader versions are sorted according to their version identifiers, and the first valid historical version is selected as the target recovery version.

[0115] In some embodiments of this application, the version identifier sorting strategy sorts the version identifiers from largest to smallest according to their sequence number or value, such as sorting them in the order of V3, V2, V1. During version recovery, the memory controller sorts the valid historical versions in the above-mentioned basic dataset according to the version identifier descending order rule, generating an ordered list of valid version candidates. If the version identifiers of the valid historical versions are consecutive, they are directly sorted in descending order of the sequence number. If they are not consecutive, they are still sorted from highest to lowest according to the value of the identifier itself or the size of the sequence number. For example, if the valid versions are V2, V4, V5, the sorted version is V5, V4, V2. Furthermore, the memory controller selects the first valid historical version from the sorted list of valid version candidates as the target recovery version for this autonomous recovery.

[0116] In one embodiment, the step of determining a historically valid version in the version management table as the target recovery version further includes: reading the stability flag of each historically valid version in the version management table. Specifically, this stability flag is updated by the memory controller after each successful boot; if a version with the highest stability flag exists, that version is preferentially selected as the target recovery version; if the stability flags of all historically valid versions are the same, the latest version is selected as the target recovery version based on the version identifier. This makes the recovery strategy more compatible. If an older version has been stable for a long time, its stability flag will be high. In the event of a boot failure, rolling back to this "tested" version may be more reliable than rolling back to the latest historical version, avoiding a cycle of repeated boot failures.

[0117] Optionally, in some embodiments of this application, it may further include: In response to a version rollback command sent by the host, locate the target historical version in the version management table according to the version identifier corresponding to the version rollback command; Update the logical address to physical address mapping table, mapping the startup logical address to the physical address corresponding to the target historical version.

[0118] A version rollback command is a bootloader version precise rollback control command initiated by the host or remote maintenance terminal to the storage device's memory controller. It is a storage device extended command, such as CMD56 for eMMC, DeviceManagement Request for UFS, and Vendor Specific Command for NVMe, and is the core signal that triggers the storage device to perform a soft recovery. This version rollback command carries a target version identifier, which tells the memory controller to remap the boot logical address to the physical address corresponding to the specified historical version.

[0119] For example, specifically, the memory controller 210 receives a version rollback instruction sent by the host system 10 through the connection interface circuit 230. This instruction carries a target version identifier. The memory controller 210 reads the version management table from the non-volatile secure storage area, locates the corresponding target historical version in the table according to the target version identifier, and verifies the status information of the target version. After confirming that it is in a valid state, the memory controller 210 extracts the physical address corresponding to the target historical version and verifies the validity of the physical block to ensure that it stores complete bootloader target version data. Then, the memory controller 210 enables atomic update mode for the logical physical address mapping table, modifies the physical address of the currently active version that the startup logical address originally pointed to to the physical address corresponding to the target historical version, and after completing the mapping modification, non-volatilely saves the mapping table and verifies the update result to realize the fixed-point rollback of the bootloader version.

[0120] Next, the memory controller retrieves the host-accessible boot logical address from the logical address to physical address mapping table in the boot sector. Simultaneously, it verifies the validity of the physical address corresponding to the target historical version, confirming that the physical address stores complete bootloader target version data. Further, in atomic mode, the memory controller edits the logical address to physical address mapping table, changing the physical address of the currently active version, which was originally pointed to by the boot logical address, to the physical address corresponding to the target historical version.

[0121] In one embodiment, in response to a query command sent by the host system, the version management table is read; at least one of the following information—version identifier, status information, and write timestamp—of each version of the bootloader is packaged into response data in a preset format, and returned to the host system via a standard protocol. This provides a powerful diagnostic and management interface for the host side. The host can use a simple command to learn which bootloader versions are stored on the storage device, which is the currently used version, and which are historical versions. This is extremely valuable for remote operation and maintenance of data centers or embedded devices.

[0122] Optionally, in some embodiments of this application, the version management table is also used to record the digital signature information of each version of the bootloader, and the digital signature information is used for startup chain security verification.

[0123] Optionally, in some embodiments of this application, the version management table is also used to record at least one of the following: version identifier, integrity check code, and status information of each version of the bootloader.

[0124] Optionally, in some embodiments of this application, the version management table is stored in a non-volatile secure storage area of ​​the storage device, which is a dedicated system area of ​​the storage device for RPMB replay protected memory blocks.

[0125] Optionally, in some embodiments of this application, the logical address to physical address mapping table is a mapping table independently maintained by the boot area, and the logical address to physical address mapping table is isolated from the address mapping table of the user data area in the storage device.

[0126] Optionally, in some embodiments of this application, the reserved logical address range is located in the target address segment of the boot sector logical address space and does not respond to read / write requests initiated by the host through standard storage access commands. It should be noted that the reserved logical address range is not independent of the boot sector address space, but rather a dedicated target address segment specifically allocated by the memory controller within the overall boot sector logical address space. This target address segment can be set as a high address segment of the boot sector logical address space (e.g., above 0xFFF00000). This address segment is distinct from the boot logical address (e.g., 0x0000) that the host uses to access the bootloader; both are components of the boot sector logical address space and are exclusively managed by the memory controller, without occupying the address space of the user data area. Furthermore, the memory controller has implemented strict access permission configurations for this target address range, ensuring that it does not respond to any read or write requests initiated by the host through standard storage access commands. These standard storage access commands refer to the general read and write instructions defined by various types of storage device protocols, such as the standard read and write commands for SD / MMC, the general IO read and write commands for NVMe, and the standard storage access commands for UFS. From the host's perspective, this address range is equivalent to being invisible or unallocated. The host cannot identify, access, modify, or overwrite any data within this address range through normal operations, thus preventing the Bootloader's historical versions from being accidentally corrupted by the host.

[0127] Optionally, in some embodiments of this application, it may further include: When a version update instruction for the bootloader is received again, the new update version is written to the third physical address allocated by the memory controller; Update the logical address to physical address mapping table to map the startup logical address from the physical address corresponding to the current active version to the third physical address; Modify the mapping relationship between the physical address corresponding to the current active version and the logical address to physical address mapping table to reserve the free logical address within the reserved logical address range; Update the version management table to include the association information for each version of the bootloader.

[0128] In this scenario, the storage device has completed at least one bootloader version update. There is currently an active version (such as V2) and an archived historical version (such as V1). After receiving the update instruction through the storage device communication interface, the memory controller checks whether there are any available free physical addresses in the boot area and whether there are any free reserved logical addresses in the reserved logical address range. Only when all verifications pass and resources are sufficient will the subsequent update process be started; otherwise, the process will be terminated and the reason for the update failure will be reported back to the initiator.

[0129] The memory controller 210 allocates a new free physical address (i.e., a third physical address) for the new update version within the startup area of ​​the storage device. This third physical address is independent of the physical blocks of the current active version and historical versions. Subsequently, it receives the complete program data of the new update version, performs integrity verification on the data, and writes the data to the third physical address according to the flash memory storage rules. The writing process does not overwrite any existing physical blocks of the version. For details, please refer to the previous embodiments, which will not be repeated here.

[0130] To further understand the data update method of this application, the following will explain it from different scenarios, as follows: Please see Figure 3 , Figure 3 This is a schematic diagram of the overall process of the data update method provided in the embodiments of this application. The memory controller 210 constructs an independent logical-physical address (L2P) mapping table (hereinafter referred to as L2P mapping table) within the startup area of ​​the rewritable non-volatile memory module 220.

[0131] The memory controller 210 uses a hardware isolation mechanism to prevent user data operations of the host system 10 from interfering with the boot area mapping relationship. At the same time, the memory controller 210 divides the boot area logical address space into two types of logical address ranges: one is the boot logical address L_boot, which serves as the fixed entry point for the host to access the Bootloader; the other is the reserved logical address range L_reserved, which serves as the address range corresponding to the memory controller 210. This address range is configured not to respond to read and write requests initiated by the host system 10 through standard storage access commands, thus making it inaccessible to the host.

[0132] The memory controller 210 writes the body and field definitions of the L2P mapping table to a specified physical address in the startup area, thus completing the non-volatile storage of the L2P mapping table.

[0133] Within the boot area of ​​the rewritable non-volatile memory module 220, the memory controller 210 searches and selects the first free physical address as the first physical address, and writes the complete data of the initial version of the bootloader to the first physical address according to the physical programming rules of the eMMC flash memory. During the writing process, the data is cached through the buffer memory 214 and the data integrity is verified to ensure that the initial version data is not damaged.

[0134] After the verification is successful, the memory controller 210 establishes a one-to-one mapping relationship between the preset boot logic address L_boot and the first physical address in the constructed L2P mapping table, and completes the initial mapping configuration. The memory controller 210 non-volatilely stores the updated L2P mapping table to the boot area and completes the initial deployment of the bootloader. At this time, after the device is powered on, it can access the initial version in the first physical address through L_boot.

[0135] The memory controller 210 monitors the commands issued by the host system 10 in real time through the connection interface circuit 230, and continuously determines whether it has received a version update command for the bootloader. If no version update command is received, the memory controller 210 waits for commands or executes other regular commands of the storage device to maintain the current bootloader running state; if a version update command is received, it proceeds to step 4.

[0136] Within the startup area of ​​the rewritable non-volatile memory module 220, the memory controller 210 searches and selects free physical addresses without valid data and address conflicts as second physical addresses, without overwriting the initial version data already stored in the first physical address.

[0137] The memory controller 210 receives the Bootloader update data sent by the host system 10 through the connection interface circuit 230, caches the data in the buffer memory 214, and completes the data integrity verification and digital signature verification (in this embodiment, digital signature verification is a pre-security verification step, and subsequent writing can only be performed after the verification is passed). After the verification is passed, the memory controller 210 writes the update data block by block to the second physical address according to the block programming rules of the flash memory medium. After the writing is completed, the second physical address is read and written to verify that the data is written completely and without damage.

[0138] The memory controller 210 enables atomic update mode for the L2P mapping table, which avoids data corruption in the mapping table caused by power failure or abnormal interruption during the update process.

[0139] In atomic update mode, the memory controller 210 atomically remaps the mapping relationship of the boot logical address L_boot in the L2P mapping table from the first physical address to the second physical address, completing the pointer switching of the active version. After the mapping relationship is modified, the memory controller 210 stores the updated L2P mapping table non-volatilely and verifies the mapping result by simulating host access to L_boot, confirming that L_boot can correctly point to the second physical address and read the updated version data.

[0140] The memory controller 210 retrieves and filters out unallocated, unmapped free reserved logical addresses from the reserved logical address range L_reserved in the L2P mapping table.

[0141] Subsequently, the memory controller 210 re-enables the atomic update mode of the L2P mapping table, changing the mapping relationship of the first physical address in the L2P mapping table from the boot logical address L_boot to the free reserved logical address L_reserved, thereby releasing the binding relationship between the first physical address and L_boot and realizing the secure archiving of the initial version to the reserved logical address range. After archiving is completed, the memory controller 210 non-volatilely stores the updated L2P mapping table and verifies the mapping result to confirm that the first physical address is only inaccessible to the host, thus avoiding being mistakenly marked as an invalid data block by the flash translation layer (FTL).

[0142] The memory controller 210 locates the non-volatile secure storage area of ​​the rewritable non-volatile memory module 220 (in this embodiment, the RPMB replay protection memory block of eMMC is preferred), and reads the version management table (if the version management table has not been built, the table body creation and metadata writing operations are performed first).

[0143] In the version management table, the memory controller 210 updates the status information of the initial version of the Bootloader from "currently active" to "historically valid" and records the free reserved logical address L_reserved corresponding to the initial version. At the same time, it adds a mapping entry for the updated version of the Bootloader in the version management table, enters the version identifier, second physical address, integrity check code, digital signature information and other related data of the updated version, and sets the status information of the entry to "currently active".

[0144] After the update is completed, the memory controller 210 non-volatilely stores the updated version management table to the RPMB area, completing the synchronous update of the version management table and providing data basis for subsequent operations such as autonomous recovery from startup failure and version rollback.

[0145] After the memory controller 210 completes the update of the L2P mapping table and the version management table, it sends a restart command to the embedded device where the storage device is located, triggering the device to power on again. After the device powers on, the host boot firmware loads the updated version of the Bootloader in the second physical address through the boot logical address L_boot, so that the new version can take effect and run.

[0146] When the memory controller 210 receives the Bootloader version update instruction from the host system 10 again, the memory controller 210 allocates a free physical address (such as the third physical address) within the boot area range for the new version, writes the new version data and completes the verification; atomically remaps L_boot to the third physical address and switches the active version; modifies the mapping relationship of the current active version (original second physical address) to reserve the free L_reserved in the logical address range, completes the archiving, and then updates the status of the original active version to "historically valid", adds an "active" status entry for the new version and stores the relevant information.

[0147] Through the above iterative process, the embodiments of this application can realize unlimited version updates of the Bootloader. The number of versions is only limited by the total storage capacity of the rewritable non-volatile memory module 220, breaking through the traditional limitation on the number of fixed partitions.

[0148] Please see Figure 4 , Figure 4 This is a flowchart illustrating the Bootloader upgrade and secure archiving scenario provided in this application embodiment. The memory controller 210 receives a Bootloader version update instruction from the host system 10 through the connection interface circuit 230 of the storage device 20. The instruction includes information such as the version identifier of the new version V2, complete data, digital signature, and integrity check code. After the processor 211 of the memory controller 210 parses the instruction, it triggers the version update process, as follows: Within the startup area of ​​the rewritable non-volatile memory module 220, the processor 211 of the memory controller 210 determines a free physical address with no valid data and no address conflict, and allocates it as the second physical address PB2; PB2 does not overlap with PB1 where V1 is located.

[0149] The buffer memory 214 of the memory controller 210 temporarily caches the complete data of the new version V2. The processor 211 first performs data integrity verification (such as CRC32 verification), and then verifies the digital signature of V2 after the verification is passed. The memory interface control circuit 213 of the memory controller 210 writes the complete data of V2 into PB2 of the rewritable non-volatile memory module 220 block by block according to the physical programming rules of eMMC flash memory.

[0150] After the write is completed, the memory interface control circuit 213 of the memory controller 210 performs a readback check on PB2. The processor 211 compares the readback data with the V2 data cached in the buffer memory 214. After confirming that there is no write error, the memory controller 210 returns a status feedback of "new version write completed" to the host system 10 through the connection interface circuit 230.

[0151] The processor 211 of the memory controller 210 enables the atomic update mode for the L2P mapping table. In the atomic update mode, the processor 211 modifies the mapping relationship of the boot logic address L_boot in the L2P mapping table, remapping it from L_boot→PB1 (V1) to L_boot→PB2 (V2).

[0152] After the mapping relationship is modified, the memory interface control circuit 213 of the memory controller 210 writes the updated L2P mapping table into the specified physical block of the start area of ​​the rewritable non-volatile memory module 220 to complete the non-volatile saving, and the processor 211 turns off the atomic update mode.

[0153] The processor 211 simulates host access logic, reads the physical block data corresponding to L_boot, and confirms that the complete V2 data can be read correctly; then the memory controller 210 returns the status feedback of "active version switching completed" to the host system 10 through the connection interface circuit 230.

[0154] The processor 211 of the memory controller 210 retrieves the unallocated free reserved logical address L_reserved_1 from the reserved logical address range L_reserved pre-configured in the L2P mapping table; L_reserved is an address range exclusively managed by the memory controller 210 and is defaulted to not responding to standard read and write commands from the host system 10.

[0155] Processor 211 restarts the atomic update mode of the L2P mapping table, modifies the mapping relationship of PB1 in the L2P mapping table, that is, unbinds PB1 from L_boot and remaps it to L_reserved_1 (L_reserved_1→PB1(V1)). After the mapping is modified, the memory interface control circuit 213 of the memory controller 210 saves the updated L2P mapping table non-volatilely to the boot area of ​​the rewritable non-volatile memory module 220. The processor 211 disables the atomic update mode and verifies the mapping result: confirming that PB1 is only bound to L_reserved_1 and L_boot still stably points to PB2 (V2).

[0156] The memory interface control circuit 213 of the memory controller 210 locates the RPMB (Replay Protection Memory Block) secure storage area of ​​the rewritable non-volatile memory module 220 and reads the version management table.

[0157] Processor 211 updates the association information of V1 in the version management table: changing the status from "currently active" to "historically valid", and recording its associated reserved logical address L_reserved_1. At the same time, processor 211 adds a mapping entry for V2 in the version management table: entering information such as V2's version identifier, PB2 physical address, L_boot logical address, digital signature, integrity check code, etc., and setting the status to "currently active". The memory interface control circuit 213 of the memory controller 210 writes the updated version management table into the RPMB area of ​​the rewritable non-volatile memory module 220 to complete the non-volatile storage; then the memory controller 210 returns the final feedback "version upgrade + old version archiving completed" to the host system 10 through the connection interface circuit 230.

[0158] The processor 211 of the memory controller 210 sends a restart command to the device where the storage device 20 is located. After the device is powered on again, the boot firmware of the host system 10 loads version V2 of the rewritable non-volatile memory module 220PB2 through L_boot to enable the new version of the bootloader.

[0159] As can be seen, because the address range does not respond to standard host read and write commands, the old version is "invisible" to the host, and because it still holds a valid logical address mapping, it will not be mistakenly reclaimed by the FTL garbage collection mechanism. This fundamentally solves the "ghost backup" problem.

[0160] Please see Figure 5 , Figure 5 This is a schematic diagram of the autonomous deep recovery process after a startup failure provided in this application embodiment. Specifically, after the device is powered on, the BootROM inside the host system 10 starts to execute and initiates a Bootloader loading request to the storage device through the preset boot logic address L_boot. The request is transmitted to the memory controller 210 through the connection interface circuit 230.

[0161] The memory interface control circuit 213 of the memory controller 210 reads the complete data of the physical storage block PB2 where the currently active version (e.g., V2) is located in the rewritable non-volatile memory module 220 according to the mapping relationship of L_boot in the L2P mapping table, and caches it in the buffer memory 214. Then, the processor 211 of the memory controller 210 performs integrity verification (e.g., CRC32, SHA verification) and digital signature verification on the cached active version data, and monitors the version loading execution time. If the verification passes, the execution does not time out, and the version function is normal, the device starts successfully and the process ends. If the verification fails, the execution times out, or the version function is abnormal, the version anomaly detection process is entered.

[0162] In the event of a version anomaly, if the processor 211 of the memory controller 210 detects an abnormality in the loading / verification of the active version, it determines that the current active version is unavailable, triggers the autonomous deep recovery process, suspends the current startup operation, and enters the recovery logic execution stage. Specifically, the memory interface control circuit 213 of the memory controller 210 reads the version management table from the RPMB secure storage area of ​​the rewritable non-volatile memory module 220, loads all version records in the table into the buffer memory 214, and provides them to the processor 211 for parsing.

[0163] Processor 211 traverses the version management table, filters out all version records with the status "historically valid", excludes versions with the status "invalid" (such as data corruption, marked as obsolete), and forms a candidate list of valid historical versions (such as including versions V1, V0, etc.).

[0164] Next, the processor 211 sorts the list of valid historical version candidates according to a preset strategy. In this embodiment, the version number is sorted in descending order (i.e., the latest valid historical version is tried first). The valid historical version with the largest version number (such as V1) is placed at the top of the list. Then, the processor 211 extracts the physical storage block address (such as PB1) and reserved logical address corresponding to the version from the version management table to confirm that its physical storage block is valid and the data is complete in the rewritable non-volatile memory module 220.

[0165] Processor 211 enables atomic update mode for the L2P mapping table. In atomic update mode, it modifies the mapping relationship of L_boot in the L2P mapping table, atomically remapping it from the original active version physical block (PB2) to the physical storage block (PB1) corresponding to the target recovery version (V1). After the mapping modification is completed, memory interface control circuit 213 writes the updated L2P mapping table to the boot area of ​​rewritable non-volatile memory module 220. After saving, processor 211 disables atomic update mode. Then, memory controller 210 sends a restart command to the device, triggering the device to power on again and attempt to load the target recovery version (V1).

[0166] If the target recovery version (e.g., V1) still fails to load or verify after restarting, the memory controller 210 queries the version management table again, filters the remaining valid historical versions (e.g., V0), sorts them in descending order of version number, and selects the next first valid version as the new target recovery version. Then, it performs atomic remapping and restart operations until a valid historical version loads successfully, or all valid historical versions have been tried and all have failed (at which point a final alarm may be triggered or the system may enter minimum functional mode). This solves the "bricked" problem that traditional A / B systems cannot handle after two consecutive upgrade failures, achieving deep recovery.

[0167] In all the above application scenarios, the core operations involved, such as bootloader version switching, device state restoration, and function mode switching, are all implemented through a unified action of dynamic remapping of the boot logic address L_boot by the memory controller. The memory controller does not need to perform physical operations such as erasing, overwriting, or rewriting on the non-volatile storage medium. It only needs to modify the logical address to the physical address corresponding to the boot logic address L_boot in the physical address mapping table in atomic update mode to complete the rapid switching of the bootloader version. The entire operation is efficient and safe, and will not cause any damage to historical version data.

[0168] The above completes the data update process for this application.

[0169] As can be seen from the above, this application provides a data update method applied to a storage device. The storage device includes a memory controller and a non-volatile storage medium. The non-volatile storage medium has a boot area for storing a bootloader. After constructing a logical address to physical address mapping table in the boot area of ​​the storage device, the logical address to physical address mapping table is used to manage the boot logical address and retain the mapping relationship between the logical address range and the physical address. The initial version corresponding to the bootloader is written to a first physical address, and the preset boot logical address is mapped to the first physical address in the logical address to physical address mapping table. When a version update instruction for the bootloader is received, the updated version corresponding to the bootloader is written to a second physical address. Finally, the logical address to physical address mapping table is updated to map the boot logical address from the first physical address to the second physical address. In the data update scheme provided in this application, an independent logical address to physical address mapping table is constructed in the boot area. The updated version is written to the second physical block instead of overwriting the old block. It supports multiple iterative updates and maps the old version to the reserved logical address range, realizing the safe retention of multiple versions. This not only solves the problems of insufficient recovery depth and inability to cope with continuous upgrade failures, but also supports the fixed-point rollback of historical versions. At the same time, it can dynamically allocate physical addresses according to the actual version size of the bootloader, getting rid of the hard limit on the number of versions and greatly improving the utilization efficiency of storage space.

[0170] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0171] The data update method and storage device provided in the embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A data update method applied to a storage device, the storage device comprising a memory controller and a non-volatile storage medium, the non-volatile storage medium having a boot area for storing a bootloader, characterized in that, include: A logical address to physical address mapping table is constructed in the boot area of ​​the storage device. The logical address to physical address mapping table is used to manage the boot logical address and reserve the mapping relationship between the logical address range and the physical address. Write the initial version corresponding to the bootloader to the first physical address, and map the preset boot logical address to the first physical address in the logical address to physical address mapping table; When a version update instruction for the bootloader is received, the updated version corresponding to the bootloader is written to the second physical address; Update the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address.

2. The data update method according to claim 1, characterized in that, Also includes: The mapping relationship of the first physical address in the logical address to physical address mapping table is modified from the startup logical address to a reserved logical address in the reserved logical address range, so as to archive the initial version to the reserved logical address range.

3. The data update method according to claim 2, characterized in that, The step of modifying the mapping relationship of the first physical address in the logical address to physical address mapping table from the startup logical address to a reserved logical address within the reserved logical address range, so as to archive the initial version into the reserved logical address range, includes: Determine the unallocated free reserved logical addresses within the free reserved logical address range in the logical address to physical address mapping table; Modify the mapping entry corresponding to the first physical address from the startup logical address to the idle reserved logical address.

4. The data update method according to claim 2, characterized in that, Also includes: Detect the number of allocated reserved logical addresses within the reserved logical address range; When the number of allocated resources reaches the preset threshold, the version management table is queried to obtain the status information of the bootloader version corresponding to each reserved logical address. In the version management table, the reserved logical address corresponding to the version with an invalid status is marked as free; If no invalid version is found, the historical versions are sorted according to the version identifier in the version management table. Based on the sorting results, the mapping relationship between the earliest valid historical version of the version representation and the corresponding reserved logical address is removed, and the reserved logical address after removal is marked as free.

5. The data update method according to claim 4, characterized in that, Also includes: A version management table is constructed in the non-volatile secure storage area of ​​the storage device. The version management table is a dedicated management table independent of the logical address to physical address mapping table. The association information of each version of the bootloader is written into the version management table according to a preset format. The association information includes at least one of the physical address, reserved logical address, status information and security verification information corresponding to each version.

6. The data update method according to claim 2, characterized in that, After modifying the mapping relationship of the first physical address in the logical address to physical address mapping table from the startup logical address to a reserved logical address within the reserved logical address range, the method further includes: Update the version management table of the storage device with the association information of the initial version and the association information of the updated version of the bootloader.

7. The data update method according to claim 6, characterized in that, The update of the version management table of the storage device, which includes the association information of the initial version and the association information of the updated version of the bootloader, includes: In the version management table of the storage device, the reserved logical address corresponding to the initial version of the bootloader is updated to the modified reserved logical address, and the status information corresponding to the initial version is updated to the historical valid status. Add a mapping entry corresponding to the updated version to the version management table of the storage device, and set the status information of the updated version to the current active status; The updated version management table is stored in the non-volatile storage medium.

8. The data update method according to claim 7, characterized in that, Also includes: If the bootloader of the current active version fails to start, then query the version management table. In the version management table, a version with a historically valid status is identified as the target recovery version. The logical address to physical address mapping table is then updated based on the target recovery version to remap the boot logical address to the physical address corresponding to the selected target recovery version.

9. The data update method according to claim 8, characterized in that, The step of determining the historical version with a valid status in the version management table as the target recovery version includes: Based on the version identifiers of each version of the bootloader, the historical valid versions are sorted in descending order of version number, and the version at the top of the sort is selected as the target recovery version.

10. The data update method according to claim 6, characterized in that, Also includes: In response to a version rollback command sent by the host, the corresponding target historical version is located in the version management table according to the target version identifier indicated by the version rollback command; Update the logical address to physical address mapping table, and remap the startup logical address to the physical address corresponding to the target historical version.

11. The data update method according to claim 6, characterized in that, The version management table is also used to record the digital signature information of each version of the bootloader, and the digital signature information is used for secure boot chain security verification.

12. The data update method according to claim 6, characterized in that, The version management table also records at least one of the following: version identifier, integrity check code, and status information for each version of the bootloader.

13. The data update method according to claim 6, characterized in that, The version management table is stored in the non-volatile secure storage area of ​​the storage device, which is a replay-protected memory block or a dedicated system area of ​​the storage device.

14. The data update method according to claim 1, characterized in that, The logical address to physical address mapping table is a mapping table independently maintained by the boot area, and the logical address to physical address mapping table is isolated from the address mapping table of the user data area in the storage device.

15. The data update method according to claim 1, characterized in that, The reserved logical address range is located in a specified address segment within the boot zone logical address space and is configured not to respond to read / write requests initiated by the host system through standard storage access commands.

16. The data update method according to claim 1, characterized in that, Also includes: When a version update instruction for the bootloader is received again, the new update version is written to the third physical address allocated by the memory controller; Update the logical address to physical address mapping table, and map the startup logical address from the physical address corresponding to the current active version to the third physical address; Modify the mapping relationship between the physical address corresponding to the current active version and the logical address to physical address mapping table to an idle reserved logical address within the reserved logical address range; Update the version management table, change the status of the current active version to a historical valid status, and create a corresponding record for the new updated version.

17. The data update method according to claim 1, characterized in that, After updating the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address, the method further includes: Initiate a restart operation on the storage device to enable the updated version of the bootloader.

18. The data update method according to claim 1, characterized in that, Before updating the logical address to physical address mapping table to map the boot logical address from the first physical address to the second physical address, the method further includes: Verify the updated digital signature information; If the verification passes, the logical address to physical address mapping table is updated to map the startup logical address from the first physical address to the second physical address.

19. A storage device, characterized in that, include A connection interface for electrically connecting to a host system; Memory module and; The memory controller includes a processor, a data management circuit, a memory interface control circuit, and a buffer memory, and is electrically connected to the connection interface and the memory module. The memory controller is configured to perform the data update method as described in any one of claims 1 to 18.

Images