Unified command transfer for managed memory

By combining multiple boot commands into a single command transmission using unified command transmission technology, the problems of high latency and low bandwidth availability of memory devices in the boot program are solved, enabling more efficient memory operations and improving the performance of electronic devices.

CN120973296APending Publication Date: 2025-11-18MICRON TECHNOLOGY INC
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202510626442.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2025-04-17
Filing Date
2025-05-15
Publication Date
2025-11-18

AI Technical Summary

Technical Problem

In the prior art, when a memory device executes a bootloader, the configuration of a single boot command leads to high latency and reduced bandwidth availability, making it unable to effectively support the parallel execution of multiple boot commands.

Method used

By employing a unified command transmission technology, multiple boot commands of the same type are combined into a single command and transmitted to the memory system through the host system. The memory system then performs parallel operations without system interruption, reducing latency and improving bandwidth availability.

Benefits of technology

By using unified command transmission technology, the execution latency of the bootloader is reduced, the bandwidth availability of the memory system is improved, and the processing power and user experience of electronic devices are enhanced.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120973296A_ABST
    Figure CN120973296A_ABST
Patent Text Reader

Abstract

The invention relates to unified command transfer for managed memory. A host system may be configured to transmit a unified command transfer including a plurality of boot commands of the same type to a memory system for executing a boot program of the memory system. A boot loader (e.g., system boot software) may support generation of the unified command transfer such that a host command manager may transfer the unified command transfer to the memory system. The memory system may receive the unified command transfer and perform a boot operation associated with the unified command transfer. In some cases, performing the boot operations may include sequentially performing each boot operation on a single system interrupt. The memory system may transmit information associated with the boot operation back to the host command manager in a message, and the host command manager may transmit an indication of the message to the boot loader.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross-reference

[0002] The present patent application claims priority to U.S. Patent Application No. 19 / 182,508 to Huo et al., titled “UNIFIED COMMAND TRANSMISSION FOR MANAGED MEMORY,” filed April 17, 2025, and U.S. Patent Application No. 63 / 648,559 to Huo et al., titled “UNIFIED COMMAND TRANSMISSION FOR MANAGED MEMORY,” filed May 16, 2024, each of which is assigned to the assignee hereof and each of which is hereby expressly incorporated by reference herein in its entirety. TECHNICAL FIELD

[0003] The technical field relates to unified command transmission for managed memory. BACKGROUND

[0004] Memory devices are widely used to store information in computers, user devices, wireless communications devices, cameras, digital displays, and other devices. Information is stored by programming memory cells within a memory device to various states. For example, binary memory cells can be programmed to one of two supported states, typically represented by a logic 1 or a logic 0. In some examples, individual memory cells can support more than two states, any of which can be stored. To access stored information, a memory device can read (e.g., sense, detect, retrieve, determine) a state from a memory cell. To store information, a memory device can write (e.g., program, set, assign) a state to a memory cell.

[0005] There are a variety of types of memory devices, including magnetic hard disks, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), self- selecting memory, chalcogenide memory technology, or non-volatile (NOR) and negative- and (NAND) memory devices, among others. Memory cells can be described in terms of volatile or non-volatile configurations. Memory cells configured in non-volatile configurations can maintain a stored logical state for long periods of time even in the absence of an external power source. Memory cells configured in volatile configurations lose stored state when disconnected from an external power source. SUMMARY

[0006] A host device is described. The host device can include processing circuitry associated with one or more memory devices and configured to cause the host device to transmit a first message comprising a plurality of commands to a memory device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and receive one or more second messages comprising information for each command of the plurality of commands from the memory device based at least in part on transmitting the first message.

[0007] A memory device is described. The memory device can include one or more memory arrays; and processing circuitry coupled with the one or more memory arrays and configured to cause the memory device to receive a first message comprising a plurality of commands from a host device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and transmit one or more second messages comprising information associated with each command of the plurality of commands to the host device based at least in part on receiving the first message.

[0008] A method at a host device is described. The method can include transmitting a first message comprising a plurality of commands to a memory device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and receiving one or more second messages comprising information for each command of the plurality of commands from the memory device based at least in part on transmitting the first message.

[0009] A method at a memory device is described. The method can include receiving a first message comprising a plurality of commands from a host device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and transmitting one or more second messages comprising information associated with each command of the plurality of commands to the host device based at least in part on receiving the first message.

[0010] A method at a bootloader is described. The method can include allocating a buffer for a plurality of commands, wherein each command of the plurality of commands comprises a same type of command; loading the plurality of commands into the buffer; providing a message comprising an indication of the buffer to a host command manager based at least in part on loading the plurality of commands into the buffer; and obtaining information associated with each of the plurality of commands from the host command manager. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 An example of a system supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0012] Figure 2 An example of a system supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0013] Figure 3 An example of a process flow supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0014] Figure 4 An example of a command graph supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0015] Figure 5 An example of a process flow supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0016] Figure 6 A block diagram of a host device supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0017] Figure 7 A block diagram of a memory device supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0018] Figure 8 A block diagram of a bootloader supporting unified command transfer for managed memory according to examples disclosed herein is shown.

[0019] Figures 9 to 11 A flow diagram illustrating one or more methods supporting unified command transfer for managed memory according to examples disclosed herein is shown. DETAILED DESCRIPTION

[0020] In some systems, a host system can be configured to initiate a boot program (e.g., power-on program, initialization program, system boot phase) to one or more memory devices of a memory system. The host system can include a host system controller including a boot loader (e.g., system startup software including a boot loader, system kernel startup, application / library loader operable during a system boot phase) and a host command manager configured to perform operations identified by the boot loader. That is, the boot loader can be software including instructions associated with performing a boot program at one or more memory devices, and the host command manager can be configured to execute the instructions of the boot loader. For example, the boot loader can be configured to identify boot operations performed by one or more memory devices and boot commands corresponding to the boot operations, and the host command manager can be configured to transmit the boot commands to the memory system based on accessing the boot loader (e.g., receiving the commands from the boot loader).

[0021] However, in some cases, the boot loader can not support multiple boot commands due to a queue length of the boot loader configured for a single boot command. In some such cases, the boot loader can identify and indicate to the host command manager each boot command associated with the boot program, such that the host command manager can transmit each boot command to cause one or more memory devices to individually perform. For example, performing each boot operation (e.g., corresponding to each boot command) at one or more memory devices can include sequentially receiving each boot command, sequentially performing each boot operation (e.g., accessing one or more memory arrays), and sequentially transmitting information (e.g., completion indication, data) associated with each boot operation to the host command manager. In some implementations, performing each boot operation can result in a system interruption completing and responding to each boot command, resulting in an increased latency. Accordingly, individually transmitting each boot command, individually performing each boot operation, and responding to each boot command can be associated with a relatively high latency, resulting in a reduced bandwidth availability during performing the boot program.

[0022] According to examples described herein, a system can support unified command transmission. Unified command transmission can be used, for example, to perform a boot procedure of a memory system. According to various aspects, a host system can be configured to transmit a single command that includes multiple commands of a same type (e.g., associated with a boot procedure) to a memory system. For example, a unified command transmission can include multiple boot commands associated with a same type of boot operation. In some examples, a unified command transmission can include multiple memory device profile query commands (e.g., Universal Flash Storage (UFS) query commands), multiple memory device provisioning commands (e.g., UFS interconnect commands (UICs)), or multiple memory device access commands (e.g., read commands, write commands). In some such examples, the memory device profile query commands and the memory device access commands can be associated with accessing one or more memory arrays of the memory system. In some other examples, the memory device profile query commands and the memory device provisioning commands can be associated with operations other than accessing the one or more memory arrays.

[0023] In some cases, a boot loader can support generating a unified command transmission such that a host command manager can transmit the unified command transmission to one or more memory devices. For example, a boot loader can identify each boot command associated with a boot procedure and group the boot commands associated with each type of boot operation. The boot loader can allocate a buffer and load the boot commands of a same type into the buffer, then transmit an indication of the buffer (e.g., a unified command transmission) to the host command manager, from which the host command manager can transmit the unified command transmission (e.g., a message including the boot commands) to the memory system. The memory system can receive the unified command transmission and perform the operations associated with the unified command transmission. In some cases, performing the operations can include sequentially performing each operation (e.g., accessing one or more memory devices, accessing memory system settings) and not cause a system interrupt for each operation, such that the unified command transmission can be associated with a single system interrupt. The memory system can transmit information (e.g., completion indications, data) associated with the operations back to the host command manager in one or more messages, and the host command manager can transmit an indication of the information to the boot loader. Thus, performing a boot procedure based on a unified command transmission can be associated with reduced latency, resulting in relatively lower latency and increased bandwidth availability during performance of the boot procedure.

[0024] In addition to being applied in the memory systems described herein, the techniques for unified command transmission for managed memory can also generally be implemented to improve the performance of various electronic devices and systems, including artificial intelligence (AI) applications, augmented reality (AR) applications, virtual reality (VR) applications, and gaming. Some electronic device applications, including high-performance applications such as AI, AR, VR, and gaming, can be associated with relatively high processing requirements to meet user expectations. As such, improving the processing capabilities of electronic devices by reducing response times, improving power consumption, reducing complexity, increasing data processing amounts or access speeds, reducing communication times, or increasing memory capacity or density, among other performance metrics, can improve user experience or appeal. Implementing the techniques described herein can improve the performance of electronic devices by supporting the communication and execution of a single boot command that includes multiple sub-commands associated with individual operations of a boot program, which can reduce processing or latency time for executing a boot program, thereby improving user experience, among other benefits.

[0025] Features of the disclosure are illustrated and described in the context of systems, devices, and circuits. Features of the disclosure are further illustrated and described in the context of process flows, command diagrams, and flowcharts.

[0026] Figure 1 An example of a system 100 that supports unified command transmission for managed memory according to examples disclosed herein is shown. The system 100 includes a host system 105 coupled with a memory system 110. The system 100 can be included in a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle, an Internet of Things (IoT) enabled device, an embedded computer such as one included in a vehicle, industrial equipment, or a networked commercial device, or any other computing device that includes a memory and a processing device.

[0027] The memory system 110 can be or include any device or collection of devices that includes at least one memory array. For example, the memory system 110 can be or include a Universal Flash Storage (UFS) device, an Embedded Multimedia Controller (eMMC) device, a flash device, a Universal Serial Bus (USB) flash device, a Secure Digital (SD) card, a Solid State Drive (SSD), a Hard Disk Drive (HDD), a Dual In-Line Memory Module (DIMM), a Small Outline DIMM (SO-DIMM), or a Non-Volatile DIMM (NVDIMM), among other devices.

[0028] The system 100 can include a host system 105 that can be coupled with the memory system 110. In some examples, this coupling can include an interface with a host system controller 106, which can be an example of a controller or control component configured to cause the host system 105 to perform various operations in accordance with the examples described herein. The host system 105 can include one or more devices and, in some cases, can include a processor chipset and a software stack executed by the processor chipset. For example, the host system 105 can include an application configured for communication with the memory system 110 or a device therein. The processor chipset can include one or more cores, one or more caches (e.g., memory local to or included in the host system 105), a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a Peripheral Component Interconnect Express (PCIe) controller, a Serial Advanced Technology Attachment (SATA) controller). For example, the host system 105 can use the memory system 110 to write data to and read data from the memory system 110. Although Figure 1 Although one memory system 110 is shown, the host system 105 can be coupled with any number of memory systems 110.

[0029] The host system 105 can be coupled with the memory system 110 via at least one physical host interface. In some cases, the host system 105 and the memory system 110 can be configured to communicate (e.g., exchange or otherwise transfer control, address, data, and other signals between the memory system 110 and the host system 105) via the physical host interface using an associated protocol. Examples of physical host interfaces can include, but are not limited to, a SATA interface, a UFS interface, an eMMC interface, a PCIe interface, a USB interface, a Fibre Channel interface, a Small Computer System Interface (SCSI), a Serial Attached SCSI (SAS), a Double Data Rate (DDR) interface, a DIMM interface (e.g., a DIMM slot interface that supports DDR), an Open NAND Flash Interface (ONFI), and a Low Power Double Data Rate (LPDDR) interface. In some examples, one or more such interfaces can be included in or otherwise supported between a host system controller 106 of the host system 105 and a memory system controller 115 of the memory system 110. In some examples, the host system 105 can be coupled with the memory system 110 via a respective physical host interface of each memory device 130 included in the memory system 110 or via a respective physical host interface of each type of memory device 130 included in the memory system 110 (e.g., the host system controller 106 can be coupled with the memory system controller 115).

[0030] The memory system 110 can include a memory system controller 115 and one or more memory devices 130. The memory devices 130 can include one or more memory arrays of any type of memory cells (e.g., non-volatile memory cells, volatile memory cells, or any combination thereof). Although Figure 1 Two memory devices 130-a and 130-b are shown in the example of FIG. 1, the memory system 110 can include any number of memory devices 130. Moreover, if the memory system 110 includes more than one memory device 130, different memory devices 130 within the memory system 110 can include the same or different types of memory cells.

[0031] The memory system controller 115 can be coupled with and in communication with the host system 105 (e.g., via a physical host interface) and can be an example of a controller or control component configured to cause the memory system 110 to perform various operations in accordance with the examples described herein. The memory system controller 115 can also be coupled with and in communication with the memory devices 130 to perform operations at the memory devices 130 such as reading data, writing data, erasing data, or refreshing data, among other such operations, which can be collectively referred to as access operations. In some cases, the memory system controller 115 can receive commands from the host system 105 and communicate with the one or more memory devices 130 to execute such commands (e.g., at a memory array within the one or more memory devices 130). For example, the memory system controller 115 can receive a command or operation from the host system 105 and can convert the command or operation into instructions or appropriate commands to effectuate a desired access of the memory devices 130. In some cases, the memory system controller 115 can exchange data with the host system 105 and the one or more memory devices 130 (e.g., in response to or otherwise associated with a command from the host system 105). For example, the memory system controller 115 can convert a response (e.g., a data packet or other signal) associated with the memory devices 130 into a corresponding signal for the host system 105.

[0032] The memory system controller 115 can be configured for other operations associated with the memory devices 130. For example, the memory system controller 115 can perform or manage operations such as wear leveling operations, garbage collection operations, error control operations (e.g., error detection operations or error correction operations), encryption operations, caching operations, media management operations, background refresh, health monitoring, and address translation between logical addresses (e.g., logical block addresses (LBAs)) associated with commands from the host system 105 and physical addresses (e.g., physical block addresses) associated with memory cells within the memory devices 130.

[0033] The memory system controller 115 can include hardware such as one or more integrated circuits or discrete components, a buffer memory, or a combination thereof. The hardware can include circuitry with specialized (e.g., hard-coded) logic to perform the operations at tributed herein to the memory system controller 115. The memory system controller 115 can be or include a microcontroller, specialized logic circuitry (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a digital signal processor (DSP)), or any other suitable processor or processing circuitry.

[0034] The memory system controller 115 can also include a local memory 120. In some cases, the local memory 120 can include read-only memory (ROM) or other memory that can store operational code (e.g., executable instructions) that can be executed by the memory system controller 115 to perform the functions attributed herein to the memory system controller 115. In some cases, the local memory 120 can additionally or alternatively include static random access memory (SRAM) or other memory that can be used by the memory system controller 115 for internal storage or computation, e.g., related to the functions attributed herein to the memory system controller 115. Additionally or alternatively, the local memory 120 can be used as a cache for the memory system controller 115. For example, data can be stored in the local memory 120 when read from or written to the memory devices 130, and the data can be available within the local memory 120 for subsequent retrieval by or manipulation (e.g., updating) by the host system 105 (e.g., with reduced latency relative to the memory devices 130) according to a cache policy.

[0035] Although Figure 1 Although an example of the memory system 110 has been described as including the memory system controller 115, in some cases, the memory system 110 can not include the memory system controller 115. For example, the memory system 110 can additionally or alternatively rely on an external controller (e.g., implemented by the host system 105) or one or more local controllers 135 that can each be internal to the memory devices 130 to perform the functions attributed herein to the memory system controller 115. In general, one or more of the functions attributed herein to the memory system controller 115 can in some cases be performed instead by the host system 105, the local controllers 135, or any combination thereof. In some cases, a memory device 130 that is at least partially managed by the memory system controller 115 can be referred to as a managed memory device. An example of a managed memory device is a managed NAND (MNAND) device.

[0036] Memory devices 130 can include one or more arrays of non-volatile memory cells. For example, memory devices 130 can include NAND (e.g., NAND flash) memory, ROM, phase change memory (PCM), self-selecting memory, other chalcogenide-based memory, ferroelectric random access memory (FeRAM), magnetic RAM (MRAM), NOR (e.g., NOR flash) memory, spin-transfer torque (STT)-MRAM, conductive-bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), and electrically erasable programmable ROM (EEPROM), or any combination thereof. Additionally or alternatively, memory devices 130 can include one or more arrays of volatile memory cells. For example, memory devices 130 can include RAM memory cells, such as dynamic RAM (DRAM) memory cells and synchronous DRAM (SDRAM) memory cells.

[0037] In some examples, memory devices 130 can include (e.g., on the same die, within the same package) local controllers 135 that can perform operations on one or more memory cells of respective memory devices 130. Local controllers 135 can operate in conjunction with memory system controller 115 or can perform one or more functions attributed herein to memory system controller 115. For example, as explained in Figure 1 In some examples, memory devices 130-a can include local controller 135-a and memory devices 130-b can include local controller 135-b.

[0038] In some cases, memory devices 130 can be or include NAND devices (e.g., NAND flash devices). Memory devices 130 can be or include dies 160 (e.g., memory dies). For example, in some cases, memory devices 130 can be a package that includes one or more dies 160. In some examples, a die 160 can be a piece of electronic-grade semiconductor (e.g., a silicon die cut from a silicon wafer) that is cut from a wafer. Each die 160 can include one or more planes 165, and each plane 165 can include a respective set of blocks 170, where each block 170 can include a respective set of pages 175, and each page 175 can include a set of memory cells.

[0039] In some cases, the NAND memory devices 130 can include memory cells configured to each store one bit of information, which can be referred to as single-level cells (SLCs). Additionally or alternatively, the NAND memory devices 130 can include memory cells configured to each store multiple bits of information, which can be referred to as multi-level cells (MLCs) when configured to each store two bits of information, triple-level cells (TLCs) when configured to each store three bits of information, quad-level cells (QLCs) when configured to each store four bits of information, or more generally as multi-level memory cells. Multi-level memory cells can provide greater storage density relative to SLC memory cells, but in some cases can involve narrower read or write margins or greater complexity for supporting circuitry.

[0040] In some cases, a plane 165 can refer to a group of blocks 170, and in some cases, concurrent operations can be performed on different planes 165. For example, a concurrent operation can be performed on memory cells within different blocks 170, as long as the different blocks 170 are in different planes 165. In some cases, individual blocks 170 can be referred to as physical blocks, and a virtual block 180 can refer to a group of blocks 170 within which concurrent operations can occur. For example, concurrent operations can be performed on blocks 170-a, 170-b, 170-c, and 170-d within planes 165-a, 165-b, 165-c, and 165-d, respectively, and blocks 170-a, 170-b, 170-c, and 170-d can collectively be referred to as a virtual block 180. In some cases, a virtual block can include blocks 170 from different memory devices 130 (e.g., include blocks in one or more planes of memory device 130-a and memory device 130-b). In some cases, blocks 170 within a virtual block can have the same block address within their respective planes 165 (e.g., block 170-a can be “block 0” of plane 165-a, block 170-b can be “block 0” of plane 165-b, and so on). In some cases, performing concurrent operations in different planes 165 can be subject to one or more restrictions, such as performing concurrent operations on memory cells within different pages 175 that have the same page address within their respective planes 165 (e.g., related to command decoding, page address decoding circuitry, or other circuitry shared across planes 165).

[0041] In some cases, a block 170 can include memory cells organized into rows (pages 175) and columns (e.g., strings, not shown). For example, memory cells in the same page 175 can share a common word line (e.g., be coupled with a common word line), and memory cells in the same string can share a common digit line (which can alternatively be referred to as a bit line) (e.g., be coupled with a common digit line).

[0042] For some NAND architectures, memory cells can be read and programmed (e.g., written) at a first granularity level (e.g., at a page granularity level or a portion thereof) but erased at a second granularity level (e.g., at a block granularity level). That is, a page 175 can be a minimum unit of memory (e.g., a group of memory cells) that can be programmed or read independently (e.g., concurrently as part of a single program or read operation), and a block 170 can be a minimum unit of memory (e.g., a group of memory cells) that can be erased independently (e.g., concurrently as part of a single erase operation). Further, in some cases, a NAND memory cell can be erased before it can be overwritten with new data. Thus, for example, in some cases, a used page 175 can not be updated until the entire block 170 containing the page 175 is erased.

[0043] In some cases, the memory system 110 can utilize the memory system controller 115 to provide a managed memory system, which can include, for example, one or more memory arrays and related circuitry in combination with a local (e.g., on-die or in-package) controller (e.g., local controller 135). An example of a managed memory system is a managed NAND (MNAND) system.

[0044] In some systems, the host system 105 can be configured to initiate a boot procedure (e.g., power-on procedure, initialization procedure, system boot phase) on the memory system 110. The host system controller 106 can include a boot loader 107 (e.g., system startup software including a boot loader, system kernel startup, application / library loader that can operate during a system boot phase) and a host command manager 108 configured to perform operations identified by the boot loader 107. For example, the boot loader 107 can be firmware (e.g., software) of the memory system controller 115 including instructions associated with performing a boot procedure at the memory device 130, and the host command manager 108 can be configured to execute the instructions of the boot loader 107. In some cases, the boot loader 107 can be configured to identify boot operations performed by the memory device 130 and boot commands corresponding to the boot operations. In some such examples, the host command manager 108 can be configured to perform the boot commands by transmitting the boot commands to the memory system 110 based on accessing the boot loader 107 (e.g., receiving the commands from the boot loader). In some implementations, the boot loader 107 can transmit information (e.g., commands, instructions, data) to the host command manager 108. However, in other implementations, the host command manager 108 can be configured to access the boot loader 107 and execute information stored in the boot loader 107.

[0045] According to examples described herein, system 100 can support unified command transmission for performing a boot procedure of memory system 110. For example, host system 105 can be configured to transmit a single command to memory system 110 (e.g., memory system controller 115) that includes multiple boot commands of a same type. For instance, the unified command transmission can include multiple memory device configuration file query commands (e.g., UFS query commands), multiple memory device provisioning commands (e.g., UICs), or multiple memory device access commands (e.g., read commands, write commands) associated with a same type of boot operation, such that the unified command transmission can include multiple memory device configuration file query commands (e.g., UFS query commands), multiple memory device provisioning commands (e.g., UICs), or multiple memory device access commands (e.g., read commands, write commands). In some such examples, the memory device configuration file query commands and the memory device access commands can be associated with accessing one or more memory arrays (e.g., memory devices 130) of the memory system. In some other examples, the memory device configuration file query commands and the memory device provisioning commands can be associated with operations other than accessing one or more memory arrays.

[0046] In some cases, boot loader 107 can support generating a unified command transmission such that host command manager 108 can transmit the unified command transmission to memory system 110. For example, boot loader 107 can identify each boot command associated with a boot procedure and group the boot commands associated with each type of boot operation. Boot loader 107 can allocate a buffer and load the boot commands of a same type into the buffer, then transmit an indication of the buffer (e.g., a unified command transmission) to host command manager 108, from which host command manager 108 can transmit the unified command transmission (e.g., a message including the boot commands) to memory system 110. Memory system 110 can receive the unified command transmission and perform the boot operations associated with the unified command transmission. In some cases, performing the boot operations can include sequentially performing each boot operation and not cause a system interrupt for each boot operation, such that the unified command transmission can be associated with a single system interrupt (e.g., an interrupt of host command manager 108 after a response by memory system 110). Memory system 110 can transmit information (e.g., completion indications, data) associated with the boot operations back to host command manager 108 in one or more messages, and host command manager 108 can transmit an indication of the information to boot loader 107 in one or more messages. Thus, performing a boot procedure based on a unified command transmission can be associated with reduced latency, resulting in a relatively lower latency and increased bandwidth availability during performance of the boot procedure.

[0047] The system 100 can include any number of non-transitory computer- readable media that support unified command transport for managed memory. For example, the host system 105 (e.g., the host system controller 106), the memory system 110 (e.g., the memory system controller 115), or the memory device 130 (e.g., the local controller 135), or any combination thereof, can include or otherwise have access to one or more non-transitory computer-readable media that store instructions (e.g., firmware, logic, code) for performing the functions attributed herein to the host system 105, the memory system 110, or the memory device 130, or combinations thereof. For example, such instructions, when executed by the host system 105 (e.g., the host system controller 106), the memory system 110 (e.g., the memory system controller 115), or the memory device 130 (e.g., the local controller 135), can cause the host system 105, the memory system 110, or the memory device 130 to perform the associated functions described herein.

[0048] Figure 2 An example of a system 200 that supports unified command transport for managed memory in accordance with the examples disclosed herein is shown. The system 200 can be an example of the system 100 or aspects thereof described with reference to Figure 1 The system 200 can include a memory system 210 configured to store data received from a host system 205 and send data to the host system 205 upon request by the host system 205 using an access command (e.g., a read command or a write command). The system 200 can implement aspects of the system 100 described with reference to Figure 1 For example, the memory system 210 and the host system 205 can be examples of the memory system 110 and the host system 105, respectively.

[0049] The memory system 210 can include one or more memory devices 240 to store data transferred between the memory system 210 and the host system 205 (e.g., in response to receiving an access command from the host system 205). The memory devices 240 can include one or more memory devices described with reference to Figure 1 For example, the memory devices 240 can include NAND memory, PCM, self- selecting memory, 3D cross-point or other chalcogenide-based memory, FERAM, MRAM, NOR (e.g., NOR flash) memory, STT-MRAM, CBRAM, RRAM, or OxRAM, among other examples.

[0050] Memory system 210 can include a storage controller 230 for controlling data to be transferred directly to and from memory devices 240 (e.g., for storing data, for retrieving data, for determining memory locations in which data is stored and from which data is retrieved). Storage controller 230 can communicate directly with memory devices 240, or via a bus (not shown), which can include using protocols specific to each type of memory device 240. In some cases, a single storage controller 230 can be used to control multiple memory devices 240 of the same or different types. In some cases, memory system 210 can include multiple storage controllers 230 (e.g., a different storage controller 230 for each type of memory device 240). In some cases, storage controller 230 can implement the aspects of local controller 135 described with reference to Figure 1 Aspects of local controller 135 are described.

[0051] Memory system 210 can include an interface 220 for communicating with host system 205 and a buffer 225 for temporarily storing data transferred between host system 205 and memory devices 240. Interface 220, buffer 225, and storage controller 230 can support translating data between host system 205 and memory devices 240 (e.g., as shown by data path 250) and can be collectively referred to as data path components.

[0052] Temporarily storing data using buffer 225 during transfer can allow data to be buffered while a command is processed, which can reduce latency between commands and can support arbitrary data sizes associated with a command. This can also allow for handling of command bursts, and buffered data can be stored or transmitted or both (e.g., after a burst stops). Buffer 225 can include relatively fast memory (e.g., some type of volatile memory, such as SRAM or DRAM) or a hardware accelerator or both to allow data to be stored to and retrieved from buffer 225 quickly. Buffer 225 can include data path switching components for bidirectional data transfer between buffer 225 and other components.

[0053] Data being temporarily stored in buffer 225 can refer to data being stored in buffer 225 during execution of an access command. For example, after an access command is completed, the associated data can no longer be saved in buffer 225 (e.g., can be overwritten with data for an additional access command). In some examples, buffer 225 can be a non-cached buffer. For example, data can not be read directly from buffer 225 by host system 205. In some examples, a read command can be added to a queue without an address matching operation (e.g., without a cache address match or lookup operation) having already been performed on an address of buffer 225.

[0054] The memory system 210 can also include a memory system controller 215 for executing commands received from the host system 205, which can include controlling data path components for data movement. The memory system controller 215 can be a reference Figure 1 The example memory system controller 115 described. The bus 235 can be used for communication between system components.

[0055] In some cases, one or more queues (e.g., command queue 260, buffer queue 265, storage queue 270) can be used to control the processing of access commands and movement of corresponding data. For example, if more than one access command from the host system 205 is processed concurrently by the memory system 210, this can be beneficial. As an example of a possible implementation, the command queue 260, buffer queue 265, and storage queue 270 are depicted at the interface 220, memory system controller 215, and storage controller 230, respectively. However, the queues can be located anywhere within the memory system 210 when implemented.

[0056] Data communicated between the host system 205 and the memory device 240 can pass in the memory system 210 along a different path than non-data information (e.g., commands, status information). For example, system components in the memory system 210 can communicate with each other using the bus 235, while data can pass through data path components using the data path 250 rather than the bus 235. The memory system controller 215 can control how and whether data is communicated between the host system 205 and the memory device 240 by communicating with data path components via the bus 235 (e.g., using a protocol specific to the memory system 210).

[0057] If the host system 205 transmits an access command to the memory system 210, the command can be received by the interface 220 (e.g., according to a protocol, such as the UFS protocol or the eMMC protocol). Thus, the interface 220 can be considered a front end of the memory system 210. After receiving each access command, the interface 220 can communicate the command to the memory system controller 215 (e.g., via the bus 235). In some cases, each command can be added to the command queue 260 by the interface 220 to communicate the command to the memory system controller 215.

[0058] The memory system controller 215 can determine that an access command has been received based on a communication from the interface 220. In some cases, the memory system controller 215 can determine that an access command has been received by retrieving a command from the command queue 260. The command can be removed from the command queue 260 after it is retrieved (e.g., by the memory system controller 215). In some cases, the memory system controller 215 can cause the interface 220 to remove the command from the command queue 260 (e.g., via the bus 235).

[0059] After determining that an access command is received, the memory system controller 215 can execute the access command. For a read command, this can include obtaining data from one or more memory devices 240 and transmitting the data to the host system 205. For a write command, this can include receiving data from the host system 205 and moving the data to one or more memory devices 240. In either case, the memory system controller 215 can use the buffer 225 to temporarily store data received from or sent to the host system 205, among other things. The buffer 225 can be considered a mid-end of the memory system 210. In some cases, buffer address management (e.g., pointers to address locations in the buffer 225) can be performed by hardware (e.g., dedicated circuitry) in the interface 220, the buffer 225, or the memory controller 230.

[0060] To handle write commands received from the host system 205, the memory system controller 215 can determine whether the buffer 225 has sufficient available space for storing data associated with the commands. For example, the memory system controller 215 can determine (e.g., via firmware, via controller firmware) an amount of space within the buffer 225 that is available for storing data associated with a write command.

[0061] In some cases, a buffer queue 265 can be used to control the flow of commands associated with data stored in the buffer 225, including write commands. The buffer queue 265 can include access commands associated with data currently stored in the buffer 225. In some cases, commands in the command queue 260 can be moved by the memory system controller 215 to the buffer queue 265 and can remain in the buffer queue 265 while associated data is stored in the buffer 225. In some cases, each command in the buffer queue 265 can be associated with an address at the buffer 225. For example, a pointer can be maintained that indicates where data associated with each command is stored in the buffer 225. Using the buffer queue 265, multiple access commands can be received sequentially from the host system 205 and at least a portion of the access commands can be processed concurrently.

[0062] If the buffer 225 has sufficient space for storing the write data, the memory system controller 215 can cause the interface 220 to transmit an availability indication to the host system 205 (e.g., a "transfer ready" indication), which can be performed in accordance with a protocol (e.g., UFS protocol, eMMC protocol). When the interface 220 receives data associated with a write command from the host system 205, the interface 220 can transfer the data to the buffer 225 for temporary storage using the data path 250. In some cases, the interface 220 can obtain a location within the buffer 225 to store the data (e.g., from the buffer 225, from the buffer queue 265). The interface 220 can indicate to the memory system controller 215 (e.g., via the bus 235) whether the data transfer to the buffer 225 has completed.

[0063] After the write data is stored in the buffer 225 by the interface 220, the data can be transferred out of the buffer 225 and stored in the memory devices 240, which can involve operations of the storage controller 230. For example, the memory system controller 215 can cause the storage controller 230 to retrieve the data from the buffer 225 using the data path 250 and transfer the data to the memory devices 240. The storage controller 230 can be considered a back end of the memory system 210. The storage controller 230 can indicate to the memory system controller 215 (e.g., via the bus 235) whether the data transfer to the one or more memory devices 240 has completed.

[0064] In some cases, the storage queue 270 can support write data transfer. For example, the memory system controller 215 can push a write command from the buffer queue 265 to the storage queue 270 (e.g., via the bus 235) for processing. The storage queue 270 can include an entry for each access command. In some examples, the storage queue 270 can additionally include a buffer pointer (e.g., address) that can indicate a location in the buffer 225 where data associated with the command is stored and a storage pointer (e.g., address) that can indicate a location in the memory devices 240 associated with the data. In some cases, the storage controller 230 can obtain a location within the buffer 225 from which to obtain the data (e.g., from the buffer 225, from the buffer queue 265, from the storage queue 270). The storage controller 230 can manage locations within the memory devices 240 to store the data (e.g., perform wear leveling, perform garbage collection). Entries can be added to the storage queue 270 (e.g., by the memory system controller 215). Entries can be removed from the storage queue 270 (e.g., by the storage controller 230, by the memory system controller 215) after the data transfer is complete.

[0065] To handle a read command received from the host system 205, the memory system controller 215 can determine whether the buffer 225 has sufficient available space for storing data associated with the command. For example, the memory system controller 215 can determine (e.g., via firmware, via controller firmware) an amount of space within the buffer 225 that is available for storing data associated with the read command.

[0066] In some cases, the buffer queue 265 can support buffered storage of data associated with read commands in a similar manner as discussed with respect to write commands. For example, if the buffer 225 has sufficient space for storing read data, the memory system controller 215 can cause the storage controller 230 to retrieve data associated with a read command from the memory devices 240 and store the data in the buffer 225 for temporary storage using the data path 250. The storage controller 230 can indicate to the memory system controller 215 (e.g., via the bus 235) when the transfer of data to the buffer 225 has completed.

[0067] In some cases, the storage queue 270 can be used to facilitate read data transfer. For example, the memory system controller 215 can push a read command to the storage queue 270 for processing. In some cases, the storage controller 230 can obtain (e.g., from the buffer 225, from the storage queue 270) a location within one or more memory devices 240 from which to retrieve data. In some cases, the storage controller 230 can obtain (e.g., from the buffer queue 265) a location within the buffer 225 to store data. In some cases, the storage controller 230 can obtain (e.g., from the storage queue 270) a location within the buffer 225 to store data. In some cases, the memory system controller 215 can move a command processed by the storage queue 270 back to the command queue 260.

[0068] After data is stored in the buffer 225 by the storage controller 230, the data can be transferred from the buffer 225 and sent to the host system 205. For example, the memory system controller 215 can cause the interface 220 to retrieve data from the buffer 225 using the data path 250 and transmit the data to the host system 205 (e.g., in accordance with a protocol such as the UFS protocol or the eMMC protocol). For example, the interface 220 can process a command from the command queue 260 and can indicate to the memory system controller 215 (e.g., via the bus 235) that the transfer of data to the host system 205 has completed.

[0069] The memory system controller 215 can execute the received commands according to an order (e.g., a first-in, first-out order, an order according to the command queue 260). For each command, the memory system controller 215 can cause data corresponding to the command to move into and out of the buffer 225, as discussed herein. While data is moving into the buffer 225 and stored within the buffer 225, the command can remain in the buffer queue 265. If processing of the command is complete (e.g., if data corresponding to an access command has been transferred out of the buffer 225), the command can be removed (e.g., by the memory system controller 215) from the buffer queue 265. If a command is removed from the buffer queue 265, an address previously storing data associated with this command can be used to store data associated with a new command.

[0070] In some examples, the memory system controller 215 can be configured for operations associated with one or more memory devices 240. For example, the memory system controller 215 can perform or manage operations such as wear leveling operations, garbage collection operations, error control operations such as error detection operations or error correction operations, encryption operations, caching operations, media management operations, background refresh, health monitoring, and address translation between logical addresses (e.g., LBAs) associated with commands from the host system 205 and physical addresses (e.g., physical block addresses) associated with memory cells within the memory devices 240. For example, the host system 205 can issue a command indicating one or more LBAs and the memory system controller 215 can identify one or more physical block addresses indicated by the LBAs. In some cases, one or more consecutive LBAs can correspond to non-consecutive physical block addresses. In some cases, the storage controller 230 can be configured to perform one or more of the described operations in conjunction with or in place of the memory system controller 215. In some cases, the memory system controller 215 can perform the functions of the storage controller 230 and the storage controller 230 can be omitted.

[0071] Figure 3 An example of a process flow 300 that supports unified command transmission for managed memory in accordance with examples disclosed herein is shown. The process flow 300 can illustrate aspects of or operations of a system, which can be an example of the system 100 or the system 200 described with reference to Figure 1 and 2 respectively. For example, the process flow 300 can be implemented by the host system 105 or 205 and the memory system 110 or 210 described with reference to Figure 1 or 2. Furthermore, some processes or operations of the process flow 300 can be performed by the host system 105 or 205 and the memory system 110 or 210 described with reference to Figure 1The described boot loader 107 (e.g., system startup software including a boot loader, system kernel startup, application / library loader operable during a system boot phase) and host command manager 108 are implemented at. Process flow 300 illustrates operations associated with performing a boot procedure on system 100 based on a unified command transfer.

[0072] In the following description of process flow 300, the methods, techniques, processes, and operations can be performed in different orders or at different times. Further, some operations can be excluded from process flow 300, or other operations can be added to process flow 300. Aspects of process flow 300 can be implemented by memory system controller 115 or host system controller 106, which can include boot loader 107 and host command manager 108, as described with reference to Figure 1 Additionally or alternatively, aspects of process flow 300 can be implemented as instructions (e.g., firmware) stored in a memory. For example, the instructions, when executed by a controller (e.g., a processor, host system controller 106, memory system controller 115, local controller 135) can cause the controller to perform the operations of process flow 300.

[0073] Process flow 300 can illustrate operations associated with performing a boot procedure on memory system 110 based on a unified command transfer transmitted from host system 105. The boot procedure can be a power-up procedure or a startup procedure to cause memory system 110 to change from an initial power level to an operational power level (e.g., associated with normal operation of memory system 110) or from an initial processing level to an operational processing level (e.g., associated with normal operation of memory system 110). Memory system 110 can include one or more memory devices, which can be as described with reference to Figure 1or 2. Each memory device can include one or more memory arrays of memory cells. For example, each memory device can be a non-volatile memory device (e.g., a NAND memory device) including one or more non-volatile memory arrays (e.g., NAND memory arrays) of non-volatile memory cells (e.g., NAND memory cells). Additionally, the memory system 110 can include a memory system controller 115 configured to facilitate and perform operations on the one or more memory devices. In some cases, the memory system 110 can be an instance of a UFS system such that the memory system 110 can include a certain number of controllers, processors, and interfaces for facilitating and performing operations of the memory system 110. For example, the memory system controller 115 can include a UFS interface coupled with the host system 105. In some cases, the system can include a memory physical connection interface 301, such as a UFS interface, coupling the host system 105 and the memory system 110. The host system 105 and the memory system 110 can be configured to communicate via the memory physical connection interface 301 using command descriptors, such as UFS protocol information units (UPIUs).

[0074] The host system 105 can include a host system controller 106 including a bootloader 107 and a host command manager 108. The bootloader 107 can be firmware (e.g., system startup software) including instructions that can be executed or transferred to the host command manager 108. In some cases, the bootloader 107 can include one or more processors configured to modify instructions stored at the bootloader 107. For example, the bootloader 107 can be or include a bootloader, a system kernel startup, or loading of an application or system library. The host command manager 108 can be configured to perform operations or transfer and communicate commands on behalf of the host system 105 based on received commands. For example, the host command manager 108 can transfer commands indicated in instructions of the bootloader 107 to the memory system controller 115. In some cases, (e.g., when the memory system 110 is a UFS system), the host command manager 108 can be coupled with and configured to communicate with the memory system controller 115 via the memory physical connection interface 301.

[0075] At 305, the bootloader 107 can identify a condition associated with initiating a boot procedure for the memory system 110. For example, the bootloader 107 can detect a power-up procedure or a start-up procedure associated with the memory system 110. In some implementations, the bootloader 107 can detect a change in an initial power level or an initial processing level of the memory system 110 and determine that a boot procedure is initiated. That is, the bootloader 107 can receive information from one or more sensors of the memory system 110 and can initiate a boot procedure based on a change in a value indicated by the one or more sensors. For example, the bootloader 107 can receive an indication of an initial power level or an initial processing level and, after determining that a change in the initial power level or the initial processing level satisfies a threshold, the bootloader 107 can determine that a boot procedure is initiated. In some cases, the bootloader 107 can identify an input received from a user of the host system 105 and determine that a boot procedure is initiated.

[0076] At 310, the bootloader 107 can identify operations associated with performing a boot procedure for the memory system 110. In some cases, the bootloader 107 can store instructions including a list of operations performed at the memory system 110 during a boot procedure (e.g., to complete a boot procedure at the memory system 110). In some examples, the operations can include a memory device profile query operation, such as a UFS query operation. In some such examples, the memory device profile query operation can be associated with determining a characteristic of the memory system 110 (e.g., a memory device of the memory system 110), such as an operating parameter (e.g., a power level, a size of the memory system 110, an available storage space of the memory system 110). In some implementations, performing the memory device profile query operation can include accessing one or more memory arrays (e.g., or one or more registers) of the memory system 110. In other implementations, performing the memory device profile query operation can not include accessing the one or more memory arrays.

[0077] In other examples, the operations can include memory device provisioning operations, such as UIC operations. In some such examples, the memory device provisioning operations can be associated with setting operational parameters (e.g., register information) or transmitting operational instructions to one or more controllers of the memory system 110. In some implementations, performing the memory device provisioning operations can not include accessing one or more memory arrays. In some examples, the operations can include memory device access operations, such as read operations or write operations. In some such examples, the memory device access operations can be associated with accessing one or more memory arrays. In some implementations, when the memory device access operation is a read operation, performing the memory device access operation can include reading information from one or more memory cells of one or more memory arrays and transmitting the information (e.g., to the host system 105, to another memory device). In some implementations, when the memory device access operation is a write operation, performing the memory device access operation can include writing information to one or more memory cells. The memory device access operations can include address information associated with accessing the memory system 110 and / or data to be accessed (e.g., read or written).

[0078] At 315, the bootloader 107 can identify commands associated with performing a boot procedure for the memory system 110. The commands can be associated with the operations identified at step 310 of the process flow 300. For example, the commands can be memory device configuration file query commands, such as UFS query commands, corresponding to memory device configuration file query operations. Likewise, the commands can be memory device provisioning commands, such as UFS UIC commands, corresponding to memory device provisioning operations. Further, the commands can be access commands, such as read commands or write commands, corresponding to memory device access operations. In some examples, identifying the commands can include identifying a number of each type of command associated with performing the boot procedure. For example, identifying the commands can include identifying a number of memory device configuration file query commands, a number of memory device provisioning commands, and a number of access commands. In some examples, identifying the commands can include identifying a size of each type of command, such that the size can indicate a size of each command of a certain number of commands of each type of command.

[0079] At 320, the boot loader 107 can allocate a buffer for the commands identified at step 315 of the process flow 300. That is, the boot loader 107 can allocate a buffer for the boot commands corresponding to the operations associated with performing the boot procedure on the memory system 110. The buffer can be a packet associated with the commands. In some cases, the buffer can be a physical storage space (e.g., local memory) of the host system 105. In other cases, the buffer can be a command descriptor transmitted from the host system 105 to the memory system 110, such as a UFS UPIU. In some examples, the buffer can be allocated based on the number of commands identified at step 315 of the process flow 300. For example, the boot loader 107 can identify the number of commands, identify a size corresponding to the number of commands, and allocate a size of the buffer based on the size corresponding to the number of commands.

[0080] In some cases, the boot loader 107 can select a type of command associated with the buffer. That is, the buffer can be configured to store a single type of command, such that after identifying the commands associated with performing the boot procedure, the boot loader 107 can select a type of command for the buffer. For example, the boot loader 107 can select a memory device configuration file query command for the buffer, and the boot loader 107 can allocate the buffer based on selecting the memory device configuration file query command. That is, the boot loader 107 can identify a number of memory device configuration file query commands and a size associated with the number, and then the boot loader 107 can allocate a buffer (e.g., a size of the buffer) based on the size. In some cases, the boot loader 107 can allocate multiple buffers, such that each type of command is allocated a particular buffer.

[0081] At 325, the boot loader 107 can load the commands associated with performing the boot procedure to the buffer. After allocating the buffer based on the commands, the boot loader 107 can load the commands to the buffer. If the buffer is configured to store a single type of command, then the boot loader 107 can load the commands selected for the buffer during allocation to load to the buffer. For example, when the buffer is allocated for storing memory device configuration file query commands, at 325, the boot loader 107 can load the memory device configuration file query commands to the buffer. In some cases, loading the buffer can generate a packet associated with the buffer. That is, the buffer can be a message including each of the commands loaded to the buffer. In some cases, loading the buffer can include generating a command descriptor, such as a UPIU, including fields indicating a type of the commands and the commands associated with the buffer.

[0082] At 330, the boot loader 107 can transmit an indication of the buffer to the host command manager 108 based on loading the buffer. For example, the boot loader 107 can transmit the buffer as a message to the host command manager 108, where the message includes the command loaded into the buffer. In other examples, the boot loader 107 can transmit an indication that the buffer has been loaded to the host command manager 108. In some cases, transmitting the indication of the buffer to the host command manager 108 can include the host command manager 108 accessing the buffer. For example, the host command manager 108 can access the buffer stored by the boot loader 107. In some such examples, the host command manager 108 can access the command loaded into the buffer. In other examples, the host command manager 108 can access the buffer received in the message, which can include accessing the command included in the message (e.g., based on loading the command into the buffer).

[0083] At 335, the host command manager 108 can transmit the command message to the memory system 110 via the memory physical connection interface 301. In some cases, the memory system 110 can receive the command message via the memory system controller 115 (e.g., via a UFS interface). The command message can be a unified command transmission, and can include each of the commands transmitted as part of the buffer. That is, each unified command transmission can include a single type of command based on the buffer being associated with the single type of command. For example, the unified command transmission can include a memory device profile query command loaded into the buffer based on a memory device profile query command. In some cases, the unified command transmission can be transmitted as a command descriptor (e.g., a UFS UPIU) to the memory system 110 via the memory physical connection interface 301. That is, the unified command transmission can include fields indicating the type of command and a quantity of commands associated with the buffer.

[0084] At 340, the memory system 110 can determine whether to access one or more memory arrays of the memory system 110 based on the command message. For example, some memory device profile query commands and access commands can be associated with accessing one or more memory arrays, while some memory device profile query commands and memory device provisioning commands can not be associated with accessing one or more memory arrays. The memory system 110 can determine the type of command associated with the command message, and then determine whether the type of command is associated with accessing one or more memory arrays. For example, the memory system 110 can identify that the type of command associated with the command message is a memory device profile query command, and the memory system 110 can determine whether to access a memory array based on details of the memory device profile query command. In some cases, determining the type of command can include identifying the type of command from fields of a command descriptor (e.g., a UFS UPIU).

[0085] At 345, the memory system 110 can perform operations associated with the commands received as part of the command message. That is, if the command message indicates a number of memory device profile query commands, performing the command operations can include performing a number of memory device profile query operations. Likewise, if the command message indicates a number of memory device provisioning commands, performing the command operations can include performing a number of memory device provisioning operations. Further, if the command message indicates a number of memory device access commands, performing the command operations can include performing a number of memory device access operations. In some cases, performing the command operations can include changing a power level of the memory system 110 from an initial power level to an operational power level (e.g., enabling one or more power supplies) or changing a processing level of the memory system 110 from an initial processing level to an operational processing level. In some cases, performing operations associated with the boot program can be facilitated by the memory system controller 115 or a local controller of the memory devices. In some cases, performing operations associated with the boot program can be facilitated by a UFS interface in the memory system controller 115. In some cases, the memory system 110 can determine to access one or more memory arrays at step 340 of the process flow 300 based on the command message, thus performing the command operations can include accessing the one or more memory arrays. In other cases, the memory system 110 can determine not to access one or more memory arrays at step 340 of the process flow 300 based on the command message, thus performing the command operations can not include accessing the one or more memory arrays.

[0086] At 348, the memory system 110 can transmit a response to the unified command transmission. The response can be, for example, a UFS ready to transfer command descriptor indicating that the memory system 110 has information to provide to the host system 105 as a result of the command operations of the unified command transmission. The response transmitted at 348 can be associated with (e.g., can trigger) an interrupt of the host command manager 108 (e.g., a single interrupt associated with the unified command transmission). For example, the memory system 110 can perform all of the commands of the unified command transmission and use the response at 348 to indicate to the host system 105 that the commands of the unified command transmission have completed and that information associated with the commands is ready to be transferred.

[0087] At 350, the memory system 110 can transmit information associated with performing the command operations to the host command manager 108. In some cases, the information can be transmitted as a single message containing information associated with each operation (e.g., each command) in the command operations. In other cases, the information can be transmitted as a number of messages corresponding to a number of operations performed during the command operations, where each message contains information associated with a respective operation or region of memory addresses. In some examples, the information can be indications associated with completing operations in the command operations, such that each indication can represent completing a respective operation in the command operations. In other examples, the information can be information associated with the commands. For example, a memory device configuration file query command can request information about characteristics of the memory system 110 (e.g., memory devices of the memory system 110), such as operating parameters (e.g., power levels, size of the memory system 110, available storage space of the memory system 110), so the transmitted information can correspond to a response to such a command. In some examples, the information can be data associated with the commands. For example, a memory device access command (e.g., a read command) can request data from the memory system 110, so the transmitted information can be data associated with such a command. In some aspects, the information transmitted at 350 can use direct memory access (DMA). For example, the host system 105 (e.g., the host command manager 108) can allocate a memory region for the transfer of the information. In some cases, the host command manager 108 can specify DMA transfer parameters in a memory descriptor (e.g., a source (SRC) or destination (DST) descriptor). In some cases, the host command manager 108 can use a scatter-gather DMA mode, where a data transfer from one non-contiguous memory block can be performed using a series of smaller contiguous block transfers, where at least a subset of the series of smaller contiguous block transfers can be included in a single unified command transfer.

[0088] At 355, the host command manager 108 can transmit information associated with performing the command operations to the bootloader 107. In some cases, the information can be transmitted as a single message containing information associated with each operation (e.g., each command) of the bootloader. In other cases, the information can be transmitted as a number of messages corresponding to a number of operations performed during the bootloader, where each message contains information associated with a respective operation. In some examples, the information can be indications associated with completing operations of the bootloader, such that each indication can represent completing a respective operation of the bootloader. In other examples, the information can be information associated with the commands. In some examples, the information can be data associated with the commands.

[0089] In some cases, bootloader 107 may use information to verify the completion of the bootloader or to initiate other parts of the bootloader. For example, the operation associated with the information may be associated with the type of command indicated by the command message; however, it may not indicate all operations contained in the bootloader. Therefore, bootloader 107 may restart the bootloader for the next type of command. For example, process flow 300 may restart at step 310 for the remaining operations of the bootloader. In some cases, process flow 300 may restart a certain number of times (e.g., iterations) until the bootloader completes.

[0090] Implementing unified command transmission within process flow 300 can support improvements in latency and processing availability during bootstrap execution. For example, implementing unified command transmission allows a number of bootstrap commands and operations to be executed via a single system interrupt, thereby reducing the latency that would otherwise be associated with a number of system interrupts for a number of commands and operations. Similarly, a single system interrupt can provide additional processing availability for performing other operations during bootstrap execution.

[0091] It should be understood that Figure 3 The bootloader shown is an example of a unified command transmission using 335. The unified command transmission at 335 and the corresponding operation performed at 345 can be used for operations other than the bootloader described, which are used to send a single unified command corresponding to multiple commands executed at memory system 110, wherein the multiple commands are associated with a single response (e.g., a response message sent at 348).

[0092] Figure 4 Example of a command diagram 400 supporting unified command transfer of managed memory, based on the examples disclosed herein. Command diagram 400 may illustrate aspects or operations implemented by the system, which may serve as a reference. Figure 1 and 2 Examples of system 100 or system 200 are described respectively. For example, command diagram 400 can be found in reference... Figure 1 Or, as described in section 2, the host system 105 or 205 and memory system 110 or 210 are implemented. Similarly, command diagram 400 can illustrate the command messages implemented within process flow 300, as shown in reference... Figure 3 Description. Command diagram 400 may be an example of a command descriptor for unified command transmission, wherein a single message transmitted between host system 105 and memory system 110 may contain a number of commands corresponding to operations associated with the bootloader of memory system 110.

[0093] Command diagram 400 illustrates unified command transmission, which can be transmitted as a command descriptor (e.g., a UFS UPIU) 410 between host system 105 and memory system 110 via memory physical connection interface 310 (e.g., a UFS interface), as described with reference to FIG. 1. In some examples, command diagram 400 can be an example of a buffered message transmitted between a bootloader 107 (e.g., system startup software) implemented within host system controller 106 and host command manager 108, as described with reference to FIG. 1. In some such examples, the buffered message can be generated by bootloader 107. In other examples, command diagram 400 can be an example of a command message transmitted between host command manager 108 and memory system 110. In some such examples, the command message can be generated by bootloader 107 and initially transmitted as a buffered message to host command manager 108, or the command message can be generated by host command manager 108 based on receiving a buffered message from bootloader 107. Figure 3 Figure 1 In some examples, command diagram 400 can be an example of a buffered message transmitted between a bootloader 107 (e.g., system startup software) implemented within host system controller 106 and host command manager 108, as described with reference to FIG. 1. In some such examples, the buffered message can be generated by bootloader 107. In other examples, command diagram 400 can be an example of a command message transmitted between host command manager 108 and memory system 110. In some such examples, the command message can be generated by bootloader 107 and initially transmitted as a buffered message to host command manager 108, or the command message can be generated by host command manager 108 based on receiving a buffered message from bootloader 107.

[0094] Command diagram 400 illustrates a command descriptor 410 that includes a number of fields each associated with storing one or more bits. According to various aspects, the command descriptor can include a number of fields that identify aspects or characteristics of a unified command transmission. For example, command descriptor 410 can include a unified command transmission header 420, transaction specific fields 430, and an extended command field 435 each associated with one or more fields. Unified command transmission header 420 can include a field that indicates whether the command descriptor includes a unified command transmission. Transaction specific fields 430 can specify which kinds of commands are in extended command field 435. Extended command field 435 can include a command list. In one example, the command descriptor can correspond to a UFS UPIU, where the UPIU can include a field associated with unified command transmission header 420 that includes fields identifying: a transaction type of the UPIU, a flag of the UPIU, a logical unit number (LUN) of the UPIU, a query function of the UPIU, a task management function of the UPIU, a status of the UPIU, device information, an additional header segment length of the UPIU, a data segment length of the UPIU. Likewise, the UPIU can include a field associated with extended command field 435 that includes an additional header segment, a header end-to-end cyclic redundancy check (E2E CRC) bit, a data segment of the UPIU, and a data E2E CRC bit. In some such examples, the fields can include bits that indicate substantive information associated with the respective field, or the fields can include bits that indicate whether an operation associated with the respective field is supported.

[0095] ​Command map 400 illustrates a UPIU that includes a field that indicates a command setup type 425. The field that indicates the command setup type can be a field that includes an initiator identifier (IID) and a subspace for its use, where the command setup type 425 can be included in the subspace. For example, field "4" can include the IID and the command setup type 425. The command setup type 425 can indicate a type of command associated with the unified command transfer. That is, each UPIU can be associated with a number of commands that include the same type of command, and the command setup type 425 can indicate this same type of command. In some examples, the command setup type 425 can indicate that the number of commands are memory device configuration file query commands, memory device provisioning commands, or memory device access commands.

[0096] Command map 400 illustrates a command descriptor 410 that includes a number of fields that indicate each of a number of commands associated with the unified command transfer. For example, the command descriptor can include transaction specific fields 430 (e.g., fields 12 through 31), where each transaction specific field can identify a command of the unified command transfer. In some cases, the transaction specific fields 430 can be configured to store a header that indicates a number of commands. For example, each transaction specific field can store a header associated with a respective command of the number of commands. In some cases, the transaction specific fields can be used as a list of the number of commands.

[0097] Command map 400 illustrates a command descriptor that includes a number of fields dedicated to storing each of a number of commands associated with the unified command transfer. For example, the command descriptor can include additional header segments (e.g., fields k, k+1, k+2, k+3, where k is an integer; fields j, j+1, j+2, j+3, where j is an integer) as part of the extended command field 435, each configured to store a respective command of the number of commands. If the transaction specific fields are used as a list of the number of commands, the additional header segments can be used to store the commands themselves. For example, the additional header segments can store details associated with executing each of the commands (e.g., LBA address, block length).

[0098] Implementing the unified command transfer with a number of commands associated with a boot program can support latency and processing availability improvements during execution of the boot program. For example, implementing the unified command transfer can enable a number of commands and operations of the boot program to implement a single system interrupt, thereby reducing latency that would otherwise be associated with a number of system interrupts for the number of commands and operations. Likewise, the single system interrupt can provide additional processing availability for other operations to be performed during the boot program. Additionally or alternatively, the unified command transfer can be used to enable a number of commands that are executed outside of the boot program to be passed within a single unified command transfer (e.g., a single UPIU) of commands.

[0099] Figure 5 An example of a process flow 500 that supports unified command transfer for managed memory is shown in accordance with the examples disclosed herein. The process flow 500 can illustrate aspects of, or operations of, a system, which can be an example of the system 100 or the system 200 described with reference to Figure 1 and 2 respectively. For example, the process flow 500 can be implemented by the host system 105 or 205 and the memory system 110 or 210 described with reference to Figure 1 or 2. Further, some of the processes or operations of the process flow 500 can be implemented by the host system controller 106 including the bootloader 107 (e.g., system startup software) and the host command manager 108 described with reference to Figure 1 The process flow 500 illustrates operations associated with performing a boot procedure for the system 100 based on unified command transfer.

[0100] In the following description of the process flow 500, the methods, techniques, processes, and operations can be performed in different orders or at different times. Further, some operations can be excluded from the process flow 500, or other operations can be added to the process flow 500. Additionally or alternatively, aspects of the process flow 500 can be implemented as instructions (e.g., firmware) stored in a memory. For example, the instructions, when executed by a controller (e.g., a processor, the host system controller 106, the memory system controller 115, the local controller 135) can cause the controller to perform the operations of the process flow 500.

[0101] At 505, the host system controller 106 can identify commands associated with performing a boot procedure for the memory system 110. For example, the bootloader 107 can identify operations associated with performing a boot procedure and commands corresponding to the identified operations. In some such examples, the bootloader 107 can identify a type of each command identified. That is, for each command, the bootloader 107 can determine whether the command is a memory device configuration file query command (e.g., a UFS query command), a memory device provisioning command (e.g., a UIC command), or a memory device access command (e.g., a read command, a write command).

[0102] At 510, the host system controller 106 can group commands of the same type. For example, after identifying the type of each command, the bootloader 107 can determine a number of commands in each type of command. That is, the bootloader 107 can determine a number of memory device profile query commands, a number of memory device provisioning commands, and a number of memory device access commands. After determining the number of each type of command, the bootloader 107 can group the commands such that each command is grouped with other commands of the same type. For example, a number of memory device profile query commands can be grouped, a number of memory device provisioning commands can be grouped, and a number of memory device access commands can be grouped.

[0103] After grouping the commands into groups of the same type, the host system controller 106 can assemble one or more unified command transmissions. For example, the bootloader 107 can assemble the commands of each group into a respective unified command transmission, which can include the commands associated with the group. In some cases, assembling one or more unified command transmissions can include allocating one or more buffers, where each buffer is associated with a respective group. In some such cases, assembling one or more unified command transmissions can include loading the commands of the respective group into each of the one or more buffers. In other cases, the host command manager 108 can access the buffers (e.g., receive the buffers from the bootloader 107) and assemble one or more unified command transmissions. For example, the host command manager 108 can generate a UPIU indicating each unified command transmission and transmit the UPIU to the memory system 110 via the memory physical connection interface 301, as described with reference to FIG. 2. Figure 3

[0104] ​At 515, the memory system 110 can determine whether to access one or more memory arrays of the memory system 110 based on the one or more unified command transmissions. That is, the memory system controller 115 can receive the one or more unified command transmissions, and the memory system controller 115 can determine the type of command associated with each unified command transmission. After identifying the type of command included in each unified command transmission, the memory system controller 115 can determine whether the type of command is associated with accessing one or more memory arrays. For example, a memory device configuration file query command can or can not be associated with accessing one or more memory arrays. In some such examples, the memory system controller 115 can identify other details associated with the memory device configuration file query command to determine whether the unified command transmission indicates accessing one or more memory arrays. In other examples, a memory device provisioning command can be associated with not accessing one or more memory arrays. In some examples, a memory device access command can be associated with accessing one or more memory arrays. In some cases, the memory system 110 can determine that the type of command corresponding to the one or more unified command transmissions is associated with accessing one or more memory arrays, and the process flow 500 can continue to step 520. However, in other cases, the memory system 110 can determine that the type of command corresponding to the one or more unified command transmissions is associated with not accessing one or more memory arrays, and the process flow 500 can continue to step 525.

[0105] At 520, the memory system 110 can access one or more memory arrays as part of executing a boot program. That is, the memory system 110 can access one or more memory arrays to access data in the one or more memory arrays. For example, the memory system 110 can identify that the unified command transmission is associated with a number of write commands, and the memory system 110 can write data associated with the number of write commands to the one or more memory arrays. In other examples, the memory system 110 can identify that the unified command transmission is associated with a number of read commands, and the memory system 110 can read data associated with the number of read commands from the one or more memory arrays. In some examples, the memory system 110 can identify that the unified command transmission is associated with a number of memory device configuration file query commands (e.g., a UFS query command requesting an indication of available storage capacity of the one or more memory arrays), and the memory system 110 can access the one or more memory arrays to determine the available storage capacity of the one or more memory arrays. In some cases, accessing the one or more memory arrays can include performing a direct memory access (DMA). In some such cases, accessing the one or more memory arrays can include identifying mapping information associated with the one or more memory arrays.

[0106] At 525, the memory system 110 can not access the one or more memory arrays as part of executing the boot program. That is, the memory system 110 can perform operations associated with the boot program without accessing the one or more memory arrays. For example, the memory system 110 can identify that the unified command transport is associated with a quantity of memory device configuration file query commands (e.g., UFS query commands requesting an indication of a power level of the memory system 110) and the memory system 110 can not access the one or more memory arrays to identify the power level. In some such examples, the memory system 110 can identify the power level based on detecting information from one or more sensors at the memory system 110. In other examples, the memory system 110 can identify that the unified command transport is associated with a quantity of memory device provisioning commands (e.g., UIC commands) and the memory system 110 can perform one or more UIC operations without accessing the one or more memory arrays.

[0107] In some cases, the memory system 110 can transmit information back to the host system 105 after accessing or not accessing the one or more memory arrays. For example, the memory system 110 can transmit information including data or completion indications back to the host system 105, where the data or indications correspond to each command associated with the unified command transport. In some examples, the memory system 110 can transmit the information as a single message to the host system 105.

[0108] Implementing the unified command transport within the process flow 500 can support latency and processing availability improvements during execution of the boot program. For example, implementing the unified command transport can enable a single system interrupt for a quantity of commands and operations of the boot program, thereby reducing latency otherwise associated with a quantity of system interrupts for the quantity of commands and operations. Likewise, the single system interrupt can provide additional processing availability for performing other operations during the boot program.

[0109] Figure 6 A block diagram 600 of a host device 620 that supports unified command transport for managed memory in accordance with examples as disclosed herein is shown. The host device 620 can be an example of aspects of the host devices described with reference to Figures 1 to 5 Examples of aspects of the host device described. The host device 620, or various components thereof, can be examples of means for performing various aspects of unified command transport for managed memory, as described herein. For example, the host device 620 can include a transmission component 625, a reception component 630, or any combination thereof. Each of these components, or components thereof (e.g., one or more processors, one or more memories), can communicate, directly or indirectly, with one another (e.g., via one or more buses).

[0110] The transmission component 625 can be configured as or otherwise support a means for transmitting, to a memory device, a first message including a plurality of commands, where the first message includes a field indicating a type of the plurality of commands, and where each command of the plurality of commands is a memory device configuration file query command or a memory device provisioning command. The reception component 630 can be configured as or otherwise support a means for receiving, from the memory device, one or more second messages including information for each command of the plurality of commands based at least in part on transmitting the first message.

[0111] In some examples, the reception component 630 can be configured as or otherwise support a means for receiving, from the bootloader, an indicator of a buffer including the plurality of commands, where transmitting the first message to the memory device is based at least in part on receiving the indicator from the bootloader.

[0112] In some examples, the transmission component 625 can be configured as or otherwise support a means for providing the information to the bootloader based at least in part on receiving the one or more second messages from the memory device.

[0113] In some examples, the first message indicates that the memory device accesses a respective portion of one or more memory arrays of the memory device for each command of the plurality of commands.

[0114] In some examples, the first message is a single memory device command. In some examples, the plurality of commands is included in an additional header segment portion of the single memory device command.

[0115] In some examples, the transmission component 625 can be configured as or otherwise support a means for transmitting, to the memory device, a third message including a plurality of second commands, where the third message includes a field indicating a type of the plurality of second commands, where each second command of the plurality of second commands is a read command or a write command. In some examples, the reception component 630 can be configured as or otherwise support a means for receiving, from the memory device, one or more fourth messages including data for each second command of the plurality of second commands based at least in part on transmitting the third message.

[0116] In some examples, transmitting the first message including the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

[0117] In some examples, the information associated with each command includes query response information or interconnect response information.

[0118] In some examples, the described functionality of the host device 620, or various components thereof, can be supported by, or can be directed to, at least a portion of at least one processor, which can include one or more processing elements (e.g., a controller, a microprocessor, a microcontroller, a digital signal processor, a state machine, discrete gate logic, discrete transistor logic, discrete hardware components, or any combination thereof). In some examples, the described functionality of the host device 620, or various components thereof, can be implemented, at least in part, by instructions executable by this at least one processor (e.g., stored in a memory, a non-transitory computer readable medium).

[0119] Figure 7 A block diagram 700 showing a memory device 720 supporting unified command transfer for managed memory in accordance with the examples disclosed herein is shown. The memory device 720 can be an example of the memory device described with reference to Figures 1 to 5 Examples of aspects of the described memory device. The memory device 720, or various components thereof, can be examples of means for performing various aspects of unified command transfer for managed memory, as described herein. For example, the memory device 720 can include a receiving component 725, a transmitting component 730, an operating component 735, a queue component 740, or any combination thereof. Each of these components, or components of subcomponents thereof (e.g., one or more processors, one or more memories), can communicate, directly or indirectly, with one another (e.g., via one or more buses).

[0120] The receiving component 725 can be configured as, or otherwise support, a means for receiving, from a host device, a first message including a plurality of commands, where the first message includes a field indicating a type of the plurality of commands, and where each command of the plurality of commands is a memory device configuration file query command or a memory device provisioning command. The transmitting component 730 can be configured as, or otherwise support, a means for transmitting, to the host device, one or more second messages including information associated with each command of the plurality of commands based at least in part on receiving the first message.

[0121] In some examples, the operating component 735 can be configured as, or otherwise support, a means for performing a plurality of operations corresponding to the plurality of commands based at least in part on receiving the first message, where transmitting the one or more second messages is based at least in part on performing the plurality of operations.

[0122] In some examples, the information associated with each command includes query response information or interconnect response information.

[0123] In some examples, to support performing multiple operations, the queue component 740 can be configured as or otherwise support a means for placing, based at least in part on receiving the first message, a single bundled command corresponding to the multiple commands into the command queue for execution, the single bundled command corresponding to a single response to the host device.

[0124] In some examples, the operation component 735 can be configured as or otherwise support a means for accessing, for each command of the multiple commands, a respective portion of one or more memory arrays of the memory device, where transmitting the one or more second messages is based at least in part on accessing the respective portion of the one or more memory arrays for each command of the multiple commands.

[0125] In some examples, the information associated with each command includes data associated with accessing a respective portion of one or more memory arrays for a respective command of the multiple commands.

[0126] In some examples, the first message is a single memory device command. In some examples, the multiple commands are included in an additional header segment portion of the single memory device command.

[0127] In some examples, the receive component 725 can be configured as or otherwise support a means for receiving, from a host device, a third message including a plurality of second commands, where the third message includes a field indicating a type of the plurality of second commands, and where each second command of the plurality of second commands is a read command or a write command. In some examples, the transmit component 730 can be configured as or otherwise support a means for transmitting, based at least in part on receiving the third message, one or more fourth messages including data associated with each second command of the plurality of second commands to the host device.

[0128] In some examples, the operation component 735 can be configured as or otherwise support a means for accessing, for each second command of the plurality of second commands, a respective portion of one or more memory arrays of the memory device, where transmitting the one or more fourth messages is based at least in part on accessing the respective portion of the one or more memory arrays for each second command of the plurality of second commands.

[0129] In some examples, receiving the first message including the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

[0130] In some examples, the described functionality of the memory device 720, or various components thereof, can be supported by, or can be directed to, at least a portion of at least one processor, where the at least one processor can include one or more processing elements (e.g., a controller, a microprocessor, a microcontroller, a digital signal processor, a state machine, discrete gate logic, discrete transistor logic, discrete hardware components, or any combination of one or more of such elements). In some examples, the described functionality of the memory device 720, or various components thereof, can be implemented at least in part by instructions (e.g., stored in a memory, a non-transitory computer-readable medium) that can be executed by the at least one processor.

[0131] Figure 8 A block diagram 800 showing a bootloader 820 that supports unified command transfer for managed memory in accordance with the examples disclosed herein. The bootloader 820 can be an example of a bootloader whose aspects are described with reference to Figures 1 to 5 The bootloader 820, or various components thereof, can be an example of means for performing various aspects of unified command transfer for managed memory as described herein. For example, the bootloader 820 can be system startup software associated with operations to perform a system boot phase (e.g., system startup), and can include components such as a bootloader, a system kernel startup, and an application or system library loading. The bootloader 820 can include an allocation component 825, a loading component 830, a transfer component 835, a receiving component 840, an identification component 845, or any combination thereof. Each of these components, or components of subcomponents thereof (e.g., one or more processors, one or more memories), can communicate, directly or indirectly, with one another (e.g., via one or more buses).

[0132] The allocation component 825 can be configured as or otherwise support a means for allocating a buffer for a plurality of commands, where each command of the plurality of commands includes a same type of command. The loading component 830 can be configured as or otherwise support a means for loading the plurality of commands into the buffer. The transfer component 835 can be configured as or otherwise support a means for providing, to a host command manager, a message including an indication of the buffer based at least in part on loading the plurality of commands into the buffer. The receiving component 840 can be configured as or otherwise support a means for obtaining, from the host command manager, information associated with each of the plurality of commands.

[0133] In some examples, the identification component 845 can be configured as or otherwise support a means for identifying a plurality of operations associated with a boot program, where the plurality of commands correspond to the plurality of operations, where allocating the buffer for the plurality of commands is based at least in part on identifying the plurality of operations.

[0134] In some examples, the identifying component 845 can be configured as or otherwise support a means for identifying a power level change associated with the bootloader, where allocating the buffer for the plurality of commands is based at least in part on identifying the power level change associated with the bootloader.

[0135] In some examples, the identifying component 845 can be configured as or otherwise support a means for identifying a number of commands in the plurality of commands. In some examples, the identifying component 845 can be configured as or otherwise support a means for identifying a size of the buffer based at least in part on identifying the number of commands, where allocating the buffer for the plurality of commands is based at least in part on identifying the size of the buffer.

[0136] In some examples, the type of command includes a memory device configuration file query command or a memory device provisioning command.

[0137] In some examples, the type of command includes a read command or a write command.

[0138] In some examples, the message includes a field indicating a type of command in the plurality of commands.

[0139] In some examples, the described functionality of the bootloader 820, or various components thereof, can be supported by or can refer to at least a portion of at least one processor, which can include one or more processing elements (e.g., a controller, a microprocessor, a microcontroller, a digital signal processor, a state machine, discrete gate logic, discrete transistor logic, discrete hardware components, or any combination thereof). In some examples, the described functionality of the bootloader 820, or various components thereof, can be implemented at least in part by instructions (e.g., stored in memory, on a non-transitory computer readable medium) that can be executed by the at least one processor.

[0140] Figure 9 A flow diagram illustrating a method 900 that supports unified command transfer for managed memory is shown, and in accordance with the examples as disclosed herein. The operations of method 900 can be implemented by a host device or its components as described herein. For example, the operations of method 900 can be performed by a host device as described with reference to FIGS. 1-8 and 10-11, by the host device 1000 as described with reference to FIG. 12, by the host device 1200 as described with reference to FIG. 13, or by a processor or processor component of a host device. Figures 1 to 6 The described host device can execute a set of instructions that are stored in non-transitory media of the host device (for example, RAM, ROM, PROM, EEPROM, flash memory, etc.), in order to control the functional elements of the device to perform the actions described. Additionally or alternatively, the host device can perform aspects of the described functions using special-purpose hardware.

[0141] At 905, the method can include transmitting a first message including a plurality of commands to a memory device, where the first message includes a field indicating a type of the plurality of commands, and where each command of the plurality of commands is a memory device profile query command or a memory device provisioning command. In some examples, aspects of the operation 905 can be performed by a transmitting component 625 as described herein. Figure 6 The transmitting component 625 described above can perform.

[0142] At 910, the method can include receiving one or more second messages including information for each command of the plurality of commands from the memory device based at least in part on transmitting the first message. In some examples, aspects of the operation 910 can be performed by a receiving component 630 as described herein. Figure 6 The receiving component 630 described above can perform.

[0143] In some examples, the apparatuses described herein can perform one or more methods, such as the method 900. An apparatus can include features, circuitry, logic, means, or instructions (such as a non-transitory computer-readable medium storing instructions that can be executed by a processor) for performing the following aspects of the disclosure, or any combination thereof:

[0144] Aspect 1 : A method, apparatus, or non-transitory computer-readable medium including operations, features, circuitry, logic, means, or instructions for, or any combination thereof: transmitting a first message including a plurality of commands to a memory device, where the first message includes a field indicating a type of the plurality of commands, and where each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and receiving one or more second messages including information for each command of the plurality of commands from the memory device based at least in part on transmitting the first message.

[0145] Aspect 2: The method, apparatus, or non-transitory computer-readable medium of aspect 1, further including operations, features, circuitry, logic, means, or instructions for, or any combination thereof: receiving an indicator of a buffer including the plurality of commands from a bootloader, where transmitting the first message to the memory device is based at least in part on receiving the indicator from the bootloader.

[0146] Aspect 3: The method, apparatus, or non-transitory computer-readable medium of any of aspects 1 -2, further including operations, features, circuitry, logic, means, or instructions for, or any combination thereof: providing the information to a bootloader based at least in part on receiving the one or more second messages from the memory device.

[0147] Aspect 4: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 1-3, wherein the first message indicates that the memory device is to access a respective portion of one or more memory arrays of the memory device for each command of the plurality of commands.

[0148] Aspect 5: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 1-4, wherein the first message is a single memory device command and the plurality of commands are included in an additional header segment portion of the single memory device command.

[0149] Aspect 6: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 1-5, further including operations, features, circuitry, logic, means, or instructions for, or any combination thereof: transmitting a third message including a plurality of second commands to the memory device, wherein the third message includes the field indicating the type of the plurality of second commands, wherein each second command of the plurality of second commands is a read command or a write command; and receiving one or more fourth messages including data for each second command of the plurality of second commands from the memory device based at least in part on transmitting the third message.

[0150] Aspect 7: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 1-6, wherein transmitting the first message including the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

[0151] Aspect 8: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 1-7, wherein the information associated with each command includes query response information or interconnect response information.

[0152] Figure 10 A flow diagram illustrating a method 1000 of supporting unified command transmission of managed memory in accordance with the examples as disclosed herein is shown. The operations of method 1000 can be implemented by a memory device or its components as described herein. For example, the operations of method 1000 can be performed by the memory device as described with reference to FIGS. 1-7. Figures 1 to 5 In some examples, a set of instructions can be used to control the functional elements of the memory device to perform the described functions. Additionally or alternatively, the memory device can use special-purpose hardware to perform aspects of the described functions.

[0153] At 1005, the method can include receiving a first message including a plurality of commands from a host device, wherein the first message includes a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device configuration file query command or a memory device provisioning command. In some examples, aspects of the operation 1005 can be performed by the command interface 210 as described with reference to FIGS. 1-7.Figure 7 The described receiving component 725 performs the operations.

[0154] At 1010, the method can include transmitting, to the host device, one or more second messages including information associated with each command of the plurality of commands based at least in part on receiving the first message. In some examples, aspects of the operations 1010 can be performed by a receiving component 725 as described with reference to FIG. 7. Figure 7 The described transmitting component 730 performs the operations.

[0155] In some examples, the apparatuses described herein can perform one or more methods, such as the method 1000. An apparatus can include features, circuitry, logic, means, or instructions (such as a non-transitory computer-readable medium storing instructions that are executable by a processor) for performing the following aspects of the present disclosure, or any combination thereof:

[0156] Aspect 9: A method, apparatus, or non-transitory computer-readable medium including operations, features, circuitry, logic, means, or instructions for receiving, from a host device, a first message including a plurality of commands, where the first message includes a field indicating a type of the plurality of commands, and where each command of the plurality of commands is a memory device configuration file query command or a memory device provisioning command, and transmitting, to the host device, one or more second messages including information associated with each command of the plurality of commands based at least in part on receiving the first message, or any combination thereof.

[0157] Aspect 10: The method, apparatus, or non-transitory computer-readable medium of Aspect 9, further including operations, features, circuitry, logic, means, or instructions for performing a plurality of operations corresponding to the plurality of commands based at least in part on receiving the first message, where transmitting the one or more second messages is based at least in part on performing the plurality of operations.

[0158] Aspect 11: The method, apparatus, or non-transitory computer-readable medium of Aspect 10, where the information associated with each command includes query response information or interconnect response information.

[0159] Aspect 12: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 10-11, where performing the plurality of operations includes operations, features, circuitry, logic, means, or instructions for placing, into a command queue for execution, a single bundled command corresponding to the plurality of commands based at least in part on receiving the first message, the single bundled command corresponding to a single response to the host device.

[0160] Aspect 13: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 9-12, further comprising operations, features, circuitry, logic, means, or instructions for, or any combination thereof: accessing a respective portion of one or more memory arrays of a memory device for each command of the plurality of commands, wherein transmitting the one or more second messages is based at least in part on accessing the respective portion of the one or more memory arrays for each command of the plurality of commands.

[0161] Aspect 14: The method, apparatus, or non-transitory computer-readable medium of Aspect 13, wherein the information associated with each command includes data associated with accessing the respective portion of the one or more memory arrays for the respective command of the plurality of commands.

[0162] Aspect 15: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 9-14, wherein the first message is a single memory device command and the plurality of commands are included in an additional header segment portion of the single memory device command.

[0163] Aspect 16: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 9-15, further comprising operations, features, circuitry, logic, means, or instructions for, or any combination thereof: receiving, from the host device, a third message including a plurality of second commands, wherein the third message includes the field indicating the type of the plurality of second commands, and wherein each second command of the plurality of second commands is a read command or a write command; and transmitting, to the host device, one or more fourth messages including data associated with each second command of the plurality of second commands based at least in part on receiving the third message.

[0164] Aspect 17: The method, apparatus, or non-transitory computer-readable medium of Aspect 16, further comprising operations, features, circuitry, logic, means, or instructions for, or any combination thereof: accessing a respective portion of the one or more memory arrays of the memory device for each second command of the plurality of second commands, wherein transmitting the one or more fourth messages is based at least in part on accessing the respective portion of the one or more memory arrays for each second command of the plurality of second commands.

[0165] Aspect 18: The method, apparatus, or non-transitory computer-readable medium of any of Aspects 9-17, wherein receiving the first message including the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

[0166] Figure 11A flow diagram illustrating a method 1100 of supporting unified command transfer of managed memory in accordance with examples as disclosed herein is shown. The operations of method 1100 can be implemented by a boot loader or its components as described herein. For example, the operations of method 1100 can be performed by a boot loader as described with reference to Figures 1 to 5 FIGS. 1 through 8. In some examples, a boot loader can execute a set of instructions to control the functional elements of a device to perform the described functions. Additionally or alternatively, the boot loader can use special-purpose hardware to perform aspects of the described functions.

[0167] At 1105, the method can include allocating a buffer for a plurality of commands, where each command of the plurality of commands includes a same type of command. In some examples, aspects of the operation 1105 can be performed by an allocation component 825 as described with reference to Figure 8 FIGS. 1 through 8.

[0168] At 1110, the method can include loading the plurality of commands into the buffer. In some examples, aspects of the operation 1110 can be performed by a loading component 830 as described with reference to Figure 8 FIGS. 1 through 8.

[0169] At 1115, the method can include providing a message including an indication of the buffer to a host command manager based at least in part on loading the plurality of commands into the buffer. In some examples, aspects of the operation 1115 can be performed by a transfer component 835 as described with reference to Figure 8 FIGS. 1 through 8.

[0170] At 1120, the method can include obtaining information associated with each of the plurality of commands from the host command manager. In some examples, aspects of the operation 1120 can be performed by a receiving component 840 as described with reference to Figure 8 FIGS. 1 through 8.

[0171] In some examples, the devices described herein can perform one or more methods, such as method 1100. A device can include features, circuitry, logic, means for performing aspects of the disclosure (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) or any combination thereof:

[0172] Aspect 19: A method, device, or non-transitory computer-readable medium including operations, features, circuitry, logic, means for, or instructions for, or any combination thereof, allocating a buffer for a plurality of commands, where each command of the plurality of commands includes a same type of command, loading the plurality of commands into the buffer, providing a message including an indication of the buffer to a host command manager based at least in part on loading the plurality of commands into the buffer, and obtaining information associated with each of the plurality of commands from the host command manager.

[0173] Aspect 20: The method, apparatus, or non-transitory computer-readable medium of aspect 19, further comprising operations, features, circuitry, logic, means, or instructions, or any combination thereof, for identifying a plurality of operations associated with a boot program, wherein the plurality of commands correspond to the plurality of operations, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the plurality of operations.

[0174] Aspect 21 : The method, apparatus, or non-transitory computer-readable medium of any of aspects 19-20, further comprising operations, features, circuitry, logic, means, or instructions, or any combination thereof, for identifying a power level change associated with a boot program, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the power level change associated with the boot program.

[0175] Aspect 22: The method, apparatus, or non-transitory computer-readable medium of any of aspects 19-21, further comprising operations, features, circuitry, logic, means, or instructions, or any combination thereof, for identifying a number of commands in the plurality of commands; and identifying a size of the buffer based at least in part on identifying the number of commands, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the size of the buffer.

[0176] Aspect 23: The method, apparatus, or non-transitory computer-readable medium of any of aspects 19-22, wherein the type of command comprises a memory device profile query command or a memory device provisioning command.

[0177] Aspect 24: The method, apparatus, or non-transitory computer-readable medium of any of aspects 19-23, wherein the type of command comprises a read command or a write command.

[0178] Aspect 25: The method, apparatus, or non-transitory computer-readable medium of any of aspects 19-24, wherein the message comprises a field indicating the type of command in the plurality of commands.

[0179] It should be noted that the described techniques include possible implementation ways and that the operations and the steps can be rearranged or otherwise modified and that other implementations are possible. Furthermore, portions from two or more of the methods can be combined.

[0180] Information and signals described herein can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, or symbols, which can be referenced throughout the above description, can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some drawings can illustrate signals as single signals; however, such signals can represent a bus of signals, where the bus can have a variety of bit widths.

[0181] The terms "in electronic communication," "in conductive contact," "connected," and "coupled" can refer to a relationship between components in which a signal flow between the components is supported. Components are considered to be in electronic communication (or in conductive contact or connected or coupled) with one another if there exists any conductive path between the components that can support a signal flow between the components at any time. The conductive path between components that are in electronic communication (or in conductive contact or connected or coupled) with one another at any given time can be an open circuit or a closed circuit based on the operation of the device that includes the connected components. The conductive path between connected components can be a direct conductive path between the components, or the conductive path between connected components can be an indirect conductive path that can include intervening components such as switches, transistors, or other components. In some examples, the signal flow between connected components can be interrupted for a period of time, for example, using one or more intervening components such as switches or transistors.

[0182] The term "coupled" (e.g., "electrically coupled") can refer to a condition from an open circuit relationship between components in which a signal cannot presently pass between the components through a conductive path to a closed circuit relationship between the components in which a signal can pass between the components through a conductive path. If a component, for example, a controller, couples other components together, the component causes a change that allows a signal to flow between the other components through a conductive path that previously did not permit signal flow.

[0183] The term "isolated" refers to a relationship between components in which a signal cannot presently flow between the components. If there is an open circuit between the components, the components are isolated from one another. For example, if a switch positioned between two components is open, the components separated by the switch are isolated from one another. If a controller isolates two components, the controller causes a change that prevents a signal from flowing between the components using a conductive path that previously permitted signal flow.

[0184] As used herein, the term "substantially" means that a modified property (e.g., a verb or adjective modified by the term "substantially") need not be absolute, but is close enough to the property to be economically or otherwise practically useful.

[0185] The terms “if’,” “when,” “based on,” or “based at least in part on” can be used interchangeably. In some examples, the terms “if’,” “when,” “based on,” or “based at least in part on” can be interchangeable if used to describe a conditional relationship, a causal relationship, or a part of a process between events or actions.

[0186] The term “in response to’ can refer to a condition or action occurring at least partially (if not entirely) as a result of a prior condition or action. For example, a first condition or action can be performed and a second condition or action can occur at least partially as a result of the prior condition or action occurring (whether directly after the first condition or action or after one or more other intervening conditions or actions after the first condition or action).

[0187] Devices discussed herein, including memory arrays, can be formed on a semiconductor substrate, such as silicon, germanium, silicon-germanium alloys, gallium arsenide, gallium nitride, etc. In some other examples, the substrate is a semiconductor wafer. In other examples, the substrate can be a silicon-on-insulator (SOI) substrate (such as silicon-on-glass (SOG) or silicon-on-sapphire (SOP)) or an epitaxial layer of semiconductor material on another substrate. The conductivity of the substrate, or sub-regions of the substrate, can be controlled by doping with various chemical species, including but not limited to phosphorus, boron, or arsenic. Doping can be performed by ion implantation or by any other doping method during initial formation or growth of the substrate.

[0188] Switching components or transistors discussed herein can represent field effect transistors (FETs) and include three-terminal devices including a source, a drain, and a gate. The terminals can be connected to other electronic elements by conductive materials, such as metals. The source and drain can be conductive and can include heavily doped (e.g., degenerate) semiconductor regions. The source and drain can be separated by a lightly doped semiconductor region or channel. If the channel is n-type (i.e., the majority carriers are electrons), the FET can be referred to as an n-type FET. If the channel is p-type (i.e., the majority carriers are holes), the FET can be referred to as a p-type FET. The channel can be covered by an insulating gate oxide. The channel conductivity can be controlled by applying a voltage to the gate. For example, applying a positive or negative voltage to an n-type or p-type FET, respectively, can cause the channel to become conductive. A transistor can be “turned on” or “activated” if a voltage greater than or equal to the threshold voltage of the transistor is applied to the transistor gate. A transistor can be “turned off’ or “deactivated” if a voltage less than the threshold voltage of the transistor is applied to the transistor gate.

[0189] The description set forth herein describes example configurations and does not represent all of the possible configurations that can be implemented or that are within the scope of the claims. The term "exemplary" used herein means "serving as an example, instance, or illustration," and not "preferred" or "superior" to other examples. The detailed description includes specific details for the purpose of providing an understanding of the described techniques. These techniques, however, can be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts described herein.

[0190] In the appended figures, similar components or features can have similar reference labels. Further, various components of the same type can be distinguished by adding a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the detail can be applicable to any one of the similar components with the same first reference label irrespective of the second reference label.

[0191] The functions described herein can be implemented in hardware, software executed by a processing system (e.g., one or more processors, one or more controllers, control circuitry, processing circuitry, logic circuitry), firmware, or any combination thereof. If implemented in software executed by a processing system, the functions can be stored on or transmitted over as one or more instructions (e.g., code) on a computer-readable medium. The functions described herein can be implemented using software, hardware, firmware, hardwiring, or a combination of any of these methods and approaches. Features described herein can be physically located in various places, including being distributed such that portions of functions are implemented at different physical locations.

[0192] The illustrative blocks and modules described herein can be implemented or performed with one or more processors (e.g., DSPs, ASICs, FPGAs, discrete logic, discrete transistor logic, discrete hardware components, other programmable logic devices, or any combination thereof) designed to perform the functions described herein. A processor can be an example of a microprocessor, controller, microcontroller, state machine, or other types of processor. A processor can also be implemented as at least one of a plurality of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0193] As used herein, including in the claims, “or” as used in a list of items (for example, the phrase “at least one of A, B, or C”) indicates an inclusive list such that, for example, the list means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an exemplary step that is described as “based on condition A” can be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on.”

[0194] As used herein, including in the claims, the indefinite articles “a” and “an” are intended to be construed as “at least one” of the items or “one or more” of the items. Thus, the terms “a,” “at least one,” “one or more,” “at least one of the one or more,” and the like can be used interchangeably. For example, if a claim recites “a component,” then the individual functions of the component can be performed by a single component or any combination of components. Thus, the term “a component” that has specific properties or performs a specific function can refer to “at least one” or “one or more” of the components that have the specific properties or perform the specific function. A subsequent use of the term “the” to refer back to the component initially introduced by a definite article can refer to any one of or all of the “one or more” components. For example, a component initially introduced by a definite article can be understood to mean “one or more components,” and a subsequent claim referring back to “the component” can be understood to mean “at least one” of the “one or more components.” Similarly, a subsequent use of the term “the” to refer back to a component initially introduced by “one or more” can refer to any one of or all of the “one or more” components. For example, a subsequent claim referring back to “the one or more components” can be understood to mean “at least one” of the “one or more components.”

[0195] Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium can be any available medium or combination of media that can be accessed by a computer. By way of example, and not limitation, non-transitory computer-readable media can include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), optical disk storage, magnetic disk storage, or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program elements in the form of instructions or data structures and that can be accessed by a computer or one or more processors. Also, substantially similar to the above, a communication medium can include wired communications, wireless communications, optical communications, or any other desirable communication media.

[0196] The description herein is presented to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A host device, comprising: processing circuitry associated with one or more memory devices and configured to cause the host device to: transmit a first message comprising a plurality of commands to a memory device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and receive one or more second messages comprising information for each command of the plurality of commands from the memory device based at least in part on transmitting the first message.

2. The host device of claim 1, wherein the processing circuitry is further configured to cause the host device to: receive an indicator of a buffer comprising the plurality of commands from a bootloader, wherein transmitting the first message to the memory device is based at least in part on receiving the indicator from the bootloader.

3. The host device of claim 1, wherein the processing circuitry is further configured to cause the host device to: provide the information to a bootloader based at least in part on receiving the one or more second messages from the memory device.

4. The host device of claim 1, wherein the first message indicates that the memory device accesses a respective portion of one or more memory arrays of the memory device for each command of the plurality of commands.

5. The host device of claim 1, wherein: the first message is a single memory device command, and the plurality of commands are included in an additional header segment portion of the single memory device command.

6. The host device of claim 1, wherein the processing circuitry is further configured to cause the host device to: transmit a third message comprising a plurality of second commands to the memory device, wherein the third message comprises the field indicating the type of the plurality of second commands, wherein each second command of the plurality of second commands is a read command or a write command; and receive one or more fourth messages comprising data for each second command of the plurality of second commands from the memory device based at least in part on transmitting the third message.

7. The host device of claim 1, wherein transmitting the first message comprising the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

8. The host device of claim 1, wherein the information associated with each command comprises query response information or interconnect response information.

9. A memory device, comprising: one or more memory arrays; and processing circuitry coupled with the one or more memory arrays and configured to cause the memory device to: receive a first message comprising a plurality of commands from a host device, wherein the first message comprises a field indicating a type of the plurality of commands, and wherein each command of the plurality of commands is a memory device profile query command or a memory device provisioning command; and transmitting one or more second messages comprising information associated with each of the plurality of commands to the host device based at least in part on receiving the first message.

10. The memory device of claim 9, wherein the processing circuitry is further configured to cause the memory device to: perform a plurality of operations corresponding to the plurality of commands based at least in part on receiving the first message, wherein transmitting the one or more second messages is based at least in part on performing the plurality of operations.

11. The memory device of claim 10, wherein the information associated with each command comprises query response information or interconnect response information.

12. The memory device of claim 10, wherein performing the plurality of operations comprises the processing circuitry configured to cause the memory device to: place a single bundled command corresponding to the plurality of commands into a command queue for execution based at least in part on receiving the first message, the single bundled command corresponding to a single response to the host device.

13. The memory device of claim 9, wherein the processing circuitry is further configured to cause the memory device to: access a respective portion of the one or more memory arrays of the memory device for each of the plurality of commands, wherein transmitting the one or more second messages is based at least in part on accessing the respective portion of the one or more memory arrays for each of the plurality of commands.

14. The memory device of claim 13, wherein the information associated with each command comprises data associated with accessing the respective portion of the one or more memory arrays for the respective one of the plurality of commands.

15. The memory device of claim 9, wherein: the first message is a single memory device command, and the plurality of commands are included in an additional header segment portion of the single memory device command.

16. The memory device of claim 9, wherein the processing circuitry is further configured to cause the memory device to: receive a third message comprising a plurality of second commands from the host device, wherein the third message comprises the field indicating the type of the plurality of second commands, and wherein each second command of the plurality of second commands is a read command or a write command; and transmit one or more fourth messages comprising data associated with each second command of the plurality of second commands to the host device based at least in part on receiving the third message.

17. The memory device of claim 16, wherein the processing circuitry is further configured to cause the memory device to: access a respective portion of the one or more memory arrays of the memory device for each second command of the plurality of second commands, wherein transmitting the one or more fourth messages is based at least in part on accessing the respective portion of the one or more memory arrays for each second command of the plurality of second commands.

18. The memory device of claim 9, wherein receiving the first message comprising the plurality of commands is based at least in part on initiating a boot procedure of the memory device.

19. A method at a boot loader, comprising: allocating a buffer for a plurality of commands, wherein each command of the plurality of commands comprises a same type of command; loading the plurality of commands into the buffer; providing a message comprising an indication of the buffer to a host command manager based at least in part on loading the plurality of commands into the buffer; and obtaining information associated with each of the plurality of commands from the host command manager.

20. The method of claim 19, further comprising: identifying a plurality of operations associated with a boot loader, wherein the plurality of commands correspond to the plurality of operations, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the plurality of operations.

21. The method of claim 19, further comprising: identifying a power level change associated with a boot loader, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the power level change associated with the boot loader.

22. The method of claim 19, further comprising: identifying a number of commands of the plurality of commands; and identifying a size of the buffer based at least in part on identifying the number of commands, wherein allocating the buffer for the plurality of commands is based at least in part on identifying the size of the buffer.

23. The method of claim 19, wherein the type of command comprises a memory device profile query command or a memory device provisioning command.

24. The method of claim 19, wherein the type of command comprises a read command or a write command.

25. The method of claim 19, wherein the message comprises a field indicating the type of command of the plurality of commands. ​

Citation Information

Cited By

  • Transmission efficiency improvement method and device, electronic equipment and storage medium

    CN121326254A