Parallel boot execution of memory devices

Abstract

The present disclosure as a whole relates to reducing boot delays for memory devices in dual boot systems. Boot code is loaded into a data storage device controller in a flexible manner by being able to receive blocks of boot code from two separate locations, a host memory buffer (HMB) and a memory device that can be a NAND device. A portion of the boot code can be received from the HMB, and another portion of the boot code can be received from the memory device. If the HMB or the memory device can transfer blocks faster than the other location, the controller can receive blocks from the faster location and periodically confirm the transfer speed to ensure that the boot code delay is optimized.

Description

Background Art Technical Field

[0002] Embodiments of the present disclosure are generally directed to reducing boot delays for memory devices in dual boot systems.

[0003] Description of Related Art

[0004] The startup process of a computing system is generally referred to as booting. During the boot procedure, a specified code is loaded into a processing unit located at a memory device controller in order to initiate a wake-up procedure for a data storage device. The duration of the boot is an important factor for consumers, and the time for the controller to load the boot code from an external location storing the boot code can be highly valued to allow the overall boot duration requirements to be met.

[0005] For NAND-based memory devices, the default storage location for the boot code is in the NAND memory itself. However, the NVMe standard provides an alternative option based on which a host device DRAM partition (i.e., a portion of the host DRAM allocated for data storage devices) can be used to store the boot code. When the host DRAM is used for boot code storage, the DRAM partition is called a host memory buffer (HMB).

[0006] Currently, the boot process is performed by starting the boot from a single location (NAND or HMB). Both NAND and HMB have their own advantages and disadvantages. For NAND, NAND is usually available before HMB, and parallel sensing can be performed on multiple dies, but the sensing time may be adversely affected. For HMB, there is high throughput, and in some cases, HMB may be available before NAND, but HMB is not always available at boot time, which depends on the host device and a link to the host device must be available.

[0007] Therefore, there is a need in the art for a boot program that accelerates the boot process by utilizing the advantages of both NAND and HMB. Summary of the invention

[0008] The present disclosure as a whole relates to reducing boot delays for memory devices in dual boot systems. Boot code is loaded into a data storage device controller in a flexible manner by being able to receive blocks of boot code from two separate locations, a host memory buffer (HMB) and a memory device that can be a NAND device. A portion of the boot code can be received from the HMB, and another portion of the boot code can be received from the memory device. If the HMB or the memory device can transfer blocks faster than the other location, the controller can receive blocks from the faster location and periodically confirm the transfer speed to ensure that the boot code delay is optimized.

[0009] In one embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive a boot code block of boot code from a host device; and receive a boot code block of boot code from the one or more memory devices.

[0010] In another embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive boot code blocks of boot code from both a host device and the one or more memory devices; confirm that all boot code blocks have been received; confirm an authentication signature of the boot code; determine whether the boot code block is invalid; determine whether the invalid boot code block is from the host device or from the one or more memory devices; and receive a valid boot code block from either the host device or the one or more memory devices that did not deliver an invalid boot code block.

[0011] In another embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive a boot code block of boot code from the one or more memory devices or a host device; receive a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices are booted; and determine whether an average delay for receiving boot code from the one or more memory devices is different from an average delay for receiving boot code from the host device. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Thus, a detailed understanding of the manner in which the above-described features of the present disclosure are understood, a more particular description of the present disclosure, the above brief overview, may be obtained by reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical embodiments of the present disclosure and are therefore not to be considered limiting of its scope, as the present disclosure may admit to other equally effective embodiments.

[0013] Figure 1 is a schematic diagram of a data storage system according to one embodiment.

[0014] Figure 2 is a schematic diagram of a dual-boot process according to one embodiment.

[0015] Figure 3A is a flow chart illustrating a boot process according to one embodiment.

[0016] Figure 3Bis a flow chart illustrating a boot process according to another embodiment.

[0017] Figure 4 is a flow chart illustrating a boot process according to another embodiment.

[0018] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0019] Hereinafter, reference is made to the embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the embodiments specifically described. On the contrary, any combination of the following features and elements (whether or not related to different embodiments) is considered to realize and practice the present disclosure. In addition, although the embodiments of the present disclosure can achieve advantages that are superior to other possible solutions and / or superior to the prior art, whether a specific advantage is achieved by a given embodiment is not a limitation to the present disclosure. Therefore, the following aspects, features, embodiments and advantages are merely illustrative, and are not considered to be elements or limitations of the appended claims, unless explicitly stated in the claims. Similarly, reference to "the present disclosure" should not be interpreted as a summary of any inventive subject matter disclosed herein, and should not be considered to be elements or limitations of the appended claims, unless explicitly stated in the claims.

[0020] The present disclosure as a whole relates to reducing boot delays for memory devices in dual boot systems. Boot code is loaded into a data storage device controller in a flexible manner by being able to receive blocks of boot code from two separate locations, a host memory buffer (HMB) and a memory device that can be a NAND device. A portion of the boot code can be received from the HMB, and another portion of the boot code can be received from the memory device. If the HMB or the memory device can transfer blocks faster than the other location, the controller can receive blocks from the faster location and periodically confirm the transfer speed to ensure that the boot code delay is optimized.

[0021] Figure 11 is a schematic diagram of a data storage system 100 according to one embodiment. The data storage system 100 includes a host computer device 102 and a data storage device 104. The data storage device 104 can be used as a storage device for the host computer system 102. For example, the host computer system 102 can utilize a non-volatile memory (NVM) 116, such as NAND, included in the data storage device 104 to store and retrieve data. In some examples, the data storage system 100 can include multiple storage devices, such as the data storage device 104, that can be used as a storage array. For example, the data storage system 100 may include multiple data storage devices 104 that are configured as a redundant array of inexpensive / independent disks (RAID) that are collectively used as a mass storage device for the host computer system 102.

[0022] The host computer system 102 includes a host memory 106, which includes a host boot area 108, a host data buffer 112, and a host queue 114 as a part of a host memory buffer (HMB) 110. HMB 110 is a storage device in the host memory 106 of the host computer system 102, which is assigned to the data storage device 104. The data storage device 104 can utilize HMB 110 in any desired function. In the embodiment discussed herein, the data storage device 104 utilizes HMB 110 to store boot code. The host computer system 102 can store data to one or more storage devices (such as data storage device 104) and / or retrieve data from the one or more storage devices. The host computer system 102 can communicate with the data storage device 104 via an interface. The host computer system 102 may include any of a variety of devices, including a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called "smart" phone, a so-called "smart" tablet computer, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, etc.

[0023] In some embodiments, the host queue 114 includes one or more host queues, wherein the host queue 114 stores the generated commands for retrieval by the data storage device 104. In addition, the data of the commands generated in the one or more host queues 114 can be stored in the host data buffer 112. In some embodiments, the host data buffer 112 includes one or more host data buffers.

[0024] The HMB 110 of the host memory 106 may be a host DRAM partition allocated for the data storage device 104. Boot code (i.e., code for the startup process or boot operation of the computing system) may be stored in the HMB 110. More specifically, the boot code is stored in the host boot area 108 of the HMB 110. During the boot operation, the boot code is obtained from the HMB 110 and transmitted to the device controller 120. Since the HMB 110 is a volatile memory, the boot code is written during the previous run time. During the boot time, and only when the HMB 110 content is still valid, the HMB 110 is available, and the boot code can be obtained from the HMB 110.

[0025] The data storage device 104 includes a device controller 120, volatile memory such as dynamic random access memory (DRAM) 122, and NVM 116. In some examples, for clarity, the data storage device 104 may include Figure 1 104. For example, the data storage device 104 may include a printed circuit board (PCB) to which the components of the data storage device 104 are mechanically attached, and the printed circuit board includes conductive traces that electrically interconnect the components of the data storage device 104, etc. In some examples, the physical size and connector configuration of the data storage device 104 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, a 3.5" data storage device (e.g., an HDD or SSD), a 2.5" data storage device, a 1.8" data storage device, a peripheral component interconnect (PCI), a PCI extension (PCI-X), a PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, MiniPCI, etc.). In some examples, the data storage device 104 may be directly coupled (e.g., directly soldered) to a motherboard of the host computer system 102.

[0026] In some examples, the data storage device 104 may include an interface that may include one or both of a data bus for exchanging data with the host computer system 102 and a control bus for exchanging commands with the host computer system 102. The interface may operate according to any suitable protocol. For example, the interface may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Standard (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. The electrical connection of the interface (e.g., data bus, control bus, or both) is electrically connected to the controller 120, thereby providing an electrical connection between the host computer system 102 and the device controller 120, allowing data to be exchanged between the host computer system 102 and the device controller 120. In some examples, the electrical connection of the interface may also allow the data storage device 104 to receive power from the host computer system 102. For example, the power supply may receive power from the host computer system 102 via the interface.

[0027] The data storage device 104 includes an NVM 116, which may include a plurality of memory devices or memory cells and a NAND boot area 150. The plurality of memory devices or memory cells may be arranged into one or more memory arrays 124. Boot code, which may be the same as the boot code stored in the HMB 110 of the host computer system 102, may be stored in the one or more memory arrays 124. During a boot operation, the boot code is retrieved from the NAND boot area 150 and transferred to the device controller 120.

[0028] NVM 116 may be configured to store and / or retrieve data. For example, a memory cell of NVM 116 may receive data and a message indicating that the memory cell is storing data from device controller 120. Similarly, a memory cell of NVM 116 may receive a message indicating that the memory cell is retrieving data from device controller 120. In some examples, each of the memory cells may be referred to as a die. In some examples, a single physical chip may include multiple dies (i.e., multiple memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0029] In some examples, each memory cell of NVM 116 may include any type of nonvolatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of nonvolatile memory device.

[0030] NVM 116 may include multiple flash memory devices or memory cells. Flash memory devices may include NAND or NOR-based flash memory devices, and may store data based on the charge contained in the floating gate of the transistor for each flash memory cell. In NAND flash memory devices, the flash memory devices may be divided into multiple blocks, which may be divided into multiple pages. Each block in a plurality of blocks within a particular memory device may include multiple NAND cells. The rows of NAND cells may be electrically connected using word lines to define pages in a plurality of pages. The corresponding cells in each of the plurality of pages may be electrically connected to the corresponding bit lines. In addition, the NAND flash memory device may be a 2D or 3D device, and may be a single-level cell (SLC), a multi-level cell (MLC), a three-level cell (TLC), or a four-level cell (QLC). The device controller 120 may write data to the NAND flash memory device at a page level and read data from the NAND flash memory device, and erase data from the NAND flash memory device at a block level.

[0031] In some examples, the data storage device 104 includes a power supply that can provide power to one or more components of the data storage device 104. When operating in a standard mode, the power supply can use power provided by an external device such as a host computer system 102 to power one or more components. For example, the power supply can use power received from the host computer system via an interface of the data storage device 104 to power one or more components. In some examples, the power supply may include one or more power storage components that are configured to supply power to one or more components when operating in a shutdown mode, such as when power is stopped from being received from an external device. In this way, the power supply can be used as an onboard backup power supply. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like. In some examples, the amount of power that can be stored by one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0032] In some examples, data storage device 104 may include one or more volatile memories, such as DRAM 122, which may be used by device controller 120 to store information. In addition, device controller 120 may include one or more volatile memories. In some examples, device controller 120 may use volatile memories as caches. For example, device controller 120 may store cached information in volatile memories until the cached information is written to NVM 116. Examples of volatile memories include, but are not limited to, random access memory (RAM), DRAM, static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)).

[0033] The data storage device 104 includes a device controller 120 that can manage one or more operations of the data storage device 104. For example, the device controller 120 can manage reading data from the NVM 116 and / or writing data to the NVM 116. In some embodiments, when the data storage device 104 receives a write command from the host computer system 102, the device controller 120 can initiate a data storage command to write data to the NVM 116 and monitor the progress of the data storage command. The device controller 120 can determine at least one operating characteristic of the data storage system 100 and store the at least one operating characteristic to the NVM 116. In some embodiments, when the data storage device 104 receives a write command from the host computer system 102, the controller 120 temporarily stores the data associated with the write command in an internal memory or a write buffer before sending the data to the NVM 116.

[0034] The device controller includes a PCIe MAC PHY 126, a boot logic component 134, a control path 132, one or more direct memory accesses (DMAs) 128, an error correction module 130, a flash interface module (FIM) 136, and one or more processors 144. The one or more processors 144 are chips or logic circuits that respond to and process commands to operate a computing system such as the data storage device 104. The one or more processors 144 may perform all mathematical operations and manage controller operations.

[0035] Data exiting the host computer system 102 and entering the data storage device 104 may be performed via the PCIe MAC PHY 126. If the device controller 120 has completed a command, data associated with the completed command may be transferred via the PCIe MAC PHY 126 to the host queue 114 present in the host computer system 102.

[0036] Data is passed from the PCIe MAC PHY 126 to the control path 132 and one or more DMAs 128. The one or more DMAs 128 can perform data transfers between the host computer system 102 and the data storage device 104 without the involvement of the host computer system 102 CPU. The control path 132 can be used to obtain physical page regions (PRPs), issue completions and interrupts, and activate the DMAs 128 for data transfers between the host computer system 102 and the data storage device 104. The error correction module 130 corrects data obtained from the memory array. The device controller 120 can interact with the NVM 116 using the FIM 136 for read and write operations.

[0037] The boot logic unit 134 includes an HMB boot area 138, a NAND boot area 140, and a control and security module 142. The boot logic unit 135 identifies the parallel boot execution of the HMB boot area 108 and the NAND boot area 150. The HMB boot area 138 can determine the state of the boot according to the HMB boot area 108. Similarly, the NAND boot area 140 can determine the state of the boot according to the NAND boot area 150. The control and security module 142 can be used for the control and implementation of the HMB boot area 108 and the NAND boot area 150 for the parallel boot execution.

[0038] Figure 2 is a schematic diagram of a parallel boot process according to one embodiment. The boot code is stored in Figure 1 The boot code is the same in both the host boot area 108 and the NAND boot area 150. The boot code of about 80KB (including the associated context) is divided into blocks of a predetermined size (such as about 4KB). For example, the HMB boot area 108 includes about 20 blocks of about 4KB, and the NAND boot area 150 includes about 20 blocks of about 4KB.

[0039] like Figure 2As shown, the first 4KB block of boot code is represented by 0, the second 4KB block of boot code is represented by 1, and so on. When a boot operation is initiated, a boot code block is obtained from the HMB boot area 108 of the HMB 110, and the same boot code block is obtained from the NAND boot area 150. During the boot operation, the boot code blocks of both the HMB boot area 108 and the NAND boot area 150 are simultaneously obtained at the device controller 120 and are stored internally in a controller memory such as SRAM of the device controller 120. In one embodiment, the acquisition from the HMB boot area 108 can occur faster than the acquisition from the NAND boot area 150. In another embodiment, the acquisition from the NAND boot area 150 can occur faster than the acquisition from the HMB boot area 108.

[0040] When reading the boot code from the HMB boot area 108, the first boot code block 0 is read first, the second boot code block 1 is read second, and so on. The reading from the HMB boot area 108 can be read from the first boot code block (e.g., block 0) to the last boot code block (e.g., block 19). When reading from the NAND boot area 150, the last boot code block 19 is read first, the penultimate boot code block 18 is read second, and so on. The reading from the NAND boot area 150 can be read from the last boot code block (e.g., block 19) to the first boot code block (e.g., block 0). In another embodiment, the listed reading order of the boot code blocks from the HMB boot area 108 and the NAND boot area 150 can be switched. When the entire boot code is read from the HMB boot area 108 and the NAND boot area 150 together, the boot operation is completed.

[0041] The entire boot code may be read partially from the HMB boot area 108 and partially from the NAND boot area 150, where each portion of the boot code read from the HMB boot area 108 and the NAND boot area 150 is equal. For example, boot code blocks 0-9 may be read from the HMB boot area 108, and the remaining boot code blocks 10-19 may be read from the NAND boot area 150. Since all the boot code has been read, the boot process has been completed.

[0042] In another embodiment, the entire boot code may be read partially from the HMB boot area 108 and partially from the NAND boot area 150, where each portion of the boot code read from the HMB boot area 108 and the NAND boot area 150 is not equal. For example, boot code blocks 0-13 may be read from the HMB boot area 108, and the remaining boot code blocks 14-19 may be read from the NAND boot area 150. Since all the boot code has been read, the boot process has been completed.

[0043] Since the boot code blocks of uneven amounts can be read from the HMB boot area and the NAND boot area, the controller can place the relevant parts of the boot code in the HMB and NAND. For example, if parallel loading (i.e., reading of the controller) is completed at boot code block 12, boot code blocks 0-12 are read from a first position such as the HMB boot area 108, and boot code blocks 12-19 are read from a second position such as the NAND boot area 150. Therefore, the HMB boot area 108 can be loaded faster (i.e., the reading of the controller is faster). Due to the faster reading speed of the HMB boot area 108, boot code blocks 0-14 (i.e., 15 boot code blocks) can be placed in the HMB, and boot code blocks 11-19 (i.e., 9 boot code blocks) can be placed in the NAND. The overlap or overhead of boot code blocks 11-14 can cause the read throughput to change. The listed examples are not intended to be limiting, but to provide examples of possible implementations.

[0044] Figure 3A 300 is a flow chart illustrating a boot process 300 according to one embodiment. The boot process 300 describes the boot operation of a data storage device when each boot code block includes an authentication code or an authentication signature. The terms "authentication code" and "authentication signature" may be used interchangeably herein and may have the same meaning. The authentication code checks for a valid boot code block. At box 302, a boot operation is initiated. At box 304, the boot code block is loaded from the HMB to the internal memory of the device controller. At box 308, the boot code block is loaded from the NAND boot area to the internal memory of the device controller. The loading of the boot code block from the HMB and NAND at boxes 304 and 308 may occur simultaneously.

[0045] Whenever a boot code block is read from an HMB boot area or a NAND boot area and delivered to the controller, the controller checks for a valid authentication code at blocks 306 and 310. When a boot code block includes an invalid authentication code, the controller may be configured to receive a corresponding boot code block from another boot area. The controller includes logic components such as Figure 1 The boot logic unit 134 of the controller may be configured to determine the starting position of the associated boot code block having the invalid authentication code (e.g., the HMB boot area or the NAND boot area). For example, if the boot code block 0 of the HMB boot area includes the invalid authentication code, the controller may be configured to receive the boot code block 0 from the NAND boot area to replace the invalid boot code block 0 received from the HMB boot area. Similarly, if the boot code block 0 of the NAND boot area includes the invalid authentication code, the controller may be configured to receive the boot code block 0 from the HMB boot area to replace the invalid boot code block 0 received from the NAND boot area.

[0046] At block 312, the controller determines whether all boot code blocks including a valid authentication code have been received. In some examples, the controller may receive the same one or more boot code blocks from both the NAND boot area and the HMB boot area. When all boot code blocks including a valid authentication code have been received at block 312, the boot process is completed at block 314. However, if all boot code blocks have not been received, the remaining boot code blocks are loaded into the HMB boot area at block 304 and the remaining boot code blocks are loaded into the NAND boot area at block 308.

[0047] Figure 3B 350 is a flow chart illustrating a boot process 350 according to another embodiment. The boot process 350 describes the boot operation of a data storage device when the controller checks a valid authentication code or authentication signature for the entire boot code. The terms "authentication code" and "authentication signature" may be used interchangeably herein and may have the same meaning. The authentication code checks for a valid boot code block. At box 352, the boot operation is initiated. At box 354, the boot code block is obtained from the HMB boot area and stored in the internal memory of the device controller. At box 356, the boot code block is obtained from the NAND boot area and stored in the internal memory of the device controller. The loading of the boot code block from the HMB and NAND at boxes 354 and 356 may occur simultaneously.

[0048] At box 358, the controller determines whether all boot code blocks have been received at the controller. If the boot code blocks received at the controller at box 358 are less than all boot code blocks, the controller waits until all boot code blocks are received. Boot code blocks can be received from the HMB boot area, the NAND boot area, or from both the HMB boot area and the NAND boot area. After all boot code blocks have been read from the HMB boot area and the NAND boot area at box 358 and delivered to the controller, the controller confirms the authentication signature of the entire boot code at box 360.

[0049] At block 362, if the authentication signature is valid, the boot operation is complete. However, if the authentication signature is invalid, at block 364, the controller uses a logic component (such as Figure 1The boot logic unit 134 of the controller determines whether the damaged boot code block that causes the invalid authentication signature is from the HMB. If the damaged boot code block is from the HMB, then the relevant boot code block is loaded from the NAND boot area stored in the internal memory of the controller at box 356. However, if the damaged boot code block is not from the HMB (that is, from NAND), then the relevant boot code block is loaded from the HMB at box 354 and stored in the internal memory of the controller. For each instance of the damaged boot code block, the boot code block may be reloaded from another boot area. At box 362, if the authentication signature is valid, the boot operation is completed at box 366.

[0050] Figure 4 4 is a flow chart illustrating a boot process 400 according to another embodiment. The boot process 400 describes the boot operation of a data storage device during an "exploit-exploit" tradeoff, such as when a host device (e.g., Figure 1 The host computer system 102 has one or more memory devices (e.g., Figure 1 The boot code is stored in both the HMB and the NAND. The exploit portion of the “exploit-exploit” tradeoff may refer to performing boot operations from locations that exhibit faster boot delays (i.e., HMB or NAND). The explore portion of the “exploit-exploit” tradeoff may refer to updating the current average estimate of booting from other locations that are not used for boot operations due to slower boot delays. In one embodiment, the “explore-exploit” factor may be gradually reduced to about 0, where a more efficient location (HMB or NAND) will be used for boot operations.

[0051] At block 402, a static configuration is set where the "explore-exploit" factor or EE factor is equal to 5. The EE factor may include values ​​between about 0 and about 100. At block 404, the controller starts a counter, set A, and set B. The counter is set to about 0. In one embodiment, set A refers to NAND and set B refers to HMB. Figure 4 In the example, set A has a faster average latency. Figure 4 In the example of , set A is set to NAND, but it should be understood that set A can be HMB. At block 406, a boot start command is received. When the boot start command is received, the boot code block is loaded from the NAND boot area and the HMB boot area.

[0052] At block 408, the controller determines whether the remainder of the counter divided by 100 is greater than 100 minus the EE factor. When the remainder of the counter divided by 100 is less than 100 minus the EE factor, the storage device may utilize a boot source with lower performance or slower average latency to update the current average estimate for booting from the lower performance location. At block 410, since the remainder of the counter divided by 100 is less than 100 minus the EE factor, a boot from set A or NAND is performed to update the current average estimate for booting. However, if the remainder of the counter divided by 100 is greater than 100 minus the EE factor at block 408, then at block 412, a boot is performed from set B or HMB.

[0053] At box 414, the average delay or current average estimate of the boot from set A or set B is calculated, tracked, and updated. At box 416, the controller determines whether it is necessary to switch the boot position based on the average delay of each set A and B, so as to mark the position indicating better delay with A. Generally speaking, for values ​​of EE factor <50, A will be used most of the time. If switching is required at box 416, the boot position is switched at box 418. Thereafter, the counter is increased by 1 at box 420, and the next boot operation starts at box 406. For example, the controller may receive a boot code block from one or more memory devices (such as NAND) and switch to receiving a boot code block from a host device (such as an HMB of a host computer system). For another example, the controller may receive a boot code block from a host device (such as an HMB of a host computer system) and switch to receiving a boot code block from one or more memory devices (such as NAND). If the boot position does not need to be switched from a first boot position to a second boot position at box 416, the counter is increased by 1 at box 420, and the next boot process 400 starts at box 406. In some embodiments, the boot process 400 may be used to apply boot code blocks unevenly to the HMB and NAND to optimize the average latency for each location.

[0054] By utilizing boot code blocks from both the memory device and the host memory buffer, the latency of the boot procedure of the data storage device is reduced.

[0055] In one embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive a boot code block of a boot code from a host device; and receive a boot code block of a boot code from one or more memory devices. The boot code includes 20 blocks of predetermined size. The boot code block received from the host device is used for the first half of the boot code, and wherein the boot code block received from the one or more memory devices is used for the second half of the boot code. The number of boot code blocks received from the host device is different from the number of boot code blocks received from the one or more memory devices. Each boot code block received has an authentication signature, and wherein the controller is configured to determine whether each boot code block has a valid authentication signature. When it is determined that the authentication signature is invalid for a specific boot code block, the controller is configured to receive a specific boot code block from the host device or another of the one or more memory devices that sent the invalid specific boot code block. The controller is configured to determine whether each boot code block has a valid authentication signature after loading each boot code block.

[0056] In another embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive boot code blocks of boot code from both a host device and one or more memory devices; confirm that all boot code blocks have been received; confirm the authentication signature of the boot code; determine whether the boot code block is invalid; determine whether the invalid boot code block is from the host device or from one or more memory devices; and receive a valid boot code block from either the host device and the one or more memory devices that do not deliver an invalid boot code block. The controller is configured to receive multiple copies of the one or more boot blocks. The controller is configured to track the average number of boot code blocks received from both the one or more memory devices and the host device. An additional boot code block greater than the average is placed in each of the host device and the one or more memory devices. The controller receives boot code blocks from the host device and the one or more memory devices in different orders. The controller receives more than half of the boot code blocks from the host device or the one or more memory devices. The authentication signature of the boot code is received from both the host device and the one or more memory devices.

[0057] In another embodiment, a data storage device includes: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receive a boot code block of boot code from one or more memory devices or a host device; receive a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices are booted; and determine whether the average delay for receiving boot code from the one or more memory devices is different from the average delay for receiving boot code from the host device. The controller is further configured to receive a boot code block from the one or more memory devices and switch to receiving a boot code block from the host device. The controller is further configured to receive a boot code block from the host device and switch to receiving a boot code block from the one or more memory devices. The controller is configured to calculate the average delay for receiving boot code from both the one or more memory devices and the host device. The controller is configured to increase an internal counter each time a boot occurs until a predetermined number of data storage device boots have occurred. The controller includes a boot logic component that processes both the one or more memory device boot code blocks and the host device boot code blocks.

[0058] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be envisaged without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from a host memory buffer HMB of a host device, wherein the boot code is associated with a boot operation of the data storage device, wherein the boot code block of the boot code from the HMB was stored in the HMB during a previous run time of the data storage device; receiving a boot code block of the boot code from the one or more memory devices; confirming that all boot code blocks of the boot code have been received, wherein a portion of the boot code blocks are received from the HMB and a different portion of the boot code blocks are received from the one or more memory devices; confirming the authentication signatures of all of the boot code blocks of the boot code, wherein the controller is further configured to receive a valid boot code block from any one of the HMB and the one or more memory devices that does not deliver an invalid boot code block based on confirming the authentication signatures; When the number of boot code blocks received from the host device plus the number of boot code blocks received from the one or more memory devices equals a total number of boot code blocks of the boot code, the data storage device is booted using the boot code blocks received from the host device and the boot code blocks received from the one or more memory devices.

2. The data storage device of claim 1, wherein the boot code comprises 20 blocks of a predetermined size.

3. The data storage device of claim 1, wherein the boot code block received from the host device is for a first half of the boot code, and wherein the boot code block received from the one or more memory devices is for a second half of the boot code. 4 . The data storage device of claim 1 , wherein the number of boot code blocks received from the host device is different from the number of boot code blocks received from the one or more memory devices. 5 . The data storage device of claim 1 , wherein each boot code block received has an authentication signature, and wherein the controller is configured to determine whether each boot code block has a valid authentication signature.

6. The data storage device of claim 5 , wherein upon determining that the authentication signature is invalid for a specific boot code block, the controller is configured to receive the specific boot code block from the host device or another one of the one or more memory devices that sent the invalid specific boot code block. 7 . The data storage device of claim 5 , wherein the controller is configured to determine whether each boot code block has a valid authentication signature after loading each boot code block.

8. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: A boot code block of boot code is received from both a host memory buffer HMB of the host device and the one or more memory devices, wherein: The boot code is associated with a boot operation of the data storage device; the boot code block of the boot code from the HMB being stored in the HMB during a previous run time of the data storage device; Confirm that all boot code blocks have been received; confirming the authentication signature of the boot code; Determine if the boot code block is invalid; determining whether the invalid boot code block is from the host device or from the one or more memory devices; receiving a valid boot code block from any of the host device and the one or more memory devices that did not deliver the invalid boot code block; and In response to receiving the valid boot code block, the data storage device is booted using the boot code block received from the host device, the boot code blocks received from the one or more memory devices, and the valid boot code block.

9. The data storage device of claim 8, wherein the controller is configured to receive multiple copies of one or more boot blocks.

10. The data storage device of claim 8, wherein the controller is configured to track an average number of boot code blocks received from both the one or more memory devices and the host device.

11. The data storage device of claim 8, wherein the controller receives the boot code blocks from the host device and the one or more memory devices in different orders.

12. The data storage device of claim 8, wherein the controller receives more than half of the boot code block from the host device or the one or more memory devices.

13. The data storage device of claim 8, wherein the authentication signature of the boot code is received from both the host device and the one or more memory devices.

14. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from both a host device and the one or more memory devices; tracking an average number of boot code blocks received from both the one or more memory devices and the host device, wherein an additional boot code block greater than the average number is placed in each of the host device and the one or more memory devices; Confirm that all boot code blocks have been received; confirming the authentication signature of the boot code; Determine if the boot code block is invalid; determining whether the invalid boot code block is from the host device or from the one or more memory devices; as well as A valid boot code block is received from either of the host device and the one or more memory devices that did not deliver the invalid boot code block.

15. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host memory buffer HMB of the host device; receiving a boot data block from another of the one or more memory devices or the HMB of the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different from an average delay for receiving the boot code from the host device; as well as A first number of boot code blocks of the boot code stored in the one or more memory devices and a second number of boot code blocks of the HMB of the host device are adjusted based on the determination result, wherein: The total number of boot code blocks is equal to the first number of boot code blocks plus the second number of boot code blocks; and The boot code block of the boot code stored in the one or more memory devices is different from the boot code block of the boot code stored in the HMB of the host device.

16. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host device; receiving a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different from an average delay for receiving the boot code from the host device; as well as The boot code block is received from the one or more memory devices and switched to receiving the boot code block from the host device.

17. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host device; receiving a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different from an average delay for receiving the boot code from the host device; as well as The boot code block is received from the host device and switched to receiving the boot code block from the one or more memory devices.

18. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host device; receiving a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different from an average delay for receiving the boot code from the host device; as well as The average delay for receiving the boot code for both the one or more memory devices and the host device is calculated.

19. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host device; receiving a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different from an average delay for receiving the boot code from the host device; as well as An internal counter is incremented each time a boot occurs until the predetermined number of data storage device boots have occurred.

20. A data storage device comprising: one or more memory devices; and a controller coupled to the one or more memory devices, wherein the controller is configured to: receiving a boot code block of boot code from the one or more memory devices or a host device; receiving a boot data block from the other of the one or more memory devices or the host device after a predetermined number of data storage devices have booted; determining whether an average delay for receiving the boot code from the one or more memory devices is different than an average delay for receiving the boot code from the host device, wherein the controller includes a boot logic component that processes both the one or more memory device boot code blocks and the host device boot code blocks.

Images