Fast boot by optimizing boot partition access and staged loading of firmware from non-volatile memory devices

Abstract

The invention relates to fast boot by optimizing boot partition access and staged loading of firmware from non-volatile memory devices. A memory subsystem includes a non-volatile memory (NVM) memory device and a processing device operably coupled to the memory device and a host system. The processing device includes an embedded volatile memory and retrieves ROM code from an internal read only memory (ROM) of the processing device in response to energization of the memory subsystem. The processing device executes the ROM code to load boot code from the memory device into the embedded volatile memory. The processing device executes the boot code to load a first stage firmware into the embedded volatile memory. The first stage firmware is to enable access to a boot partition of the memory device before the processing device has a full operational access to the memory device.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to memory subsystems, and more particularly, to fast boot by optimizing boot partition access and staging firmware loading from non-volatile memory (NVM) devices. Background Art

[0002] A memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. Generally, a host system may utilize the memory subsystem to store data at and retrieve data from the memory devices. Summary of the Invention

[0003] In one aspect, the present disclosure provides a memory subsystem comprising: a memory device including non-volatile memory; and a processing device operatively coupled to the memory device and a host system, wherein the processing device includes embedded volatile memory and is configured to perform operations including: in response to power-on of the memory subsystem, retrieving ROM code from an internal read-only memory (ROM) of the processing device; executing the ROM code to load boot code from the memory device into the embedded volatile memory; and executing the boot code to load first-stage firmware into the embedded volatile memory, wherein the first-stage firmware is configured to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device.

[0004] In another aspect, the present disclosure provides a method comprising: by a processing device, in response to power-on of a memory device, retrieving ROM code from an internal read-only memory (ROM) of the processing device; executing the ROM code to load boot code from the memory device into the embedded volatile memory of the processing device; and executing the boot code to load first-stage firmware into the embedded volatile memory, wherein the first-stage firmware is configured to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device.

[0005] On the other hand, the present disclosure provides a non-transitory computer-readable storage medium storing instructions that, when executed by a processing device of a memory subsystem, cause the processing device to perform operations including: retrieving ROM code from an internal read-only memory (ROM) of the processing device in response to power-on of the memory subsystem; executing the ROM code to load boot code from a memory device of the memory subsystem into an embedded volatile memory of the processing device; and executing the boot code to load a first-stage firmware into the embedded volatile memory, wherein the first-stage firmware is used to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure will be more fully understood from the detailed description given below and from the accompanying drawings of various embodiments of the present disclosure.

[0007] Figure 1A Illustrate an example computing system including a memory subsystem according to an embodiment.

[0008] Figure 1B is a block diagram of a peripheral component interconnect express (PCIe) NVM memory overlay within a memory device according to some embodiments. Figure 1A of the memory device according to some embodiments.

[0009] Figure 2 is a flowchart of a method for fast boot by optimizing boot partition access and phased loading of firmware from an NVM device according to various embodiments.

[0010] Figure 3 is a flowchart of a method for fast boot by optimizing boot partition access and phased loading of firmware from an NVM device according to an embodiment.

[0011] Figure 4 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0012] Aspects of the present disclosure relate to fast (or accelerated) boot by optimizing boot partition access and phased loading of firmware from a non-volatile memory (NVM) device. The memory subsystem may be a storage device, a memory module, or a combination of a storage device and a memory module. Examples of storage devices and memory modules are described below in connection with Figure 1A Generally, a host system may utilize a memory subsystem that includes one or more components, such as a memory device that stores data. The host system may provide data to be stored at the memory subsystem and may request data to be retrieved from the memory subsystem.

[0013] A memory device may be a non-volatile memory device that can store data from a host system. An example of a non-volatile memory device is a NAND (Not AND) memory device. Other examples of non-volatile memory devices are described below in conjunction with Figure 1A Each of the memory devices may include one or more memory cell arrays organized into physical blocks of memory cells. A memory cell ("cell") is an electronic circuit that stores information. Depending on the cell type, a cell may store one or more bits of binary information and have various logical states related to the number of bits stored. The logical states may be represented by binary values (e.g., "0" and "1") or combinations of such values.

[0014] In some memory subsystems that employ a memory controller (which includes a processing device and embedded memory), the controller uses boot firmware (such as the Basic Input / Output System (BIOS) or the newer Unified Extensible Firmware Interface (UEFI)) to perform a boot. Once the BIOS or UEFI firmware is executed, it supports further system boot from the NVM device. (Although is the current standard for most modern NVM devices, the present disclosure is not limited to such current standards.)

[0015] Generally, a motherboard (e.g., which may include a controller and other memory subsystem components) supports BIOS / UEFI boot firmware, but modern motherboards tend to use flash memory to store the boot firmware. For example, due to reliability and eXecute In Place (XIP) capabilities, Serial Peripheral Interface (SPI) NOR (or SPI-NOR) flash drives have become a common choice for storing boot firmware (especially in automotive and industrial applications). For example, due to this XIP capability, SPI-NOR devices do not need to first copy the boot firmware to random access memory (RAM) (usually static RAM (SRAM)) to be able to execute the boot firmware. However, these SPI-NOR flash drives have the disadvantage of slowing down the boot (e.g., at least because the firmware is not executed outside of SRAM, which has a lower latency and higher data transfer rate than SPI-NOR memory), and have the disadvantage of increasing the Bill of Materials (BOM) cost of the motherboard.

[0016] In such memory subsystems, the boot firmware may read a boot sector (or the EFI partition in the UEFI system) from the device. The initial boot sector or EFI partition contains a boot loader, such as GRUB for many distributions or for The Windows Boot Manager. The boot firmware loads the boot loader into the memory of the memory subsystem (e.g., volatile memory). The boot loader then takes over and loads the kernel of the operating system (OS), thus initializing the OS boot process. Once the OS kernel is loaded and starts executing, the OS kernel uses drivers to communicate efficiently with devices, thus ensuring fast data transfer.

[0017] The challenge with this typical boot process is that the boot process is slow before the OS kernel is fully available and executing, and loading the boot firmware (or executing the boot firmware outside of the SPI-NOR memory) may take several seconds or more, which is a long time in modern computing systems. Thus, a significant delay is incurred before the boot firmware (UEFI or BIOS) is executed. Additionally, even after the boot firmware starts executing, the link must be initialized and the PCIe path trained before the peripheral component interconnect express (PCIe) data path that can be used to link the NVMe device to the host system can reach full data speed. This initialization includes detecting the device, determining the number of paths to use, and setting the data rate.

[0018] In modern NVM devices, PCIe signals are differential, which means that PCIe uses a pair of wires for each path, one for the positive and one for the negative. The signals on these wires need to be synchronized for proper communication. However, due to various reasons (such as differences in trace lengths on the motherboard), the signal on one wire may arrive earlier than the signal on the other wire. Thus, the path training adjusts for these timing differences or skews so that the signals on each pair are properly aligned. Thus, PCIe path training adds additional delay to the boot process. However, even after the boot loader is loaded and executed, waiting for the OS kernel to be loaded until the OS can be initialized also incurs more delay. All of these delays increase the time to ready (TTR), i.e., the time required from power-on until the NVM device is fully operational (e.g., can support full user data memory operations from the host system).

[0019] Aspects of the present disclosure address the above and other drawbacks of current boot methods in memory subsystems by performing firmware loading in stages such that a small first-stage firmware (something much smaller than the full or main boot firmware) is first loaded into the embedded volatile memory (VM) of the controller. In these embodiments, when executed, this first-stage firmware provides minimal support for accessing the boot partition via the NVM interface to the NVM memory device. In the present disclosure, for example, this NVM interface may be PCIe / The interface, however, is common in the industry. Since the first-stage firmware is minimized in size, the first-stage firmware can be quickly loaded and executed by the controller to provide this minimal support. In various embodiments, the first-stage firmware is configured to initialize the PCIe link with the host system and perform PCIe training for a single PCIe lane of the PCIe interface. In some embodiments, initializing this single PCIe lane is performed at a first-generation data rate, which is a slower data rate, but is faster for initializing basic functionality.

[0020] More specifically, in some embodiments, in response to power-on of the memory subsystem, the controller retrieves ROM code from the controller's internal read-only memory (ROM), which may also store boot firmware such as UEFI or BIOS. In some embodiments, the controller executes the ROM code to load boot code from the NVM memory device into an embedded volatile memory (VM) (e.g., SRAM or tightly coupled memory). The controller can then execute the boot code to load the first-stage firmware into the embedded VM. In some embodiments, the first-stage firmware is executed to enable access to the boot partition of the memory device before the processing device has full operational access to the NVM memory device (which means the host system also does not have full operational access to the NVM memory device).

[0021] In various embodiments, after executing the first-stage firmware, the controller loads the second-stage firmware into either the embedded VM or system memory (e.g., dynamic RAM). The controller can further execute the second-stage firmware to provide the host system with full operational access to the memory device, including training the PCIe link of the PCIe interface of the memory device at maximum PCIe speed. In at least some embodiments, the execution of the boot code further enables the boot loader code to be loaded from the boot partition of the NVM memory device (since basic PCIe functionality has been established). The execution of the boot loader code enables the download and execution of the OS kernel, as previously explained. In at least some embodiments, the second-stage firmware is loaded while executing at least one of the boot loader code or the OS kernel, thereby enabling parallel download of the main boot firmware while continuing the OS boot process.

[0022] Advantages of the present disclosure include, but are not limited to, significantly reducing the time-to-readiness (TTR) of the NVM memory device of the memory subsystem. Optimization of boot partition access based on staged firmware loading can also be performed in a manner transparent to the host system. Further advantages include the ability to avoid using an SPI-NOR flash drive for booting, which is slower and involves BOM cost. These and other advantages will be discussed later and will be apparent to those skilled in the art of memory subsystem boot and initialization.

[0023] Figure 1A Describe an example computing system 100 that includes a memory subsystem 110 in accordance with some embodiments of the present disclosure. The memory subsystem 110 may include media, such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination thereof. Each memory device 130 or 140 may be one or more memory components.

[0024] The memory subsystem 110 may be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include solid state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controllers (eMMCs), universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0025] The computing system 100 may be a computing device, such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, a drone, a train, an automobile, or other transportation vehicle), an Internet of Things (IoT) capable device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes a memory and a processing device.

[0026] The computing system 100 may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, the host system 120 is coupled to different types of memory subsystems 110. Figure 1A Describe an example of a host system 120 coupled to a single memory subsystem 110. As used herein, "coupled to" or "coupled with" generally refers to a connection between components or devices, which may be an indirect communication connection or a direct communication connection (e.g., without an intervening component or device), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, and the like.

[0027] The host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 120 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0028] The host system 120 can be coupled to the memory subsystem 110 via a physical host interface 122, and the physical host interface 122 can communicate via a system bus. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect Express (PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS), Double Data Rate (DDR) memory buses, Small Computer System Interface (SCSI), Dual In-line Memory Module (DIMM) interfaces (e.g., DIMM socket interfaces that support Double Data Rate (DDR)), Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface can be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 via a PCIe interface, the host system 120 can further utilize the NVM Express interface to access components (e.g., the memory device 130). The physical host interface can provide an interface for transferring control, address, data, and other signals between the memory subsystem 110 and the host system 120. Figure 1A Illustrate the memory subsystem 110. Generally, the host system 120 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0029] The memory devices 130, 140 can include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., the memory device 140) can be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0030] Some examples of non-volatile memory devices (e.g., the memory device 130) include NAND-type flash memory and write-in-place memory, such as three-dimensional cross-point (“3D cross-point”) memory. The cross-point array of non-volatile memory can perform bit storage based on the change of bulk resistance in combination with a stackable cross-grid data access array. Additionally, compared with many flash-based memories, cross-point non-volatile memory can perform in-situ write operations, where non-volatile memory cells can be programmed without prior erasure of the non-volatile memory cells. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0031] Each of the memory devices 130 may include one or more arrays of memory cells. One type of memory cell (e.g., single-level cell (SLC)) may store one bit per cell. Other types of MLC memory cells (e.g., binary-level cell (BLC), triple-level cell (TLC), quad-level cell (QLC), and penta-level cell (PLC)) may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more arrays of memory cells (e.g., SLC, BLC, TLC, QLC, PLC, or any combination thereof). In some embodiments, a particular memory device may include an SLC portion, a BLC portion, a TLC portion, a QLC, or a PLC portion of memory cells. The memory cells of the memory devices 130 may be grouped into pages, where a page may refer to a logical unit of the memory device used to store data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0032] Although non-volatile memory components (e.g., NAND-type flash memory (e.g., 2D NAND, 3D NAND) and 3D cross-point arrays of non-volatile memory cells) are described, the memory devices 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase-change memory (PCM), self-selecting memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer torque (STT)-MRAM, conductive-bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0033] The memory subsystem controller 115 (or simply controller 115) may communicate with the memory devices 130 to perform operations such as reading data, writing data, or erasing data at the memory devices 130 and other such operations. The memory subsystem controller 115 may include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware may include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 may be a microcontroller, dedicated logic circuitry (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or other suitable processor.

[0034] The memory subsystem controller 115 may include a processor 117 (processing device) configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines for controlling the operation of the memory subsystem 110, including handling communication between the memory subsystem 110 and the host system 120. In some embodiments, this embedded memory includes SRAM or tightly coupled memory (TCM), which is a memory that can be accessed faster than the volatile memory (VM) of the memory device 140.

[0035] In some embodiments, the local memory 119 may include memory registers for storing memory pointers, fetched data, etc. The local memory 119 may also include a read-only memory (ROM) for storing microcode, for example, the ROM may be an internal masked ROM in some embodiments. Although Figure 1A the illustrated memory subsystem 110 has been shown to include a memory subsystem controller 115, in another embodiment of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may rely on external control (e.g., provided by an external host, or provided by a processor or controller separate from the memory subsystem).

[0036] Generally, the memory subsystem controller 115 may receive commands or operations from the host system 120 and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations associated with the memory device 130, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical block addresses (e.g., logical block address (LBA), namespace) and physical addresses (e.g., physical block address). The memory subsystem controller 115 may further include host interface circuitry for communicating with the host system 120 via a physical host interface. The host interface circuitry may convert commands received from the host system into command instructions for accessing the memory device 130, and convert responses associated with the memory device 130 into information for the host system 120.

[0037] The memory subsystem 110 may also include additional circuitry or components not shown. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., a row decoder and a column decoder) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0038] In some embodiments, the memory device 130 includes a local media controller 135 that operates in conjunction with the memory subsystem controller 115 to perform operations on one or more memory cells of the memory device 130. An external controller (e.g., the memory subsystem controller 115) may manage the memory device 130 externally (e.g., perform media management operations on the memory device 130). In some embodiments, the memory device 130 is a managed memory device, which is an original memory device combined with a local controller (e.g., the local media controller 135) for memory management within the same memory device package or memory die. An example of a managed memory device is a managed NAND (MNAND) device. For example, the memory device 130 may represent a single die or multiple dies with some control logic (e.g., the local media controller 135) embodied thereon. In some embodiments, one or more components of the memory subsystem 110 are omitted.

[0039] In some embodiments, the memory device 130 includes registers 138 in which information (e.g., parameters that may be stored permanently and that guide different stages of the firmware boot of the memory device 130) accessed by the controller 115 during the boot process is stored. For example, these parameters may include, but are not limited to, the PCIe link speed and lane configuration for accessing the boot partition (see Figure 2 ). For example, these registers 138 may include one or more memory-mapped I / O registers or sticky registers.

[0040] In various embodiments, controller 115 includes a memory interface component 113. The memory interface component 113 is responsible for handling the interaction of the memory subsystem controller 115 with the memory devices (e.g., memory device 130) of the memory subsystem 110. For example, the memory interface component 113 may send memory access commands (e.g., programming commands, read commands, or other commands) corresponding to requests received from the host system 120 to the memory device 130. Additionally, the memory interface component 113 may receive data from the memory device 130, such as data retrieved in response to an acknowledgement that a read command or programming command has been successfully executed. In some embodiments, the memory subsystem controller 115 includes at least a portion of the memory interface 113. For example, the controller 115 may include a processor 117 (e.g., a processing device) configured to execute instructions stored in local memory 119 for performing the operations described herein. In some embodiments, the memory interface component 113 is part of the host system 120, an application, or an operating system.

[0041] Figure 1B is according to some embodiments Figure 1A is a block diagram of a PCIe NVM memory overlay in the memory device 130. In some embodiments, at least one boot partition exists on the memory device 130 to store additional firmware for booting the memory device 130 and other system data and instructions for initializing and operating the OS. More specifically, in some embodiments and by way of example, the boot partition memory overlay 160 includes a boot program code (e.g., boot code 162), a boot loader code 164, an OS kernel 166, and a file system 168. At least some of this firmware and these instructions are used by the PCIe NAND device to initialize and boot the memory subsystem 110 for host access and will be referred to hereinafter.

[0042] Figure 2 is a flowchart of a method 200 for fast boot by optimizing boot partition access and phased loading of firmware from an NVM device according to various embodiments. The method 200 may be executed by processing logic, which may include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executing on a processing device), or a combination thereof. In some embodiments, the method 200 is performed by Figure 1AThe memory interface 113 and / or the processor 117 execute. In addition to the NVM internal firmware boot sequence executed by the controller 115, method 200 will be explained in the context of overall memory subsystem operation. Although shown in a specific order or sequence, the order of the processes can be modified unless otherwise specified. Accordingly, the illustrated embodiments should be understood as merely examples, and the illustrated processes can be executed in different orders, and some processes can be executed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible.

[0043] At operation 205, the memory subsystem 110 is powered on, which can trigger a boot sequence in which the controller 115 seeks boot firmware or code to execute that will load initial hardware parameters to enable access to further firmware and / or software for bringing the memory subsystem 110 fully online.

[0044] At operation 210, the memory device 130, which is a NVM memory device, is powered on with a delay that is minimal compared to the delay required to power on the entire memory subsystem.

[0045] At operation 215, the processing logic retrieves ROM code from the internal read-only memory (ROM) of the processing device (e.g., the controller 115). In some embodiments, this is the internal masked ROM of the controller 115.

[0046] At operation 220, the processing logic executes the ROM code to load the boot code 162 from the memory device 130 into the embedded volatile memory (e.g., the local memory 119). In some embodiments, executing the ROM code causes detection of the hardware parameters associated with loading the boot code into the embedded volatile memory (e.g., the SRAM or TCM of the controller 115).

[0047] At operation 225, the processing logic executes the boot code 162 (or the boot program code) to load the first-stage firmware into the embedded volatile memory. For example, the boot code 162 can be boot program code configured to initialize the hardware of the memory subsystem 110.

[0048] At operation 230, the processing logic loads the first-stage firmware into the embedded volatile memory. In some embodiments, the first-stage firmware is stored on a type of NVM memory embedded on the motherboard of the controller 115, such as a ROM flash memory device. In some embodiments, the first-stage firmware includes boot partition support features that include Peripheral Component Interconnect Express (PCIe) and Non-Volatile Memory Express interface functionality.

[0049] At operation 240, the processing logic executes first-stage firmware to enable access to the boot partition of the memory device 130 before the processing device has full operational access to the memory device (which means that the host system 120 also does not have full operational access to the memory device 130). For example, at sub-operation 242, the processing device performs PCIe training for a single PCIe lane of the PCIe interface that exists between the host system 120 and the NVM memory device 130. In some embodiments, the first-stage firmware is executed to further initialize the single PCIe lane at a first-generation data rate (e.g., GEN1 speed that provides PCIe functionality as fast as possible during this fast boot process). Additionally, at sub-operation 244, the processing logic ensures boot partition access and initiates the boot of the memory device 130 from the boot partition 160 (see Figure 1B ). In some embodiments, the processing logic further retrieves the PCIe lane configuration and link speed from one or more memory-mapped I / O registers of the memory device (e.g., from register 138 (see Figure 1A )). The link speed of the single PCIe lane may be different from the link speeds of all the PCIe lanes that are subsequently trained for full data rate access to the memory device 130.

[0050] At operation 250, the processing logic begins the boot program phase, e.g., by executing the boot code 162 to load the boot loader code 164 from the boot partition 160 of the memory device into the system memory. In one embodiment, the system memory is the volatile memory (e.g., DRAM) of the memory device 140.

[0051] At operation 255, the processing logic executes the boot loader code 164 to load the OS 166 kernel into the system memory.

[0052] At operation 260, after executing the first-stage firmware, the processing logic loads the second-stage firmware into either the embedded volatile memory or the system memory. The second-stage firmware may preferably be loaded into the local memory 119 (e.g., SRAM) of the controller 115, but if it is too large for the local memory 119, it may be at least partially loaded into the system memory on the memory device 140 (e.g., in DRAM). In at least some embodiments, the second-stage firmware is loaded while at least one of the boot loader code or the OS kernel is being executed, thus enabling parallel download of the main boot firmware (e.g., here the second-stage firmware) while continuing with the OS boot process.

[0053] At operation 265, the processing logic executes second stage firmware to provide full operational access of the host system 120 to the memory device 130 at the maximum PCIe data speed. Thus, at sub-operation 267, the processing logic trains the PCIe links of the PCIe interface of the memory device 130 at the maximum PCIe speed. These link speeds can be retrieved from parameters stored in the registers 138 of the memory device 130.

[0054] At operation 270, the processing logic executes (or initiates) the OS kernel 166 from the system memory to initialize the boot of the OS (e.g., or other OS). At this time, the OS can control the entire memory subsystem 110 and provide full operational support to the host system 120 to access the memory device 130, e.g., by employing drivers.

[0055] Figure 3 is a flowchart of a method 300 for fast boot by optimizing boot partition access and phased loading of firmware from an NVM device. The method 300 can be executed by processing logic, which can include hardware (e.g., processing devices, circuitry, special logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions running or executing on a processing device), or a combination thereof. In some embodiments, the method 300 is executed by Figure 1A the memory interface 113 and / or the processor 117. Although shown in a particular order or sequence, the order of the process can be modified unless otherwise specified. Thus, the illustrated embodiments should be understood as merely examples, and the illustrated processes can be executed in a different order, and some processes can be executed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible.

[0056] At operation 310, in response to power-on of the memory device, the processing logic retrieves the ROM code from the internal read-only memory (ROM) of the processing device.

[0057] At operation 320, the processing logic executes the ROM code to load the boot code from the memory device into the embedded volatile memory of the processing device.

[0058] At operation 330, the processing logic executes the boot code to load the first stage firmware into the embedded volatile memory. In some embodiments, when the first stage firmware is executed, it enables access to the boot partition of the memory device before the processing logic has full operational access to the memory device.

[0059] Figure 4Illustrate an example machine of computer system 400, and a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein can be executed within the machine. In some embodiments, computer system 400 may correspond to a host system (e.g., Figure 1A host system 120), which includes, is coupled to, or utilizes a memory subsystem (e.g., Figure 1A memory subsystem 110). In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a server or client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0060] The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network appliance, server, network router, switch, or bridge, or any machine capable of executing a set of instructions (sequentially or otherwise) that specify actions to be taken by that machine. Moreover, although a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0061] Example computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 410 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 418, which communicate with each other via a bus 430.

[0062] Processing device 402 represents one or more general-purpose processing devices, such as a microprocessor, central processing unit, or the like. More specifically, processing device 402 can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or a processor implementing a combination of instruction sets. Processing device 402 can also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. Processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein. Computer system 400 may further include a network interface device 408 for communicating via network 420.

[0063] The data storage system 418 may include a machine-readable storage medium 424 (also referred to as a non-transitory computer-readable storage medium) having stored thereon one or more sets of instructions 426 or software embodying any one or more of the methodologies or functions described herein. The instructions 426 may also reside, completely or at least partially, within the main memory 404 and / or the processing device 402 during execution by the computer system 400, which also constitutes a machine-readable storage medium. The machine-readable storage medium 424, the data storage system 418, and / or the main memory 404 may correspond to Figures 1A to 1B the memory subsystem 110 of

[0064] In one embodiment, the instructions 426 include instructions for implementing the functionality corresponding to Figure 1A the memory interface 113 of

[0065] Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, items, numbers, or the like.

[0066] However, it should be borne in mind that all of these terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may relate to the actions and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the registers and memories of the computer system and transforms them into other data similarly represented as physical quantities within the computer system memory or registers or other such information storage systems.

[0067] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. This computer program may be stored in a non-transitory computer-readable storage medium, such as but not limited to any type of disk, including floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0068] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. The structure of a variety of these systems will appear as will be set forth in the description below. Additionally, the present disclosure has been described without reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the present disclosure as described herein.

[0069] The present disclosure may be provided as a computer program product or software that includes machine-readable media having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process in accordance with the present disclosure. Machine-readable media includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, machine-readable (e.g., computer-readable) media includes machine (e.g., computer) readable storage media such as read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory components, and the like.

[0070] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments of the present disclosure as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A memory subsystem comprising: a memory device comprising a non-volatile memory; and a processing device operably coupled to the memory device and a host system, wherein the processing device includes embedded volatile memory and is configured to perform operations including: Retrieving ROM code from an internal read-only memory ROM of the processing device in response to power-on of the memory subsystem; executing the ROM code to load boot code from the memory device into the embedded volatile memory; and The boot code is executed to load first stage firmware into the embedded volatile memory, wherein the first stage firmware is used to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device. 2 . The memory subsystem of claim 1 , wherein the boot code is a boot program code configured to initialize hardware of the memory subsystem.

3. The memory subsystem of claim 1 , wherein the embedded volatile memory comprises static random access memory (SRAM), and wherein executing the ROM code causes detection of hardware parameters associated with loading the boot code into the SRAM.

4. The memory subsystem of claim 1 , wherein the first stage firmware includes a boot partition support feature, the boot partition support feature including peripheral component interconnect express (PCIe) and non-volatile memory express (NVMe). Interface functionality.

5. The memory subsystem of claim 1, further comprising a PCIe interface coupled between the processing device and the host system, wherein the operations further comprise executing the first stage firmware to: performing PCIe training of a single PCIe lane of the PCIe interface; and Initiate the memory device from the boot partition guide.

6. The memory subsystem of claim 5, wherein executing the first stage firmware is further used to initialize the single PCIe lane at a first generation data rate, the operation further comprising retrieving the PCIe lane configuration and link speed from one or more memory mapped I / O registers of the memory device.

7. The memory subsystem of claim 1 , wherein the operations further comprise: After executing the first stage firmware, loading a second stage firmware into one of the embedded volatile memory or a system memory; and The second stage firmware is executed to provide the host system with full operational access to the memory device, including training a PCIe link of a PCIe interface of the memory device at a maximum PCIe speed.

8. The memory subsystem of claim 7, wherein the operations further comprise: loading, via execution of the boot code, boot loader code from a boot partition of the memory device into the system memory; Executing the boot loader code to load an operating system (OS) kernel into the system memory; and The OS kernel is executed to initialize booting of the OS, wherein the second stage firmware is loaded while at least one of the boot loader code or the OS kernel is executed.

9. A method comprising: Retrieving, by the processing device in response to powering on the memory device, ROM code from an internal read-only memory ROM of the processing device; executing the ROM code to load boot code from the memory device into an embedded volatile memory of the processing device; and The boot code is executed to load first stage firmware into the embedded volatile memory, wherein the first stage firmware is used to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device.

10. The method of claim 9, wherein the boot code is a boot program code configured to initialize hardware of a memory subsystem containing the memory device.

11. The method of claim 9, wherein executing the ROM code causes detection of hardware parameters associated with loading the boot code into the embedded volatile memory.

12. The method of claim 9, further comprising executing the first stage firmware to cause: performing PCIe training of a single PCIe lane of the PCIe interface; and Initiate the memory device from the boot partition guide.

13. The method of claim 12, wherein executing the first stage firmware is further used to initialize the single PCIe lane at a first generation data rate, the method further comprising retrieving a PCIe lane configuration and a link speed from one or more memory mapped I / O registers of the memory device.

14. The method according to claim 9, further comprising: After executing the first stage firmware, loading a second stage firmware into one of the embedded volatile memory or a system memory; and The second stage firmware is executed to provide the host system with full operational access to the memory device, including training a PCIe link of a PCIe interface of the memory device at a maximum PCIe speed.

15. The method according to claim 14, further comprising: loading, via execution of the boot code, boot loader code from a boot partition of the memory device into the system memory; Executing the boot loader code to load an operating system (OS) kernel into the system memory; and The OS kernel is executed to initialize booting of the OS, wherein the second stage firmware is loaded while at least one of the boot loader code or the OS kernel is executed.

16. A non-transitory computer-readable storage medium storing instructions that, when executed by a processing device of a memory subsystem, cause the processing device to perform operations comprising: Retrieving ROM code from an internal read-only memory ROM of the processing device in response to power-on of the memory subsystem; executing the ROM code to load boot code from a memory device of the memory subsystem into an embedded volatile memory of the processing device; and The boot code is executed to load first stage firmware into the embedded volatile memory, wherein the first stage firmware is used to enable access to a boot partition of the memory device before the processing device has full operational access to the memory device.

17. The non-transitory computer-readable storage medium of claim 16, wherein the boot code is a boot program code configured to initialize hardware of the memory subsystem, and wherein executing the ROM code causes detection of hardware parameters associated with loading the boot code into the embedded volatile memory.

18. The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise executing the first stage firmware to cause: performing PCIe training of a single PCIe lane of a PCIe interface, wherein training the single PCIe lane comprises operating at a first generation data rate; Initiate the memory device from the boot partition guide; and The PCIe lane configuration and link speed are retrieved from one or more memory mapped I / O registers of the memory device.

19. The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise: After executing the first stage firmware, loading a second stage firmware into one of the embedded volatile memory or a system memory; and The second stage firmware is executed to provide a host system with full operational access to the memory device, including training a PCIe link of a PCIe interface of the memory device at a maximum PCIe speed.

20. The non-transitory computer-readable storage medium of claim 19, wherein the operations further comprise: loading, via execution of the boot code, boot loader code from a boot partition of the memory device into the system memory; Executing the boot loader code to load an operating system (OS) kernel into the system memory; and The OS kernel is executed to initialize booting of the OS, wherein the second stage firmware is loaded while at least one of the boot loader code or the OS kernel is executed.

Images