A solid state drive firmware architecture system

Abstract

The application discloses a solid state disk firmware architecture system, comprising: a plurality of drive modules, each of the drive modules corresponding to a storage particle type, and the plurality of drive modules being sequentially stored in a non-volatile memory and sharing a same preset running memory address segment at runtime; a hardware identification module for acquiring type information of a storage particle carried by a current solid state disk at a firmware starting stage; and a loading management module connected with the hardware identification module and the non-volatile memory, loading the target drive module from the non-volatile memory to the preset running memory address segment for calling by a firmware main program. Thus, by using firmware normalization, only one unified firmware image needs to be maintained, different NAND / DRAM particle combinations are adapted by loading different Overlay drive modules, the number of firmware versions is greatly reduced, and management complexity is reduced.

Description

Technical Field

[0001] This invention relates to the field of hardware storage system technology, and more particularly to a solid-state drive firmware architecture system. Background Technology

[0002] Solid-state drive (SSD) firmware needs to support various NAND Flash storage chips and DRAM cache chips to meet the needs of different markets and application scenarios. Currently, SSD firmware typically employs two management methods for different NAND / DRAM chip combinations: Method 1 involves compiling a separate firmware image for each NAND / DRAM chip combination. This results in a large number of firmware versions, requiring the maintenance of multiple code branches, exponentially increasing development and testing workload, and making firmware management extremely complex. Method 2 involves selecting and loading different driver code within the firmware through conditional compilation or runtime configuration. While this reduces the number of firmware versions, the code is filled with numerous conditional branches, resulting in a chaotic code structure, poor maintainability, and the mixing of code for different chip configurations, increasing firmware complexity and potential instability. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a solid-state drive firmware architecture system that utilizes compiler overlay technology to achieve dynamic loading of multiple NAND / DRAM chip drivers, thereby achieving unified firmware management and reducing software management complexity.

[0004] The objective of this invention is achieved through the following technical solution:

[0005] This application discloses a solid-state drive firmware architecture system, comprising: multiple driver modules, each driver module corresponding to a type of storage chip and independently compiled into an image file; the multiple driver modules are sequentially stored in non-volatile memory and share the same preset running memory address segment during runtime; a hardware identification module, used to obtain the type information of the storage chip currently installed in the solid-state drive during the firmware startup phase; and a loading management module, connected to the hardware identification module and the non-volatile memory, used to select a corresponding target driver module from the multiple driver modules according to the type information, and load the target driver module from the non-volatile memory into the preset running memory address segment for use by the firmware main program.

[0006] Furthermore, the preset runtime memory address segment corresponds to a continuous physical address range in system memory with a fixed starting address and a fixed length; each of the plurality of driver modules is specified at compile time to use the same continuous physical address range as its runtime load address; each time the load management module loads, it only reads the binary image data of the selected target driver module from the non-volatile memory and writes it into the continuous physical address range to overwrite the previously stored data content in the address range, and at the same time, only the binary image data of any one driver module resides in the continuous physical address range.

[0007] Furthermore, each of the multiple driver modules occupies a preset fixed-capacity storage block in the non-volatile memory. The fixed capacity of the storage block occupied by any driver module is equal to the actual data length of the binary image file generated after compilation, rounded up to an integer multiple of the minimum storage unit capacity. The storage blocks of each driver module are arranged sequentially according to a preset order, and the ending physical address of the storage block of the previous driver module is adjacent to the starting physical address of the storage block of the next driver module. The loading management module calculates the storage starting address of the target driver module in the non-volatile memory based on the sequence number of the target driver module in the preset order and the fixed capacity.

[0008] Furthermore, the plurality of driving modules include at least one NAND Flash driving module and at least one DRAM driving module; the binary image file of the NAND Flash driving module contains at least two of the following: code for implementing NAND Flash initialization operations, code for implementing NAND Flash read / write control operations, code for implementing NAND Flash bad block management operations, and code for implementing NAND Flash ECC error correction operations; the binary image file of the DRAM driving module contains at least one of the following: code for implementing DRAM initialization operations and code for implementing DRAM refresh control operations; and the NAND Flash driving module and the DRAM driving module are stored as independent binary image files in the non-volatile memory, and each responds to the independent loading operation of the loading management module.

[0009] Furthermore, the firmware main program resides in system memory and is used to perform flash memory conversion layer management operations, garbage collection operations, wear leveling operations, and error handling operations. The firmware main program has a set of function pointers, which includes at least a pointer to a memory chip read operation function, a pointer to a memory chip write operation function, and a pointer to a memory chip erase operation function. The memory chip operation instructions in the firmware main program are issued through the set of function pointers to call the corresponding function in the target driver module currently residing in the preset running memory address range.

[0010] Furthermore, the binary image file of the target driver module also includes a function export table, which records the correspondence between the function symbols of each function provided by the target driver module and their relative offset addresses in the preset runtime memory address segment. After loading the target driver module into the preset runtime memory address segment, the loading management module is also used to read the function export table and, according to the records in the function export table, update the pointer values ​​of the group of function pointers in the firmware main program to the actual physical addresses of each function in the system memory, so as to establish a runtime call link between the firmware main program and the target driver module.

[0011] Furthermore, it also includes a particle configuration table, which is pre-stored in a preset system reserved storage area in the non-volatile memory; each record in the particle configuration table includes at least a storage particle type identifier field and a driver module storage address offset field; after obtaining the type information of the storage particles currently installed on the solid-state drive, the hardware identification module compares the obtained type information with the storage particle type identifier field of each record in the particle configuration table. When the comparison matches, it reads the value of the driver module storage address offset field in that record and transmits the value to the loading management module; the loading management module determines the storage start position of the target driver module in the non-volatile memory based on the received value of the driver module storage address offset field.

[0012] Furthermore, the type information of the storage chips obtained by the hardware identification module includes the supplier identifier and device identifier of the NAND Flash chip, as well as the supplier identifier and device identifier of the DRAM chip. The hardware identification module completes the acquisition of the type information by sending a NAND Flash read ID instruction sequence to the NAND Flash chip interface and receiving the first identifier data returned by the NAND Flash chip, and sending a DRAM mode register read instruction sequence to the DRAM chip interface and receiving the second identifier data returned by the DRAM chip.

[0013] Furthermore, after the loading management module completes the loading of the target driver module and the function pointer redirection operation, the firmware main program performs interface timing configuration and internal register initialization on the NAND Flash chip by calling the function corresponding to the NAND Flash initialization function in the target driver module; and performs mode register configuration and impedance calibration on the DRAM chip by calling the function corresponding to the DRAM initialization function in the target driver module; after completing the initialization configuration of the NAND Flash chip and the DRAM chip, the firmware main program further performs metadata reconstruction of the flash conversion layer, recovery of the logical address to physical address mapping table, and puts the solid-state drive into a command-ready state to respond to read and write commands from the host.

[0014] The beneficial effects of this invention are as follows: Firmware normalization requires maintaining only a single, unified firmware image. By loading different Overlay driver modules, different NAND / DRAM chip combinations can be adapted, significantly reducing the number of firmware versions and management complexity. The code structure is clear, with the general firmware base and chip driver code completely separated, resulting in a well-defined code hierarchy that is easy to read and maintain. Development efficiency is improved; when adding support for a new chip type, only the corresponding Overlay driver module needs to be developed, without modifying the general firmware base code or recompiling the entire firmware. Testing costs are reduced; the general firmware base only needs to be tested once, while the chip driver can be tested independently, and test cases can be reused. Firmware upgrades are flexible, allowing for upgrades of either the general base or specific chip driver modules, providing a more flexible upgrade strategy while reducing the size of the upgrade package. Scalability is strong; when adding support for new chip models, no modification to existing code is required, only the corresponding Overlay driver module needs to be developed. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall architecture of a solid-state drive firmware architecture system according to some embodiments of this application;

[0016] Figure 2 This is a document based on the overlay column as a whole according to an embodiment of this application;

[0017] Figure 3 This describes the data loading process according to embodiments of this application;

[0018] Figure 4 This is a flowchart illustrating the firmware boot process according to an embodiment of this application. Detailed Implementation

[0019] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Before we begin, let's explain some technical terms:

[0021] Overlay technology is a code organization method provided by the compiler, allowing a program to be divided into multiple independent code segments. These segments can share the same memory space. When an overlay driver module is called, it is loaded into the shared memory area, overwriting (overlaying) the previous content. In this invention, the universal firmware base serves as the main program (root) resident in memory, while different flash memory drivers are stored as overlay driver modules in specific areas of the NAND Flash. During firmware startup, the universal base is first loaded and run. After identifying the flash memory type, the corresponding overlay driver module is dynamically loaded into a preset memory area. After initialization, subsequent firmware processes continue.

[0022] Firmware root program is the main program part of the solid-state drive firmware that resides in system memory, does not change with the type of storage chips, and is used to perform core management functions such as flash translation layer (FTL), garbage collection, and wear leveling.

[0023] The Flash Translation Layer (FTL) is the core management layer in the firmware main program. It is responsible for translating the logical addresses sent by the host into physical addresses on the NAND Flash storage chips and managing the persistence and restoration of the address mapping table.

[0024] The solid-state drive firmware architecture system according to an embodiment of this application includes: multiple driver modules, each driver module corresponding to a type of storage chip and independently compiled into an image file; the multiple driver modules are sequentially stored in non-volatile memory and share the same preset running memory address segment during runtime; a hardware identification module, used to obtain the type information of the storage chip currently mounted on the solid-state drive during the firmware startup phase; and a loading management module, connected to the hardware identification module and the non-volatile memory, used to select a corresponding target driver module from the multiple driver modules according to the type information, and load the target driver module from the non-volatile memory into the preset running memory address segment for use by the firmware main program.

[0025] For clarity, the description of the embodiments of this application will be further explained in conjunction with the accompanying drawings.

[0026] refer to Figure 1 The firmware main program is mounted on a universal firmware base (i.e., ROOT) and includes several core functional modules, such as a management layer (e.g., FTL), garbage collection mechanism, wear leveling algorithm, error handling module, Wear Level, bad block management, and function call interface. The firmware main program code is shared by all flash memory chips and does not change with the chip model. The universal firmware base connects to the NAND / DRAM operation interface layer (which is a unified abstract interface for function pointers), then communicates with the dynamic loading manager, the hardware identification module, and finally with the NAND Flash storage area. The NAND Flash storage area is configured with modules such as TLC driver module Overlay_001, MLC driver module Overlay_002, SLC driver module Overlay_003, DDR4 driver module Overlay_004, LPDDR4 driver module, and Overlay_005. As mentioned earlier, the multiple driver modules described in this embodiment are Overlay driver modules. Independent driver modules are developed for each type of NAND flash chip and DRAM flash chip. Each driver module is compiled into an independent Overlay image file, including NAND Flash initialization driver, read / write control driver, bad block management driver, ECC error correction driver, DRAM initialization driver, DRAM refresh control driver, etc.

[0027] Each driver module operates within the same address range, let's call it region A, but each module's memory address is different, allowing for a compact arrangement. (Reference) Figure 2As shown, the general base firmware is the main program code, and the driver code for other DRAM and NAND, such as the init code sec (including int code DRAM Type 0-LTR code), NAND driver (including NADA Type 0, NADA Type 1, etc.), are compactly arranged into a whole file using overlay technology. This file is stored in flash and will be read and loaded in subsequent loading processes.

[0028] During the firmware boot phase, the hardware identification module reads the ID information of the NAND / DRAM chips (such as Manufacturer ID and Device ID) and matches it with a pre-stored chip configuration table to determine the type of chips used by the current hardware. The load management module, based on the chip identification result, loads the corresponding Overlay driver module from a predefined storage location (such as a specific Flash region) to a preset memory address (i.e., region A), and completes linking work such as function pointer redirection, enabling the general firmware base to correctly call the chip-specific driver. Furthermore, after power-on with the NAND DRAM type configured for mass production, the loader is pre-loaded. After PFW initialization, the Init code sec can be switched to LTR (long-term resident) code; and a compilation script is used to package drivers of various types into a single firmware package. Figure 3 As shown in the loading process, the main code is loaded into a fixed location within the code execution area, while the DRAM and NAND drivers load the necessary parts to their corresponding locations as needed. The firmware version management table stores firmware version information and a list of supported flash memory types in a fixed location within the Flash memory, facilitating the identification of compatible flash memory configurations during firmware upgrades.

[0029] In this embodiment, the non-volatile memory refers to a specific reserved area within the NAND Flash memory array inside the solid-state drive (SSD) used to store firmware images and configuration data. Alternatively, NOR Flash or other types of non-volatile storage media can be used. The preset runtime memory address segment refers to a pre-allocated contiguous physical address space with a fixed starting address and fixed length in system memory (such as the SRAM inside the SSD controller or external DRAM). This address space is designed as a shared coverage area for multiple driver modules. The storage particles refer to the NAND Flash storage particles and DRAM cache particles used in the SSD. The image file refers to the binary object file generated by compiling and linking the driver module source code, which can be directly loaded into memory for execution. The hardware identification module refers to the functional logic unit responsible for reading the storage particle identification information and determining the particle model during the firmware boot process. The loading management module refers to the functional logic unit responsible for moving the corresponding driver module binary data from the non-volatile memory to the preset runtime memory address segment based on the identification result and completing the runtime linking.

[0030] In some embodiments, the preset runtime memory address segment corresponds to a continuous physical address range in system memory with a fixed starting address and a fixed length; each of the plurality of driver modules is specified at compile time to use the same continuous physical address range as its runtime load address; each time the load management module loads, it only reads the binary image data of the selected target driver module from the non-volatile memory and writes it into the continuous physical address range to overwrite the previously stored data content in the address range, and at the same time, only the binary image data of any one driver module resides in the continuous physical address range.

[0031] To efficiently locate and load the required driver modules, each of the multiple driver modules occupies a preset fixed-capacity storage block in the non-volatile memory. The fixed capacity of the storage block occupied by any driver module is equal to the actual data length of its compiled binary image file, rounded up to an integer multiple of the minimum storage unit capacity. The storage blocks of each driver module are arranged sequentially according to a preset order, and the ending physical address of the storage block of the previous driver module is adjacent to the starting physical address of the storage block of the next driver module. The loading management module calculates the starting address of the target driver module in the non-volatile memory based on the sequence number of the target driver module in the preset order and the fixed capacity. Referring to Tables 1 and 2, each overlay driver module is stored in Flash in a fixed order, and each driver module has a fixed size (e.g., 4KB) for easy addressing. The firmware version management table records the supported particle types and driver versions. The particle configuration table establishes a mapping between particle IDs and driver module addresses. The overlay area in RAM is shared, and only one particle driver is loaded at a time.

[0032] Table 1 shows the Flash storage space layout as follows:

[0033]

[0034] Table 2 shows the RAM runtime space layout as follows:

[0035]

[0036] The plurality of driver modules include at least one NAND Flash driver module and at least one DRAM driver module; the binary image file of the NAND Flash driver module contains at least two of the following: code for implementing NAND Flash initialization operations, code for implementing NAND Flash read / write control operations, code for implementing NAND Flash bad block management operations, and code for implementing NAND Flash ECC (Error Correction Operation). The binary image file of the DRAM driver module contains at least one of the following: code for implementing DRAM initialization operations and code for implementing DRAM refresh control operations. Furthermore, the NAND Flash driver module and the DRAM driver module are stored as independent binary image files in the non-volatile memory and respond to independent loading operations of the loading management module, respectively.

[0037] In this embodiment, the firmware main program resides in system memory and is used to perform flash memory conversion layer management operations, garbage collection operations, wear leveling operations, and error handling operations. The firmware main program has a pre-defined set of function pointers, which includes at least pointers to memory chip read operation functions, memory chip write operation functions, and memory chip erase operation functions. Memory chip operation instructions in the firmware main program are issued through these function pointers to call the corresponding function within the target driver module currently residing in the pre-defined running memory address range. The general firmware base does not contain any chip-specific code; it calls the chip driver through the function pointer interface, achieving true normalized management. The NAND / DRAM operation interface layer is a unified function pointer abstraction and does not contain any chip-specific code.

[0038] Furthermore, in order to correctly establish the link between the firmware main program and the dynamically loaded driver module at runtime, the binary image file of the target driver module also includes a function export table. The function export table records the correspondence between the function symbols of each function provided by the target driver module and their relative offset addresses in the preset runtime memory address segment. After loading the target driver module into the preset runtime memory address segment, the loading management module is also used to read the function export table and, according to the records in the function export table, update the pointer values ​​of the group of function pointers in the firmware main program to the actual running physical addresses of each function in the system memory, so as to establish a runtime call link between the firmware main program and the target driver module.

[0039] To achieve automatic identification of the storage type, the solid-state drive firmware architecture system of this application embodiment further includes a storage type configuration table, which is pre-stored in a preset system reserved storage area in the non-volatile memory. Each record in the storage type configuration table includes at least a storage type identifier field and a driver module storage address offset field. After obtaining the type information of the storage type currently installed in the solid-state drive, the hardware identification module compares the obtained type information with the storage type identifier field of each record in the storage type configuration table. When the comparison matches, the module reads the value of the driver module storage address offset field in that record and transmits the value to the loading management module. The loading management module determines the starting storage position of the target driver module in the non-volatile memory based on the received value of the driver module storage address offset field.

[0040] Specifically, the type information of the storage chips acquired by the hardware identification module includes the supplier identifier and device identifier of the NAND Flash chip, as well as the supplier identifier and device identifier of the DRAM chip. The hardware identification module acquires the type information by sending a NAND Flash read ID instruction sequence to the NAND Flash chip interface and receiving the first identifier data returned by the NAND Flash chip, and by sending a DRAM mode register read instruction sequence to the DRAM chip interface and receiving the second identifier data returned by the DRAM chip. Figure 4 The firmware boot flowchart shows the complete process from firmware power-on to completion of particle driver loading, which includes:

[0041] First, a power-on reset is performed. After power-on, basic hardware initialization is performed. Then, the general firmware base (Root program) is loaded. The NAND and DRAM chip IDs are read. The matching driver is searched in the chip configuration table. If the corresponding driver is found, the corresponding Overlay driver module is loaded. After the function pointer binding is completed, firmware initialization continues. Otherwise, an error is reported and the program exits, indicating that magnetic chips are not supported.

[0042] Finally, in the complete initialization process of this embodiment, after the loading management module completes the loading of the target driver module and the function pointer redirection operation, the firmware main program performs interface timing configuration and internal register initialization on the NAND Flash chip by calling the function corresponding to the NAND Flash initialization function in the target driver module; and performs mode register configuration and impedance calibration on the DRAM chip by calling the function corresponding to the DRAM initialization function in the target driver module; after completing the initialization configuration of the NAND Flash chip and the DRAM chip, the firmware main program further performs metadata reconstruction of the flash conversion layer, recovery of the logical address to physical address mapping table, and puts the solid-state drive into a command-ready state to respond to read and write commands from the host.

[0043] It is understood that the solid-state drive firmware architecture system described in this application adopts firmware normalization, requiring only the maintenance of a unified firmware image. By loading different Overlay driver modules, it adapts to different NAND / DRAM chip combinations, greatly reducing the number of firmware versions and management complexity. The code structure is clear, with the general firmware base and chip driver code completely separated, resulting in a clear code hierarchy that is easy to read and maintain. Development efficiency is improved; when adding support for a new chip type, only the corresponding Overlay driver module needs to be developed, without modifying the general firmware base code or recompiling the entire firmware. Testing costs are reduced; the general firmware base only needs to be tested once, while the chip driver can be tested independently, and test cases can be reused. Firmware upgrades are flexible, allowing for upgrades of only the general base or only the driver module of a specific chip, providing a more flexible upgrade strategy while reducing the size of the upgrade package. It has strong scalability; when adding support for a new chip model, no modification to the existing code is required, only the corresponding Overlay driver module needs to be developed.

[0044] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A solid-state drive firmware architecture system, characterized in that: include: Multiple driver modules, each corresponding to a storage particle type, are independently compiled into image files. The multiple driver modules are stored sequentially in non-volatile memory and share the same preset running memory address segment during runtime. The hardware identification module is used to obtain the type information of the storage chips currently installed in the solid-state drive during the firmware boot phase; And a loading management module, which connects the hardware identification module and the non-volatile memory, is used to select the corresponding target driver module from the plurality of driver modules according to the type information, and load the target driver module from the non-volatile memory into the preset running memory address segment for the firmware main program to call; The preset running memory address segment corresponds to a continuous physical address range in the system memory with a fixed starting address and a fixed length; Each of the plurality of driver modules is specified at compile time to use the same continuous physical address range as its runtime load address; each time the load management module loads, it reads only the binary image data of the selected target driver module from the non-volatile memory and writes it into the continuous physical address range to overwrite the previously stored data content in the address range, and at the same time, only the binary image data of any one driver module resides in the continuous physical address range. The plurality of driver modules each occupy a storage block of a preset fixed capacity in the non-volatile memory. The fixed capacity of the storage block occupied by any driver module is equal to the actual data length of the binary image file generated after compilation, rounded up to an integer multiple of the minimum storage unit capacity. The storage blocks of each driver module are arranged in a preset order, and the ending physical address of the storage block of the previous driver module is adjacent to the starting physical address of the storage block of the next driver module. The loading management module calculates the storage starting address of the target driver module in the non-volatile memory based on the sequence number of the target driver module in the preset order and the fixed capacity.

2. The solid-state drive firmware architecture system according to claim 1, characterized in that, The plurality of driving modules include at least one NAND Flash driving module and at least one DRAM driving module; The binary image file of the NAND Flash driver module contains at least two of the following: code for implementing NAND Flash initialization operations, code for implementing NAND Flash read / write control operations, code for implementing NAND Flash bad block management operations, and code for implementing NAND Flash error correction operations. The binary image file of the DRAM driver module contains at least one of the code for implementing DRAM initialization operations and the code for implementing DRAM refresh control operations. Furthermore, the NAND Flash driver module and the DRAM driver module are stored as independent binary image files in the non-volatile memory, and each responds to the independent loading operation of the loading management module.

3. The solid-state drive firmware architecture system according to claim 1, characterized in that, The firmware main program resides in the system memory and is used to perform flash memory conversion layer management operations, garbage collection operations, wear leveling operations, and error handling operations. The firmware main program has a set of function pointers pre-defined. The set of function pointers includes at least a pointer to the storage chip read operation function, a pointer to the storage chip write operation function, and a pointer to the storage chip erase operation function. The storage granule operation instructions in the firmware main program are issued through the set of function pointers to call the corresponding function in the target driver module currently residing in the preset running memory address segment.

4. The solid-state drive firmware architecture system according to claim 3, characterized in that, The binary image file of the target driver module also includes a function export table, which records the correspondence between the function symbols of each function provided by the target driver module and their relative offset addresses in the preset running memory address segment; After loading the target driver module into the preset running memory address segment, the loading management module is also used to read the function export table and, according to the record content in the function export table, update the pointer values ​​of the group of function pointers in the firmware main program to the actual running physical address of each function in the system memory, so as to establish a runtime call link between the firmware main program and the target driver module.

5. The solid-state drive firmware architecture system according to claim 3, characterized in that, It also includes a granular configuration table, which is pre-stored in a preset system reserved storage area in the non-volatile memory; Each record in the particle configuration table contains at least a storage particle type identifier field and a driver module storage address offset field; After obtaining the type information of the storage chips currently installed in the solid-state drive, the hardware identification module compares the obtained type information with the storage chip type identifier field of each record in the chip configuration table. When the comparison matches, it reads the value of the driver module storage address offset field in that record and transmits the value to the loading management module. The loading management module determines the starting storage location of the target driver module in the non-volatile memory based on the value of the received driver module storage address offset field.

6. The solid-state drive firmware architecture system according to claim 3, characterized in that, The type information of the storage chip obtained by the hardware identification module includes the supplier identifier and device identifier of the NAND Flash chip, as well as the supplier identifier and device identifier of the DRAM chip. The hardware identification module acquires the type information by sending a NAND Flash read ID instruction sequence to the NAND Flash chip interface and receiving the first identification data returned by the NAND Flash chip, and by sending a DRAM mode register read instruction sequence to the DRAM chip interface and receiving the second identification data returned by the DRAM chip.

7. The solid-state drive firmware architecture system according to claim 3, characterized in that, After the loading management module completes the loading of the target driver module and the function pointer redirection operation, the firmware main program calls the function corresponding to the NAND Flash initialization function in the target driver module to perform interface timing configuration and internal register initialization of the NAND Flash chip. By calling the function corresponding to the DRAM initialization function in the target driver module, the mode register configuration and impedance calibration of the DRAM chip are performed. After completing the initial configuration of the NAND Flash and DRAM chips, the firmware master program further performs metadata reconstruction of the flash conversion layer, restoration of the logical address to physical address mapping table, and puts the solid-state drive into a command-ready state to respond to read and write commands from the host.

Images